Estilos de arquitectura

Un estilo de arquitectura es una familia de arquitecturas que comparten ciertas características. Por ejemplo, N niveles es un estilo de arquitectura común. Más recientemente, las arquitecturas de microservicios han empezado a ganar favor. Los estilos de arquitectura no requieren el uso de tecnologías concretas, pero algunas tecnologías son adecuadas para determinadas arquitecturas. Por ejemplo, los contenedores son una opción natural para los microservicios.

Hemos identificado un conjunto de estilos de arquitectura que se encuentran normalmente en aplicaciones en la nube. El artículo para cada estilo incluye:

• Descripción y diagrama lógico del estilo.
• Recomendaciones para cuándo elegir este estilo.
• Ventajas, desafíos y procedimientos recomendados.
• Una implementación recomendada mediante los servicios de Azure pertinentes.

Un paseo rápido por los estilos

En esta sección se ofrece un paseo rápido por los estilos de arquitectura que hemos identificado, junto con algunas consideraciones de alto nivel para su uso. Tenga en cuenta que la lista no es exhaustiva. Lea más detalles en los temas vinculados.

N niveles

Arquitectura N-tier es una arquitectura tradicional para aplicaciones empresariales. Las dependencias se administran dividiendo la aplicación en capas que realizan funciones lógicas , como la presentación, la lógica de negocios y el acceso a datos. Una capa solo puede llamar a capas que se encuentran debajo de ella. Sin embargo, esta estratificación horizontal puede ser una desventaja. Puede ser difícil introducir cambios en una parte de la aplicación sin tocar el resto de la aplicación. Esto hace que las actualizaciones frecuentes sean un desafío, lo que limita la rapidez con la que se pueden agregar nuevas características.

La arquitectura de n niveles es una opción habitual para migrar aplicaciones existentes que ya usan una arquitectura en capas. Por ese motivo, el modelo N-tier se ve con mayor frecuencia en soluciones de infraestructura como servicio (IaaS), o en aplicaciones que utilizan una combinación de IaaS y servicios administrados.

Web-Cola-Trabajo

Para una solución paaS pura, considere la posibilidad de usar una arquitectura web-Queue-Worker . En este estilo, la aplicación tiene un front-end web que controla las solicitudes HTTP y un trabajo back-end que realiza tareas intensivas de CPU o operaciones de larga duración. El front-end se comunica con el trabajador a través de una cola de mensajes asincrónica.

Web-queue-worker es adecuado para dominios relativamente simples con algunas tareas que consumen muchos recursos. Al igual que en la de n niveles, la arquitectura es fácil de entender. El uso de servicios administrados simplifica la implementación y las operaciones. Pero con dominios complejos, puede ser difícil administrar las dependencias. La interfaz y el trabajador pueden convertirse fácilmente en componentes monolíticos grandes que son difíciles de mantener y actualizar. Al igual que con N niveles, esto puede reducir la frecuencia de las actualizaciones y limitar la innovación.

Microservicios

Si la aplicación tiene un dominio más complejo, considere la posibilidad de pasar a una arquitectura de microservicios . Una aplicación de microservicios se compone de muchos servicios pequeños e independientes. Cada servicio implementa una única funcionalidad empresarial. Los servicios se acoplan de forma flexible y se comunican a través de contratos de API.

Cada servicio se puede crear mediante un equipo de desarrollo pequeño y centrado. Los servicios individuales se pueden implementar sin mucha coordinación entre equipos, lo que fomenta las actualizaciones frecuentes. Una arquitectura de microservicios es más compleja a la hora de compilar y administrar que la de n niveles o la de web-cola-trabajo. Requiere una cultura de desarrollo maduro y DevOps. Si se hace correctamente, este estilo puede dar lugar a una mayor velocidad de lanzamiento, una innovación más rápida y una arquitectura más resistente.

Arquitectura basada en eventos

Event-Driven Arquitecturas usan un modelo publish-subscribe (pub-sub), donde los productores publican eventos y los consumidores se suscriben a ellos. Los productores son independientes de los consumidores y los consumidores son independientes entre sí.

Considere una arquitectura controlada por eventos para aplicaciones que ingieren y procesan un gran volumen de datos con una latencia muy baja, como soluciones de IoT. El estilo también es útil cuando diferentes subsistemas deben realizar diferentes tipos de procesamiento en los mismos datos de eventos.

Macrodatos, Big Compute

Big Data y Big Compute son estilos de arquitectura especializados para cargas de trabajo que se ajustan a determinados perfiles específicos. Los macrodatos dividen un conjunto de datos muy grande en fragmentos, realizando el procesamiento paralelo en todo el conjunto, para el análisis y los informes. El proceso grande, también denominado informática de alto rendimiento (HPC), realiza cálculos paralelos en un gran número (miles) de núcleos. Los dominios incluyen simulaciones, modelado y representación 3D.

Estilos de arquitectura como restricciones

Un estilo de arquitectura coloca restricciones en el diseño, incluido el conjunto de elementos que pueden aparecer y las relaciones permitidas entre esos elementos. Las restricciones guían la "forma" de una arquitectura mediante la restricción del universo de opciones. Cuando una arquitectura se ajusta a las restricciones de un estilo determinado, surgen determinadas propiedades deseables.

