“Hoy en día, con respecto a la arquitectura de aplicaciones, es común escuchar sobre el concepto de microservicios y sus maravillas.

Este concepto se basa en la idea de que las diversas funcionalidades o módulos de la aplicación deben desacoplarse en servicios más pequeños que sean independientes entre sí y puedan comunicarse entre sí. Esto contrasta con la arquitectura monolítica tradicional, donde todas las funcionalidades están acopladas en la misma capa comercial y la base de datos es única.

Por ejemplo, en un sitio web, el historial de productos consultados y la recomendación de productos pueden separarse en dos servicios independientes, en los que este último consultará el servicio del historial mediante protocolos síncronos como HTTP/REST o asíncronos como AMQP.

Este tipo de organización permite que cada microservicio tenga un ciclo de vida independiente de los demás, lo que abre muchas puertas. Veamos:

– Flexibilidad de implementación: los servicios independientes pueden implementarse en diferentes idiomas;

– Más fácil de mantener: los servicios más pequeños son más fáciles de entender, desarrollar y probar;

– Menor tiempo de comercialización: los servicios independientes pueden ser desarrollados por diferentes equipos en paralelo;

– Despliegue independiente: La actualización de una funcionalidad requiere únicamente la indisponibilidad y el despliegue del respectivo microservicio y no de toda la aplicación;

– Infraestructura distribuida: los diversos servicios pueden ser alojados en diferentes servidores;

– Altamente escalable: la adición de una nueva funcionalidad puede hacerse con un nuevo servicio sin necesidad de modificar los servicios existentes;

– Más resistente: el fallo de un microservicio sólo provoca la indisponibilidad de su funcionalidad en lugar de toda la aplicación.

Es una larga lista de ventajas, pero no debemos olvidar que, la mayoría de las veces, para ganar algo, necesitamos comprometer algo también, y entonces surgen las desventajas. En el caso de los microservicios tenemos inevitablemente una mayor complejidad en comparación con el monolito, ya que se trata de un sistema distribuido. Si nos centramos en la aplicación como un todo, vemos que con los microservicios se consumirá más memoria, el mecanismo de comunicación entre los servicios tiene que ser implementado y probado y hay más paquetes para hacer el despliegue, sin mencionar el desafío que a veces es decidir qué microservicios deben existir.

¿Es entonces aconsejable abrazar ciegamente este concepto de microservicios y abandonar el modelo monolítico para siempre? En mi opinión, no. Ambos tienen mérito y ambos tienen sus casos de uso. Si la aplicación en su conjunto es pequeña, muchas de las ventajas de los microservicios en relación con el monolito desaparecen y las que quedan ya no pueden justificar el aumento de la complejidad. Sin embargo, si se trata, por ejemplo, de una aplicación crítica que no puede estar indisponible o de una aplicación con varios módulos que se actualizan constantemente, los microservicios son un enfoque que debe considerarse seriamente».

Rafael Mendes

Backend Developer – Prime Solutions