No caiga en la trampa de que "los microservicios son geniales" y sepa cuándo es mejor optar por un modelo monolítico

Los monolitos y los microservicios son dos enfoques básicos para crear aplicaciones. Algunas personas los consideran heredados y modernos, respectivamente. Pero esto no es del todo correcto. Elegir entre ellos es una cuestión muy compleja, ya que ambos tienen sus pros y sus contras.

La mayoría de las aplicaciones nuevas no necesitan ser microservicios desde el principio. Es más rápido, más fácil y más barato empezar como un monolito y pasar a los microservicios más adelante si lo considera beneficioso.

Con el tiempo, a medida que las aplicaciones monolíticas se vuelven cada vez menos fáciles de mantener, algunos equipos deciden que la única forma de resolver el problema es comenzar a refactorizar dividiendo su aplicación en microservicios. Otros equipos toman esta decisión simplemente porque "los microservicios son geniales". Este proceso lleva mucho tiempo y, a veces, genera incluso más gastos de mantenimiento. Antes de comenzar, es fundamental considerar cuidadosamente todos los pros y contras y asegurarse de haber alcanzado los límites actuales de la arquitectura monolítica. Y recuerde, es más fácil romper que construir.

En este artículo, no vamos a comparar monolitos con microservicios. En cambio, analizaremos consideraciones, patrones y principios que le ayudarán a:

• sacar lo mejor de su monolito actual y prepararlo potencialmente para entrar en microservicios;
• Proporcionar una migración perfecta desde el monolito a los microservicios;
• comprender qué más puede cambiar con la migración de microservicios.

Monolito modular

Lo primero que debes hacer es mirar la estructura de tu proyecto. Si no tienes módulos, te recomiendo encarecidamente que los consideres. No te obligan a cambiar tu arquitectura a microservicios (lo cual es bueno porque queremos evitar todo el mantenimiento correspondiente), pero te sacan muchas ventajas.

Según la herramienta de automatización de compilación de su proyecto (por ejemplo, Maven, Gradle u otra), puede dividir su proyecto en módulos separados e independientes. Algunos módulos pueden ser comunes a otros, mientras que otros pueden encapsular áreas de dominio específicas o ser específicos de una característica, lo que aporta funcionalidad independiente a su aplicación.

Te brindará los siguientes beneficios:

1. Partes desacopladas de su aplicación.
2. Las funciones se pueden desarrollar de forma independiente, lo que minimiza los conflictos.
3. Es mucho más fácil incorporar nuevas personas ya que no necesitan profundizar en todo el proyecto; en cambio, pueden comenzar desde partes aisladas.
4. Pruebas mejoradas, porque ahora puedes probar cada módulo por separado.
5. Si eventualmente necesitas migrar a microservicios, tienes una base muy sólida para ello.

Como puede ver, el monolito modular es la forma de obtener lo mejor de ambos mundos. Es como ejecutar microservicios independientes dentro de un único monolito, pero evitando la sobrecarga de microservicios colaterales. Una de las limitaciones que puede tener es no poder escalar diferentes módulos de forma independiente. Tendrá tantas instancias de monolito como requiera el módulo más cargado, lo que puede generar un consumo excesivo de recursos. El otro inconveniente son las limitaciones de usar diferentes tecnologías. Por ejemplo, no puede mezclar Java, Golang y Python en un monolito modular, por lo que se ve obligado a ceñirse a una tecnología (lo que, por lo general, no es un problema).

El patrón de la higuera estranguladora

Piense en el patrón Strangler Fig. Su nombre se debe a un árbol que envuelve y eventualmente reemplaza a su anfitrión. De manera similar, el patrón sugiere que reemplace partes de una aplicación heredada con nuevos servicios uno por uno, modernizando un sistema antiguo sin causar interrupciones significativas.

En lugar de intentar una revisión arriesgada y completa, se actualiza el sistema pieza por pieza. Este método es beneficioso cuando se trata de monolitos grandes y complejos que son demasiado difíciles de manejar para reemplazarlos en un solo esfuerzo. Al adoptar el patrón de la higuera estranguladora, los equipos pueden eliminar gradualmente el sistema antiguo mientras fomentan el crecimiento del nuevo, minimizando los riesgos y asegurando la entrega continua de valor.

Para implementar el patrón Strangler Fig, debes seguir tres pasos:

1. Transformar. Aquí, se identifica qué parte extraer del monolito y se implementa como un microservicio independiente. Reescribe esta parte utilizando tecnologías modernas y aborda los problemas de la implementación anterior. Aprovecha la oportunidad para hacerlo mejor.
2. Coexistir. Cuando un nuevo microservicio está listo para producción, lo ejecutas en tu infraestructura, manteniendo la implementación heredada. Distribuyes el tráfico en cierta proporción, moviendo gradualmente más y más tráfico a la nueva implementación, pero siempre tienes tu versión anterior como una reversión.
3. Eliminar. Después de un tiempo, cuando considere que su nuevo microservicio es lo suficientemente confiable, traslade todo el tráfico al nuevo microservicio y elimine el antiguo.

