La arquitectura de microservicios propone separar cada parte del sistema en un componente de software: una porción de código que se enfoca en resolver una parte del sistema se separa del resto y se comunica vía mensajes entre procesos (en general, peticiones HTTP REST), de modo que pueda ser reemplazada, actualizada o modificada sin afectar al resto del sistema.

En este artículo, veremos las ventajas y desventajas más relevantes de la arquitectura, para saber si conviene o no aplicarlo en nuestro proyecto si es que estamos iniciándolo o con el plan de migrar de arquitectura.

Ventajas

Menor acoplamiento

Como cada microservicio está separado del otro, el acoplamiento de funcionalidades se reducido: al tener separadas las funcionalidades del sistema en diferentes servicios, queda más marcada la diferencia entre los diferentes contextos de la aplicación, dificultando la posibilidad de que la funcionalidades se acoplen entre sí. De todas formas, no descarta la posibilidad de que el mismo nivel de acoplamiento no se pueda lograr en otra arquitectura o que no suceda acoplamiento entre microservicios.

Despliegue independiente

Cada microservicio tiene su propia secuencia de despliegue en producción, y su actualización no afectaría a todo el sistema: al actualizar un microservicio, solo se ve afectado el servicio específico que brinda y no el resto de las funcionalidades del sistema, por estar separados en procesos diferentes. En una arquitectura monolítica, por ejemplo, por estar la base de código en el mismo proceso en el hardware (servidor físico, la nube, etc.), una modificación al sistema podría afectar a otra parte que está en la misma base de código, aunque no haya sido actualizada, debido a conflictos de integración de ramas o merges entre ramas erróneos.

Diversidad y libertad de elección de tecnologías

Como cada microservicio es independiente a otro y está separado del resto, para un microservicio se puede usar el stack tecnológico que se crea más conveniente para el servicio que brinde. ¿Es más conveniente usar MERN para un servicio? ¿Usar Spring Boot para otro? ¿.NET? Es posible. Lo importante es mantener clara y definida la interfaz que cada microservicio expone a los demás.

Desventajas

Dificultad en detección de errores

Cada parte del sistema es un proceso diferente del hardware que interactúa con otros a través de mensajes, en la mayoría de los casos, HTTP. Si el sistema tiene varios microservicios (10 o incluso 100 o más) que realizan funcionalidades y responden a casos de uso: ¿Qué hacer cuando alguno falla? Los errores pueden deberse a latencia entre dos microservicios o más microservicios, algún microservicio que se cayó sin dar aviso, consistencia de datos, actualización de la interfaz que no se comunicó, entre otros. ¿Cómo noto y qué hago en consecuencia si algún microservicio dejó de funcionar? ¿Cómo hacer debugging?

Algunas de estas dificultades tienen soluciones simples que el mismo equipo puede solucionar, y otras merecen de herramientas externas para manejar la arquitectura.

Manejo de transacciones distribuidas

Las transacciones distribuidas se dan entre microservicios que guardan o actualizan información y usan más de uno para llevar a cabo la transacción. La dificultad en este caso es la comunicación del error a los servicios involucrados y dejarlos consistentes. Si existe algún error en uno de los microservicios que amerite un rollback del proceso, se puede realizar rollback sobre el microservicio que se realizó, pero es necesario aplicar algún tipo de estrategia sobre los anteriores, que, dependiendo de la cantidad de microservicios involucrados, puede precisar un gran esfuerzo.

Consistencia eventual

Al tener cada microservicio una base de datos específica, y cada uno comunicándose vía mensajes entre procesos (casi siempre peticiones HTTP), puede ser que la información que reciba el usuario final o incluso cada microservicio no sea siempre consistente: por ejemplo, el microservicio responsable de mostrar las nuevas películas y series de Netflix muestra a un usuario final una película menos que a otro, porque la actualización de esas películas, dependiente de otro microservicio, se vio retrasada.

Complejidad operacional

Aunque la independencia de despliegue es un beneficio en la arquitectura, a medida que va creciendo la cantidad de microservicios, es necesario manejar el despliegue de cada uno. En lugar de tener uno o pocos que desplegar, pueden llegar a ser 100 microservicios con pipelines específicos a desplegar. Este problema puede mitigarse con herramientas como kubernetes, docker o Ansible Automation (entre otros), pero de igual modo le agrega el costo de aprendizaje para lograr una operación efectiva de los microservicios.

 

Si ya conocemos las ventajas y desventajas de la arquitectura de microservicios, podemos decidir implementarla aceptando sus ventajas en pos de sus desventajas. Podemos hacer foco si el negocio detrás del proyecto merece la implementación: ¿las ventajas que tiene la arquitectura de microservicios ayudarán a hacerlo crecer? ¿A minimizar los riesgos? ¿Esas ventajas valen las desventajas que trae? Si procedemos a implementarlo, ya tendremos una previsualización de las desventajas y podremos disponernos a encontrar herramientas o ideas que ayuden a aprovechar más aún sus ventajas.

Fuentes:

Microservices • Martin Fowler • YOW! 2016

Building Microservices: Designing Fine-Grained Systems. Sam Newman, 2nd Edition.

Microservices: a definition of this new architectural term. Martin Fowler