close-up-photo-of-feather-2575955-1

Aligerar el monolito: Miniservicios y Microservicios

Joan Llopis Consultoría Técnica Estrategia de Producto

Las aplicaciones monolíticas siguen siendo protagonistas en muchas empresas. Son aplicaciones desarrolladas a lo largo de los años, generalmente por equipos diversos, y que proporcionan gran valor de negocio. ¿Quieres saber cómo aligerarlas para mantenerlas actualizadas con plena funcionalidad? En este artículo te contamos cómo hacer más ligero un monolito. 

A lo largo de los años, el monolito va acumulando código, se vuelve cada vez más difícil de mantener e incluso se imposibilita actualizar sus dependencias con lo que llegamos a soportar un riesgo real por este código obsoleto. Nuestro equipo sufre con cada cambio y llega a tener afectación en nuestro negocio. Nos planteamos cómo proceder para seguir actualizando y añadiendo funcionalidad sin estresar a nuestro equipo de tecnología, que suele estar infradimensionado.

Llegado el momento de aligerar nuestro monolito, valoramos migrar a una arquitectura basada en microservicios. Se puede y  nos espera un viaje interesante. Aunque quizá pensamos que, por muy atractiva que sea la idea, los microservicios nos imponen demasiado.

¿Disponemos de alguna alternativa más manejable y que no sea tan transgresora? ¿Podemos hacer una migración más pausada a medida que nos sentimos cómodos con los nuevos planteamientos hacia nuestro nuevo entorno basado en microservicios?

Podríamos pasar por una arquitectura de miniservicios, a medio camino entre nuestro querido monolito que tantos beneficios nos ha dado y los microservicios, para conseguir que el equipo se adapte a la nueva manera de operar, que sin duda imponen las arquitecturas de microservicios. Empecemos por el principio…

¿Qué son los microservicios?

Los microservicios se refieren a una arquitectura que, atendiendo a la definición que de ella hacen James Lewis y Martin Fowler, tiene unas características ventajosas:

  • Arquitectura basada en componentes, que se pueden actualizar y reemplazar de manera independiente.
  • Se ejecutan, despliegan y escalan independientemente.
  • Exponen sus servicios a través de una API.
  • Su contexto es una funcionalidad del modelo de negocio, tienen una sola responsabilidad.
  • Cada microservicio gestiona su propia base de datos.
  • Se comunican mediante eventos orquestados generalmente con colas de mensajes o llamadas a procedimientos remotos.
  • Diseñados para recuperarse de errores.
  • Diseño evolutivo. Su desarrollo no depende de otros microservicios y no comparten código.
  • Tienen acoplamiento débil.

Alcanzar estos beneficios, migrar a microservicios, supone un reto que nuestro equipo tendrá que abordar. Las características de los microservicios añaden un cambio en la operación diferente de la que estábamos acostumbrados con nuestro monolito:

  • Al pasar a tener un mayor número de microservicios respecto al monolito, es inevitable un aumento en las tareas de mantenimiento y actualización, o al menos, una manera diferente de hacerlo. Dónde solo teníamos que actualizar un entorno ahora tenemos muchos (fácilmente podemos empezar en los 10-15 microservicios). Elegir un buen proveedor de servicios cloud es básico para obtener un buen resultado.
  • En ocasiones, el rendimiento no es el esperado. Para resolver una operación en la que antes bastaba una llamada ahora hay que realizar varias y además en red, aumentando la latencia. Como en el punto anterior, elegir un buen proveedor, solvente, junto a un buen sistema de cache no solo solucionará el problema sino que nos permitirá alcanzar escala con facilidad.
  • Duplicación de código: Al ser totalmente independientes, los microservicios no comparten código. Debemos utilizar librerías, módulos, etc para compartir.
  • Dificulta la realización de tests del modelo de negocio al depender de un número más o menos significativo de microservicios. De nuevo, la elección de buenas herramientas es clave en este apartado.
  • Aparecen nuevos conceptos que se han de resolver y añaden complejidad: discovery, orquestación, despliegue,… Para orquestar estos servicios y proporcionar el descubrimiento automático, tenemos que integrar plataformas como Kubernetes, Hashicorp Nomad o, Docker swarm. Todos los grandes proveedores cuentan con estos servicios. No escatimemos en este punto.
  • Necesitamos añadir centralización de logs y de errores. ¿Te atreves a depurar una pila de microservicios sin herramientas?

