Iniciando desde la interfaz del usuario (en algunos casos), pasando por una o varias capas de lógica de negocio, la capa de persistencia, y, hasta la base de datos, el producto de Software se construía como un solo concepto, y a menudo se ejecuta como un solo binario o unidad entregable (JAR, WAR, EAR, Folder, etc.).
La Arquitectura de Microservicios es un enfoque para el desarrollo de un producto de Software, en donde cada concepto específico de negocio es construido en una unidad pequeña de código accesible a través de una API liviana y bien definida.
El TODO del producto de Software entonces, constituye la ejecución sincronizada de un conjunto de estos servicios, cada uno con su propia e independiente definición, para el proceso de una transacción padre disparada desde una interfaz de usuario o sistema.
Características de los Microservicios
Aunque parece no existir una especificación única para crear Microservicios, y más depende del caso de negocio y/o planificación; generalmente se sugiere que deban cumplir las siguientes características:
Interfaz Única
Cada Microservicio debe proveer una interfaz ligera y bien definida para consumo, que aísle todos los detalles técnicos, estructura de datos y datos de la capacidad de negocio que maneja, a sus clientes.
Especializado
Cada servicio es diseñado con un conjunto limitado de capacidades que resuelvan uno y solo un problema de negocio, y que incluye su propia estructura de datos persistentes.
Autónomo
Cada servicio puede ser desarrollado, desplegado, operado y escalado sin afectar o depender de otros servicios o sistemas, o, de otros datos fuera de su especialización.
<!-- /wp:column -->
Claramente una Arquitectura de Microservicios es una aplicación del paradigma de Cómputo Distribuido, lo que representa muchas ventajas para el negocio pero también muchos retos en la operación y mantenimiento.
Ventajas de la Arquitectura de Microservicios
|
Agilidad Este paradigma de desarrollo permite crear equipos pequeños e independientes que se apropian de la especialización de los servicios, acelerando el tiempo de desarrollo, facilitando la auto-organización e incluso el soporte post-producción. |
Escalamiento Esta división de funcionalidad hace más fácil la medición y observabilidad de la implementación, permitiendo planificar mejor la disponibilidad y escalabilidad. |
|
Simplificación de Despliegue Una unidad pequeña de implementación, permite ciclos de CI/CD más simples, reduciendo el tiempo de despliegue de la misma y el rollback en caso de fallos. Esto agiliza las operaciones y al mismo tiempo reduce el riesgo de innovación con nuevas características. |
Resiliencia A diferencia de una Arquitectura Monolítica, un fallo en una Arquitectura de Microservicios compete a un componente específico, lo que hace más fácil su recuperación y no desestabiliza el producto de Software por completo, sino la capacidad de negocio concreta que le compete. |
|
Independencia Tecnológica El uso de una sola tecnología no es una restricción en la Arquitectura de Microservicios, dado que su interfaz de consumo abstrae los detalles de implementación y habilita a la selección de la mejor herramienta de acuerdo a la especialización del servicio. |
Reutilización de Código Evidentemente una vez construido un servicio que atiende una capacidad de negocio, el mismo puede ser utilizado por otros productos de Software de forma que su construcción aproveche la funcionalidad ya implementada. |
Desventajas de la Arquitectura de Microservicios
Más que desventajas, se puede hablar de retos a la hora de adoptar una Arquitectura de Microservicios, y entre los principales tenemos:
|
Versionamiento Un Microservicio, al ser autónomo, suele evolucionar independientemente del producto o de los productos de Software a los cuales provee funcionalidad. Esto significa que su interfaz API y la validación del esquema de datos varía continuamente, sin embargo para no afectar la estabilidad de sus clientes antiguos debe mantener un versionamiento de los mismos y obviamente mantenerlos operando. Esto tanto para áreas de operaciones y de desarrollo implica una tarea adicional en su implementación. |
Pruebas Si bien un Microservicio por sí solo es más simple de probar, su orquestación con otros servicios (test de integración) y las pruebas integrales (pruebas end to end) son mucho más complejas. Esto resulta a menudo en una cobertura incompleta de escenarios de pruebas y un esfuerzo redoblado en su desarrollo. |
|
Rollback y Sistemas Distribuidos El reto más grande, para mí, es el diseño de sistemas distribuidos, puesto que hay que definir qué sucede en caso de fallos esperados o inesperados en la orquestación de los servicios, analizar patrones de resiliencia y recuperación de transacciones, mirar la atomicidad de operaciones y consistencia de datos, entre otros. Claro está, que para esto nos podemos apoyar en conceptos como “Patrones de Integración Empresarial”, “Mallas de servicios” o similares, pero sin duda estas decisiones son extremadamente relevantes no solo para el desarrollo sino para el soporte post-producción. |
Coordinación de equipos Si bien, al desarrollar un Microservicio, paradigmas como la Agilidad y un equipo responsable puede representar una gran ventaja para generar valor e innovación constante en su implementación, al tener decenas o centenas de microservicios con decenas o centenas de equipos responsables, la cooperación y comunicación de estos equipos es un reto, pues el TODO de un Sistema y su evolución se puede poner en riesgo cuando se carece de una acción combinada. |
|
Sobrecarga de infraestructura En la Arquitectura Monolítica un operador a menudo mira un servidor y un Software correspondiente con su archivo log; en un paradigma de Arquitectura de Microservicios puede enfrentarse a escenarios donde un Software tiene 100 servicios y centenas de servidores, con uno o varios balanceadores, muchos archivos de logs y decenas de formatos. Aunque hoy existen esquemas de contenerización como Docker y Kubernetes, la administración sigue siendo un reto y se necesita varias tecnologías complementarias para enfrentarlo. |
Tiempo y esfuerzo 1x A este punto del artículo ya hemos descrito muchas actividades adicionales en el diseño, implementación, operación y mantenimiento de la Arquitectura de Microservicios, por su característica de Sistema Distribuido. Por este motivo es importante sopesar el beneficio de este paradigma en contraste con el caso de negocio y los resultados esperados a corto, medio y largo plazo; del mismo modo debemos pensar en el soporte post implementación, en relación al equipo, sus capacidades. |
|
Despliegue ¡Si!, desplegar un solo microservicio es simple, sin embargo desplegar cientos de ellos de forma manual se vuelve imposible. El orden de despliegue, los cambios de base de datos que implica, la estratégia de entrega (Blue-Green, Canary, etc.), entre otros, son cosas a planificar y deben estar automatizadas, con prácticas DevOps entre otras como Integración Continua (CI) y entrega Continua (CD). |
Logs y Monitoreo De la misma manera, un producto de Software Monolítico deja un solo log de operación y se puede medir su performance centralizadamente. En una Arquitectura de Microservicios, vamos a tener tantos logs como servicios implementados para el producto de Software y además si estos son redundantes, tendremos logs multiplicados por cada servicio. Debemos planificar una estratégia para rastrear errores, identificar la salud de cada servicio y del sistema como tal. |
|
Debug Encontrar un problema no siempre va a ser posible revisando logs (que al ser tantos ya nos agrega una complejidad), a veces vamos a tener que depurar la implementación y esto en un sistema distribuido no va a ser factible, por lo que se requerirá de otras técnicas y patrones que permitan repetir ciertas ciclos de transacciones. |
Pensamientos Finales
A este punto del artículo, puede sonar complejo decidir por microservicios, y la verdad lo es; sin embargo, esta complejidad no se evidencia desde el momento cero de una implementación, sino que irá apareciendo gradualmente mientras vamos creando más microservicios y escalándolos.
Son muchas sus ventajas, y aunque hay retos, en una estratégia digital a largo plazo es sin duda el camino a adoptar, y así mismo, debe venir acompañada de un soporte directivo dado que la estructura organizacional, técnica y de costos va a tener que evolucionar también.
¿Debo usar Microservicios? La realidad es que muchos desarrollos de Software nacen con este enfoque, sin abordar en un primer momento las soluciones a estos desafíos, pero eventualmente lo harán. Les invito a ver una interesante conversación entre Martin Fowler y Sam NewMan sobre cuando usar microservicios y cuando no.
El soporte de este tipo de aplicaciones es complejo, pues detectar un fallo en una Arquitectura de Microservicios requiere de un entrenamiento en el flujo de negocio, en los puntos de integración y en la interpretación de los logs de información. En muchos casos al soporte de primera línea le faltan insumos para responder y el escalamiento de las incidencias es muy rápido al equipo técnico, resultando en una sobrecarga de operación y costo.
Top comments (1)
Muchas gracias por compartir esto, me ha servido de mucho, dónde trabajo usamos microservicios y no me había parado a preguntarme porque eligieron esta arquitectura, ahora entiendo.