De sistemas monolíticos a microservicios

Actualizamos este artículo en 2022 para incluir nuevos desarrollos respecto a la transición de los sistemas monolíticos a la arquitectura basada en microservicios.

En la arquitectura monolítica todos los servicios y funciones están agrupados  dentro de una única base de código. Sin embargo, esta arquitectura ha ido quedando obsoleta, pues los proyectos han ido creciendo en complejidad, cargas de trabajo, número de desarrolladores y de usuarios.

Para responder a las necesidades actuales de las empresas, se vuelve necesario que las aplicaciones sean construidas de forma distribuida, donde los distintos componentes puedan desplegarse de forma independiente.

Es por esto que se está utilizando cada vez más una arquitectura basada en microservicios, la cual facilita el trabajo en equipo de los desarrolladores y es más fácilmente escalable.

¿Qué son los sistemas o aplicaciones monolíticos?

Los sistemas monolíticos (también definidos como aplicaciones monolíticas) agrupan todas las funcionalidades y servicios de negocio en una base de código única. Para realizar un cambio en este tipo de arquitectura, es necesario actualizar todo el código base, creando y desplegando una versión actualizada de la aplicación. Esto hace que las actualizaciones sean restrictivas y consuman más tiempo de desarrollo, pruebas y despliegue.

Beneficios de los sistemas monolíticos

Las primeras aplicaciones de software usan este diseño y, aunque se han desarrollado alternativas más sofisticadas, siguen teniendo ventajas importantes: son fáciles de desarrollar, fáciles de desplegar y – por su misma simplicidad – es sencillo y rápido ejecutarlas. 

Debido a la simpleza de su estructura, el desarrollo de aplicaciones monolíticas suele ser menos costoso que sus alternativas.

Sus beneficios principales incluyen:

• Desarrollo centralizado. Por ser la forma estándar para crear aplicaciones, no se requieren conocimientos adicionales. Además de haber una amplia gama de herramientas disponibles, todo el código fuente se encuentra en un solo lugar, pudiendo entenderse rápidamente.

• Depuración completa. El proceso de depuración es muy natural por estar todo el código en un solo lugar, pudiendo seguirse con facilidad el flujo de algún requerimiento para encontrar un inconveniente.

• Pruebas y seguimiento de errores en un solo lugar. Al tener menos variables que chequear, resulta mucho menor el riesgo de que algo salga mal. Como todas las transacciones se registran en un solo lugar, solo se chequea un servicio, sin otras dependencias.

• Fácil incorporación de nuevos miembros del equipo. Como el código fuente se encuentra en un solo lugar, los nuevos miembros del equipo pueden familiarizarse fácilmente con la aplicación.

• Despliegue y ejecución simple. Solo se debe implementar una unidad a ejecutar, sin dependencias. Como la interfaz de usuario está empaquetada con el código del backend, no se tienen que hacer cambios importantes. No se requieren herramientas sofisticadas de automatización para desarrollar  y desplegar la aplicación.

• Simplicidad en la aplicación. Desde la perspectiva de la lógica empresarial, si se necesitan otros datos para alguna nueva característica, ya se encuentran en un mismo paquete.

• Confiabilidad. Como la arquitectura monolítica es un método estándar ya probado y comprobado, también se considera más confiable que cualquier otra arquitectura más nueva y, por tanto, menos probada en el mercado.

• Bajo costo en las primeras etapas de la aplicación. Como todo el código fuente está en un solo lugar, queda empaquetado en una única unidad a implementar. Por tanto, no hay gastos en infraestructura ni en desarrollo.

Sin embargo, una aplicación que concentra toda su funcionalidad no es necesariamente mejor, en especial si su sistema tiende a crecer en complejidad, usuarios, desarrolladores y carga.

Desventajas de los sistemas monolíticos

• Actualizar una aplicación monolítica tiene dificultades. Al tratarse de un código único todo nuevo despliegue requiere relanzar la aplicación en su conjunto. Además, por el tamaño del código único, resulta difícil identificar y solucionar problemas concretos.  Esto, a su vez, puede resultar abrumador para los desarrolladores que necesitan entender el código en su totalidad para poder trabajar en él, pues cualquier paso en falso puede comprometer el código en su conjunto.

• Las aplicaciones monolíticas son un reto de crecimiento. Tratándose de un código único, no es posible trabajar en diversos ambientes simultáneamente. El crecimiento del código va aparejado de una sobrecarga de la aplicación informática, lo que en última instancia repercute sobre su agilidad.

