Modelo Arquitectónico: cómo elegir el ideal para tu proyecto

¿Qué es un Modelo Arquitectónico y por qué es importante? 

Básicamente, un modelo arquitectónico es la estructura abstracta en la que se implementará su aplicación. 

"La arquitectura de software de un programa o sistema informático es la estructura o estructuras del sistema que abarca los componentes de software, las propiedades visibles externamente de esos componentes y las relaciones entre ellos." (Bass, Clements y Kasman, Arquitectura de software en la práctica) 

Para definir el modelo que mejor se adapta a tu proyecto, necesitamos conocer bien las estrategias de la empresa a corto, medio y largo plazo, los requisitos no funcionales y arquitectónicos del software, así como la curva de crecimiento de usuarios en el tiempo y el volumen de solicitudes. . 

Además de los puntos mencionados a lo largo de este artículo, todavía hay otros a tener en cuenta a la hora de decidir qué modelo arquitectónico aplicar. Como ejemplo, podemos enumerar: 

• Preocupaciones de seguridad; 
• Almacenamiento de datos; 
• Lockins; 
• Volumen total de usuarios; 
• Volumen de usuarios simultáneos; 
• TPS (transacciones por segundo); 
• Plan de disponibilidad/SLA; 
• Requerimientos legales; 
• Disponibilidad en uno o más tipos de plataformas; 
• Integraciones. 

El estudio de la arquitectura, los RA (requisitos arquitectónicos), los VA (variables arquitectónicas), los RF (requisitos funcionales), los RNF (requisitos no funcionales) y los criterios que definen cada uno de estos elementos influyen directamente en la elección del modelo correcto. 

La elección del modelo arquitectónico puede impactar todo ciclo de vida de la aplicación. Por tanto, este es un tema que debemos tratar con mucha atención. El uso de MVP (especialmente aquellos que no entran en producción) puede ayudar mucho en esta tarea. Dan una oportunidad única de equivocarse, ajustar, volver a equivocarse, probar conceptos, ajustar y equivocarse tantas veces como sea necesario para que al final el software tenga la arquitectura en la versión más correcta, trayendo así las verdaderas ganancias de este. elección. 

Cómo se dividen los modelos arquitectónicos 

Es ideal dejar claro que como muchas definiciones en el mundo del software, qué son los modelos arquitectónicos y qué son pueden variar. Por eso, en este artículo intenté dividirlos en cuatro grandes grupos: monolíticos, semimonolíticos (o monolitos modulares), monolitos distribuidos (o microlitos) y microcomponentizados. 

Monolítico 

Modelo en el que todos los componentes forman una única aplicación o ejecutable integrados en un único código fuente. En este caso, todo se desarrolla, implementa y escala como una sola unidad. 

Pros 

• Sencillez: Dado que la aplicación se trata como una unidad única y cohesiva, se vuelve más simple ya que todas las partes están contenidas en un único código fuente. 
• Mayor cumplimiento de las Normas de Diseño: Teniendo en cuenta que tenemos un único código fuente, otro factor que lo facilita es que los propios patrones de diseño (Patrones de diseño, 01/2000) fueron escritos en tiempos de dominio de los monolitos, haciendo más adherente su aplicación. 
• Mayor rendimiento: Debido a la baja latencia en la comunicación, los monolitos tienden a tener un buen rendimiento, incluso utilizando tecnologías más obsoletas. 
• Menor consumo de recursos: la baja complejidad, la simplicidad y la menor sobrecarga de comunicación entre capas favorecen un menor consumo de recursos. 
• Solución de problemas simplificada: Creación de entornos de desarrollo y depuraciones Se convierten fácilmente en monolitos, ya que los componentes comparten los mismos procesos. Otro factor que podemos tener en cuenta es que los monolitos tienen menos puntos de falla externos, simplificando la búsqueda de errores. 

Contras 

