Del monolito a los microservicios

El desarrollo de una nueva aplicación nace siempre de la necesidad de resolver algún problema. Muchas de estas aplicaciones comienzan resolviendo algo muy sencillo que poco a poco crece y crece hasta que resuelve demasiados problemas a la vez y generalmente de manera exponencial en complejidad programática.

Es así como una aplicación se va convirtiendo en algo cada vez más grande y difícil de gobernar. De aquí surge la necesidad de hacer un alto y pensar en una mejor estrategia.

¿Qué hay realmente detrás de una arquitectura monolítica?

Pues a simple vista nada especial. Tenemos un aplicativo que nos permite entregar rápidamente funcionalidades en un cierto periodo de tiempo entregando al usuario mucho valor. Los retos se van viendo en el tiempo cuando:

• Nuestra la aplicación va adquiriendo nuevas funcionalidades, crece nuestro código lo que hace que cada vez sea más difícil de manejar y de entender.
• Como toda la aplicación, está desarrollada en un único stack tecnológico que nos ata pues diferentes problemas y complejidades las tenemos que abordar con la misma tecnología. Además, no podremos cambiar el stack por el alto esfuerzo que implica.
• Refactorizar el extenso código sería una tarea titánica y cuando menos arriesgada.
• También sucede que cuando algo falla, toda la aplicación falla. Es entonces cuando nos damos cuenda de que el código es interdependiente haciendo que la aplicación se detenga ante cualquier problema en cualquier parte. En caso de aplicaciones con misión crítica esto es terrible.
• Escalar la aplicación a nivel de recursos para soportar más carga (datos, usuarios, etc.) significa necesariamente escalar todo el monolito cuando es posible que sólo una parte de este necesite de más poder de cómputo.
• A medida que crece la aplicación se hace tan interdependiente que es casi imposible trabajar de manera aislada sin impactar en otros desarrollos.

Microservicios

Fue así como se llegaron a estudiar numerosas estrategias acerca de nuevas arquitecturas que puedan ayudarnos a hacer crecer nuestra aplicación sin arrastrar todos estos inconvenientes.

De la necesidad se hizo la virtud. Llegamos a los microservicios. Una forma de hacer grandes proyectos de software en pequeños módulos desacoplados que se comunican entre sí mediante una siempre accesible y sencilla API.

Esta arquitectura modular, además, se adapta muy bien a grandes proyectos basados en la nube. Frente a la arquitectura monolítica, los microservicios presentan las siguientes ventajas:

• Mejoran la tolerancia al fallo, dado que la aplicación está compuesta de módulos desacoplados buena parte de la aplicación puede seguir funcionando a pesar de que algún módulo falle.
• Nos liberan de estar atados a un stack tecnológico concreto, si alguien quiere probar una nueva tecnología en un servicio individual lo puede hacer sin afectar el funcionamiento de toda la aplicación. En caso de falla es más sencillo volver al estado anterior.
• Igualmente podremos utilizar diferentes stacks tecnológicos para diferentes propósitos que hagan una programación más sencilla y óptima en tiempos de ejecución.
• Es más sencillo entender y de explicar un módulo específico que tener que aprender todo el monolito.
• Los microservicios son más sencillos de escalar y permiten poner los recursos en los módulos que son necesarios y de misión crítica, pudiendo crear un balance armónico y un consumo de recursos más sostenido y a medida de cada necesidad.
• Los equipos de desarrollo serán más pequeños y dedicados.
• Se puede actualizar un servicio sin tener que re implementar el resto de la aplicación.

Pero como todo en la vida, nada es perfecto y tampoco lo serán las arquitecturas de microservicios. Tendremos por ello que poner especial atención en:

• Hacer que todas las piezas de la arquitectura funcionen de manera armónica.
• Tener especial cuidado en la redirección de servicios, especialmente con la latencia de red.
• Evitar que el manejo de transacciones en múltiples servicios se vuelva complejo de manejar.
• Probar los servicios de manera individual será más fácil, pero tendremos que poner especial atención en las de integración.
• Desplegar múltiples servicios de varios equipos de desarrollo.

Con todo y con ello, es igualmente cierto que con las herramientas de automatización correctas tendremos muchas ayudas que nos ayuden a paliar estos aspectos.

Adoptando Microservicios

Como ya hemos expuesto, arquitectura de microservicios es una meta, pero para alcanzarla tenemos que pasar por distintas etapas, con diferentes objetivos pues es completamente necesario pasar de una a otra sin romper mientras la continuidad del servicio.

Así que iremos paso a paso hasta lograr llegar a la arquitectura:

• Identificar y separar los contextos de la aplicación pues deben funcionar de manera independiente y aislada, esto quiere decir que mientras los contratos entre servicios se mantengan, dos o más servicios no deberían verse afectados por nuevas implementaciones, ni por cambios a los mismos.
• Obtener las dependencias en el sistema monolítico.
• Diseño e implementación de la interfaz.
• Migrar y crear nuevas funcionalidades en módulos. Una buena práctica es la de hacer que cada servicio realice un único cometido.
• Convertir las dependencias en API.
• Implementar test unitarios y de integración para realizar pruebas de cada servicio de manera independiente e integrado con cada uno de los demás servicios.
• Crear una estrategia de convivencia que de soporte en el tiempo de migración.
• Despliegue, cada interfaz y API debe poder ser desplegado de una manera sencilla en un contenedor auto gestionado, poco a poco deberán poder ser desplegadas automáticamente.
• VOILÁ.

Por todo ello, los microservicios no son una moda, están para quedarse, lo tenemos claro. ¿Por qué? por la alta disponibilidad, por la elasticidad, por la escalabilidad, por la mantenibilidad y por la auditabilidad.