Estrategias de transición hacia los microservicios

Las arquitecturas basadas en microservicios se han convertido en uno de los recursos más eficientes y beneficiosos en el paradigma del diseño de software, y actualmente están consiguiendo reemplazar a los tradicionales sistemas monolíticos. Este tipo de arquitectura consiste en la construcción de una aplicación con el concepto de un conjunto de pequeños servicios que realizan operaciones independientes. Actualmente, son mucho más eficientes que un sistema monolítico tradicional, ya que cuentan con numerosas ventajas, como su sencilla implementación o su alta escalabilidad, entre otras. 

Tanto es así, que cada vez son más clientes, conscientes de los beneficios de una arquitectura microservicios, los que están comenzando a migrar sus aplicaciones y programas a una arquitectura de microservicios, que propiciará una mejora muy significativa tanto para el equipo de desarrollo como para los propios usuarios finales. Al realizar la migración, nuestro principal objetivo es construir una solución que continúe resolviendo todos los objetivos y necesidades por parte del cliente, y que podrá ser de distintos tipos, como luego veremos. 

Sin embargo, es vital ser conscientes de que este proceso de migración a microservicios conlleva una planificación específica y un sobreesfuerzo para cada proyecto, en el que intervienen diversos factores, siempre tomando como punto de partida las necesidades y requerimientos exigidos por parte del cliente. 

Comparativa abstracta entre un sistema monolítico y uno basado en microservicios. 

En este artículo nos centraremos en debatir las diferentes estrategias de transición hacia los microservicios que podemos aplicar para que esta migración se lleve a cabo de manera satisfactoria, así como en describir posibles obstáculos que puedan surgir a lo largo de este proceso, y cómo superarlos. 

Estrategias de transición hacia los microservicios

Consideraciones previas 

Antes de decidir y adoptar una forma de abordar la migración, cuando estamos realizando la planificación relacionada con el sistema involucrado debemos tener presentes los siguientes aspectos: 

1. Determinar los servicios

Es esencial determinar qué servicios se crearán, de manera que estarán delimitados por la descomposición del sistema monolítico. Así, por ejemplo, si en una aplicación existen partes en las cuales se realizan despliegues de manera frecuente, o un gran ratio de cambios, esto nos puede dar pistas de posibles servicios para nuestro sistema. Estos límites nos ayudarán a que la estructura de los microservicios a crear esté definida correctamente. 

Este concepto forma parte del Diseño Dirigido por el Dominio (DDD), y se conoce como bounded context, el cual nos garantizará que el equipo de desarrollo comprenda de manera correcta los requisitos. Además, el uso del context map, una herramienta que representa de manera visual la relación entre los bounded context y su integración, aportará coherencia al sistema.

2. Realizar pruebas (testing)

Estas pruebas nos asegurarán que, a lo largo del proceso de desarrollo, la funcionalidad inicial esté garantizada, de forma que la transición se realice de manera efectiva, y que todos sus componentes estén soportados. Este proceso va directamente relacionado con el concepto de integración continua, que es un tipo de metodología que se aplica en el desarrollo de software, y que nos permite evitar grandes cambios futuros, así como estar constantemente revisando el funcionamiento del sistema.

Dentro de las pruebas que se pueden realizar, nos encontramos con los siguientes tipos:

• Tests unitarios: para verificar métodos o funciones concretas
• Tests de integración: para observar que el funcionamiento entre las diferentes capas/clases de un servicio es el correcto
• Tests E2E (end-to-end):verifican la interacción entre microservicios, y cómo funcionan como sistema completo

También existen las pruebas de contrato, que se encargan de comprobar la interacción entre componentes, asegurando que se cumplen los acuerdos establecidos en materia de comunicación o de especificaciones y documentación.  Estas pruebas son útiles cuando varios equipos diferentes se encargan de microservicios interconectados, de manera que, si se produce algún cambio en un microservicio de otro equipo, siempre se tiene que cumplir dicho contrato, evitando así desajustes con el resto de microservicios. 

Una vez que hemos planificado correctamente cómo vamos a proceder con respecto a la transición, vamos a ver qué estrategias se pueden aplicar para que esta migración se complete exitosamente. 

Posibles estrategias de transición hacia los microservicios

Hasta ahora, hemos tenido en cuenta los distintos servicios y la idea de realizar pruebas automáticas aplicando integración continua, es decir, de manera frecuente y al incorporar nuevo código a lo largo del desarrollo. ¿Cómo podemos migrar nuestro sistema de manera óptima? Podemos establecer 3 estrategias que pueden llevarse a cabo a la hora de realizar la transición, si bien es cierto que pueden existir múltiples variaciones en función de cada sistema concreto. Destacamos: 

