Patrón Arquitectura de Microservicios

La arquitectura de microservicios esta basada en un patrón cuyo máximo objetivo es poder desacoplar lo máximo posible todos los componentes. No existe una definición formal sobre microservicios, pero lo que sí existen en estas arquitecturas, son una serie de características comunes.

¿Por qué usar esta arquitectura?

Imagínate que tienes que desarrollar un software bancario, en el que tienes varios módulos, tarjetas, cuenta nómina, créditos, hipotecas etc…; en el que cada servicio, además tiene que interactuar, con otros servicios. Si utilizásemos la arquitectura tradicional de un monolíto:

• La arquitectura de la aplicación aumentaría en complejidad.
• Aunque hubiese varios equipos, no serían realmente independientes.
• Se podrían provocar fallos en cascada.
• El tiempo de puesta en producción, al tener una pieza grande aumenta.
• Se debe usar la misma tecnología para toda la aplicación.
• Dificultad para escalar, no se puede escalar solo una parte.
• El equipo de operaciones se ve obligado a tomar control de la aplicación para su puesta en producción.

En cambio si ese software bancario, lo pudiésemos modular y orientar a una arquitectura de microservicios, tendríamos las siguientes características:

• Independencias entre desarrollo y operaciones.
• Velocidad y agilidad, lo que mejora el time to market.
• Mejor código y calidad.
• El código se crea en función del negocio y la funcionalidad, dominios.
• Se incrementa la productividad.
• Al tener varios microservicios podremos escalar sin ningún problema, la parte que se necesite.
• Cada equipo que será responsable de un microservicio, podrá elegir la tecnología a usar.
• Los microservicios deberán poder ser consumidos por otros microservicios.

Por lo que el por qué usar esta arquitectura, sería básicamente los puntos que hemos expuesto anteriormente. Aunque, nos aportan muchos beneficios, hay que tener en cuenta que también tiene sus problemas y complejidades. Como monitorizarlos?, control de errores, caídas de microservicios, comunicación entre ellos…, etc.

Características principales de los Microservicios

• Endpoints inteligentes: Se evita hacer uso de los ESB (Enterprise Service Bus).
• Bases de Datos aisladas: En lugar de una base de datos común para toda la aplicación, se tendrá un Base de Datos para cada microservicio.
• Automatización: Cada microservicio estará automatizado para tener entregas constantes.
• Cada microservicio es una pequeña aplicación que tiene su propia arquitectura consistiendo de una capa de negocio junto con varios adaptadores.

• Algunos microservicios pueden ser expuestos a través de un API que podrán ser consumidos por otros microservicios o por aplicaciones de clientes.
• En tiempo de ejecución, por lo general cada instancia suele un contenedor docker o estar en un cloud

Consideraciones a tener en cuenta con Microservicios

Antes de empezar a implementar una Arquitectura de Microservicios, es necesario tener alguna consideración:

• Cultura Devops: Conocimientos sobre Integración continua y despliegue continuo.
• Aprovisionamiento rápido: Capaz de lanzar nuevos recursos de manera rápida y eficaz.
• Monitorización y capacidades de Debug: Necesitamos saber qué esta pasando por nuestros servicios.
• Capacidad de lanzar y gestionar muchos servicios de manera rápida.

Ecosistema de Microservicios

Cuando implementamos un Patrón de Arquitectura de Microservicios, se deben de tomar una serie de medidas e implementaciones para su interacción con el mundo exterior; facilitar su desarrollo y evitar problemas.

• API Gateway: Un API Gateway es un simple punto de entrada en el sistema. Encapsula el sistema interno de arquitectura y proporciona un API que es adaptado a cada cliente. Además, debe tener otras responsabilidades como:
  • Cache
  • Autenticación
  • Monitorización
  • Balanceo de carga
  • Cache
  • Administración
  • Manejo de la respuesta
• Service Discovery: El service discovery es una “base de datos” de servicios, de sus instancias y sus localizaciones
• Load Balancing: Cuando se hace una petición a un servicio, el cliente hace peticiones via router a todas las localizaciones conocidas, este router hace una query al Service Registry y traslada la petición a una instancia disponible.
• Fault tolerance: Debido a que se tienen muchas dependencias, hay que hacer un sistema que sea tolerante al fallo, para ello hay implementaciones como el Circuit Breaker.
• Configuration management: En un sistema complejo y con muchas dependencias y en donde los tiempos son vitales, lo mejor es tener un sistema de configuración externalizada para propiedades y gestión de microservicios.

Patrones de diseño de Microservicios

A continuación vamos a nombrar unos cuantos patrones de diseño, de los que hablaremos más en profundidad en otras entradas de Refactorizando.

• Event driven: En este patrón un microservicio publica un evento y otro microservicio lo consumirá.
• Aggregator o Proxy: Un cliente web necesita información que esta en varios microservicios. En este caso se invoca a un microservicio que agrega las llamadas a otros microservicios para obtener la respuesta.

• Chained: En este caso se realizan llamadas consecutivas para componer la información.

• Asynchronous messaging: Con un patrón de llamadas REST, las peticiones y llamadas son asíncronas (se pueden hacer implementaciones para llegar a asíncronas); por lo que provoca que en muchas ocasiones se utilice un servicio de mensajería asíncrona como Kafka para enviar información.
• Patrón Saga: El Patrón Saga es una secuencia de transacciones locales donde cada transacción actualiza información dentro de un servicio.

Conclusión

Este Patrón de Arquitectura de Microservicios es una solución a muchos de los problemas que existen en el desarrollo, pero no a todos. Antes de empezar a implementar una solución de estas características habrá que evaluar su viabilidad. Ya que hay que tener en cuenta que una solución de estas características, al final integra muchos servicios, y el coste también podría aumentar.