• Problemas de confiabilidad. Debido a lo interdependientes e interconectados que están los componentes de un sistema monolítico, incluso un problema menor lleva a que toda la aplicación pueda fallar.

• Falta de flexibilidad. Cuando se trata de un sistema monolítico, no se tiene otra opción sino ajustarse a una sola tecnología, que puede tener sus propias limitaciones. Adoptar cualquier tipo de nueva tecnología podría significar tener que reescribir todo el sistema, lo cual es extremadamente costoso y requiere mucho tiempo. Por tanto, resulta casi imposible realizar actualizaciones, por lo que los desarrolladores no pueden beneficiarse de los nuevos frameworks y lenguajes más avanzados. Esto se convierte en un problema importante cuando se vuelva obsoleto el framework utilizado actualmente.

En muchos casos la elección de usar una aplicación monolítica no la hace un equipo de desarrollo, sino que hace parte de decisiones de negocio y de relaciones con proveedores externos. Si una aplicación de negocio se vende como una sola unidad, estaremos atados a esa arquitectura obligatoriamente.

Actualmente, los microservicios son una alternativa efectiva, especialmente cuando hay flexibilidad en el modelo de desarrollo y cuando diferentes equipos deben trabajar en conjunto.

¿Qué son los microservicios?

Los microservicios son una manera de construir aplicaciones y servicios digitales. 

Una arquitectura de microservicios busca desacoplar o independizar los componentes individuales de una aplicación, para que cada componente sea una aplicación en sí misma. 

Los microservicios se conectan entre sí a través de APIs, permitiendo que diferentes equipos trabajen al mismo tiempo en diferentes partes de una aplicación.

Beneficios de los microservicios

• El gran diferenciador de los microservicios es que los distintos componentes del software pueden ser desarrollados y desplegados de forma independiente. 

• Se refuerza el aislamiento del código, pues al tratarse de componentes separados se puede reducir el impacto que puedan tener los errores de un componente en la totalidad del código (como sucede con las aplicaciones monolíticas).

• Los microservicios permiten que componentes individuales estén escritos en distintos lenguajes de programación, haciendo posible contar con programadores de distintas especialidades trabajando en el mismo producto.

• Los microservicios pueden verse como una evolución del SOA (Service Oriented Architecture). La función de esta arquitectura es dividir un sistema complejo en una variedad de unidades independientes, cada una orientada a una función particular, con su propia lógica de negocio e independencia a nivel de desarrollo. Si bien SOA proponía desarrollar y pensar en servicios independientes para el negocio, en la mayoría de los casos estos servicios estaban unidos en una misma aplicación.

• Los microservicios nos permiten evolucionar y promover el crecimiento del software. Cuando un componente específico del microservicio crece más allá de sus capacidades, es posible separarlo en elementos más pequeños o asignarle más recursos. Los microservicios ofrecen simplicidad en la arquitectura de software.

Los retos de hacer microservicios

Aunque los microservicios se distinguen por su eficiencia, flexibilidad, agilidad y potencial de crecimiento, implican retos importantes para su implementación.

Al tener un mayor número de componentes, su operación es más compleja, por lo que crear y desarrollar la infraestructura requiere más tiempo y más recursos.

Esta es una razón para que una cultura DevOps (desarrollo y operaciones) le ofrezca agilidad al proceso de desarrollo. Como menciona Martin Fowler en su blog de Pre-requisitos para microservicios, hay diferentes retos en la operación de sistemas basados en microservicios:

• Habilidades de aprovisionamiento rápido de recursos, ya sea en cloud o on-premise. Conocimiento de herramientas de automatización para desplegar y mantener una aplicación distribuida.

• Esquemas de monitoreo para servicios distribuidos, incluyendo métricas de aplicación, redes, consolidación de logs, así como maneras de enlazar una operación o transacción de un cliente con los diferentes microservicios que utiliza.

• Prácticas de desarrollo ágil como DevOps, Integración Continua, despliegue Continuo y equipos de desarrollo con enfoque de producto.

Fowler propone la creación de un modelo de madurez donde las capacidades actuales, las debilidades y la hoja de ruta de un equipo de desarrollo están claramente documentadas.

Adicionar al equipo consultores que tengan un alto nivel de madurez en estas prácticas permite reducir el riesgo y aumentar la velocidad de implementación de estas prácticas.

¿Que es más fácil de desarrollar, sistemas monolíticos o microservicios?

Es importante tomar una decisión cuidadosa sobre cuál sería la arquitectura adecuada considerando estos factores: el problema que se está abordando, el alcance del desarrollo, la expectativa de futuros desarrollos, el tamaño del equipo de trabajo y el presupuesto disponible.