• Tamaños de equipo limitados: averías relacionadas con Integración continua y los conflictos de fusión ocurren con mayor frecuencia en monolitos, lo que crea dificultades de trabajo paralelo para equipos grandes. 
• Escalabilidad: La escalabilidad puede estar limitada en ciertos aspectos. Incluso con facilidad en la escalabilidad vertical, la escalabilidad horizontal a menudo puede convertirse en un problema que podría afectar el crecimiento de la aplicación. 
• Disponibilidad de ventana: Normalmente, para un monolito se intercambian ejecutables, lo que requiere una ventana de disponibilidad sin que los usuarios accedan a la aplicación, lo que no ocurre con otros modelos arquitectónicos que pueden utilizar otras técnicas. desplegar como Azul verde o incluso trabajar con imágenes o vainas.
• Tecnología única: La baja diversidad tecnológica a menudo puede convertirse en un impedimento para el crecimiento de la aplicación al servir solo a un tipo de sistema operativo, por ejemplo, o no satisfacer completamente nuevas necesidades. Características solicitado por los clientes porque no cuentan con actualizaciones que sean capaces de resolver problemas complejos. 
• Mayor gasto de compilación y ejecución: Los monolitos grandes generalmente tardan mucho en compilarse y ejecutarse localmente, lo que genera un mayor compromiso de tiempo de desarrollo. 

Cuándo usar 

• Baja escalabilidad y disponibilidad: Si la aplicación tiene una escala limitada donde, por ejemplo, el número de usuarios es bajo o no es obligatoria una alta disponibilidad, el modelo monolítico es una buena solución. 
• Aplicaciones de escritorio: El modelo monolítico es muy recomendable para aplicaciones de escritorio. 
• Equipos de baja antigüedad: Los modelos monolíticos, por su sencillez y ubicación de componentes, permiten trabajar con mejor rendimiento a equipos de baja antigüedad. 
• Funciones limitadas: para una infraestructura limitada y con recursos escasos. 

Semimonolítico (o monolito modular) 

Modelo en el que las aplicaciones están compuestas por partes de estructuras monolíticas. En este caso, la combinación intenta equilibrar la simplicidad del modelo monolítico y la flexibilidad del modelo microcomponentizado. Actualmente, este modelo arquitectónico suele confundirse con los microservicios. 

Pros 

• Aporta los beneficios de los modelos monolíticos y microcomponentes: Con esto, es posible mantener piezas como estructuras monolíticas y microcomponentar únicamente aquellos componentes que tengan una necesidad real. 
• Diversidad tecnológica: posibilidad de utilizar diferentes enfoques tecnológicos. 
• Infraestructura diversificada: Este modelo se puede desarrollar para utilizar infraestructura tanto On-Premise como Cloud, favoreciendo la migración entre ambas. 
• Admite equipos más grandes: La segmentación de componentes permite que varios equipos trabajen en paralelo, cada uno dentro de su propio ámbito.
• Especialidades Técnicas: Debido a la segmentación, se aprovechan mejor las habilidades duras del equipo, como frontend, UX, backend, QA, arquitectos, etc. 

Contras 

• Estandarización: Debido a la gran cantidad de componentes que pueden aparecer en un modelo semimonolítico, la estandarización (o la falta de ella) puede convertirse en un problema importante. 
• Complejidad: La complejidad inherente a este tipo de modelo también tiende a aumentar con nuevas Características. Por lo tanto, nuevas características como mensajería, almacenamiento en caché, integraciones, control de transacciones, pruebas, entre otras, pueden agregar aún más complejidad al modelo. 
• Presupuesto: En modelos que soportan el uso de diversas tecnologías con equipos grandes se necesitan profesionales más especializados y con mayor nivel de veteranía, lo que muchas veces supone un mayor gasto en gastos de personal. 
• Solución de problemas complejos: La complejidad del modelo y la diversidad de tecnologías hacen que la resolución de problemas de la aplicación sea cada vez más difícil. Esto se debe a la gran cantidad de puntos de falla (incluidos los externos a la aplicación) que llegan a existir y la comunicación entre ellos. 

Cuándo usar 

• Aceptado en múltiples escenarios: Es un modelo flexible que puede afrontar diversos escenarios, pero no siempre de la mejor manera. 
• Pequeña definición: En proyectos que tienen incertidumbres o incluso que no tienen la definición completa de sus requerimientos, este modelo es el más adecuado. 
• En equipos medianos y grandes: Como se ha comentado, la división de componentes en varios grupos facilita el trabajo paralelo de equipos medianos y grandes. Normalmente, los grupos tienen sus propios repositorios de código, lo que hace que el trabajo paralelo sea más ágil. 
• Varios Antigüedad: Este modelo se beneficia de equipos con este formato, ya que el software semimonolítico presenta desafíos variados, tanto en la capa frontend como backend y en temas de infraestructura (IaC – Infrastructure as a Code). 
• infraestructura: para una infraestructura híbrida o basada en la nube, este modelo es más aplicable. Es un modelo que permite, por ejemplo, la adopción gradual entre On-Premise y Cloud, facilitando la adaptación y minimizando los impactos operativos. 

