por Alejandro Cruz Rojas
¿De dónde vienen los microservicios?
La historia de los microservicios inicia con la arquitectura orientada a servicios (SOA) y ha evolucionado a lo largo de las últimas dos décadas. Tenemos algunos hitos relevantes en la historia de los microservicios:
- Orígenes en SOA (Década de 1990): Los microservicios tienen sus raíces en la arquitectura orientada a servicios (SOA), que promovía la creación de servicios independientes y reutilizables en el ámbito empresarial. SOA se centraba en la publicación de servicios reusables que podrían ser utilizados por clientes, principalmente internos a la organización.
- Netflix y Amazon (2010-2012): Empresas como Netflix y Amazon fueron pioneras en la adopción de arquitecturas basadas en microservicios. Netflix, en particular, jugó un papel importante al migrar de una arquitectura monolítica a una basada en microservicios para mejorar la escalabilidad y la disponibilidad de su plataforma de transmisión de video.
- Martin Fowler y James Lewis (2014): Los expertos en software Martin Fowler y James Lewis publicaron un artículo influyente titulado «Microservices» en el sitio web de ThoughWorks. Este artículo ayudó a popularizar el término y a definir las características clave de los microservicios, como la independencia, la comunicación a través de API y la descentralización.
- Adopción Generalizada (Años 2010 en adelante): A medida que más empresas se enfrentaron a los desafíos de escalabilidad y desarrollo ágil, adoptaron arquitecturas basadas en microservicios. Grandes compañías como Google, Facebook, Uber y Airbnb implementaron exitosamente esta arquitectura para lograr una mayor agilidad y escalabilidad.
¿Qué son los microservicios?
Es fundamentalmente un estilo arquitectónico que pretende fragmentar aplicaciones grandes (denominadas “monolíticas”) en mini-aplicaciones independientes (desde la perspectiva tecnológica y de negocio) que permitan gestionar los cambios y evolución de éstas, de una modo más ágil y escalable.
Algunos de los principios de diseño arquitectónico que se siguen habitualmente son:
- Los módulos deben estar alineados a unidades organizacionales con solo una variedad pequeña de roles. Los requerimientos de los usuarios están asociados a la unidad organizacional en la que trabajan: sus flujos de trabajo, sus políticas, sus metas, etc. En la medida que un microservicio puede cubrir unidades de negocio específicas, puede también aislar los cambios y limitar el impacto que cada cambio pueda tener en otros microservicios. Si, por ejemplo, se requiere implementar una nueva política de cálculo de comisiones de venta de un grupo de vendedores, no deseamos modificar la nómina por completo o todas las áreas de RRHH por esta razón.
- Cada módulo debería tener su propia base de datos. El hecho de que gran cantidad de módulos compartan una misma tabla (pensemos por ejemplo en una tabla de empleados) involucra el riesgo de que cuando un nuevo requerimiento implique modificar esa tabla, esa modificación termine afectando módulos que comparten tal tabla incluso cuando no tengan nada que ver con el requerimiento que origina el cambio. A esto se le conoce como acoplamiento accidental.
- La intercomunicación entre microservicios se debe dar a través de la red, de modo síncrono o asíncrono (vía apis web, message brokers o mecanismos similares). Así, un microservicio no requiere conocer el interior de otro microservicio con el que colabora, dejándolo a salvo de cualquier cambio al interior de él.
- Los módulos deberían estar diseñados para ser escalables por medio del uso de tecnologías de virtualización. Si cada microservicio se publica al interior de un contenedor (como Docker), entonces podemos generar nuevas instancias de él sobre demanda a fin de ofrecer una vía simple y económica de escalamiento. Si además usamos un orquestador de contenedores (como Kubernetes), podemos programar reglas para la creación, enrutamiento(balanceo de carga) y baja de esas instancias en tiempo de ejecución. Esto además, conforme a la demanda de servicios observada en tiempo real.
- Los microservicios deben ser independientes a nivel desarrollo, pruebas y deployment. De este modo los equipos de trabajo pueden alinear el desarrollo de funcionalidades con el paradigma ágil.
¿Por qué desarrollar usando Microservicios?
Podríamos resumir que las dos grandes motivaciones para usar microservicios son:
- Conseguir servicios de alta disponibilidad a bajo costo. Con una estrategia correcta que combine la tecnología de virtualización (contenedores, orquestadores y proveedores de escalamiento elástico, típicamente en la nube) con un diseño adecuado para la resiliencia (caída de microservicios particulares) podríamos conseguir servicios de TI robustos y económicos en consumo de recursos de infraestructura.
- Conseguir aumentar la velocidad de desarrollo de nuevas funcionalidades. Al limitar el impacto que tiene un microservicio en el desarrollo de los demás microservicios (en dimensiones que van desde las comunidades de usuarios, hasta los equipos de desarrollo y las tecnologías que utilicen) permitimos agilizar el trabajo de los distintos involucrados.
¿Hay riesgos a la hora de implantar este enfoque?
Algunos de los riesgos que mayor impacto pueden tener son:
- leer y actualizar. Este aspecto es sin duda, uno de los más importantes problemas a resolver.
- Equipo de trabajo insuficientemente capacitado. Este estilo arquitectónico incorpora gran cantidad de aspectos a resolver: La integración con el resto de microservicios, la complejidad del procesamiento distribuido, la existencia de múltiples instancias, el manejo de redundancia, los procesos de pruebas, la infraestructura de monitoreo, la tolerancia a fallas, etc. No presenta un escenario muy propicio para aprender con una filosofía ensayo-error.
Conclusiones
Si consideramos que este estilo arquitectónico ajusta especialmente bien como una solución de escalamiento y alta disponibilidad, pero que tiene como contraparte mayor complejidad en todos los procesos de TI, deberíamos evaluar qué aplicaciones merece la pena involucrar en iniciativas de desarrollo bajo microservicios. Definitivamente no todas las aplicaciones tienen requerimientos de este corte (al final, no todos somos Netflix).
El uso de microservicios tiene una curva de aprendizaje significativa. Por ello es importante que tengamos estrategias de soporte educativo adecuadas. Es recomendable incorporar uno o más especialistas con experiencia previa, especialmente a nivel de diseño y que de ser posible hayan vivido ciclos completos de desarrollo y puesta en producción de este tipo de aplicaciones.