¿Cómo se evoluciona de una arquitectura monolítica a una arquitectura de microservicios?

¿Cómo se evoluciona de una arquitectura monolítica a una arquitectura de microservicios?

Gedeón Domínguez Tecnología

De una arquitectura monolítica a una arquitectura basada en microservicios: desmontando el m(onol) ito.

La arquitectura monolítica es cómoda y ese es un gran punto a su favor, ¿Por qué decidir entonces trabajar en arquitecturas de microservicios, si pueden ser más complicadas? En este post se detallan las razones y el proceso que conlleva el inevitable paso de monolito a microservicios, comentando su evolución.

¿Qué es la arquitectura monolítica?

La arquitecturas monolíticas son aquellas en las que el grueso de la tecnología implicada se apoya sobre un desarrollo único, acoplado, que funciona como una única pieza de código indivisible. Encontramos monolitos en proyectos de todo tipo, desde un eCommerce a un software de gestión (ERP) y en cualquier tecnología (PHP, Java, NodeJS, etc). Estas arquitecturas son muy cómodas en las primeras fases de un proyecto por muchos motivos:

  • Rápidas de desarrollar
  • Sencillas de entender
  • Fáciles de desplegar

A medida que un proyecto crece, el monolito crece con él, y pasados los años es muy frecuente que en vez de un monolito tengamos un “monolote”, una estructura acoplada de decenas de miles de líneas de código que va tendiendo al caos

Nuestro otrora ágil desarrollo MVC se ha convertido en una hidra de 10 cabezas, está descontrolado y ya no quedan más posibilidades para escalar verticalmente o el precio de la infraestructura se está disparando. Al no poder partir servicios no tenemos más remedio que seguir subiendo capacidad de máquinas como única manera de escalar, y esto es un callejón sin salida a medio plazo.

Aparecen problemas de diversa tipología:

  • Legacy
  • Acoplamiento excesivo
  • Deuda técnica
  • Cuellos de botella técnicos
  • Héroes irremplazables. Personas que acumulan todo el know how generando una dependencia excesiva de la organización
  • Regresiones constantes

¿Cómo se llega a la arquitectura de microservicios?

Es así cuando llega el momento de cortar cabezas de la bestia y empezar a migrar progresivamente a una arquitectura más distribuida: bienvenidos microservicios. Lo primero es abrazar el cambio y saber que va a ser un proceso duro. Lo segundo es evitar los errores más comunes:

  • Plantear un desarrollo desde 0, en paralelo,  para sustituir a la bestia: no suele funcionar. El desarrollo de la nueva arquitectura nunca está al nivel funcional del anterior y nadie se atreve a hacer el cambio. El problema se hace más grande porque no paramos de actualizar el monolito porque tenemos que seguir dando servicio. Callejón sin salida.

 

  • Sacar una nueva rama con el cambio de arquitectura e intentar mantenerla actualizada con los evolutivos del monolito que vayan surgiendo. Muy costoso.

 

  • Long-shots: Hacer planteamientos a mucho tiempo vista (6 meses – 2 años). Planteamientos demasiado ambiciosos. Dead end.

Evolución a la arquitectura de microservicios

En nuestra experiencia la mejor manera de afrontar esta transición es radicalmente poquito a poco. Ya, suena raro. Me explico.

Cambios radicales de arquitectura pero en ciclos de trabajo muy cortos: Prueba de concepto -> despliegue -> consolidación -> avance. Una sola rama de trabajo, mismo equipo, trabajando el mantenimiento evolutivo y el cambio de arquitectura release a release. Necesitaremos un buen arquitecto (muy bueno). Es un trabajo de cirujano en el que vamos seccionando pequeños elementos funcionales y llevándolos a un ecosistema nuevo, asíncrono, desacoplado y, en la medida de lo posible, serverless o basado en un modelo de servicio y no de máquina.

 

Normalmente nos enfrentamos con escenarios profundamente síncronos y necesitamos ir añadiendo asincronicidad para separar conceptos.

 

Una estrategia típica es meter colas de mensajes y la forma de avanzar suele parecerse a:

  • Seleccionar un primer servicio autocontenido y pequeño de la plataforma o un cuello de botella concreto. Por ejemplo: el envío de correos, las alertas, los SMS, la autenticación, una API en concreto…. 
  • Localizar todos los puntos de llamada/uso de esta pieza.
  • Crear el microservicio
  • Meter la tijera y a través del sistema de colas desacoplar esta primera pieza
  • Subir
  • Probar
  • Repetir

Si iteramos suficientes veces y con cabeza este proceso,  el monolito acaba siendo el esqueleto del animal que fue, pero todo el músculo está fuera. Nos pueden quedar piezas claves de enrutamiento, coordinación, orquestación, etc pero la idea es que el negocio esté troceado por dominio y separado por servicios.

 

A veces el objetivo no tiene que ser llegar a sustituir la pieza completa y sólo trocear unos pocos servicios puede tener un impacto enorme en nuestra arquitectura.

 

No hay dos proyectos iguales pero típicamente se utilizan piezas como:

  • Colas
  • Caches
  • Proxys
  • Api Gateways
  • Centralizadores de logs y trazas de rendimiento
  • Cortafuegos
  • Tests, tests, tests.
  • ¿He dicho tests? Hay que garantizar la integridad y evitar grandes regresiones
  • Integración continua
  • Service discovery 

 

Las posibilidades son infinitas. Son proyectos destinados a equipos muy senior y con una gran visión de arquitectura y operaciones (DevOps). Si cuentas con ellos, me parecen proyectos muy bonitos. Nunca los abordaría con:

  • Un equipo junior
  • Un equipo lento o excesivamente burocrático
  • Un equipo con miedo: Hay que romper y arreglar, no hay que tener miedo. Hay que romper para poder arreglar.

 

No podemos olvidar el negocio durante este proceso, y de cara a conseguir aceptación por parte de la dirección para abordar este proceso (y su coste) es muy interesante mezclar esta evolución con una estrategia de quick wins. Suele ser fácil en este contexto solucionar pequeños problemas históricos que permitan al resto de stakeholders ver que se está aportando además un valor tangible y accionable. Vencer la resistencia al cambio, cuando el cambio tiene coste alto y resultados poco visibles, puede ser muy complicado justificar el esfuerzo y los recursos por muy importante que sea ejecutar el cambio a nivel técnico.

 

Si dudas si ha llegado el momento de trocear tu monolito, es que ha llegado el momento.

 

A veces, arrancar un proyecto directamente en microservicios puede ser un error, pero dejar que el monolito coja demasiado tamaño y se descontrole puede ser igual de peligroso. Muy interesante puede resultar un enfoque intermedio de “miniservicios” o de Bounded Context, que dejaremos para siguientes artículos de nuestro blog ¡A por ello!

Contáctanos

INFORMACIÓN IMPORTANTE SOBRE COOKIES

Este sitio web utiliza cookies propias y de analítica para mejorar tu experiencia. Algunas de estas cookies son imprescindibles para que el site funcione correctamente.
Puedes ver más información sobre las cookies en nuestra Política de privacidad.

Aceptar