Monolito distribuido 

Este modelado es un modelado "moderno" que también ha sido implementado y confundido con el modelo de microcomponentes/microservicios.  

"No deberías comenzar un nuevo proyecto con microservicios, incluso si estás seguro de que tu aplicación será lo suficientemente grande como para que valga la pena". (Fowler, Martín. 2015) 

En resumen, en este modelo arquitectónico el software se construye sobre la base del modelo monolítico, pero se implementa según el modelo microcomponenteizado. Actualmente muchos lo consideran un antipatrón. 

No valdría la pena enumerar las características pro (no sé si las hay), pero sí vale la pena mencionar las que van en contra: este modelo arquitectónico reúne los puntos negativos de los otros dos estilos con los que se combina. confundido.  

En él los servicios están altamente acoplados y además tienen varios tipos de complejidad, tales como: operacional, testabilidad, despliegue, comunicaciones e infraestructuras. 

El alto acoplamiento, especialmente entre servicio. backend Trae serias dificultades de implementación, sin mencionar el aumento significativo de los puntos de falla en el software. 

Microcomponenteizado 

Modelo de software en el que todos los componentes están segmentados en partes pequeñas y completamente desacopladas. Dentro de los microcomponentes podemos mencionar: 

• Microfronteras 
• Microbases de datos 
• Microvirtualizaciones 
• Microservicios 
• Microlotes 
• BFFs 
• API 

"Un microservicio es un componente de aplicación orientado a servicios que tiene un alcance estricto, está fuertemente encapsulado, está débilmente acoplado, se puede implementar y escalar de forma independiente" (Gartner, s.f.). 

Las opiniones convergen para decir que cada microservicio que funcionó fue primero un monolito que se volvió demasiado grande para ser mantenido y llegó a un punto común de tener que ser separado. 

Pros 

• Escalabilidad: La escalabilidad en este modelo se vuelve bastante flexible. Dependiendo de la necesidad, los componentes se escalan de forma específica.
• Desarrollo ágil: Los equipos pueden trabajar de forma independiente en cada componente, lo que facilita la implementación continua y acelera el ciclo de desarrollo. 
• Resiliencia: Si un componente falla, no necesariamente afecta a toda la aplicación. Esto mejora la resiliencia general del sistema. Es importante tener en cuenta que existen enfoques de punto único de falla para evitar este tipo de problema. 
• Tecnología diversificada: cada componente puede desarrollarse utilizando diferentes tecnologías, permitiendo elegir la mejor herramienta para cada tarea específica. Además, también favorece las habilidades existentes de cada equipo. 
• Facilidad de mantenimiento: Los cambios en un componente no afectan automáticamente a otros, lo que facilita el mantenimiento y la actualización continuos. 
• Desacoplamiento: Los componentes son independientes entre sí, lo que significa que los cambios en un servicio no afectan automáticamente a otros, lo que facilita el mantenimiento. 

Contras 