Al final, gestionar esa arquitectura necesita de unas herramientas, un conocimiento y una experiencia nada desdeñables, pero que acaban dando sus frutos cuando finalizamos la migración y obtenemos los beneficios.

Es indudable que los microservicios son una tecnología relevante que nos ofrece muchas ventajas respecto a nuestro monolito actual. Hay que tener en cuenta nuestras necesidades y dimensionar el proceso en base a ellas. Nuestro alcance tiene que estar dentro de nuestras capacidades.

Si aún así no nos vemos preparados para afrontar esta migración, podemos pasar por una fase previa de aprendizaje a través de los Miniservicios, nuestro primer paso a una arquitectura de microservicios total.

Y, ¿qué es un miniservicio?

En palabras de Ross Garrett, Head of Product Marketing de Cloud Elements, «Considero que los miniservicios son unos microservicios pragmáticos, donde aprovecho las piezas de esa práctica que tienen sentido para mí y obtengo la mayoría de los beneficios de la funcionalidad.»

Es decir, la arquitectura de miniservicios es una alternativa pragmática que relaja las restricciones de diseño y reduce las fricciones, permitiendo obtener los beneficios asociados a los microservicios.

Podemos adaptar las características de los microservicios a nuestras necesidades, de ahí el pragmatismo de los miniservicios:

  • Puedes utilizar HTTP (REST) aunque perdamos el acoplamiento ligero. Esto hace que nuestros servicios sean dependientes pero permite utilizar tecnologías conocidas por nuestro equipo en lugar de otras como pub-sub o gRPC.
  • Construye monolitos modulares. Poner el foco en la parte de modelo de negocio que queremos resolver y encontremos un equilibrio entre el desarrollo de la funcionalidad y la complejidad de la implementación.
  • No es necesario que cada servicio gestione su propia base de datos. Se puede utilizar una base de datos compartida entre los distintos miniservicios.

Y aún así, esto nos permite obtener ventajas respecto a los monolitos. Me permito reproducir la lista ofrecida por Tom Manion que me parece suficientemente completa, sobre las ventajas de los miniservicios:

  • Reutilización
  • Simplicidad obtenida mediante la arquitectura de la aplicación
  • Desacoplado y rápido
  • Sencillo para devops
  • Fácil de depurar
  • Menor carga de red
  • Desarrollo rápido
  • Gestión de versiones más sencilla
  • Soluciones compartidas mediante implementación de patrones
  • Es fácil migrar a microservicios desde una arquitectura de miniservicios

Como vemos, es relativamente sencillo implementar una arquitectura de miniservicios que nos sirve de experiencia para abordar la migración completa hacia los microservicios.

Conclusión

Los tres modelos: monolito, miniservicios y microservicios, tienen sus ventajas e inconvenientes.

Las ventajas que ofrece la arquitectura de microservicios se hace evidente y pasar por una etapa de «adaptación» con los miniservicios puede ser beneficioso para foguear al equipo.

Al considerar una u otra aproximación hay que tener en cuenta el tamaño del proyecto, la experiencia del equipo, los costes asumibles de gestión y mantenimiento o la dedicación del equipo.

Generalmente, si la implementación de una funcionalidad cabe en unos pocos repositorios, es un buen candidato a su implementación mediante miniservicios. Cuando el número es grande, la inversión en microservicios puede compensar.

El inconveniente es que si nuestro equipo es pequeño quizá la sobrecarga de gestionar múltiples microservicios, tanto en el desarrollo como en la gestión posterior, sea demasiado grande y nos convenga dar ese paso previo por los miniservicios hasta tener la experiencia.

La elección de la arquitectura debe abordarse teniendo en cuenta las ventajas e inconvenientes obtenidos en relación a las capacidades de nuestro equipo y el coste que supone dicho cambio.

Si nos decidimos por migrar a un modelo de miniservicios, evolucionar posteriormente a microservicios es un proceso sencillo y continuista, que ya se encuentra a medio camino.

Referencias

Escribe un email a info@clouddistrict.com
o déjanos tus datos para que nos pongamos en contacto contigo

Hola, mi nombre es nombre y trabajo en empresa Por favor, escribidme a o llamadme al teléfono (opcional). Me gustaría hablar con vosotros de...

* Este campo es obligatorio

Enviar