Patrones de diseño en microservicios

Hoy en día en el mundo del desarrollo software, la arquitectura de microservicios ha emergido como un enfoque poderoso para construir aplicaciones escalables, flexibles y robustas.

Los microservicios son tanto un estilo de arquitectura como un modo de programar software. Se centran en dividir las aplicaciones en elementos más pequeños e independientes entre sí. De esta forma conseguiremos crear aplicaciones que sean más fáciles de escalar y más rápidas de desarrollar, a diferencia del enfoque tradicional y monolítico de las aplicaciones, en el que todo se compila en una sola pieza.

Patrones de diseño en microservicios

Ahora ya tenemos ciertos conocimientos de lo qué son y cuándo usar microservicios y por qué puede ser efectivo utilizarlos en el desarrollo software. Pero los desarrolladores pueden seguir encontrándose con otros obstáculos a la hora de trabajar, que pueden afectar al desarrollo o a los estándares de calidad del software. Para poder mitigar o, en cierta parte, solucionar estos problemas, tenemos los patrones de diseño en microservicios.

Los patrones de diseño de software se han convertido en una herramienta invaluable, brindando soluciones probadas y comprobadas para problemas comunes de diseño. Cada patrón es como una plantilla que puede ser utilizada o modificada al gusto de quien lo use, pudiendo adaptarla al problema de diseño particular que tenga tu código.

Cuáles son los diferentes patrones de diseño en microservicios

A continuación, vamos a describir los diferentes patrones de diseño que podemos utilizar a la hora de usar los microservicios. Describiremos su uso y las diferentes ventajas o casos en los que podemos trabajar con ellos.

CQRS

CQRS (Command Query Responsibility Segregation) es un enfoque arquitectónico que separa la responsabilidad de procesar comandos de la responsabilidad de realizar consultas. Siendo los comandos las diferentes operaciones que modifican el estado del sistema, y las consultas las operaciones que se encargan de recuperar datos del sistema.

Con este patrón se suelen utilizar dos modelos de datos diferentes:

• Modelo de comandos: este modelo se encarga de procesar las operaciones de escritura o comandos. Está diseñado para ser eficiente en la modificación del estado del sistema y puede estar optimizado para operaciones de alto rendimiento y baja latencia. Por lo general, este modelo es más simple y enfocado en la ejecución de acciones que modifican el estado de la aplicación.
• Modelo de consultas: este modelo es el encargado de atender las operaciones de lectura o consultas. Está optimizado para recuperar y presentar datos de manera eficiente para los usuarios o servicios consumidores. Puede estar estructurado de manera diferente al modelo de comandos, con el objetivo de agilizar las operaciones de lectura y consulta.

La separación de estos modelos permite diseñar cada uno de forma independiente, facilitando así la optimización de las tareas. Con esto, permite tener grandes mejorías en:

• Desacoplamiento: al separar las operaciones de lectura y escritura, se reduce considerablemente la complejidad y el acoplamiento entre componentes.
• Escalabilidad: permite escalar vertical u horizontalmente cada modelo según las necesidades de la aplicación.
• Optimización: los modelos de comandos y consultas pueden optimizarse de manera independiente para mejorar el rendimiento y la eficiencia de la aplicación.

Sin embargo, aunque CQRS es uno de los patrones más utilizados en el área de microservicios debido a que está directamente alineado con la filosofía de esta metodología de desarrollo, este patrón introduce complejidad adicional en la arquitectura de la aplicación, ya que requiere la implementación de lógica para sincronizar los modelos de comandos y consultas, así como la gestión de posibles inconsistencias entre ellos. Por lo tanto, su adopción debe considerarse cuidadosamente en función de los requisitos y las necesidades específicas de la aplicación.

BFF