• La más reconocida y que ya hemos comentado previamente es la estrategia ICE CREAM SCOOP, la cual consiste en ir desgranando (scooping out) componentes del monolito en servicios independientes. Se trata de un proceso gradual, lo cual hace que convivan ambas arquitecturas. De esta manera, no habrá riesgo de que el despliegue o la experiencia de usuario se vean afectados. Sin embargo, esto obligará a contar con un amplio equipo de desarrollo, durante un amplio periodo de tiempo.
• La segunda estrategia es LEGO, que consiste en apilar el monolito y una capa de microservicios, lo que da como resultado una arquitectura híbrida. Es apropiada para aplicaciones excesivamente grandes o complejas para ser refactorizadas completamente. Como principal desventaja, encontramos que seguimos contando con el monolito y sus limitaciones y, además, habrá que crear nuevas APIs a medida que se añadan características para que haya soporte de los microservicios. Aplicaciones como Spotify o X (antes Twitter) utilizan este tipo de estrategia, combinando microservicios con un enfoque monolítico en ciertas áreas de su sistema. 
• Como última estrategia, tendríamos NUCLEAR OPTION, que, como su propio nombre nos deja intuir, consiste en reescribir toda la aplicación de forma que se desarrolle íntegramente basándose en microservicios. Es muy poco recomendable y rara vez se utiliza, pero puede ser útil en determinados escenarios donde las aplicaciones se han descontrolado en producción, y el coste de refactorizarla sea mayor que el de partir de cero. Nos daría la oportunidad, además, de replantear algunas de las decisiones tomadas. A su vez, el reescribir la aplicación desde cero es una gran desventaja por los problemas que genera, y porque los usuarios finales tendrán que convivir con un monolito obsoleto hasta que la nueva arquitectura esté lista. 

Posibles obstáculos a vencer 

 A pesar de la aplicación de las estrategias comentadas, muchas empresas no siguen correctamente los pasos necesarios para que esta transición se efectúe correctamente, lo que da lugar a algunas confusiones e inexactitudes que debemos superar. Entre las más comunes encontramos: 

• La creación de un “monolito distribuido”, que consiste en tener numerosos microservicios con una única base de datos común. Esto es un error de concepto, ya que nos encontramos con un punto único de fallo: si la base de datos cae, lo hace el sistema completo. Este fallo es más común de lo que pensamos: para evitarlo, debemos crear diferentes bases de datos para los microservicios, y que estos sean los encargados de comunicarse entre sí de manera síncrona o asíncrona. 
• Utilización de “nanoservicios”, que consiste en el uso de microservicios demasiado pequeños con una única función específica,  lo que hará que el sistema sea complicado de gestionar y generará un incremento en la latencia. Para evitarlo, se deberían crear microservicios que estén correctamente delimitados, de manera que no exista un acoplamiento excesivo entre los mismos. 
• La latencia de red es un aspecto muy importante que muchas veces no se tiene en consideración, y que debe estar controlado en nuestro sistema para así poder ofrecer un servicio correcto con las mejores prestaciones posibles.
• No tener en cuenta la observabilidad es algo que no debemos obviar, ya que es fundamental conocer el estado de nuestro sistema de cara a poder afrontar de la mejor manera posible los problemas que surjan. Para este cometido, se cuenta con una gran variedad de tecnologías, como por ejemplo el stack ELK, que se trata de un conjunto de productos que nos permiten monitorizar y registrar métricas de nuestros microservicios, utilizando soluciones como Grafana o Kibana. Todas estas herramientas nos ayudarán a ejecutar analíticas donde conoceremos el estado de nuestro sistema.

Debemos tener presentes siempre todos estos posibles inconvenientes para así poder tomar las decisiones correctas y, de esta manera, hacer que nuestro nuevo sistema de microservicios pueda brindar las mejores prestaciones. A pesar de ello, es posible que en nuestro sistema conviva alguna de estas malas prácticas, pudiendo ser una solución rápida, conveniente y que mejora el enfoque monolítico, pero tenemos que pensar que, en el largo plazo, lo ideal sería mejorar este tipo de prácticas, para que nuestra aplicación sea más robusta y sostenible. 

Conclusión

Como ya hemos expuesto, la transición a una nueva arquitectura basada en microservicios nunca es una tarea sencilla. Es fundamental realizar una buena planificación previa y un correcto análisis sobre cuál es la estrategia más apropiada para nuestra aplicación. Además, resulta esencial contar con un amplio equipo, entre los que convivan desarrolladores, arquitectos de software, DevOps, especialistas en bases de datos…, complejizando el mantenimiento de dicha arquitectura.

A pesar de esto, el contar con un equipo y con la formación adecuada, como la que puedes encontrar en hiberus, hará que el proceso sea más simple, facilitando el trabajo al equipo y haciendo que las expectativas y requerimientos se cumplan de manera eficaz. Además, dispondrás de un mejor mantenimiento de tu aplicación, así como una mayor adaptabilidad a los cambios, ya que se realizarán de manera más rápida, entre otras muchas ventajas. En hiberus contamos con un equipo de expertos en microservicios y te ayudamos a migrar tu negocio digital a una nueva arquitectura microservicios en base a las necesidades de tu proyecto.

Los beneficios que los microservicios aportarán a tu aplicación serán claves para su éxito. ¡No dudes en comenzar a descubrirlos!