Site Loader
Monolito

En muchas ocasiones, empresas que han apostado por un software propio y llevan desarrollando dicho software entre 4 y 7 años, se encuentran con un programa con muchas funcionalidades pero tiene una estructura monolítica. Este monolito se caracteriza porque a pesar de haber utilizado una arquitectura o un framework que prometía una separación MVC o MVP (entre otras variantes), este hecho no es real. Es por ello que todo aquel que se encuentre en esta situación, en este artículo trataré de dar unos primeros pasos para empezar a realizar esta complicada tarea.

¿Qué es un monolito?

En primer lugar, es necesario entender en qué consiste un monolito y el problema que supone a medio y largo plazo en las peticiones del usuario final. Esto se debe a que los nuevos desarrollos que vayan a ser realizados sobre este monolito pueden afectar a gran parte del sistema y por lo tanto van a añadir complejidad al desarrollo actual. Esto se traduce en un código que cada vez se hace más grande y con muchos más parches en algunos casos.

Como bien se introduce al principio del artículo, a pesar de haber utilizado una tecnología relativamente actual y haber trabajado con frameworks que prometían una separación completa entre la capa de negocio y la vista (o capa visual para el usuario), este hecho no es del todo real. Cualquier cambio o actualización que se requiera hacer en una parte del monolito, en muchas ocasiones requiere de una revisión parcial o completa del sistema y también cambios en otras partes que no deberían ser necesarias.

Con una arquitectura que no está dirigida a microservicios, será necesario tanto actualizar la parte del controlador que se encarga de renderizar la vista, como también la vista para poder introducir los nuevos requisitos del usuario.  Si es un cambio mucho más profundo es posible que necesite de una actualización de la capa de negocio (o modelo) y en este caso tiene un coste añadido para asegurarse de que las partes críticas del sistema siguen funcionando.

¿Qué tamaño tiene mi monolito?

Antes de empezar a hacer nada, debes de establecer el alcance de tu monolito y asegurarte de que eres consciente del problema o necesidades que resuelve para saber cual es la parte crítica de tu negocio y tenerlo en consideración.

En muchos proyectos no sabes ni como va a evolucionar tu idea inicial, ni las necesidades que van a ir apareciendo, es por ello que se suele hacer un prototipo sin funcionalidad real y desechable. Con esto se consigue tener una idea de cual es el proyecto y el futuro a corto y medio plazo. Sin embargo, este no es el punto en el que estamos, porque el software que tenemos entre las manos es totalmente funcional y además resuelve las necesidades de muchos usuarios. Por lo tanto tampoco es viable cortar un mantenimiento sobre este software vivo.

De todas formas, a pesar de no ser un prototipo nos ha servido para saber cual es la lógica de negocio principal, el eje en donde todo gira y las partes que posiblemente sean más secundarias. De esta forma, puedes empezar a hacerte una idea de qué módulos componen tu aplicación, los cuales en su momento no tenías una visión global para saber el límite entre uno u otro, pero que con este prototipo has logrado obtener este conocimiento. Sin embargo, ahora si que sabes exactamente qué partes componen tu software y esta información es fundamental para la tarea que te has propuesto. Es esencial que delimites los módulos secundarios y cual será tu núcleo de la aplicación.

¿Por dónde empiezo?

Si ya eres totalmente consciente de las partes que componen tu monolito o al menos vislumbras por donde puedes empezar a dividirlo, estás en el punto de aplicar los siguientes pasos.

1. No añadir más software al monolito

En primer lugar, aunque sea duro, debes de tomar la decisión de no realizar ningún nuevo desarrollo sobre ese monolito. Salvo algún mantenimiento necesario o alguna funcionalidad que se requiera por causa de fuerza mayor. No siempre el jefe del departamento informático tiene la última palabra… Por lo tanto es inevitable añadir alguna funcionalidad durante la transición a la nueva arquitectura de microservicios.

2. Microservicios

El segundo paso es introducir una arquitectura dirigida a microservicios. Este desarrollo se puede dar mediante RESTful, GraphQL u otra tecnología o estructura, pero lo más importante es que la parte del backend este separada completamente del frontend. De tal forma que los microservicios sean reutilizables y la lógica de la interfaz no esté nunca condicionada por el backend ni al revés.

3. Introducirse en la nueva arquitectura

El tercer paso está directamente relacionado con el primero. El momento de empezar a desarrollar con la nueva arquitectura ya pasó hace tiempo, por lo tanto no esperemos más y los nuevos desarrollos se deben hacer sin pensar en el monolito. Cualquier nuevo desarrollo que se presente es hora de hacerlo con la nueva arquitectura.

