Arquitectura Monolítica

El estilo arquitectónico monolítico consiste en crear una aplicación autosuficiente que contenga absolutamente toda la funcionalidad necesaria para realizar la tarea para la cual fue diseñada, sin contar con dependencias externas que complementen su funcionalidad. En este sentido, sus componentes trabajan juntos, compartiendo los mismos recursos y memoria. En pocas palabras, una aplicación monolítica es una unidad cohesiva de código.

Un monolítico podrías estar construido como una sola unidad de software o creada a partir de varios módulo o librerías, pero lo que la distingue es que al momento de compilarse se empaqueta como una solo pieza, de tal forma que todos los módulos y librerías se empaquetarán junto con la aplicación principal.

El estilo monolítico no es algo que haya sido planeado o ideado por alguien en particular, si no que todas las aplicaciones al inicio de la computación nacían con este estilo arquitectónico. Solo hace falta recordar los sistemas antiguos, donde todo funcionaba en una súper computadora, la cual realizaba todas las tareas. Recordemos que al inicio no existían el internet, por lo que no había forma de consumir servicios externos para realizar determinadas tareas, en su lugar, el sistema monolítico tenía que implementar absolutamente toda la funcionalidad necesaria para funcionar, y de esta forma ser auto suficiente.

Con el tiempo, llego el internet y con ello la posibilidad de consumir servicios externos, llegaron arquitecturas modulares que permitían separar el código en unidades de software más manejables, cohesivas y fácil de administrar, sin embargo, con todos estos avances, siguen existiendo las aplicaciones Monolíticas, las cuales son vistas por los inexpertos como algo malo o incluso como un Anti patrón, pero la realidad es que esto está muy alejado de la realidad.

A pesar de todo el estigma que tienen las aplicaciones monolíticas, la realidad es que, hasta el día de hoy, las aplicaciones monolíticas siguen teniendo un protagonismo muy importante y siguen existiendo caso donde son totalmente indispensables para mantener la operación de las empresas.

Puede parecer un poco tonto el solo hecho de pensar en hacer una aplicación monolítica hoy en día, sin embargo, todavía hay escenarios donde son totalmente necesaria, solo imagina el sistema venta y facturación de una pequeña empresa, el software de los equipos médicos, programas de escritorio, como procesadores de texto o incluso sistemas más completos como los clásicos CRM o ERP.

Todos estos sistemas muchas veces funcionan de forma independiente, sin acceso a internet y necesitan una autonomía total, solo imagina que un equipo médico no funcione si no se puede conectar a internet o que necesite de servicios externos para operar, eso podría costar vidas, o que el cajero de una tienda no pueda vender o administrar su inventario porque una dependencia no está disponible, eso podría costar la perdida de ventas. Lo cierto es que las aplicaciones monolíticas son cada vez menos atractivas, pero hasta el día de hoy, tiene aplicaciones donde difícilmente podrán ser remplazadas.

Una falsa creencia es que, una aplicación monolítica es un caos por dentro, donde todo el código está amontonado, no hay una estructura clara y que por lo general tiene miles de clases u objetos, sin embargo, esto es solo una mala fama que se le ha dado, si bien es verdad que se podía dar el caso, recordemos que eso también se podría dar en cualquier estilo de arquitectura, pues eso dependen más bien del programador y no del estilo arquitectónico.

Otra falsa creencia es creer que las aplicaciones Monolíticas son solo las aplicaciones grandísimas que hacen un montón de cosas, pero lo cierto es que un monolítico puede ser de una sola clase, o de miles, lo que define un estilo monolítico no es el número de clases, archivos o líneas de código, lo que lo define es que es autosuficiente, es decir, que tiene toda la funcionalidad para operar por sí mismo y sin depender de nadie más.

Tip: Independencia

Quizás la palabra que mejor define a un monolítico es la Independencia, pues es la capacidad más notable que tiene.

Como se estructura un Monolítico

En los Monolítico podemos tener una serie de paquetes bien organizados y un código muy claro, donde cada paquete puede tener cierta parte de la funcionalidad y están desacoplados uno de otro (recordemos que eso es independiente del estilo arquitectónico). Sin embargo, al momento de compilarse el código, todo se empaqueta como un solo software. Cabe mencionar que cualquier librería que sea requerida, será exportada como parte del archivo compilado de salida.

Algo a tomar en cuenta es que cuando los módulos son compilados por separado y son instalados como complementos ya no se trata de un Monolítico y pasar a ser un estilo arquitectónico de Microkernel, el cual analizaremos más adelante.

En la imagen podemos apreciar cómo funciona el proceso de compilación de una aplicación Monolítica, el cual todos los paquetes junto con sus dependencias son compilados y da como resultado un solo artefacto, el cual incluye todo el código junto con las dependencias. En este ejemplo decimos que hemos creado un EXE, pero se pudo haber creado un Jar en el caso de Java o un JS en el caso de JavaScript, dependiendo la tecnología utilizada tendremos un artefacto diferente, pero al final, todos contendrán todo el código con sus dependencias.

