Guía del CIO para entender los microservicios
Como CIO probablemente ya ha escuchado el término “microservicios” o “arquitectura orientada a microservicios” en alguna reunión con su equipo de desarrollo, con algún proveedor o con ambos. El objetivo de este artículo es brindar una comprensión general de qué es un microservicio, para ayudarle a tomar decisiones acerca de la conveniencia o no de su adopción, implicaciones y beneficios.
¿Qué es una arquitectura de microservicios?
Una solución construida con una arquitectura de microservicios está estructurada como un conjunto de componentes denominados servicios, cada uno de los cuales posee por lo menos las siguientes características:.
- Bajamente acoplado con los demás componentes
- Instalable y ejecutable de forma independiente
- Alcance funcional delimitado, que además debe ser significativo para el negocio
- Mantenido por un sólo equipo
Este estilo de arquitectura nace como una respuesta de las compañías con plataformas Internet globales grandes y complejas (Ebay, Netflix, Amazon, Uber, LinkedIn, Facebook, entre otras) al reto de liberar rápidamente y de forma confiable nuevas características y servicios a los usuarios de sus plataformas y además evolucionar ágilmente su infraestructura y tecnologías base.
Para ayudarnos a aterrizar la definición anterior, utilizaremos dos recursos pedagógicos muy efectivos: Una imagen (vale más que mil palabras) y la comparación (con algo conocido). El gráfico a continuación compara la arquitectura de microservicios de una plataforma de comercio electrónico con su alternativa tradicional: Arquitectura monolítica.
METER GRAFICO
IMPORTANTE: El prefijo “micro” de la denominación “microservicios” crea una expectativa errónea acerca del tamaño de cada servicio. En realidad el tamaño del servicio es un aspecto secundario. El autor desconoce porque se llegó a esta denominación, tal vez se quería tomar distancia de SOA (Service Oriented Architecture), con la cual hay coincidencias conceptuales, pero también grandes diferencias en la implementación. El autor opina que una denominación más acertada podría ser arquitectura de servicios.
Características esenciales de un microservicio
A continuación daremos un poco más de detalle acerca de cada una de las características consideradas esenciales para que un microservicio sea un microservicio.
Bajo acoplamiento
El bajo acoplamiento permite una mayor independencia en la evolución de cada microservicio, el equipo de desarrollo de cada microservicio puede trabajar con autonomía de otros equipos y ser más ágiles a la hora de implementar nuevas características o modificar las tecnologías base.
Para lograr este bajo acoplamiento los microservicios adoptan principios y tecnologías como:
- APIs: Los microservicios siguen siendo parte de una misma solución, por tanto la interacción entre ellos será necesaria. La interacción entre los servicios debe ser a través de APIs
- Comunicación asíncrona: Comunicación asíncrona, no bloqueante, con otros componentes
- Resiliencia:Mecanismos para manejar fallos, por ejemplo, la posible indisponibilidad de otros componentes con los cuales hay comunicación
- Base de datos privada: La base de datos de cada microservicio debe ser privada, es decir, sólo debe ser modificada, consultada y actualizada por el microservicio propietario. Este principio puede ser implementado como un conjunto de tablas exclusivo, un esquema o base de datos dedicada o una instalación de base de datos dedicada
Instalable y ejecutable de forma independiente
Que cada microservicio pueda ser instalado y ejecutado de forma independiente también contribuye a que el equipo de desarrollo de cada microservicio puede trabajar con mayor independencia, en su desarrollo y también pruebas, brindando mayor agilidad en la implementación y entrega de nuevas características. Por otro lado, se obtiene flexibilidad y mayor eficiencia en el uso de recursos de infraestructura, ya que cada microservicio puede ser escalado de manera independiente de acuerdo a su perfil de carga y uso de recursos.
Esta característica también trae consigo una alta complejidad de administración, operación y diagnóstico de incidentes por la naturaleza altamente distribuida que genera en la arquitectura física de la solución. Algunos principios y tecnologías que ayudan a mitigar esta complejidad son:
- Contenerización
- Construcción Continua y Entrega Continua (CI/CD)
- Automatización de tareas infraestructura: Infraestructura cómo código
- Observabilidad: Monitoreo automatizado, agregación de logs, traza distribuida, métricas de aplicación
Funcionalidad delimitada y significativa para el negocio
Cada microservicio debe implementar un conjunto de funcionalidades fuertemente relacionadas entre sí. Este principio facilita que los equipos de desarrollo puedan operar con alto grado de autonomía uno del otro.
Para definir los servicios de una solución pueden usarse técnicas como:
- Mapear microservicios a capacidades de negocio: Una capacidad de negocio es algo que el negocio hace, que genera valor, y que además la solución debe soportar
- Mapear microservicios a sub-dominios: El dominio se refiere a todos los conceptos del negocio a los que la solución da soporte: Entidades de datos, reglas de negocio, eventos, transacciones, etc.
Mantenido por un equipo
Este principio permite a la compañía organizar equipos ágiles pequeños para dar mantenimiento a los microservicios de la solución. Un mismo equipo puede mantener más de un microservicio, sin embargo, cada microservicio debe ser mantenido sólo por un equipo. Este principio contribuye también a la autonomía y agilidad en el desarrollo de software de cada microservicio.
Se recomienda la adopción de prácticas de agilismo en la gestión y operación de los equipos para obtener mayor beneficio.
En resumen
Un microservicio es un componente de software con las siguientes características esenciales:
- Bajamente acoplado con los demás componentes
- Instalable y ejecutable de forma independiente
- Alcance funcional delimitado, que además es significativo para el negocio
- Mantenido por un equipo
Una solución tiene una arquitectura de microservicios si está estructurada como una conjunto de microservicios con las características mencionadas anteriormente.
Beneficios
Permite liberar de forma continua soluciones grandes y complejas:
- Mejorando la mantenibilidad del software
- Componentes de software con alcance funcional delimitado a alto nivel, con alta cohesión e independientes unos de otros
- Diferentes equipos de desarrollo con alto grado de autonomía
- Independencia de pruebas, instalación y ejecución en producción
Desventajas
- Equipos de desarrollo y operaciones deben lidiar con una complejidad mucho mayor derivada de la naturaleza altamente
distribuida de este estilo de arquitectura
- Implementar funcionalidades que abarcan más de un servicio es más difícil y sigue necesitando comunicación entre los equipos de los servicios involucrados
- Probar las interacciones entre servicios es más difícil
- Actividades de administración y operación de la solución son más complejas
- Se debe resolver temas como:
- Deliminar funcionalmente los microservicios, es decir, dividir la solución en servicios
- Cómo mantener la consistencia de datos
- Cómo implementar consultas de datos
- Cómo manejar funcionalidades de la solución y transacciones que abarcan más de un servicio
- Cómo facilitar el diagnóstico de errores
Cuándo usar arquitectura de microservicios
Es recomendable implementar una arquitectura de microservicios cuando ya se tiene una versión de la solución que es exitosa y no para de crecer a un ritmo que requiere una mayor agilidad y velocidad para escalar y ofrecer nuevas características a los usuarios.