Una aplicación web, dependiendo de la necesidad, puede tener diferentes niveles de complejidad. Un ejemplo muy básico podría ser el de un único sistema que genera el contenido del lado del servidor, donde front-end y back-end forman parte de este (un monolito). Esto puede aumentar mucho la complejidad hasta llegar al punto en el que los clientes dependan de una API común o de una serie de APIs independientes, generando así un fuerte acoplamiento entre los sistemas y violando uno de los principios SOLID, concretamente el Principio de Segregación de Interfaces, al tener los clientes que acceder a APIs que dan mucha más información de la que ellos necesitan.

La idea detrás del enfoque de BFF es simplificar la comunicación entre un cliente y su servidor mediante la creación de un punto de entrada dedicado para cada cliente. Esto implica que cada cliente acceda a una API específica diseñada para sus necesidades particulares, permitiéndole adaptarla según sus requerimientos.

En un patrón de microservicios, esto significa generar un servicio intermedio que dé soporte única y exclusivamente a este tipo de cliente. La principal ventaja de este enfoque radica en la simplificación de la interacción entre una aplicación y sus servicios back-end. Además, facilita la evolución de los servicios back-end, ya que los cambios y adaptaciones solo requieren modificaciones en los adaptadores sin necesidad de actualizar el cliente en sí.

Aunque no todo es de color de rosas: uno de los problemas principales de utilizar una API para cada tipo de cliente es la complejidad, ya que estamos pasando de tener un único servicio a tener uno por cada aplicación cliente. Esto se vería reflejado tanto en costes de hardware como de desarrollo.

Por ello, ¿cuándo debemos usarlo? Bien, esto dependerá de nuestra aplicación. Si tenemos una aplicación en la que un tipo de cliente solo va a utilizar una parte de la API principal, seguramente sea una buena idea separarlo y crear un acceso para ese tipo concreto. En cambio, si todos los clientes van a usar los mismos métodos de la API y vamos a tener la misma funcionalidad para todos, tal vez no sea necesario usar este patrón.

API Gateway

Esta es una solución arquitectónica comúnmente utilizada en el diseño de sistemas distribuidos y microservicios. En esencia, un API Gateway actúa como un punto de entrada centralizado para todas las solicitudes de clientes que acceden a servicios dentro de un sistema. Funciona como un intermediario entre los clientes y los diferentes microservicios que componen la aplicación.

La API Gateway se sitúa entre las aplicaciones de clientes y los microservicios, y funciona como un proxy inverso que redirige las solicitudes del cliente a los servicios. Además de esto, la puerta de enlace de la API puede proporcionar otros servicios transversales como autenticación, terminación SSL y caché.

Las razones para utilizar este patrón en vez de la comunicación directa son varias:

• Facilita que los clientes puedan acceder a los diferentes servicios del sistema, ya que proporciona una única interfaz de entrada para ellos. De esta forma, los clientes no tienen por qué conocer la ubicación específica de cada servicio, lo que reduce la complejidad y el acoplamiento.
• Permite gestionar de manera centralizada aspectos como la seguridad, la autenticación, la autorización y el monitoreo. Esto simplifica la implementación de políticas de seguridad y facilita la aplicación de actualizaciones o cambios en estas políticas.
• Permite realizar enrutamiento inteligente de solicitudes, redirigiendo las peticiones a los servicios correspondientes en función de diversos criterios, como la ruta de la URL, el tipo de solicitud o los encabezados HTTP. Esto mejora la flexibilidad y la capacidad de escalabilidad de la arquitectura.
• A su vez puede realizar funciones de caché, compresión y optimización de solicitudes para mejorar el rendimiento general del sistema. Además, puede implementar técnicas de balanceo de carga para distribuir la carga de manera equitativa entre los servicios subyacentes.

Como expertos en microservicios con más de 1000 aplicaciones gestionadas, en hiberus contamos con las capacidades, la experiencia y los conocimientos necesarios para ayudarte en la migración a microservicios de tu negocio digital. ¿Quieres saber más? ¡No dudes en preguntarnos!