Patrones de Arquitectura Software. La Arquitectura Monolítica.

La arquitectura monolítica es uno de los patrones de arquitectura de software más antiguos y tradicionales. En este patrón, todas las funcionalidades y componentes de una aplicación se combinan en una sola unidad o módulo. En general, una aplicación monolítica se divide internamente en diferentes componentes funcionales, tales como la interfaz de usuario, la gestión de la lógica de negocio y la capa de acceso a los datos, pero estos componentes están estrechamente interconectados y ejecutados en un único proceso.

Es importante resaltar algunas de las características clave de la arquitectura monolítica:

• Desarrollo simplificado: Las aplicaciones monolíticas son fáciles de desarrollar debido a la naturaleza lineal y predecible del desarrollo. No hay dependencias de red, y el desarrollo, pruebas y depuración pueden ser más simples en comparación con otros estilos de arquitectura.
• Despliegue sencillo: Las aplicaciones monolíticas son fáciles de desplegar, ya que solo necesitas copiar el ejecutable compilado al servidor deseado. No se requiere coordinación de múltiples servicios.
• Rendimiento: Dado que todos los componentes de la aplicación se ejecutan en el mismo proceso, las aplicaciones monolíticas pueden tener un rendimiento eficiente, ya que no necesitan hacer llamadas de red costosas entre servicios.

Sin embargo, a pesar de estos beneficios, la arquitectura monolítica también tiene sus desafíos:

• Escalabilidad: Escalar una aplicación monolítica puede ser un desafío, ya que cada vez que se necesita más capacidad, es necesario escalar toda la aplicación en lugar de solo el componente que necesita más recursos.
• Dependencias: En una aplicación monolítica, todos los componentes están estrechamente acoplados y dependen entre sí. Esto significa que un cambio en un área del código puede tener efectos secundarios inesperados en otras áreas.
• Tiempo de despliegue y tiempo de inactividad: Dado que todo se despliega como una única unidad, un cambio en cualquier parte del código requiere un despliegue completo. Esto puede llevar a tiempos de despliegue más largos y a más tiempo de inactividad durante las actualizaciones.

A pesar de estos desafíos, la arquitectura monolítica todavía puede ser una buena elección para aplicaciones pequeñas y simples, donde la facilidad de desarrollo y despliegue supera los desafíos de la escalabilidad y las dependencias. Sin embargo, para aplicaciones más grandes y complejas, otros patrones de arquitectura como los microservicios o la arquitectura hexagonal pueden ser más adecuados.

La arquitectura monolítica se define por ser una aplicación que está construida como una unidad cohesiva y unificada. Aunque se hable de una unidad única, esta aplicación se compone internamente de diferentes componentes o módulos interconectados que abordan funciones específicas dentro del sistema. Estos módulos no son independientes en términos de operación y ejecución, sino que forman parte de un solo proceso. Aunque la aplicación sea un todo indivisible desde el punto de vista de su implementación y despliegue, internamente, la aplicación puede estar bien estructurada y organizada en diferentes capas de responsabilidad.

Las capas más comunes en una arquitectura monolítica son:

• Capa de presentación: También conocida como capa de interfaz de usuario (UI), esta es la capa que interactúa directamente con el usuario. Puede estar compuesta por páginas web, interfaces de aplicaciones móviles, interfaces de línea de comandos, entre otros. Su función es recoger las entradas del usuario y mostrar los datos y resultados al usuario.
• Capa de lógica de negocio: Esta es la capa que maneja la lógica central de la aplicación. Aquí es donde se implementan las reglas de negocio y se procesan los datos. Esta capa se comunica con la capa de presentación para recibir las entradas del usuario y con la capa de datos para almacenar o recuperar datos.
• Capa de acceso a datos: Esta capa interactúa directamente con las bases de datos o cualquier otra fuente de datos. Su propósito es manejar todas las operaciones relacionadas con los datos, como las operaciones CRUD (crear, leer, actualizar, eliminar) y las consultas a la base de datos.

Estas capas interactúan entre sí para llevar a cabo las operaciones de la aplicación. Por ejemplo, cuando un usuario realiza una acción en la interfaz de usuario, esta acción se transmite a la capa de lógica de negocio, que procesa la acción y puede solicitar o modificar datos en la capa de acceso a datos.

Aunque estas capas están lógicamente separadas, físicamente se ejecutan en el mismo proceso y están estrechamente acopladas. Esto significa que un cambio en una capa puede tener impactos en las otras capas. Por ejemplo, un cambio en la capa de acceso a datos puede requerir cambios correspondientes en la capa de lógica de negocio y posiblemente también en la capa de presentación.

En una arquitectura monolítica, el código de cada una de estas capas se combina en una única base de código, y la aplicación se despliega como una única unidad. Aunque esto puede simplificar el desarrollo y el despliegue, también puede hacer que la aplicación sea más difícil de escalar y mantener a medida que crece.