Siguiendo estos tres pasos, irás descomponiendo gradualmente un monolito en microservicios.

Los principales beneficios de utilizar el patrón Strangler Fig son:

• Migración gradual. En lugar de tener problemas y comenzar una revisión completa, arriesgada y oportuna del sistema, el patrón le permite realizar la transición paso a paso. Puede actualizar lentamente su sistema y sincronizar esta transformación con los planes de desarrollo de características. Por ejemplo, puede encontrar una parte del monolito que algún desarrollo de características afectará seriamente y elegirla como candidata para la migración a microservicios.
• Entrega continua. Este beneficio proviene de la afirmación anterior. El proceso de modernización no impide que su equipo entregue nuevas funciones de forma continua. Mientras un equipo desarrolla nuevas funciones, otro refactoriza módulos independientes.
• Mitigación de riesgos. El patrón Strangler Fig ayuda al equipo a centrarse en la modernización de partes específicas del sistema. Este enfoque permite al equipo prestar más atención a los detalles en áreas específicas, detectar problemas potenciales antes y minimizar el impacto general en la aplicación.

Cuestiones y consideraciones

Al aplicar el patrón Strangler Fig, se debe planificar la estrategia de migración con cuidado. Esto incluye identificar qué componentes reemplazar primero, garantizar la integración adecuada entre las piezas antiguas y las nuevas y mantener modelos de datos consistentes. Los equipos también deben establecer canales de comunicación claros y sistemas de monitoreo para realizar un seguimiento del progreso y el impacto de cada reemplazo.

Repercusiones de la migración de microservicios

Como ya comentamos antes, la transición a los microservicios trae consigo beneficios, pero también dificulta y encarece muchas otras cosas.

Por ejemplo, los equipos de control de calidad y desarrollo pueden enfrentarse a una situación en la que ya no pueden realizar pruebas en máquinas locales porque la capacidad de ejecutar varios microservicios localmente es limitada. O sus registros pueden volverse menos reveladores porque, en lugar de que un servicio procese un solo flujo, ahora lo procesan varios servicios. Como resultado, para ver la secuencia de registros completa, debe implementar la instrumentación y el seguimiento adecuados.

Analicemos algunos aspectos cruciales que debe considerar y tal vez planificar antes de que comience su transformación de microservicios.

Despliegue e infraestructura

Los monolitos y los microservicios tienen diferentes requisitos mínimos de infraestructura.

Al ejecutar una aplicación monolítica, normalmente se puede mantener una infraestructura más sencilla. Las opciones como máquinas virtuales o soluciones PaaS (como AWS EC2) serán suficientes. Además, se puede gestionar gran parte del escalado, la configuración, las actualizaciones y la supervisión de forma manual o con herramientas sencillas. Como resultado, se pueden evitar configuraciones de infraestructura complejas y confiar en desarrolladores o ingenieros de soporte sin necesidad de una amplia experiencia en DevOps.

Sin embargo, la adopción de una arquitectura de microservicios cambia esta dinámica. A medida que aumenta la cantidad de servicios, un enfoque manual y práctico rápidamente se vuelve impráctico. Para orquestar, escalar y administrar de manera eficaz múltiples servicios, necesitará plataformas especializadas como Kubernetes o, al menos, un servicio de contenedores administrado, lo que introduce una nueva capa de complejidad y demandas operativas.

Capa de plataforma

Mantener una aplicación monolítica es relativamente sencillo. Si surge un error CVE, se actualiza la dependencia afectada en un solo lugar. ¿Necesita estandarizar la comunicación de servicios externos? Implemente un único contenedor y reutilícelo en todo el código base.

En un entorno de microservicios, estas tareas sencillas se vuelven mucho más complejas. Lo que antes era trivial ahora implica coordinar cambios entre múltiples servicios independientes, cada uno con su ciclo de vida y dependencias. La complejidad añadida aumenta los costos tanto en tiempo como en recursos. Y la situación empeora cuando se tienen muchos equipos y muchos servicios diferentes.

Por lo tanto, muchas organizaciones introducen una capa de plataforma dedicada, generalmente administrada por un equipo de plataforma. El objetivo es crear una base que todos los microservicios puedan heredar: administrar dependencias comunes, implementar patrones estandarizados y proporcionar contenedores listos para usar. Al unificar estos elementos a nivel de plataforma, se simplifica significativamente el mantenimiento y se fomenta la coherencia en todo el sistema.

Conclusión

Dividir un monolito en microservicios es una transformación arquitectónica significativa que requiere una cuidadosa consideración y planificación.

En este artículo, analizamos los pasos que puede seguir para prepararse y atravesar el proceso sin problemas. Si se atiene al patrón Strangler Fig, podrá realizar el proceso incremental y garantizar la estabilidad del sistema durante toda la transformación. Además, el monolito modular no solo puede ser un paso de preparación útil, sino que también puede aportar beneficios que pueden impulsarlo a reconsiderar su decisión de transformación de microservicios y evitar la complejidad operativa correspondiente.