Microservicios, ¿tendencia o moda?

En los últimos tiempos, la palabra “microservicios (“microservices”, en inglés) comenzó a escucharse con fuerza. Se trata, en síntesis, de una aproximación de desarrollo que consiste en construir una aplicación sencilla como un conjunto de servicios pequeños. 

Dado que muchos la mencionan como una práctica ideal para el desarrollo de grandes aplicaciones, es importante evaluar sus aspectos positivos y negativos para entender si estamos ante una tendencia o una moda. En primer lugar, hay que entender su esencia. 

Productos, no proyectos

La mayoría de los desarrollos de software se realizan bajo el esquema de proyectos, es decir, un equipo de desarrollo define un alcance y -al cabo de un tiempo- entrega una pieza de software que se considera terminada. Pasado cierto periodo, otro equipo toma el control del producto, y el equipo de desarrollo que formó parte del proyecto se disuelve para luego tomar otros proyectos.

En cambio, en el estilo de microservicios tratan de evitar este modelo ya que prefieren optar por la idea de que un equipo debe estar a cargo del producto durante todo su ciclo de vida. Así, los desarrolladores están en contacto diario con la operación de su software y con el cliente. Este bucle de retroalimentación constante con el cliente es esencial para la mejora de la calidad de servicio.

Este sistema se relaciona también con la vinculación a las capacidades de negocio: en lugar de ver al software como un conjunto de funcionalidades terminadas, hay una relación continua, donde la pregunta es cómo puede el software ayudar a sus usuarios a mejorar.

Si bien este enfoque se podría llevar a las aplicaciones monolíticas, el nivel de granularidad que poseen los microservicios permite que sea más fácil crear relaciones personales entre los desarrolladores de servicios y sus usuarios. 

Principales características de los microservicios 

• Deployment. Se puede hacer deploy del servicio únicamente con el equipo encargado del microservicio.
• Equipos distribuidos. Cada equipo es capaz de programar sin interferir con otros equipos. Además, cambiar una parte no afecta al resto, e incluso no debería afectar la experiencia del usuario final.
• La escalabilidad no está sujeta a ninguna de las partes. Como son independientes, es posible agrupar y distribuir en varios servidores como sea necesario.
• Eficiencia. Gracias a que cada servicio es independiente de los demás y así mismo de gastar los recursos, un servicio podría consumirlos, o algunos servicios podrían compartirlos. Todo dependerá de las necesidades del producto.
• Combinar los servicios como nos interesen. Incluso, reutilizarlos para distintos usos dentro de la empresa, como piezas de puzzle. Podemos crear aplicaciones que usen una misma lógica de negocio, sin estar cautiva en una aplicación monolítica.
• Su fallo no arrastra a todo el sistema. Si un componente no funciona correctamente, no afecta al resto. Se puede aislar y manejar el error, desplegándolo por separado.
• Simplificamos el mantenimiento. Cumplen a la perfección el principio SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion). Pore so, se pueden desechar componentes que no sean utilizados, o extenderlos en otros para engancharlo en nuestra aplicación. Además, es más fácil tirar algo que no usamos a la basura, que mantenerlo como código legacy dentro de una aplicación monolítica.
• La mejor tecnología para cada problemática. Al pensar en microservicios donde cada uno de estos resuelve una problemática diferente, empezamos a hablar de diferentes productos dentro de nuestra aplicación, donde los mismos pueden tener lenguaje/arquitectura/Base de datos diferentes de acuerdo a las características que el producto requiera.

Limitaciones

Los microservicios también tienen sus desventajas ya que crean un conjunto nuevo de problemas, empezando por el despliegue. Una aplicación monolítica se instala con un programa especializado o se despliega como un archivo WAR en un contenedor de servlets.

Pero los microservicios pueden estar distribuidos en diferentes servidores y estar escritos en diferentes lenguajes. Por eso, el uso de herramientas de generación de máquinas virtuales como Vagrant y de despliegue continuo como Jenkins es una necesidad imperiosa en las arquitecturas microservicios.

Este recurso tampoco soluciona el problema del versionado. Lo que proponen es hacer resilientes los clientes a fallos en los microservicios proveedores, lo cual es más fácil de decir que de hacer.

Pero quizá el problema más grave es el mantenimiento de la consistencia de datos replicados entre los dominios de diferentes servicios: en la mayoría de las arquitecturas basadas en microservicios los datos son sólo eventualmente consistentes, lo que significa que es posible que dos clientes que se ejecutan en paralelo reciban resultados diferentes. El mayor error de diseño que yo he encontrado hasta ahora en las aplicaciones basadas en servicios es montar la replicación de forma explícita y carecer de un buen mecanismo de consolidación de datos. Por todo esto, conviene recordar que evitar la redundancia y la inconsistencia de datos fueron las dos razones principales para diseñar en un principio aplicaciones monolíticas transaccionales.

Conclusiones

Si bien este nuevo paradigma está adquiriendo mucha fuerza en la comunidad, hay que analizar su aplicación en cada caso, ya que una correcta implementación de esta arquitectura puede potenciar increíblemente el producto que se está desarrollando. Pero tomar apresuradamente la decisión de migrar a esta estructura puede generar el fracaso de tu proyecto.

Como recomendación personal, sugiero que si están en un ambiente cambiante y complejo apuesten por los microservicios, pero si los tiempos para desarrollar la arquitectura principal son cortos y además el time to market es un factor clave del producto, elijan otra arquitectura. En todo caso, hay que recordar que en un proceso de mejora continua se pueda ir haciendo reingeniería y pasar a este paradigma que es altamente beneficioso cuando es bien implementado.