#Agile Construir monolitos no esta mal.

por Publicado el

Un monolito es un programa cuyos componentes físicos o lógicos se encuentran agrupados en un solo componente. Construir monolitos no está mal, tiene implicaciones que debes considerar.

¿Cuándo es mejor diseñar monolitos?.

Cuando agrupas los componentes en un solamente grupo de archivos o componentes vas a perder capacidad de reutilizar el código, pero vas a ganar en facilidad de despliegue. La arquitectura centralizada de un monolito reduce los conflictos con dependencias externas (algo de lo que adolecen los micro servicios). Por ejemplo, en aplicaciones que se ejecutan locamente en servidores de clientes mi equipo ha tenido mejores resultados agrupando dlls y recursos en un únicamente componente, todas las librerías se compilan para incrustarse en una sola librería global. Con este estilo de construcción se previene incompatibilidades con versiones distintas de librerías. Obvio, estos componentes son poco reutilizables, no podríamos usarlos para otras aplicaciones y cuando lo hemos intentado hacer ha habido problemas.

Bueno,  el mecanismo de despliegue que acabo de describirte es un tipo de monolito, no todos los monolitos son iguales.

Tipos de monolitos.

Existen tres tipos de agrupaciones monolíticas que vas a encontrar:

  • Monolitos físicos: Es la agrupación de varios componentes con distintas preocupaciones en un nada más componente físico. El caso anterior que describí es un monolito físico. También es común encontrar modelos de N capas en un únicamente ensamblado, las responsabilidades están separadas en espacios de nombres especializados, pero juntas en el mismo componente.
  • Monolitos lógicos: Es la agrupación de varios componentes con distintas preocupaciones en un exclusivamente componente físico y en el mismo espacio de nombres. Este caso ya es un code smell, todas las unidades conceptuales que representan el dominio de problema están revueltas, puedes ver accesos a datos en los componentes de presentación o reglas de negocio distribuidas en todas los capas. No hay mucho que hacer con estos sistemas, son poco mantenibles y no reutilizables.
  • Monolitos físicos y lógicos: Es la agrupación de componentes sin arquitectura en un solo paquete físico. Básicamente, es código espagueti y dependencias agrupadas en un solo componente.

Un monolito es un mecanismo de distribución, no una arquitectura.

Si requieres agrupar varios servicios en un solo programa, esto no te da la justificación para no tener una arquitectura clara y un modelo del dominio del problema robusto. Diseña tus servicios para funcionar aisladamente aun cuando vayan a convivir juntos en una aplicación.

Cuando juntes componentes debe ser porque así lo necesitas, no porque no tienes otra opción. Por ejemplo, el servicio de emisión de facturas al que le doy soporte tiene mucho en común con el servicio de validación de facturas,  son las mismas reglas de negocios las que se ejecutan. Durante las primeras fases de trabajo con estos dos servicios, el servicio de validación, el cual estaba en una ubicación física aparte, era actualizado con menos frecuencia que el servicio de emisión, esto causaba problemas a los clientes. Para evitar tener versiones distintas de los componentes decidí volver uno, el servicio de emisión y el de validación, esto permitió ofrecer mejores tiempos de respuesta a los clientes. Conceptualmente, los servicios funcionan distinto, cada uno aparte, sin interferir uno con el otro. Se ganó en respuesta de despliegue y se perdió en razones de fallo, si falla uno de los dos servicios que ahora viven en el mismo sitio web posiblemente fallara el otro.  El cambio es reversible, en cualquier momento puedo separar los servicios porque son un monolito físico, no uno lógico.

Los micro servicios son una extensión de SOLID.

Los micro servicios son una consecuencia de construir componentes desacoplados con una sola razón de cambio. Si construyes componentes  desacoplados desde el espacio de nombres no vas a tener problemas al decidir entre micro servicios o un monolito más adelante. Si diseñas micro servicios solamente porque están de moda no vas a llegar a ningún lugar. Debes construir componentes que funcionen aisladamente desde el principio, no importa el contexto de ejecución ni el mecanismo de despliegue.

Autor imagen: Susan Holt Simpson

Gustavo Sánchez
Últimas entradas de Gustavo Sánchez (ver todo)

Publicado por Gustavo Sánchez

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.