Migración a microservicios: la transición del monolito a los microservicios

Los monolitos pueden llegar a cumplir su función en muchos clientes. De hecho, hasta hace pocos años, eran la norma. Se empaquetaba todo en un único servidor web y no se iba más allá. Sin embargo, a día de hoy, las arquitecturas basadas en microservicios están de moda.

Y no es un sinsentido, ya que, como comentamos en el artículo anterior «Beneficios de una arquitectura microservicios«, desplegar un sistema complejo en una arquitectura de microservicios supone una serie de beneficios que, tarde o temprano, notarán los usuarios finales.

La decisión de llevar a cabo una migración a una arquitectura de microservicios y, concretamente, a microservicios basados en eventos, se suele tomar cuando el código existente en un monolito se hace insostenible por la gran cantidad de deuda técnica que alberga: 

1. Hay partes duplicadas.
2. No hay tests automáticos que prueben casos de uso.
3. Existe la necesidad de escalar verticalmente, es decir, mejorar el servidor web en el que está desplegado el monolito, en fechas clave.
4. Para introducir cambios hay que parar todo el sistema.
5. Un error hardware obliga a reiniciar.

Desde nuestra experiencia, los microservicios resuelven problemas de escalabilidad y de rendimiento, además de mejorar el trabajo en equipo y la eficiencia de trabajo. Pero no solamente lo pensamos nosotros, sino que también lo piensan cientos de programadores que fueron encuestados en el año 2020 por The Software House (State of Microservices).

¿Qué es una migración?

Pero, ¿en qué consiste una migración? Se utiliza el verbo migrar a conciencia. ¿Por qué? Porque no se tiran ni el código, ni los datos, ni se empieza a implementar todo desde cero, sino que, teniendo en cuenta lo viejo: aprendizaje sobre el dominio del problema, documentación sobre qué partes han sido complicadas de diseñar/implementar/probar, etc., se construye una solución que sigue satisfaciendo las necesidades de los clientes pero de una manera más eficiente, segura, sostenible y auditable.

8 pasos para hacer una migración a microservicios

Y, ¿cómo se podría hacer una migración? Al no ser una ciencia exacta, es complicado redactar una receta genérica, pues depende en gran parte de los requisitos funcionales del cliente, del estado del monolito y de qué enfoque arquitectural se le quiera dar (luego hablaremos más sobre esto). Sin embargo, como en Hiberus tenemos un equipo especializado en microservicios con varios años de experiencia, hemos recopilado 8 pasos que se han dado en todas nuestras migraciones:

1. Es necesario identificar las partes del código (dominios) que están altamente cohesionadas y bajo acopladas con el resto, puesto que son susceptibles de ser separadas a un microservicio aparte. Por ejemplo, si la aplicación legada está construida en Java, sus paquetes nos pueden dar una idea de estas separaciones por dominio. Ejemplos de dominio pueden ser: usuarios, productos, tiendas… 
2. Separar los dominios en distintos proyectos. Se pueden utilizar lenguajes de programación distintos para cada proyecto, dependiendo de las necesidades de cada dominio. Nuestro consejo es que se trate de homogeneizar, a no ser que haya casos en los que de verdad merezca la pena implementar un dominio en un lenguaje de programación específico. Ejemplo: queremos usar Python para el dominio de Business Intelligence porque hay muchas bibliotecas que nos pueden facilitar ese tipo de trabajo, pero no queremos usarlo en el resto de dominios, puesto que queremos un lenguaje fuertemente tipado.
3. Obtener un grafo de las dependencias existentes en el sistema legado monolítico entre los dominios identificados. Se puede utilizar alguna herramienta que analice el proyecto.
4. A partir de las dependencias, diseñar una interfaz (diseño API first) para cada uno de los dominios. Estas APIs (pueden ser REST, GraphQL, gRPC…) serán la nueva puerta de entrada a cada uno de los mismos. Esto significa que si el dominio de tiendas necesita algo del dominio de productos, deberá utilizar alguna de las operaciones que ofrece el dominio de productos en su API.
5. Una vez se hayan diseñado las interfaces, habrá que implementarlas. Es en este momento cuando nos acordamos de que nuestro monolito tenía una única base de datos y en las tablas se mezcla la información de distintos dominios. ¿Qué hago ahora con la tabla “compras” cuyas filas representan a un “usuario” que ha adquirido un “producto” en una “tienda”? Como se puede apreciar, es síntoma de que hay otros dominios que no habíamos identificado en el paso 1 porque no estaban explícitamente diferenciados en el código pero sí lo estaban en la base de datos. El dominio de compras puede ser perfectamente válido, y una solución a este tipo de problemas es reflejarlo en la nueva arquitectura. Es momento de migrar los datos a los nuevos esquemas de datos de cada uno de los diferentes microservicios. Este paso puede llegar a ser muy costoso, a la par que complicado. Por eso es necesario disponer de un equipo de profesionales altamente cualificado que sea capaz de llevar a cabo esta migración de datos.
6. Una vez todos y cada uno de los microservicios son sencillos, hacen lo que tienen que hacer (y no más) con la ayuda (o no) de una o varias BBDD, es hora de integrarlos. Esto es, hacer que interactúen entre ellos, convirtiendo las dependencias de módulos que había en el monolito en llamadas a sus APIs.
7. Se deberían implementar tests unitarios para cada uno de los microservicios (entendiendo el microservicio como unidad), además de tests de integración que comprueben que saben trabajar en conjunto. Estos últimos deberían tener en cuenta las particularidades que tiene todo sistema distribuido: pérdida de mensajes, particiones de red, caída de los microservicios…
8. ¡A desplegar! Cada microservicio puede estar alojado en uno o varios servidores distintos, proporcionando: alta disponibilidad, elasticidad, escalabilidad, mantenibilidad y auditabilidad.

Antes hemos comentado que hablaríamos más sobre enfoques arquitecturales, y es que, dentro de las arquitecturas de microservicios, podemos identificar, como mínimo, un par de enfoques:

• Síncrono: se produce una conversación entre los microservicios, puesto que siguen un esquema de petición-respuesta. Este es el caso que hemos ejemplificado en los pasos anteriores, puesto que todos los microservicios exponen APIs síncronas.
• Asíncrono (event-driven): los microservicios no necesitan conocerse entre sí, sino que únicamente necesitan conocer un agente externo en el que van a publicar eventos de dominio. Estos eventos de dominio pueden ser, por ejemplo: «se ha registrado un nuevo usuario que se llama Raúl, es de Huesca…» , «la tienda XYZ se ha dado de baja», etc. Apache Kafka y RabbitMQ son algunas de las tecnologías con las que se pueden realizar este tipo de implementaciones. En Hiberus tenemos un equipo especializado en este tipo de tecnologías.

Para más detalle, en este webinar hablamos alto y tendido sobre estos dos enfoques arquitecturales:

Los microservicios han venido para quedarse, lo tenemos claro. Es por eso que, si piensas que el futuro de tu plataforma necesita las características (alta disponibilidad, escalabilidad, resiliencia…) que hemos mencionado, no dudes en contactar con nosotros, pues te asesoraremos de la mejor manera posible.

El objetivo de implantación de microservicios consiste en construir una aplicación como un conjunto de pequeños servicios, con operaciones bien definidas e independientes entre sí. Cada microservicio ejecuta su propio proceso y se encarga de implementar una funcionalidad completa del negocio. Si quieres convertir tu arquitectura tradicional en una arquitectura de microservicios, contacta con nosotros. Estaremos encantados de asesorarte en lo necesario. Además, puedes leer nuesto Caso de Éxito de Microservicios para uno de los líderes retail españoles.