Estilos de arquitectura

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

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

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

Un recorrido rápido por los estilos

Esta sección ofrece un rápido recorrido por los estilos de arquitectura que hemos identificado, junto con algunas consideraciones de alto nivel para su uso. Conozca más información en los temas vinculados.

N niveles

N niveles es una arquitectura tradicional para aplicaciones empresariales. Las dependencias se administran mediante la división de la aplicación en capas que realizan funciones lógicas como presentaciones, lógica de negocios y acceso a datos. Una capa solo puede llamar a las capas que se encuentran por debajo de ella. Sin embargo, este sistema de capas horizontales puede tener otros efectos. Puede ser difícil introducir cambios en una parte de la aplicación sin tocar el resto de esta. Eso hace que las actualizaciones frecuentes sean un problema que limita la frecuencia con la que se agregan 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, la arquitectura de n niveles es la que se encuentra más frecuentemente en soluciones de infraestructura como servicio (IaaS) o en aplicaciones que usan una combinación de IaaS y servicios administrados.

Web-Cola-Trabajo

Para una solución puramente PaaS, considere la posibilidad de usar una arquitectura Web-Cola-Trabajo . En este estilo, la aplicación tiene un front-end web que controla las solicitudes HTTP y un trabajo de back-end que realiza tareas de uso intensivo de la CPU u operaciones de larga duración. El front-end se comunica con el trabajo a través de una cola de mensajes asincrónicos.

La arquitectura Web-Cola-Trabajo es adecuada para dominios relativamente sencillos 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 que sea difícil administrar las dependencias. El front-end y el trabajo se pueden convertir fácilmente en componentes grandes y monolíticos que son difíciles de mantener y actualizar. Al igual que sucede con la de 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 sola función empresarial. Los servicios están acoplados de forma flexible y se comunican a través de contratos de API.

Un pequeño equipo de desarrollo con dedicación puede compilar cada servicio. Los servicios individuales se pueden implementar sin necesidad de mucha coordinación entre los equipos, lo cual fomenta unas 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 un desarrollo perfeccionado y una cultura de DevOps. Pero si se hace correctamente, este estilo puede dar lugar una velocidad de lanzamiento mayor, una innovación más rápida y una arquitectura más resistente.

Arquitectura basada en eventos

Las arquitecturas basadas en eventos usan un modelo de publicación-suscripción (pub-sub), en el que los productores publican eventos y los consumidores de suscriben a ellos. Los productores son independientes de los consumidores y estos, a su vez, son independientes entre sí.

Considere la posibilidad de implementar una arquitectura basada en eventos para las aplicaciones que ingieren y procesan un gran volumen de datos con una latencia muy baja como en el caso de las soluciones de IoT. Este estilo también es útil cuando diferentes subsistemas deben realizar distintos tipos de procesamiento en los mismos datos de evento.

Big Data, Big Compute

Big Data y Big Compute son los estilos de arquitectura especializados en cargas de trabajo que resultan más adecuados para determinados perfiles específicos. Big Data permite dividir un conjunto de datos muy grande en fragmentos, realizando un procesamiento paralelo en todo el conjunto, con fines de análisis y creación de informes. Big compute, también denominada informática de alto rendimiento (HPC), realiza cálculos en paralelo en un gran número (miles) de núcleos. Los dominios incluyen simulaciones, modelado y representaciones 3-D.

Estilos de arquitectura como restricciones

Un estilo de arquitectura puede crear restricciones en el diseño, incluido en el conjunto de elementos que pueden aparecer, y en las relaciones permitidas entre los elementos. Las restricciones contribuyen a dar "forma" a una arquitectura restringiendo el universo de opciones. Cuando una arquitectura cumple con las restricciones de un estilo determinado, surgen determinadas propiedades deseables.

Por ejemplo, entre las restricciones de los microservicios se incluyen:

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

Mediante la adhesión a estas restricciones, lo que surge es un sistema en el que los servicios se pueden implementar independientemente, los errores se aíslan, las actualizaciones frecuentes son posibles y resulta fácil introducir nuevas tecnologías en la aplicación.

Antes de elegir un estilo de arquitectura, asegúrese de que comprende los principios subyacentes y las restricciones de ese estilo. En caso contrario, puede acabar con un diseño que se adapta al estilo en un nivel superficial pero que no utiliza todas las posibilidades de ese estilo. También es importante ser práctico. A veces es mejor ser menos exigentes con una restricción en lugar de incidir en la pureza de una arquitectura.

En la tabla siguiente se resume cómo administra las dependencias cada estilo y qué tipos de dominios son los 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 de uso intensivo de recursos.
Microservicios	Servicios descompuestos verticalmente (funcionalmente) que se llaman mutuamente mediante API.	Dominio complicado. Actualizaciones frecuentes.
Arquitectura controlada por eventos	Productores y consumidores. Vista independiente por cada subsistema.	IoT y sistemas en tiempo real.
Macrodatos	Divide un conjunto de datos grande en fragmentos pequeños. Procesamiento en paralelo en los conjuntos de datos locales.	Análisis de datos por lotes y en tiempo real. Análisis predictivo mediante Machine Learning.
Big Compute	Asignación de datos a miles de núcleos.	Dominios con procesos intensivos como simulaciones.

Análisis de desafíos y ventajas

Las restricciones también pueden conllevar desafíos, por lo que es importante comprender las ventajas y desventajas de adoptar cualquiera de estos estilos. ¿Son superiores las ventajas del estilo de arquitectura a los posibles desafíos para este subdominio y el contexto enlazado? .

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

• Complejidad. ¿Está justificada la complejidad de la arquitectura para el dominio? O, por el contrario, ¿es demasiado simple? En ese caso, se arriesga a terminar con un sistema "sin arquitectura alguna observable", ya que esta no le ayuda a administrar las dependencias correctamente.

• Mensajería asincrónica y coherencia final. La mensajería asincrónica puede usarse para desacoplar servicios y aumentar la confiabilidad (porque se pueden recuperar los mensajes) y la escalabilidad. Sin embargo, esto también crea desafíos en el control de la coherencia final, así como la posibilidad de que se produzcan mensajes duplicados.

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

• Manejabilidad. ¿Es difícil administrar la aplicación y supervisar e 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 para 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