Es difícil que no hayas escuchado antes el término Microservicio, e incluso puede ser que hayas entrado en esta página buscando información sobre ello. Se trata de un término muy en boga en la actualidad, aunque también escucharás hablar de «Arquitectura de microservicios» o de que una aplicación sigue dicha arquitectura.

Definición

Cuando hablamos de microservicios nos referimos a un enfoque orientado a sistemas distribuidos que promueven el uso de servicios de grado más fino, con sus propios ciclos de vida, que colaboran juntos a través de peticiones HTTP a sus API.

Debido a que los microservicios se modelan en torno a los dominios de negocio, se evitan los problemas de arquitecturas en capas y monolíticas tradicionales.

Además cada microservicio es independiente y su código debe ser desplegado sin afectar a los demás. Cada uno de ellos puede escribirse en el lenguaje de programación más adecuado, ya que sólo exportan la API.

Ventajas

Los microservicios por tanto son un nuevo enfoque de las aplicaciones tradicionales, en las cuales teníamos un servidor ejecutando el código de la aplicación en un archivo war. Cada vez que algún módulo / servicio sufría un cambio, debíamos subir a producción de nuevo todo el código, incluyendo los módulos no modificados. En el caso de que haya un módulo de la aplicación que se encuentre saturado de peticiones y queramos balancear la carga, es necesario replicar toda la aplicación en otro servidor.

Frente al enfoque tradicional y en vez de tener un único ejecutable, cada servicio se ejecuta en su propio proceso, comunicándose entre si mediante llamadas a sus respectivas API. Cada microservicio, por tanto se puede desplegar de forma autónoma, de manera que dicho despliegue no afecta a los demás microservicios. Son más fáciles de escalar ya que en vez de replicar toda la aplicación, lo haremos sólo de los microservicios con más carga.

Otras ventajas de esta arquitectura es que se reduce el «Time to market» debido a que evita retrasos en la integración de la nueva funcionalidad en la aplicación monolítica. No hay unanimidad sobre esto, ya que diferentes autores indican que debido a la naturaleza distribuida de la aplicación el time to market será mayor. A continuación se enumeran las ventajas de este enfoque:

• Los servicios son muy simples, enfocados en hacer una cosa y hacerla bien. Algunos autores aseguran que Microservicios es SOA bien hecho.
• Cada servicio puede ser construido utilizando la mejor herramienta y la más apropiada para el trabajo que va a realizar.
• Se trata de sistemas débilmente acoplados.
• Múltiples desarrolladores y equipos pueden realizar entregas de manera independiente.
•  Facilita la entrega continua, permitiendo lanzamientos frecuentes, manteniendo el resto del sistema disponible y estable.

Desventajas

Pero no todo son ventajas y un sistema basado en Microservicios posee una complejidad añadida:

• Un gran número de microservicios son difíciles de orquestar.
• Dificultad para gestionar y realizar test de las dependencias.
• Aplicación no uniforme. Poder elegir entre diferentes tecnologías conlleva diseños de aplicación y arquitectura no uniformes, lo que puede incrementar el coste de mantenimiento a largo plazo.
• Complejidad DevOps. Es necesario tener un equipo Dev Ops maduro para manejar la complejidad en mantener aplicaciones basadas en microservicios.
• Incremento del uso de recursos. La inversión inicial para ejecutar estas aplicaciones es alto, debido a la ejecución independiente de cada componente en su propio proceso o contenedor de ejecución (más RAM y CPU).
• Incremento de la comunicación por la red. Este sistema requiere conexiones confiables y rápidas.
• Marshalling – Unmarshalling. Cuando un servicio requiere datos de otro, el llamante encapsula los datos en algún estándar desde su representación interna, mientras que el llamado realiza una la operación contraria para operar con dichos datos. Esto requiere más procesamiento en comparación con una arquitectura de aplicación convencional.
• Seguridad en la red. La comunicación entre servicios necesita ser securizada para evitar brechas de seguridad. Debido a la composición de diferentes módulos «movibles», estas aplicaciones son más vulnerables en cuanto a seguridad.
• Testing. Incremento de la complejidad para realizar testing de estas aplicaciones en comparación con aplicaciones monolíticas.
• Monitorización en producción. El coste de monitorizar esta aplicación es mayor y la no disponibilidad de las herramientas adecuadas es un tema a ser considerado.
• Logs y trazas. nos encontramos con una fuente inagotable de logs generados por cada uno de los procesos, por los contenedores que ejecutan los microservicios y por el propio servidor físico o virtual.
• Transaccionalidad en las operaciones. Los microservicios por naturaleza son «stateless, por lo que se ve la necesidad de una tercera capa de persistencia y gestión de la transaccionalidad.

Conclusiones

Se trata de un enfoque que no es nuevo pero en el que muchas empresas están poniendo el foco debido a la complejidad a la que han llegado sus aplicaciones empresariales. La Arquitectura de microservicios no es para todo el mundo pero se adapta perfectamente a aplicaciones enterprise o proyectos que seguro van a escalar. La velocidad gana en el mercado y la idea de Microservicios es ganar en velocidad, pero también supone cambios en la empresa, empezando por integrar primero DevOps y herramientas de DevOps en la misma. ¿Están las empresas preparadas para dar el paso a Microservicios?