Fundamento esencial de microservicios y su arquitectura

Si eres desarrollador y/o arquitecto de software que quiere basar sus soluciones en arquitectura de microservicios y ambientes dockerizados, este articulo te dará fundamentos generales para establecer, diseñar e implementar esta arquitectura con tecnologías de desarrollo como lo es .NET Core, NodeJS, Docker, Mysql, MongoDB, ORM, ODM, Entity Framework, y más.

Al finalizar, encontrarás dos links de repositorios de dos pequeños proyectos de ejemplos (en .NET Core y NodeJS), donde he implementado algunas de las tecnologías tratadas.

Igualmente, se pueden crear microservicios con otras tecnologías y lenguajes como F#, NodeJS, Python, Java, C++, Golang y más, manteniendo los patrones de arquitectura que se presentan luego.

“Te escribo una carta larga, porque no tuve tiempo de escribir una corta“, Blaise Pascal

Antes de enfocarnos en los microservicios y su arquitectura, veamos otras alternativas existentes hasta llegar a la moderna arquitectura basada en microservicios; aplicadas principalmente al ambiente de desarrollo backend.

— Acerca de CQRS y DDD, me gustaría aclarar que, no son arquitecturas en sí, sino más bien patrones arquitectónicos; como piezas o componentes de una arquitectura.

Algunos de los tipos de arquitecturas son:

• Arquitectura monolítica
• Arquitectura orientada a servicios (SOA)
• Arquitectura basada en microservicios

— Arquitectura monolítica “ Todo en uno ”

Las apps o servicios construidos bajo esta arquitectura, pueden no ser monolítica en su interior, estructurándose en varias librerías, componentes y/o capas (capas de aplicación, capa de presentación, capa de negocio, capa de acceso a datos, entre otros), sin embargo, externamente es un único contenedor (docker), único proceso, única app o único servicio, por tal motivo, esta arquitectura presenta limitación de escalabilidad y disponibilidad, ya que, la alternativa para aumentar su capacidad es mediante copias exactas de toda la instancia/contenedor en otros servidores/VM, y usando un balanceador de carga.

Evidentemente, esto presenta varias desventajas, considerando que; la densidad es poco granular, en muchos casos se quiere escalar solo una parte (El cuello de botella) pero este diseño despliega todo varias veces y al mismo grado (causando un uso ineficiente de los recursos), dado que, toda la aplicación vive en un solo contenedor.

🤔 Caso usual, para subir una nueva característica al ambiente de Prod, Stage, o incluso Dev; se bajan todos los servicios, y luego se vuelven a subir, es decir, un reset engorroso, en una ventana de tiempo variante, dependiendo del tamaño de la solución.

Lo anterior, no quiere decir que, este diseño no se use, al contrario, es usado frecuentemente, por su facilidad de desarrollo al inicio, algunas organizaciones están logrando buenos resultados, y otras ya llegaron a los límites.

— Arquitectura orientada a servicios != Arquitectura basada en microservicios

Estas dos arquitecturas tienen sus similitudes, pero, no son lo mismo, aunque, algunos profesionales en el área aseguran que, si lo son, diciendo que: “la arquitectura de microservicio es SOA implementada correctamente”.

No obstante, en SOA una solución, se estructura en múltiples servicios (regularmente servicios HTTP), donde se tienen presentes orquestadores centrales a nivel de la organización, agentes centrales y/o Enterprise Service Bus (ESB), lo que puede tener problemas de escalabilidad y disponibilidad, desplegándose en base a hosts de docker únicos, con proceso único, también, los cuales, son anti-patrones en el enfoque de microservicios.

— Arquitectura basada en microservicios

¿En qué consiste? En orientar la construcción en pequeños servicios que conforman una solución, como lo comentaba anteriormente; enfocada principalmente al ambiente de desarrollo backend, sin embargo, no está limitado solo a este, puesto que, también podría implementar se en el frontend (dividiendo la UI; en componentes y/o vistas que consumen específicos microservicios del backend); cada microservicio debe ser autónomo, de tal manera que, gestione de forma independiente el modelo de datos, la lógica, los despliegues, y el desarrollo; similar a Bounded Context en el diseño orientado por el dominio (DDD — Domain Driven Design), descentralizando así lenguajes de programación y datos.

Los microservicios normalmente se comunican con otros microservicios, usando mecanismos muy livianos y protocolos como HTTP/s, WebSockets, Advanced Message Queuing Protocol (AMQP).

• Beneficios

Permite grandes beneficios que generan agilidad a largo plazo, dado que, facilita el sostenimiento, desarrollo y despliegue de soluciones complejas, con grandes volúmenes de datos, que a menudo requieren ser escaladas, cabe resaltar, un valor agregado en la reducción de costo (ahorro), ya que, se aprovechan mejor los recursos (software y hardware), al escalar únicamente los microservicios que lo requieran.

— Lista de beneficios