• costo: alto costo de todos los componentes de este modelo (entrada, salida, solicitudes, almacenamiento, herramientas, seguridad, disponibilidad, entre otros). 
• tamaño: El software microcomponente tiende a ser de mayor tamaño en esencia. No sólo el tamaño de la aplicación, sino todo el ecosistema que la impregna desde el compromiso con el entorno de producción. 
• Complejidad operativa: Hay un aumento exponencial en la complejidad de este modelo. Diseñar buenos componentes arquitectónicos para que se gestione esta complejidad es de gran importancia. Es importante elegir y gestionar bien las herramientas de registro, APM y Monitoreo Continuo, por ejemplo. Administrar muchos microservicios puede resultar complejo. Se requiere un esfuerzo adicional para monitorear, organizar y mantener los servicios en funcionamiento. 
• Latencia: La comunicación entre microservicios puede volverse compleja, especialmente en sistemas distribuidos, y requiere estrategias adecuadas de comunicación y gestión de API. 
• Gastos generales de la red: El tráfico de red entre microservicios puede aumentar, especialmente en comparación con las arquitecturas monolíticas, lo que puede afectar el rendimiento. 
• Coherencia entre transacciones: Garantizar la coherencia en las operaciones que involucran múltiples microservicios puede resultar un desafío, especialmente cuando se trata de transacciones distribuidas. 
• Comprobabilidad:  Probar las interacciones entre microservicios puede ser más complejo que probar una aplicación monolítica, lo que requiere estrategias de prueba eficientes. 
• infraestructura: Es posible que deba invertir en una infraestructura sólida para admitir la ejecución de múltiples microservicios, incluidas herramientas de orquestación de contenedores y sistemas de monitoreo. 
• Dispersión Técnica: En este punto, podemos decir que hay una acción de la Ley de Conway "Inversa", ya que los equipos, así como las tecnologías y herramientas, tienden a seguir la dispersión y la segregación. En equipos, cada persona toma conciencia de una pequeña parte de un todo mayor. De esta forma, para tecnologías y herramientas, cada desarrollador utiliza el framework o herramientas que más le convienen. 
• Diseño basado en dominio: Para aumentar las posibilidades de éxito de este modelo, los equipos deben tener conocimientos de DDD.

Cuándo usar 

• volumetría: La arquitectura de microservicios/microcomponentes ha demostrado ser eficaz en sistemas de gran volumen, es decir, aquellos que necesitan lidiar con grandes cantidades de transacciones, datos y usuarios. 
• Disponibilidad: Una de las principales razones para adoptar este tipo de arquitectura es la disponibilidad. Cuando está bien construido, el software que adopta la microcomponentización no tiende a fallar en su totalidad cuando las partes pequeñas presentan problemas. Por lo tanto, otros componentes continúan funcionando mientras el componente problemático se recupera. 
• Escalabilidad: Si diferentes partes de su aplicación tienen diferentes requisitos de escalabilidad, los microservicios pueden resultar útiles. Puede escalar solo aquellos servicios que necesitan la mayor cantidad de recursos, en lugar de escalar toda la aplicación. 
• Tamaño del equipo: Los equipos pequeños pueden ser problemas. Configuraciones, textos estándar, entornos, pruebas, integraciones, procesos de entrada y salida. 
• Resiliencia > Rendimiento": en casos de incertidumbre, por ejemplo, el volumen de solicitudes y hasta dónde puede llegar, como grandes comercios electrónicos en periodos de alto acceso (viernes negro) donde el software debe ser más resistente y tener un rendimiento medio. 

Lista de verificación comparativao

Conclusión 

En resumen, la elección del modelo arquitectónico es crucial para el éxito del proyecto, requiriendo un análisis cuidadoso de las necesidades y objetivos. Cada modelo arquitectónico tiene sus ventajas y desventajas y debemos guiar la decisión alineándola con los requerimientos específicos del proyecto. Al considerar las estrategias, los requisitos y los estudios arquitectónicos de la empresa, es posible tomar una decisión que tendrá un impacto positivo en el ciclo de vida de la aplicación. 

El trabajo (y apoyo) del equipo de arquitectura es sumamente importante. También es de gran importancia que la gerencia y áreas afines apoyen brindando tiempo para recolectar toda esta gama de información.  

¿Aún tienes dudas? Al principio, comience con el semimonolito/monolito modular. Asimismo, preste mucha atención al modelado de bases de datos. 

Referencias 

• Garner. (Dakota del Norte.). Microservicio. Obtenido de https://www.gartner.com/en/information-technology/glossary/microservice 
• Gamma, E., Helm, R., Johnson, R. y Vlissides, J. (1994). Patrones de diseño: elementos de software reutilizable orientado a objetos. Addison-Wesley. 
• Bass, L., Clements, P., Kazman, R. (2013). Arquitectura de software en la práctica (3ª ed.). Addison-Wesley. 
• Arquitectura de Microservicios (12/2023). Obtenido de https://microservices.io/ 
• Fowler, SJ (2017). Microservicios listos para producción. Novatec. 
• Formación ArchExpert. (Dakota del Norte.). Contenido premium. Obtenido de https://one.archoffice.tech/ 
• Monolito Primero (06/2015). Obtenido de https://martinfowler.com/bliki/MonolithFirst.html 
• Microservicios. Consultado el 01/2024. Obtenido de https://martinfowler.com/tags/microservices.html