Migración de aplicacioneshacia Microservicios

La transición del monolito a los microservicios con la ayuda de SysViewSoft.

En el ciclo de vida de cualquier aplicación, 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, y probablemente 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 a microservicios.

El objetivo de la migración a 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, SysViewSoft cuenta con procesos y herramientas semi-automáticos, que aplican nuestro enfoque de transformación sistemática.


Principios de la migración a microservicios

La arquitectura de migración de aplicaciones monolíticas a microservicios puede dividirse en dos pasos principales.


El primer paso es identificar una arquitectura orientada a los microservicios a partir del código fuente del monolito. Su principal objetivo es extraer la arquitectura de la aplicación objetivo para ayudar a los arquitectos a modernizar su aplicación.

El segundo paso es transformar el código fuente existente en uno que implemente el microservicio identificado. Esa es la materialización.

Image
Ventajas de la migración a microservicios
Los microservicios se pueden implementar y probar de forma independiente. Cuanto más pequeña sea la unidad de implementación, más fácil será la implementación.
Mediante la migración a los microservicios, puede flexibilizar las dependencias entre los equipos. Cada equipo debe preocuparse solo por las API de los microservicios de los que dependen.
Se pueden implementar en diferentes lenguajes y frameworks. En cada microservicio, puede elegir la mejor tecnología para su caso práctico en particular.
Mayor seguridad, ya que los distintos componentes funcionan de manera independiente, trabajando los errores y despliegues individualmente.
Los pueden administrar diferentes equipos. El límite entre microservicios facilita que un equipo se dedique a uno o varios microservicios.
Despliegue, testeo y escalabilidad progresivos.
Pasos para la migración a microservicios
01
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.
02
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 tratar 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.
03
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.
04
A partir de las dependencias, diseñar una interfaz (diseño API first) para cada uno de los dominios. Estas APIs (pueden ser REST) serán la nueva puerta de entrada a cada uno de los mismos.
05
Una vez se hayan diseñado las interfaces, habrá que implementarlas. 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.
06
Una vez que todos y cada uno de los microservicios son simples, es decir 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.
07
Se recomienda implementar tests unitarios para cada uno de los microservicios (entendiendo el microservicio como unidad), además de tests de integración que comprueben que pueden trabajar en conjunto.
08
Integración y entrega continuas: cuando el sistema está compuesto por varios microservicios diferentes y se planea realizar cambios con mucha más frecuencia, es importante tener un proceso de construcción, prueba e implementación realmente sólido que sea ideal como sistema automatizado.
09
Realizar el despliegue. Cada microservicio puede estar alojado en uno o varios servidores distintos, proporcionando: alta disponibilidad, elasticidad, escalabilidad, mantenibilidad y auditabilidad.