En este artículo detallaremos como llegar del monolito al microservicio, es decir, de una arquitectura monolítica a una arquitectura de microservicios, identificando los pasos necesarios que tenemos que dar para llegar a ella. Se completará con un ejemplo para dar más claridad al asunto.

Cómo vimos en el artículo Qué es una arquitectura de Microservicios una arquitectura basada en microservicios nos proporciona grandes ventajas. Hay considerar que no todas las aplicaciones se adecúan a esta arquitectura y puede que encaje mejor una arquitectura monolítica o una arquitectura SOA. Incluso dentro de la propia arquitectura de microservicios podemos tener que sea síncrona, asíncrona o mixta.

1.  Pasos a seguir

Migrar de una arquitectura monolito a una de microservicios es un proceso complejo que requiere de una guía paso a paso para poder llevarla a cabo. Se debe planificar cuidadosamente para que sea lo menos traumáticamente posible. Podríamos identificar los siguientes pasos:

Identificación de los componentes de la aplicación monolítica

El primer paso consiste en identificar los componentes que existen en la aplicación monolítica. Es necesario conocer muy bien funcionalmente cada componente de negocio, así como se relacionan entre ellos para una separación conveniente.

Definir los dominios de los componentes

Los componentes se deben convertir en dominios específicos de la aplicación, delimitados por su contexto. Habitualmente cada dominio se convertirá en un microservicio. Se puede hacer uso del enfoque DDD (Domain Driven Design) para llegar a un modelo de dominio adecuado.

Diseñar la arquitectura del sistema

Una vez tenemos los microservicios identificados, se puede comenzar con el diseño de la nueva arquitectura software. Una arquitectura software es un diseño a alto nivel que define los componentes (en este caso microservicios), sus interfaces y la comunicación entre ellos.

Es necesario también definir la plataforma donde se ejecutarán los microservicios. Entre las opciones más populares se encuentran Docker, Docker Swarm, Kubernetes, Openshift, entre otras.

Implementar los microservicios y su integración

Llevar el código de cada módulo del monolítico a cada microservicio, sin considerar la refactorización del código, ya que nos ocuparía mucho más tiempo. Cada microservicio puede usar una tecnología diferente de implementación (Java, Python, etc.), así como usar la base de datos que mejor se adecúe (Oracle, MongoDB). Se añade a cada microservicio un API (síncrono y/o asíncrono) para la comunicación entre ellos.

Una vez implementados los microservicios y basados en la arquitectura previamente definida, se integran los microservicios, comunicándose entre ellos de forma síncrona o asíncrona, dependiendo del caso de uso. Es un proceso complejo y puede requerir ajustes en la arquitectura.

Pruebas y depuración

Cuando ya tenemos todos los microservicios implementados e integrados, debemos realizar las pruebas unitarias de cada microservicio y las pruebas de integración entre ellos, las cuales son más complejas que en un monolito debido a las dependencias creadas.

Es necesario realizar una depuración para comprobar que los microservicios están funcionando y comunicándose correctamente en la plataforma donde se ha desplegado.

2. Ejemplo

Lo ilustraremos con un ejemplo para mostrar cómo aplicar los pasos descritos anteriormente. y llegar del monolito al microservicio. A continuación, mostramos la aplicación monolítica de la cual partimos:

Dentro del monolito tenemos los diferentes módulos (Samurai, Batalla y Armas) que se comunican entre ellos. Se ha detallado que cada módulo tiene acoplada su interfaz gráfica propia para mostrar al cliente la información requerida. Se observa que pueden estar altamente acoplados, dependiendo de los estándares de calidad del desarrollo.

El monolito está desarrollado en un único lenguaje de programación, como puede ser Java, y usa una única base de datos SQL Server. Puede estar desplegado en un servidor de aplicaciones Java como puede ser Oracle Weblogic.

El primer paso consiste en identificar los componentes del monolito. En el ejemplo tenemos los componentes Samurai, Batalla y Armas. Además, se puede observar que cada uno tiene su IU. A nivel arquitectónico existe una única base de datos SQLServer y un servidor de aplicaciones Oracle Weblogic donde se ejecuta la aplicación.

Después debemos definir los dominios de los componentes. En el ejemplo es directo, cada componente se corresponde a un dominio. Podría pasar que Armas y Samurai fueran un único componente, con lo que se separaría en dos y listo. Dependiendo del negocio este paso puede ser complicado. Como resultado tendríamos los microservicios de Samurai, Batalla, Armas y frontend independiente identificados.

La definición de la arquitectura se basa en los dos pasos anteriores y en las necesidades futuras que se hayan identificado en la aplicación. Se debe determinar:

  • Tecnología a usar, tanto de base de datos como lenguaje de programación.
  • Determinar que microservicios tendrán estado y cuáles no.
  • Mecanismo para realizar las transacciones distribuidas.
  • Definir la plataforma en la que se ejecutarán los microservicios

En base a los microservicios identificados y la arquitectura definida, quedaría la implementación de los microservicios en sí, así como la integración entre los mismos. Podría quedarnos una aplicación con microservicios de la siguiente forma:

Podemos ver que para algunos microservicios se ha usado Java, mientras que para otro se ha usado Python. Algunos microservicios usan base de datos (con estado, MongoDB u Oracle) y otros no usan (sin estado). Se comunican entre ellos de manera síncrona mediante API REST o asíncrona mediante Kafka. Cada uno de los micros está dockerizado y se ejecutan en Kubernetes.

Como paso final se deben crear las pruebas y depurar la aplicación para detectar posibles errores.

3. Conclusiones

En este artículo hemos visto como pasar del monolito al microservicio de una forma genérica, basándonos en una guía para llevarlo a cabo. Es conveniente hacerlo paulatinamente con las diferentes partes del sistema y no todo de golpe.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *