Migración de legacy a microservicios

Existen varios pasos que tenemos que tener en cuenta en la migración de una aplicación   legacy  a microservicios, pero antes de ello tenemos que resolver la siguiente cuestión: ¿Por qué?

Migración de legacy a microservicios

En el ciclo de vida de cualquier herramienta de software llega un momento en el que ésta se ha quedado obsoleta o ha crecido de manera que ha ido más allá de su propósito inicial, probablemente a través de parches y remiendos que han hecho que no esté optimizada de la mejor manera posible, o que sus distintos componentes añadidos hayan creado una estructura que no resulta del todo eficiente. El coste del mantenimiento aumenta, la herramienta requiere de un ‘expertise’ específico y complejo, o no es compatible con el uso que se quiere hacer de nuevas tecnologías emergentes. Llegado este escenario una de las tendencias actuales es la migración de legacy a microservicios.

¿Legacy o microservicios? ¿Qué beneficio obtenemos al migrar a servicios y cuáles son los costes derivados de este servicio?

Existen varios pasos que tenemos que tener en cuenta en la migración de una aplicación legacy a microservicios, pero antes de ello tenemos que resolver la siguiente cuestión:

¿Por qué queremos migrar una aplicación existente a microservicios?

Éstas son algunas de las ventajas por las cuales podemos querer apostar por una arquitectura basada en microservicios:

• Utilización (y reutilización) de los distintos servicios según necesidad.
• Mayor facilidad en el mantenimiento de la infraestructura.
• Despliegue, testeo y escalabilidad progresivos.
• Mayor seguridad, ya que los distintos componentes funcionan de manera independiente, trabajando los errores y despliegues individualmente.
• Modularidad y poca dependencia de tecnologías específicas.

Si buscamos beneficiarnos de esta serie de características al trasladar nuestro entorno legacy a un ecosistema de microservicios, entonces tenemos que prepararnos concienzudamente, a través de un análisis de la aplicación actual, para dar este paso tan importante.

¿Qué necesitamos para el desarrollo y despliegue de una aplicación de microservicios?

Para empezar es necesario contar con un plan de migración detallado que responda a las siguientes cuestiones:

• ¿Qué tecnologías se están usando?
• ¿Hay algún módulo específico que sólo funciona con una versión del software?
• ¿Cómo se divide una aplicación monolítica en microservicios?
• ¿Conlleva la migración de versiones, tecnología, etc?

Una vez analizada la aplicación a través de estos puntos, se tendrá una idea más clara de qué es lo que puede aportar la migración a microservicios. Este análisis previo de la aplicación ayudará a revisar su estado, el proceso de negocio que alberga y las dependencias que tiene. Gracias a este proceso también se podrá obtener cierta información de la herramienta, como cuáles son las partes que más se usan, las librerías más pesadas, etc.

De este modo será más fácil contestar la pregunta crucial: ¿se puede migrar la aplicación a microservicios? La reflexión realizada servirá para poder estructurar de manera adecuada la aplicación de microservicios, de manera que sea escalable, reutilizable y fácil de modificar y mejorar.

Decidida ya la migración de la aplicación, y planteados los correspondientes requerimientos y necesidades, llegamos a otra etapa crucial en este proceso, el establecimiento de un plan de migración.

Plan de migración de legacy a microservicios

El plan de migración de legacy a microservicios pasa por las siguientes fases diferenciadas:

Generar nuevo entorno

Si no se dispone de un entorno para poder lanzar microservicios, lo primero que se debe hacer es definir el entorno en que van a correr los microservicios.

Para ello se evalúan las diferentes opciones existentes en el mercado, barajando entre la opción de tener una cloud privada, pública o híbrida.

Cuando se habla de microservicios normalmente este término suele ir relacionado con la palabra “contenedores”, especialmente con “Docker”.

Docker es un sistema de virtualización ligero que reutiliza el kernel de Linux. Al reutilizar el kernel de Linux sus imágenes son más ligeras y consumen menos recursos que con las tradicionales máquinas virtuales.

Elegir el entorno adecuado para microservicios será el punto de partida que marcará nuestros desarrollos y adaptaciones.

Establecer flujo de DevOps

Actualmente, la mayoría de las herramientas para gestionar contenedores se integran con el gestor de integración continua JENKINS.

Este flujo de integración continua y despliegue continuo ayudará a convertir los cambios que se realicen en el código, en nuevas imágenes listas para ser lanzadas en contenedores. Ya no se trabaja con artefactos, sino con imágenes Docker/Rocket que contienen el código.

Definir este flujo ayudará a generar automáticamente las imágenes que posteriormente serán desplegadas. Además servirá para poder migrar imágenes en concreto de un entorno de desarrollo a uno de producción de manera sencilla, simplemente promocionando.

Poner la aplicación legacy en contenedores

El siguiente paso es migrar la aplicación actual para que pueda correr en contenedores. En este paso se obtendrán las diferentes partes que se tengan de la aplicación (base de datos, servidor Tomcat, frontal NodeJS…) y se adaptarán para que corran en contenedores.

Al tener la aplicación en contenedores se obtienen ya todas las ventajas de correr en una infraestructura de contenedores (DevOps, escalabilidad, load balancing, etc).

Separación en microservicios

Ésta es la última parte del plan de migración. Una vez se tenga el entorno montado y se haya migrado a contenedores la aplicación legacy, se puede empezar a transformar. Requiere de desarrollo para poder separar las diferentes piezas de negocio que ahora correrán sobre microservicios.

Poco a poco se irá desglosando la aplicación legacy en varios microservicios listos para correr en contenedores.

Migración de legacy a microservicios: conclusiones

El proceso de migración de legacy a microservicios no sólo nos dará ventajas en cuanto flexibilidad, escalabilidad, etc, sino que nos reportará beneficios extra tanto a medio como largo plazo. Además de todas las ventajas inherentes a un sistema basado en contenedores, habremos dejado nuestra aplicación preparada para que interactúen con ella diferentes elementos y nuevos desarrollos como aplicaciones móviles, etc.

Al tener nuestra lógica de negocio en módulos aislados, totalmente replicables, podemos hacer uso de estos módulos desde otras aplicaciones, y podemos escalarlas de manera sencilla y eficiente conforme aumente nuestra carga sobre esos servicios.

Podremos ahorrar recursos al identificar el proceso de negocio que más carga genera, replicando este proceso de negocio y no la aplicación entera.

Sí además disponemos de un orquestador de contenedores como Kubernetes, nuestro servicio estará balanceado automáticamente cuando levantemos más réplicas del microservicio, pudiendo incluso escalar las réplicas de este microservicio automáticamente frente a picos de carga puntuales.