En general, los sistemas monolíticos son más adecuados para los siguientes casos:

• Aplicaciones simples y livianas que solo requieren una limitada funcionalidad.

• Empresas que están comenzando sus operaciones, que solo tienen un equipo de trabajo pequeño y buscan lograr un lanzamiento rápido de sus sistemas.

• Versiones prototípicas de los sistemas, en su etapa de pruebas iniciales, en los que aún no se garantiza que se vayan a utilizar con frecuencia.

Por otro lado, la arquitectura de microservicios podría ser más adecuada para estos casos:

• Aplicaciones complejas y en plena evolución, que requieran cierta agilidad y fluidez con la ayuda de desarrolladores experimentados.

• Sistemas que planean expandirse para adquirir más funcionalidad con el tiempo.

• Sistemas del negocio ya estables y verificados, que tengan mucho tráfico y que estén destinados a un proyecto a largo plazo.

Puede ser que los microservicios no sean la arquitectura más conveniente para todos los desarrollos. Es decir, un sistema monolítico puede funcionar perfectamente bien, por lo que es posible que no valga la pena desmontarlo. 

Sin embargo, a medida que las empresas van creciendo y se incrementan los requerimientos de sus aplicaciones por parte de los usuarios, la arquitectura de microservicios vale la pena.

¿Cuándo debemos pensar en microservicios?

A pesar de que la arquitectura monolítica sigue siendo común para muchas de las aplicaciones, no es lo mejor para sistemas complejos. En la medida en que un software evoluciona y se desarrolla, se vuelve más costoso preservar una arquitectura monolítica y son mayores las ventajas de adoptar una arquitectura más flexible que permita y promueva el crecimiento de su empresa.

La arquitectura de microservicios nació como una reacción de los desarrolladores ante la imposibilidad de continuar escalando aplicaciones. 

Esto sucede tarde o temprano con todo software exitoso, independientemente de la calidad del código original o de qué tan buen mantenimiento se le haya dado. En cierto punto, la arquitectura monolítica es simplemente insuficiente para las crecientes demandas de la aplicación.

Microservicios en la nube

Los servicios en la nube se caracterizan por ofrecer agilidad, flexibilidad, resiliencia y capacidad de adaptación. 

Migrar a la nube es un paso importante del proceso de modernización de cualquier software, pero estos beneficios no se dan de manera automática por el simple hecho de estar en la nube.

Cumplir con la promesa de un servicio más eficiente requiere de un ajuste paralelo en la arquitectura de su aplicación. Las arquitecturas monolíticas se convierten fácilmente en un cuello de botella para sistemas complejos y a gran escala.

Como lo describimos en nuestro artículo de Cloud Native, los microservicios son un elemento esencial de una estrategia de adopción de prácticas cloud para la transformación digital.

¿Cómo pasar de sistemas monolíticos a microservicios?

Cuando una empresa decide migrar a microservicios lo habitual es que recurra a una empresa externa especializada y con experiencia en el sector, para que así se pueda realizar el proceso de forma efectiva y rápida, sin afectar los diferentes procesos de negocio de la empresa.

Durante el proceso de migración, los desarrolladores buscarán instintivamente reemplazar lo más rápido posible el código anterior con la implementación del nuevo código, lo que podría ser sumamente arriesgado.

Es por esto que lo primero que se debe realizar es el análisis del sistema actual, para identificar qué se puede comenzar a migrar. Inicialmente se deben buscar partes de la lógica de negocio que sea posible separar. Adicionalmente, se deben identificar partes del código que consuman muchos recursos, pero que puedan ser aisladas.

Por ejemplo, se puede comenzar con las funcionalidades que están dentro del viaje que realiza el cliente por el sistema, dirigiendo gradualmente el tráfico fuera del sistema monolítico, a través de indicadores y eliminando progresivamente el código anterior.

Algunos ejemplos pueden ser áreas comunes como la gestión de archivos de medios o externos, la autenticación con sistemas externos, los sistemas de notificaciones, o funciones específicas de negocio en una aplicación tradicional (ej. costos de envío, descuentos, inventarios, entre otros).

La idea es ir reemplazando lentamente las funcionalidades en el sistema monolítico con los diversos microservicios, para así minimizar el impacto que pueda tener la migración.

Esta migración puede convertirse en un proceso desafiante y lento, especialmente para empresas con sistemas monolíticos grandes y complejos.

Contáctenos

Si su organización tiene interés en implementar microservicios de la mano de expertos, lo invitamos a contactarnos.