Por ejemplo, las restricciones de los microservicios incluyen:

• Un servicio representa una única responsabilidad.
• Cada servicio es independiente de los demás.
• Los datos son privados para el servicio que lo posee. Los servicios no comparten datos.

Al cumplir estas restricciones, lo que surge es un sistema en el que los servicios se pueden implementar de forma independiente, los errores están aislados, las actualizaciones frecuentes son posibles y es fácil introducir nuevas tecnologías en la aplicación.

Cada estilo de arquitectura tiene sus propias ventajas. Por lo tanto, antes de elegir cualquier estilo arquitectónico, asegúrese de que comprende los principios y restricciones subyacentes de ese estilo. De lo contrario, puede acabar con un diseño que se ajuste al estilo en un nivel superficial, pero no logra el potencial completo de ese estilo. Debe prestar más atención a por qué elige un estilo arquitectónico determinado que cómo implementarlo. También es importante ser pragmático. A veces es mejor relajar una restricción, en lugar de insistencia en la pureza arquitectónica.

La elección de un estilo arquitectónico adecuado debe realizarse idealmente con consensos de las partes interesadas de la carga de trabajo informadas. El equipo de carga de trabajo debe identificar primero la naturaleza del problema que están intentando resolver. A continuación, deben identificar los impulsores empresariales y las características de arquitectura correspondientes (también conocidos como requisitos no funcionales) y, a continuación, priorizarlos. Por ejemplo, si necesitan un tiempo de comercialización más corto, podrían priorizar la capacidad de mantenimiento, la capacidad de prueba y la confiabilidad de las funcionalidades de implementación rápidas. O bien, si el equipo de cargas de trabajo tiene un presupuesto restringido, podría priorizar la viabilidad y la simplicidad. Elegir y mantener un estilo arquitectónico no es una actividad única, sino un enfoque continuo: la arquitectura debe medirse, validarse y ajustarse continuamente con el tiempo. Normalmente, hay un costo significativo en el cambio de estilo arquitectónico, por lo que se puede justificar más esfuerzo por adelantado para la eficiencia del equipo a largo plazo y la mitigación de riesgos.

En la tabla siguiente se resume cómo cada estilo administra las dependencias y los tipos de dominio que son más adecuados para cada uno.

Estilo de arquitectura	Administración de dependencias	Tipo de dominio
N niveles	Niveles horizontales divididos por subred	Dominio empresarial tradicional. La frecuencia de las actualizaciones es baja.
Web-cola-trabajo	Trabajos de front-end y back-end, desacoplados mediante mensajería asincrónica.	Dominio relativamente sencillo con algunas tareas que consumen muchos recursos.
Microservicios	Servicios descomponidos verticalmente (funcionalmente) que se llaman entre sí a través de las API.	Dominio complicado. Actualizaciones frecuentes.
Arquitectura controlada por eventos	Productor/consumidor. Vista independiente por subsistema.	Sistemas IoT y en tiempo real.
Macrodatos	Divida un conjunto de datos enorme en pequeños fragmentos. Procesamiento paralelo en conjuntos de datos locales.	Análisis de datos por lotes y en tiempo real. Análisis predictivo mediante ML.
Gran capacidad de cálculo	Asignación de datos a miles de núcleos.	Dominios intensivos de proceso, como la simulación.

Tener en cuenta los desafíos y las ventajas

Las restricciones también crean desafíos, por lo que es importante comprender las desventajas al adoptar cualquiera de estos estilos. ¿Superan las ventajas del estilo de arquitectura los desafíos, para este subdominio y contexto limitado?

Estos son algunos de los tipos de desafíos que se deben tener en cuenta al seleccionar un estilo de arquitectura:

• Complejidad. ¿Está justificada la complejidad de la arquitectura para el dominio? Por el contrario, ¿el estilo es demasiado simple para su dominio? En ese caso, corre el riesgo de acabar con una "gran bola de barro", ya que la arquitectura no le ayuda a administrar las dependencias de forma limpia.

• Mensajería asincrónica y coherencia final. La mensajería asincrónica se puede usar para desacoplar servicios y aumentar la confiabilidad (ya que los mensajes se pueden reintentar) y la escalabilidad. Sin embargo, esto también crea desafíos para controlar la coherencia final, así como la posibilidad de mensajes duplicados.

• Comunicación entre servicios. A medida que se descompone una aplicación en servicios independientes, existe el riesgo de que la comunicación entre los servicios provoque una latencia inaceptable o cree una congestión de red (por ejemplo, en una arquitectura de microservicios).

• Capacidad de administración. ¿Qué tan difícil es administrar la aplicación, supervisar, implementar actualizaciones, etc.?

Recursos relacionados

• Diez principios de diseño para las aplicaciones de Azure
• Creación de aplicaciones en la nube de Microsoft
• Procedimientos recomendados en aplicaciones en la nube
• Patrones de diseño en la nube
• Pruebas de rendimiento y antipatrones para aplicaciones en la nube
• Diseño de soluciones multiinquilino en Azure
• Arquitectura de carga de trabajo crítica en Azure
• Arquitectura para startups