De Monolitos a Microservicios
La mayoría de nosotros hemos oído hablar de “Microservicios“. Los expertos en Tecnología pueden dar una explicación más profunda, pero pocos tenemos la oportunidad de participar en el desarrollo de microservicios, ya que el resto de las aplicaciones son en su mayoría “Monolitos“.
En primer lugar, ambos términos describen una arquitectura de software respaldada, la diferencia es que el monolito suele ser una única aplicación que “hace todo” per se, como suscribirse a un servicio, administrar pagos, almacenar los datos, administrar cierta información como administrador, etc. mientras que los microservicios son una colección de mini aplicaciones que se comunican entre sí, por ejemplo, cada aplicación maneja solo una “preocupación“ o aspecto del servicio: una aplicación para suscribirse, otra para pagos, etc. Hay más detalles, por supuesto, de los cuales mencionaré algunos.
Una historia habitual
La historia habitual comienza con unas cuantas personas que tienen una “idea” que podría ser la próxima “gran cosa”, por lo que dan un primer paso con una startup y se concentran en las necesidades básicas esenciales de su “idea”, que podrían desarrollar ellos mismos o más adelante algunos desarrolladores para convertir la “idea” en un “servicio” online, y sí es una aplicación monolítica con una sola base de datos y desplegada en algún servidor, ya que ahora mismo no tienen mucho tráfico ni clientes.
Después de un tiempo, la “idea” comienza a tener forma y la demanda del “servicio” en línea es cada vez mayor, por lo que la startup tiene que duplicar las instancias implementadas del monolito en el backendpara poder satisfacer la demanda. Luego, más tarde surgen algunas “ideas complementarias” que podrían mejorar la “idea” original y hacer que la experiencia del usuario del cliente sea más amigable.
Para que estas nuevas “ideas” estén disponibles para el cliente, se debe expandir el código de la aplicación original. on – con suerte, la arquitectura de software que utiliza la startup está abierta para extensiones -. A medida que pasa el tiempo, con más clientes y más tráfico y, por supuesto, al igual que con cualquier startup exitosa, más “ideas” nuevas, el monolito se ha vuelto 100 veces más grande en base de código y complejidad (con una estructura de datos igualmente compleja en la base de datos) y, por supuesto, muchas más instancias del monolito ahora se implementan en los múltiples servidores (quizás un proveedor de servicios en la nube como AWS o Google Cloud).
Estado monolito
Tomemos un tiempo para verificar cuál es el estado del monolito. Como mencioné antes, la base del código debe ser enorme, con suerte los desarrolladores han logrado mantener los principios SOLID * y el software está hecho con un Código limpio * (aunque es difícil para lograr esto en un monolito) pero, aun así, lo más probable es que haya muchas dependencias en la arquitectura que hacen que corregir errores y agregar funciones sea más tedioso para los desarrolladores. Otra cosa que sí es cierta es que no todos los servicios que ofrece el monolito tienen una gran demanda, tal vez unos tres servicios que siempre están bajo demanda, mientras que el resto de los servicios como pago se usa moderadamente y el servicio de suscripción no es utilizado tan intensamente como los demás. Independientemente, cuando escalan el monolito (implementando más instancias para satisfacer las necesidades de los clientes), tienen que duplicar todos los servicios (los más usados y los que apenas se usan), consumiendo más recursos (CPU, RAM, DB …) que es necesario. En resumen, tenemos un código grande y difícil de mantener o ampliar, y un uso ineficiente de los servidores o hardware.
Puesta en marcha: ¿cambio de arquitectura?
Ahora, hemos llegado a un punto crucial para la puesta en marcha, ¿deberían cambiar a la arquitectura de microservicios? para responder a esta pregunta se deben tomar en consideración muchas cosas, negocios, finanzas, crecimiento, etc. Personalmente solo puedo dar mi humilde opinión desde la perspectiva de la Ingeniería Informática, y voy a compartir mi propia experiencia con este desafío.
Historia del monolito
La historia del monolito que mencioné al principio es similar a la mayoría de las startups que ofrecen algún tipo de servicio web en línea, de hecho, fue la historia de mi antigua empresa, que también llegó al punto crucial de decidir dividir el monolito o no.
La situación era de crecimiento en el mercado de reservas turísticas y en números, pero por desgracia, la pandemia llegó y quebró todas las planificaciones futuras, quedándose en modo de supervivencia.
Desde hace un tiempo estoy trabajando para una nueva empresa Trentia, cuyo proyecto en cliente respondía con un “sí” a una pregunta fundamental para mí: explorar diferentes formas de desarrollo con otras perspectivas y aproximaciones para mi crecimiento profesional como lo es adentrarme en el mundo de los microservicios.
Ahora soy miembro de un equipo que está desarrollando algunos microservicios que manejan algunas funcionalidades y hay otros equipos, organizados por jerarquías que toman posesión de las otras funcionalidades de la propiedad.
Experiencia como desarrollador de Software: ventajas Microservicios
Como desarrollador de software veo numerosas ventajas de trabajar de esta manera, solo me preocupa un conjunto específico de servicios y no todos los servicios del monolito.
El código es elegante, su calidad está más controlada, el mantenimiento es más fluido, la detección de errores es más rápida y más contenida.
Lo que me encanta del enfoque de microservicios es que expande los conceptos de desacoplamiento / encapsulación que tenemos en Programación Orientada a Objetos con clases y módulos a un conjunto de “mini Softwares”, especialmente si se utilizan colas como Kafka o RabbitMQ, que hacen que cada “mini Softwares”, agnósticos entre sí, casi se desacoplen de la dependencia que intentamos lograr cuando programamos.
Métodos ágiles o scrum: aún más eficiente
El uso de métodos ágiles o scrum con esta arquitectura, lo hace aún más eficiente, ya que el ciclo es más corto y menos complicado, y esto es así porque, al igual que en la programación, la mayoría de los problemas se resuelven mediante la abstracción y el enfoque de “divide y vencerás”.
Se pueden desarrollar múltiples microservicios para resolver un problema, y cada uno con un marco / tecnología diferente (Java, NodeJs, Python …), y a la mayoría de los desarrolladores nos gusta cambiar de lenguajes de programación y tratar de aprovechar las ventajas de cada tecnología para entregar la mejor solución.
Desventajas
Puedo mencionar más ventajas que encuentro en los microservicios, pero va a ser más técnico, así que vayamos a las desventajas: personalmente y como programador encuentro que la duplicación de código es una desventaja, especialmente el Modelo, DTO, DAO … etc. Otra desventaja es que tendré que saltar entre múltiples bases de código, diferentes bases de datos / cachés, registros, etc. mientras depuro un problema.
Algo que echo de menos de mis días de monolito, es el uso intensivo de algoritmos para resolver problemas complejos, aunque, con el enfoque de microservicios, la complejidad del problema se resuelve en múltiples mini algoritmos en diferentes microservicios. Pero en general, para mí, los beneficios de los microservicios superan los inconvenientes.
Puesta en marcha: variables para cambiar a Microservicios
Volvamos a nuestra hipotética “puesta en marcha”, ¿deberían cambiar también a los microservicios? Bueno, para mí sí, pero no es tan fácil, mantener microservicios requiere múltiples equipos, cada equipo manejando algún dominio o subdominio de los “servicios”, un servicio en la nube con suficientes recursos para manejar múltiples microservicios escalables, por tanto, la decisión no es solo técnica, siempre va a haber un análisis de costes y retornos de inversión a evaluar ¿la startup genera suficientes ingresos para manejar la expansión y el crecimiento del equipo? ¿el coste de la nueva infraestructura? ¿el tiempo que tomará migrar / dividir el monolito en microservicios? y muchas más preocupaciones que no estoy contemplando del todo, solo puedo dar fe de que, como desarrollador, prefiero los microservicios en lugar de los monolitos, pero, como todo lo demás, cuando se hace correctamente.