En una arquitectura monolítica, el manejo de las peticiones de los usuarios se realiza de manera lineal y predecible, generalmente a través de un único sistema. Cuando un usuario realiza una petición, esa petición se procesa en un único sistema y sigue un camino predecible a través de las diferentes capas de la aplicación.

Por lo general, la petición del usuario se procesa de la siguiente manera:

• Recepción de la petición: La petición del usuario, que puede ser una acción realizada en la interfaz de usuario o una petición HTTP, se recibe inicialmente en la capa de presentación. Esta capa es responsable de recoger las entradas del usuario y formatearlas para su posterior procesamiento.
• Procesamiento de la petición: Una vez que la capa de presentación ha recibido y formateado la petición, la pasa a la capa de lógica de negocio. Esta capa es donde se procesa la petición. Por ejemplo, si la petición es para crear un nuevo registro, la capa de lógica de negocio comprobará las reglas de negocio, como las restricciones de validación, y procesará la petición.
• Acceso a los datos: Durante el procesamiento de la petición, la capa de lógica de negocio puede necesitar acceder a los datos almacenados en la base de datos. Para hacer esto, se comunica con la capa de acceso a datos, que se encarga de todas las operaciones relacionadas con la base de datos.
• Respuesta: Una vez que la petición ha sido procesada y se ha completado cualquier operación de acceso a datos necesaria, la capa de lógica de negocio genera una respuesta. Esta respuesta se pasa de nuevo a la capa de presentación, que formatea la respuesta en un formato adecuado para el usuario (como una página web o una respuesta API) y la envía de vuelta al usuario.

Debido a la naturaleza monolítica de este tipo de arquitectura, todas estas operaciones se realizan dentro de un único sistema y proceso. Esto puede simplificar el desarrollo y las pruebas, ya que no hay necesidad de manejar la comunicación entre diferentes servicios o procesos. Sin embargo, también puede hacer que la aplicación sea más difícil de escalar y pueda ser un punto único de fallo. Por ejemplo, si un componente de la aplicación falla, puede hacer que toda la aplicación sea inaccesible. Además, ya que todas las peticiones se procesan en un único sistema, el rendimiento de la aplicación puede verse afectado si se recibe un gran número de peticiones al mismo tiempo.

El tema de la escalabilidad es un desafío importante en el contexto de la arquitectura monolítica. Dado que toda la aplicación se ejecuta como una sola unidad, escalar una parte de la aplicación a menudo implica escalar toda la aplicación.

La escalabilidad se refiere a la capacidad de un sistema para manejar un aumento en la carga de trabajo. En el contexto de las aplicaciones de software, esto puede significar la capacidad de manejar un mayor número de usuarios, más solicitudes o más datos.

Existen dos enfoques principales para escalar una aplicación monolítica:

• Escalado Vertical: También conocido como "escalado por actualización", implica aumentar la capacidad de un único servidor añadiendo más recursos, como memoria, CPU o almacenamiento. Este enfoque puede ser efectivo hasta cierto punto, pero tiene sus limitaciones. Los servidores físicos tienen un límite en cuanto a la cantidad de recursos que pueden tener, y actualizar un servidor puede ser costoso y requerir tiempo de inactividad.
• Escalado Horizontal: También conocido como "escalado por replicación", implica duplicar la aplicación entera en múltiples servidores y balancear la carga entre ellos. Este enfoque puede ser más efectivo para manejar grandes aumentos de carga, pero también tiene sus desafíos. La coordinación entre las diferentes instancias puede ser compleja, especialmente si tienen que compartir datos.

Un problema inherente a la arquitectura monolítica es que no se puede escalar partes individuales de la aplicación de forma independiente. Si una parte de la aplicación, como la lógica de negocio, necesita más recursos, todo el sistema debe ser escalado. Esto puede ser ineficiente y costoso.

Además, la escalabilidad de las aplicaciones monolíticas puede verse limitada por su naturaleza acoplada. Como todos los componentes están interconectados, un cuello de botella en una parte de la aplicación puede afectar al rendimiento de toda la aplicación.

Finalmente, la escalabilidad de las aplicaciones monolíticas puede ser más desafiante en términos de desarrollo y mantenimiento. A medida que la aplicación crece, la base de código puede volverse grande y compleja, lo que dificulta la introducción de cambios y nuevas características. La necesidad de coordinar y desplegar cambios en toda la aplicación puede ralentizar el desarrollo y aumentar el riesgo de errores.

El ciclo de vida del desarrollo de una aplicación monolítica tiene características distintivas y presenta desafíos y beneficios específicos.

