Mucho se habla hoy en día de las arquitecturas de microservicios, muchos clientes me piden cotizaciones de migraciones de arquitecturas monolíticas a microservicios, normalmente orientado a eventos.

Las arquitecturas monolíticas son aquellas cuyos componentes están incrustados en un mismo proyecto, es decir un solo proyecto que incluye todas las partes de negocio, normalmente divididos en paquetes o en módulos.

Les recomiendo leer esta entrada: https://www.ajaltechnology.com/blog/microservicios-velocidad-y-seguridad/ para entender un poco más del tema.

Este tipo de arquitecturas son las más comunes hoy en día teniendo como deficiencia la dificultad de incorporar cambios, de despliegue y de pruebas principalmente. Pero tienen la ventaja de su pronto inicio de desarrollo y en muchas ocasiones tener una versión e infraestructura productiva en un tiempo record.

Como podemos ver en un proyecto de e-commerce podríamos tener los siguientes módulos en el mismo proyecto:

  • Administrador de ordenes
  • Control de pagos
  • Administrador de catálogos
  • Administrador de inventario
  • entre otros…

Y nuestro proyecto por lo general esta divido en dos subproyectos:

  • back: Una API Rest que brinda los servicios para hacer funcionar el negocio (Ejemplo: SpringBoot), y protegido con JWT.
  • front: La aplicación desarrollada con algún framework web como Vue, Angular o React, mismo que consume el back.

Los despliegues por lo general son separados, pero ¿te imaginas tener que desplegar todas las unidades de negocio cuando subes a producción el back?… aunque este problema es igual en el front nos enfocaremos en como resolverlo en otro post.

Para evitar este tipo de problemas entre otros como que un modulo necesita una relación en sus tablas y otro no las necesita, es decir el uso de dos bases de datos distintas. Es por ello que microservicios esta en un «boom» en el desarrollo de software.

Como principal premisa los microservicios es que las aplicaciones son desarrolladas en un conjunto de servicios pequeños e independientes que son ejecutados en su propio proceso, desarrollados y desplegados de forma independiente, ref: Kasun Idrasiri.

Si bien es cierto cuando un proyecto inicia es necesario identificar la amplitud para seleccionar correctamente si microservicios es una solución o es preferible usar una monolítica modularizada o hexagonal.

En este post daremos una lista general de como pasar de una arquitectura monolítica a de microservicios la cual desarrollaré de forma mas detallada en los post relacionados:

  • Analizar si es necesario, siempre tienes que pensar en que este cambio cuesta tiempo y esfuerzo del equipo, tienes que tenerlos disponibles para hacer un cambio gradual.
  • Documentar los eventos y el dominio, es necesario que tu proyecto se desacople de acuerdo a sus eventos y en la identificación del dominio.
  • Comenzar separando por el mas pequeño, es decir tomar un elemento de tu domino/subdominio ya delimitando su contexto e identificar cuales son los servicios que forman parte de la aplicación y sus eventos. Es importante que la primera versión no se cambie la base de datos, sino que se pruebe productivamente solo validando la separación del servicio.
  • Aunque el microservicio no necesite cambiar de no-sql a sql o viceversa, es necesario separarlo, es decir sus datos deben ser propios del microservicio, esto lo veremos mas a detalle en otro post, pero partamos de separar y preparar la migración e integración con el resto de negocio.

En posteriores «post» explicare mas a detalle características de los microservicios, pero era necesario tener un contexto de porque nacen y que buscan solucionar.

Última modificación: 8 marzo, 2021

Autor