4. Actualizar el frontend

Es cierto que esta nueva forma de trabajar puede conllevar un nuevo cambio, que es la forma de trabajar en el frontend. Por tanto, un nuevo paso sería introducirse en el nuevo paradigma de programación en la parte del frontend. Aquí se puede elegir cualquier tecnología para esta tarea, ya sea Vue.js, Angular, React entre otros. Para ello aquí tienes un artículo sobre porqué empezar con Vue.js aunque solo es una de las alternativas.

5. Inicio de la migración del monolito

Una vez que el equipo toma conciencia de qué supone esta nueva arquitectura y como funciona la forma de programar, entiende mucho mejor como seguir con la tarea de definir los módulos que componen tu monolito. Así, el siguiente paso, aunque no te guste escucharlo y suponga un abismo, es dejar de producir nuevo software y centrar casi el 100% de los esfuerzos de tus programadores en migrar los diferentes módulos que has definido. Estos módulos no deberían de ser partes críticas del sistema, de tal forma que tu equipo pueda obtener experiencia.

6. Migrar las partes críticas del monolito

Y por último, cuando todos tus programadores se han actualizado y entienden también cómo se divide el monolito es hora de migrar el núcleo principal de tu lógica de negocio. Con experiencia en la creación de microservicios y paciencia, esta tarea que se antoja complicada no debería de serlo tanto, ya que la lógica de negocio ya se conoce al 100% y la forma de trabajar también.

Beneficios de aplicar microservicios

Entre los muchos beneficios que se puede encontrar después de aplicar una arquitectura de microservicios, a continuación se enumeran algunos de ellos:

  • Programadores actualizados a los nuevos paradigmas de programación y por ende, más competentes.
  • Capacidad de escalabilidad frente a demandas imprevistas sobre la aplicación o sobre una parte de la aplicación en particular.
  • Poder pivotar y cambiar el rumbo de la aplicación rápidamente frente a necesidades del usuario final.
  • Te permite desarrollar cada servicio con una tecnología diferente y no estás casado a un stack de tecnologías.
  • Es mucho más fácil comprender un módulo de la aplicación que el monolito completo para nuevos desarrolladores que se introducen en el equipo de desarrollo.
  • Si se produce una caída de un módulo solo afectará a una parte de tu aplicación, el resto del sistema seguirá funcionando correctamente.

Conclusión

El reto al que te enfrentas no es fácil, no te voy a engañar. Además, en muchos de los casos, la gran dificultad de la migración reside principalmente en hacer comprender a nuestros jefes que durante medio año o un año (depende del monolito), no vamos a producir ningún cambio sustancial para el usuario final. Este hecho puede ser el más complicado, aunque realmente si que estemos trabajando y mejorando tanto la calidad del software como la presentación final al usuario. No olvidemos que seguramente si la aplicación empieza a incrementar sus tiempos de respuesta, el usuario si que se vaya a dar cuenta y haga la tan temible valoración sobre la aplicación como: «la aplicación va lenta«. En este caso los jefes no les va a importar cómo sea, pero van a querer que vaya rápida.

En este mundo del cambio y de la competitividad hay que mirar al futuro y el «renovarse o morir» es un hecho. De este modo, si estás pensando en ello ni te lo pienses. Es cierto que una arquitectura en microservicios también tiene sus inconvenientes, no todo es un camino de rosas, pero a largo plazo lo vas a agradecer en muchos aspectos.

Incremento de productividad

Por último, me gustaría resaltar la velocidad que toman los nuevos desarrollos con esta nueva forma de trabajar. Personalmente me encuentro en mi segunda migración desde una arquitectura monolitica a los nuevos paradigmas de programación, y he de decir que en ambos, muy pronto se ha visto un incremento de velocidad sustancial en los nuevos desarrollos.

Además, estas nuevas tecnologías te permiten satisfacer peticiones inimaginables que hacían los usuarios anteriormente, y además con unos tiempos de respuesta realmente cortos. En este mundo de desarrolladores, casi todo se puede hacer, pero depende del sistema en el que estamos trabajando la inversión de tiempo es lo que marca la respuesta de «eso no se puede hacer», porque de hacerlo no sería rentable por la inversión de tiempo necesaria.

Compartir en redes sociales:

Post Author: Vicente Javier González Llobet

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

LinkedIn
Share