• Desarrollo inicial: En las primeras etapas de desarrollo, la arquitectura monolítica puede ser más simple y directa para implementar. Todos los componentes de la aplicación se desarrollan y se prueban juntos, lo que puede facilitar la integración y la coordinación. Además, no hay necesidad de construir y mantener la infraestructura y las herramientas para la comunicación y la coordinación entre los servicios independientes, lo que puede ser necesario en otras arquitecturas, como los microservicios.
• Implementación: En una arquitectura monolítica, toda la aplicación se implementa como una unidad. Esto significa que cualquier cambio en cualquier parte de la aplicación requiere una recompilación y un redeploy completo. Esta característica puede hacer que el proceso de implementación sea más lento y aumentar el riesgo de tiempo de inactividad y errores.
• Mantenimiento y actualizaciones: A medida que la aplicación crece y evoluciona, mantener y actualizar una aplicación monolítica puede volverse más desafiante. Debido a la interconexión de los componentes, los cambios en una parte de la aplicación pueden tener efectos secundarios inesperados en otras partes. Además, a medida que la base de código crece, puede volverse más difícil de entender y manejar, lo que puede ralentizar el desarrollo y aumentar el riesgo de errores.
• Escalado y evolución: A medida que la aplicación crece y las necesidades cambian, puede ser necesario escalar la aplicación o introducir nuevas tecnologías y prácticas. Con una arquitectura monolítica, estos cambios pueden ser más difíciles de implementar. El escalado a menudo requiere el escalado de toda la aplicación, lo que puede ser ineficiente y costoso. Y debido a la interconexión de los componentes, la introducción de nuevas tecnologías o prácticas puede requerir cambios importantes en toda la aplicación.
• Depuración y pruebas: La depuración y las pruebas pueden ser más desafiantes en una arquitectura monolítica. Debido a la interconexión de los componentes, los errores pueden ser más difíciles de aislar y solucionar. Y las pruebas pueden requerir la ejecución y la verificación de toda la aplicación, lo que puede ser más lento y requerir más recursos

Aunque la arquitectura monolítica puede ser más simple y directa para el desarrollo inicial, puede presentar desafíos a medida que la aplicación crece y evoluciona. Los equipos de desarrollo pueden necesitar considerar cuidadosamente estas cuestiones y planificar con anticipación para manejar los desafíos de la escalabilidad, el mantenimiento y la evolución.

Aunque los desafíos y limitaciones de la arquitectura monolítica son evidentes, especialmente en comparación con las arquitecturas más modernas y escalables, como los microservicios, aún existen muchos casos de uso donde una arquitectura monolítica es la opción más apropiada. A continuación, se presentan algunos escenarios donde este enfoque podría ser preferible:

• Aplicaciones de pequeña a mediana escala: Para aplicaciones que no esperan un gran tráfico o no tienen una gran cantidad de funcionalidad, una arquitectura monolítica puede ser la opción más práctica y rentable. La simplicidad de desarrollo, pruebas y despliegue de estas aplicaciones puede superar la falta de escalabilidad y flexibilidad de una arquitectura monolítica.
• Aplicaciones con un equipo de desarrollo pequeño: Los equipos de desarrollo más pequeños pueden encontrar que una arquitectura monolítica es más fácil de gestionar, ya que no requiere la coordinación de múltiples servicios o equipos. Este enfoque también puede ser más fácil de entender y mantener para los desarrolladores menos experimentados.
• Aplicaciones con funcionalidad interdependiente: En algunas aplicaciones, los diferentes componentes pueden estar estrechamente interrelacionados y necesitar comunicarse frecuentemente entre sí. En estos casos, una arquitectura monolítica puede ser más eficiente, ya que la comunicación entre los componentes se realiza en el mismo proceso, lo que puede ser más rápido que la comunicación entre servicios en una arquitectura de microservicios.
• Prototipos y MVPs (Productos Mínimos Viables): Cuando se está desarrollando un prototipo o un MVP, la velocidad y la simplicidad son a menudo más importantes que la escalabilidad y la flexibilidad a largo plazo. En estos casos, una arquitectura monolítica puede permitir a los equipos de desarrollo poner en marcha una aplicación funcional más rápidamente.
• Aplicaciones internas y de línea de negocio: Para aplicaciones que se utilizan internamente en una organización y que no requieren la escalabilidad y la alta disponibilidad de las aplicaciones orientadas al consumidor, una arquitectura monolítica puede ser suficiente y más rentable.

Aunque la arquitectura monolítica tiene sus limitaciones, sigue siendo una opción válida para muchas aplicaciones, especialmente las que son más pequeñas, más simples o no requieren una alta escalabilidad o disponibilidad. Los equipos de desarrollo deben considerar cuidadosamente las necesidades y las limitaciones de su aplicación específica al elegir la arquitectura más adecuada.