1. Agilidad al implementar mejoras.
2. Facilita el mantenimiento del proyecto a largo plazo.
3. Escalabilidad de microservicios que lo requieran.
4. Funcionalidad modular/granular, con módulos autónomos.
5. Posibilidad de combinar lenguajes y tecnologías (versátil), aprovechando lo mejor de cada una.
6. Permite tecnologías más actualizadas, ya que, la actualización de dependencias/librerías en un microservicio, no compromete al resto.
7. Uso de las buenas prácticas de CI/CD.
8. Reducción de costos (Ahorro), escalando los microservicios, en los cuales sea necesario.
9. Aumenta la tolerancia a fallos.

En la siguiente imagen, se muestra el escalado de un microservicio (el rojo), ya que, solo este lo requiere.

De lo anterior, se puede decir que, los microservicios son fácil de escalar y agilizan los cambios, ya que, se construye en pequeñas porciones (granulares) para cumplir con un objetivo específico, posibilitando hacer cambios de implementación interna o incluso agregar nuevas funcionalidades, sin afectar a los demás microservicios, también ayuda a hacer uso de las buenas prácticas de integración y entrega continua (CI/CD).

En la siguiente imagen, se ilustran beneficios y aspectos de los microservicios en una visión global.

Fuente: Guía de arquitectura en apps contenerizadas por Microsoft.

¿Desafíos de arquitecturas basadas en microservicios?

“Los microservicios ofrecen grandes beneficios, pero también plantean enormes desafíos”, Según, la guía de arquitectura de soluciones ofrecida por Microsoft.

1. Establecer límites para cada microservicio dentro de la solución — Cada microservicio debe ser autónomo en datos y lógica, pero ¿hasta dónde controlará cada microservicio? Sí, los contextos se definen y administran de forma independiente.
2. Obtener datos de consultas en varios microservicios — Debido a la autonomía de estos, se tendrían bases de datos con tablas para cada uno, entonces, ¿Como se realizaría la relación entre tablas? Alternativas: CQRS (Command and Query Responsibility Segregation), patrón API Gateway (Cuidado con los cuellos de botella).
3. Consistencia de datos entre microservicios — Mantener la integridad de los datos es un reto más, por lo que, no se debe usar tablas o atributos repetidos entre microservicios.
4. Comunicación entre microservicios — No solo corresponde al protocolo de comunicación entre los mismos, sino también, al nivel de denpendencia, y modo de comunicación (síncrono o asíncrono). Para lograr el principio de autonomía, se recomienda interacción asíncrona entre microservicios, usando protocolos como; HTTP Long Polling, y AMQP (Cuidado con las excepciones y latencias)
5. Despliegues automatizados — En pocas horas o minutos debería tener la solución disponible, es por ello que, la automatización es clave, aunque no es obligatoria, pero podría requerir mucho más esfuerzo que la app de negocio en sí misma, sino se automatiza.
6. Monitoreo y estado de los microservicios — En sistemas distribuidos, teniendo varios servidores o hosts, pueden surgir fallas eventuales o grandes interrupciones, no necesariamente dependientes del código, crear eventos estandarizados para registrar diagnóstico, y logs, es una buena práctica, ya que, ayudan a tomar decisiones, y ¿por qué no?, a agregar la característica de recuperación automática de microservicios.

“Consequently, if you don’t have certain baseline competencies, you shouldn’t consider using the microservice style.” Dijo Martin Fowler en una de sus publicaciones.

¿Como identificar el tamaño ideal para separar los servicios?

Más importante que el tamaño es la autonomía de cada microservicios (No dependencia de otros), por supuesto, buscando el tamaño más pequeño posible, la cohesión ayuda a separar o agrupar microservicios, adaptar el tamaño es un proceso iterativo, usar el patrón Bounded Context (BC) facilita el proceso, al diseñar grandes apps se suelen fragmentar el modelo de dominio.

En la siguiente imagen, se identifican entidades y límites de los modelos en los microservicios.

Fuente: Guía de arquitectura en apps contenerizadas por Microsoft.

Topologías de la infraestructura

-Gateway API, expone al usuario final los microservicios mediante API REST.

-Basada en aplicación, es la interfaz de usuario que consume los microservicios.

-Orientada a mensajería, suscripción/desuscripción que responde a eventos con el fin de hacer encolamiento, frecuentemente fortalece los microservicios asíncronos.

En conclusión, la arquitectura basada en microservicios aporta enormes beneficios a grandes soluciones, sin embargo, trae como consecuencias sus propios desafíos, los microservicios son frecuentemente adoptados por empresas como Google, Netflix, Amazon, Facebook, Alibaba, Ebay, UBER, entidades bancarias, entre otras; por sus cantidades de datos, productos y/o servicios.

Los microservicios son ideales para apps en la nube, con metodologías de DevOps, Docker, Kubernetes…

🤠 Hasta la próxima !!!

— [Dockerizando] Código de ejemplo usando .NET Core y MySQL📌

— [Construyendo] Código de ejemplo usando NodeJS y MongoDB 📌

¯\_(ツ)_/¯ Deja tu feedback 😃