Características de un Monolítico

En esta sección analizaremos las características que distinguen al estilo Monolítico del resto. Las características no son ventajas o desventajas, si no que más bien, nos sirven para identificar cuando una aplicación sigue un determinado estilo arquitectónico.

Las características se pueden convertir en ventajas o desventajas solo cuando analizamos la problemática que vamos a resolver, mientras tanto, son solo características:

1. Son aplicaciones autosuficientes (no requieren de nada para funcionar).
2. Realizan de punta a punta todas las operaciones para terminar una tarea.
3. Son por lo general aplicaciones grandes, un que no es un requisito.
4. Son por lo general silos de datos privados, es decir, cada instalación administra si propia base de datos.
5. Todo el sistema corre sobre una solo plataforma.

Ventajas

• Fácil de desarrollar: Debido a que solo existe un componente, es muy fácil para un equipo pequeño de desarrollo iniciar un nuevo proyecto y ponerlo en producción rápidamente.
• Fácil de escalar: Solo es necesario instalar la aplicación en varios servidores y ponerlo detrás de un balanceador de cargar.
• Pocos puntos de fallo: El hecho de no depender de nadie más, mitiga gran parte de los errores de comunicación, red, integraciones, etc. Prácticamente los errores que pueden salir son por algún bug del programador, pero no por factores ajenos.
• Autónomo: Las aplicaciones Monolíticas se caracterizan por ser totalmente autónomas (auto suficientes), lo que les permite funcionar independientemente del resto de aplicaciones.
• Performance: Las aplicaciones Monolíticas son significativamente más rápidas debido que todo el procesamiento lo realizan localmente y no requieren consumir procesos distribuidos para completar una tarea.
• Fácil de probar: Debido a que es una sola unidad de código, toda la funcionalidad está disponible desde el inicio de la aplicación, por lo que es posible realizar todas las pruebas necesarias sin depender de nada más.

desventajas

• Anclado a un Stack tecnológico: Debido a que todo el software es una sola pieza, implica que utilicemos el mismo Stack tecnológico para absolutamente todo, lo que impide que aprovechemos todas las tecnologías disponibles.
• Escalado Monolítico: Escalar una aplicación Monolítica implica escalar absolutamente toda la aplicación, gastando recursos para funcionalidad que quizás no necesita ser escalada (en el estilo de Microservicios analizaremos como solucionar esto).
• El tamaño sí importa: sin albur, las aplicaciones Monolíticas son fácil de operar con equipo pequeños, pero a medida que la aplicación crece y con ello el equipo de desarrollo, se vuelve cada vez más complicado dividir el trabajo sin afectar funcionalidad que otro miembro del equipo también está moviendo.
• Versión tras versión: Cualquier mínimo cambio en la aplicación implicará realizar una compilación del todo el artefacto y con ello una nueva versión que tendrá que ser administrada.
• Si falla, falla todo: A menos que tengamos alta disponibilidad, si la aplicación Monolítica falla, falla todo el sistema, quedando totalmente inoperable.
• Es fácil perder el rumbo: Por la naturaleza de tener todo en un mismo módulo es fácil caer en malas prácticas de programación, separación de responsabilidades y organización de las clases del código.
• Puede ser abrumador: En proyectos muy grandes, puede ser abrumador para un nuevo programador hacer un cambio en el sistema.

Conclusiones

A pesar de la mala fama que se les ha dado a las aplicaciones Monolíticas, la realidad es que tiene ventajas que hasta el día de hoy son difíciles de igualar, entre las que destacan su total independencia el performance que puede llegar a alcanzar.

Utilizar un estilo Monolítico no es para nada malo, incluso en nuestra época, lo malo sería quedarnos siempre atascados en este estilo arquitectónico y no ir migrando a otros estilos más sofisticados a medida que nuestra aplicación va creciendo. Algunos síntomas de que el estilo arquitectónico ya nos comienza a quedar chico sería cuando, cada vez es más difícil dividir el trabajo entre los desarrolladores sin que tengan conflictos con el código, existen una necesidad de escalamiento más quirúrgica y se necesita escalar ciertas funcionalidades y no todo el proyecto, cuando el proyecto es tan grande que es complicado para los desarrolladores comprender el funcionamiento por la complejidad y la absurda cantidad de clases o archivos, y finalmente, cuando necesitamos empezar a diversificarnos con respecto al Stack tecnológico a utilizar.

Acerca de este libro

Todo lo que acabas de ver en este artículo es solo una pequeña parte del libro Introducción a la arquitectura de software, el libro más completo en español sobre arquitectura de software, donde cubrimos los temas más importantes para convertirte en un arquitecto de software profesional.

¿Quieres convertirte en arquitecto de software pero no sabes cuál es el camino adecuando? o simplemente no sabes que guía estudiar para convertirte en arquitecto de software, te invito a que veas mi libro:

Ver libro