Consideraciones para las arquitecturas de n niveles

Completado

Se han analizado los aspectos que conforman una arquitectura de n niveles y se ha implementado un ejemplo de una arquitectura de tres niveles. Veamos algunas de las ventajas y desafíos de este estilo arquitectónico, y los procedimientos recomendados para optimizarlo para el rendimiento y la seguridad.

Ventajas

Este estilo de arquitectura es beneficioso debido a su simplicidad. Es un patrón de arquitectura bien definido y de uso frecuente, tanto para implementaciones locales como en la nube, y puede funcionar con una amplia gama de aplicaciones.

Es una arquitectura independiente de la plataforma y se ajusta a las aplicaciones implementadas en Windows o Linux. Como se ha mostrado en el entorno de ejemplo, se pueden usar servicios PaaS o IaaS en cualquier nivel.

Al dividir la aplicación en niveles, cada nivel se puede escalar o actualizar de forma independiente. Si aumentan las solicitudes del sitio web, se pueden agregar más servidores web a la carga sin afectar a los otros niveles. De forma similar, si aumentan las solicitudes en el nivel de datos, se puede escalar la base de datos para tener más capacidad para controlar las solicitudes.

La separación de la red es un subproducto natural de esta arquitectura. Como la aplicación se separa en niveles, se debe aislar cada uno de ellos y permitir solamente el acceso de red necesario. El nivel de presentación se puede exponer a Internet, la base de datos se puede proteger de forma completa detrás de varios niveles de red y las funciones de la aplicación también. Al proteger el acceso de red entre los niveles, se reduce la superficie de ataque de la aplicación y aumenta su seguridad.

Desafíos y consideraciones

Cuando separe la aplicación en varios niveles, evite los niveles intermedios que solo realizan operaciones de base de datos. Cada nivel debe agregar valor específico. Los niveles adicionales agregan complejidad, tiempo de procesamiento, latencia y, en última instancia, retrasos para el usuario.

Como las API de cada dominio de nivel de aplicación no se separan en servicios individuales, se deben escalar de forma conjunta. Si un único método de aplicación necesita más capacidad de procesamiento o controlar más solicitudes que otros, el nivel de aplicación se debe escalar horizontalmente como un todo para controlar la carga, en lugar de un servicio individual.

En algunos casos, puede desarrollar una aplicación como una arquitectura de n niveles, pero seguir realizando las implementaciones de forma monolítica. Al separar completamente cada nivel, se deben implementar por separado. La separación total implica la eliminación de las dependencias compartidas, y una mayor dependencia de las llamadas de API entre los niveles. Cuando se realiza correctamente, garantiza la flexibilidad de las implementaciones de aplicaciones.

Las aplicaciones en una arquitectura de n niveles se suelen implementar en máquinas virtuales. Este es un buen primer paso, pero la evolución de la aplicación para usar servicios de PaaS ofrece numerosas ventajas de seguridad, escalabilidad y administración. Esta evolución a menudo se pasa por alto y las arquitecturas de n niveles permanecen residentes en las máquinas virtuales.

El nivel de n niveles es un estilo arquitectónico clásico, pero en muchos escenarios se ha sustituido por otros patrones de diseño modernos, como una arquitectura de microservicios. En muchos casos vale la pena invertir tiempo en evaluar otras arquitecturas para ver si son una mejor elección para la aplicación.

Procedimientos recomendados para las arquitecturas de n niveles

Hay varias cosas que debe hacer para asegurarse de que la arquitectura de n niveles se ejecuta de forma óptima. En el diagrama siguiente se muestra de forma visual cómo se pueden realizar mejoras en una arquitectura de n niveles.

Visualization of N-tier architecture.

Optimización del rendimiento

Veamos las formas de optimizar una arquitectura de n niveles para el rendimiento y la seguridad.

Escalado automático

Con la aplicación separada en niveles, se pueden usar características de la nube como el escalado automático para adaptarse a la carga del sistema. Cuando aumenten los usuarios o las solicitudes, use el escalado automático en varios niveles para agregar más recursos que controlen las solicitudes. A medida que las solicitudes disminuyen, el escalado automático reduce los recursos de proceso, además de reducir la factura. El escalado automático facilita garantizar que los usuarios tengan la mejor experiencia y que los costos se mantengan bajos. Los conjuntos de escalado de máquinas virtuales de Azure se pueden usar para las cargas de trabajo basadas en máquinas virtuales, y muchos servicios PaaS como Azure App Service tienen funcionalidades de escalado automático integradas.

Equilibrio de carga

A medida que la aplicación se escala horizontalmente con el escalado automático, el uso del equilibrio de carga se convierte en una parte necesaria de la arquitectura. Con el equilibrio de carga, a medida que se agreguen más recursos de proceso al nivel, se agregan a la distribución del equilibrador de carga para aprovechar la potencia de procesamiento adicional. Por el contrario, cuando se produce un error en un sistema, se quita de la carga para minimizar el impacto en el usuario debido a un rendimiento deficiente o solicitudes erróneas. Esto garantiza que las solicitudes de usuario vayan a sistemas en buen estado. Azure Load Balancer es una característica integrada de las funcionalidades de red y Application Gateway proporciona una solución de equilibrio de carga HTTP con más características.

Mensajería

El uso de un servicio de mensajería entre los niveles aporta un efecto positivo en el rendimiento, especialmente en las solicitudes que son de naturaleza asíncrona. El servicio coloca un mensaje en una cola, donde permanecerá hasta que se procese, lo que compensa el impacto de la carga de nivel inferior. Si se produce una interrupción del sistema, un servicio de mensajería garantiza que el mensaje todavía se controle. El mensaje permanece en la cola y se procesa después de que el sistema vuelva a estar en línea. Azure tiene varias soluciones de mensajería para elegir, en función de sus requisitos. Azure Service Bus, las colas de Azure Storage y Azure Event Hubs son algunas soluciones que deben tenerse en cuenta cuando se busca un servicio de mensajería.

Almacenamiento de datos en caché

Use una caché para los datos a los que se accede habitualmente y que tienen una frecuencia de cambio baja, o bien para los datos que no requieran persistencia a largo plazo, por ejemplo, el estado de sesión. Los sistemas de almacenamiento en caché se sitúan entre los niveles y reducen los tiempos de recuperación para estos tipos de datos. Azure Cache for Redis es un servicio PaaS adecuado para este escenario.

Optimización de la seguridad

La optimización de la aplicación para la seguridad suele ser un trabajo que no "termina" nunca. Aunque la aplicación se separa en niveles, la arquitectura debe seguir incluyendo procedimientos de seguridad bien planeados. Cuantos más niveles se agregan, más elementos hay que proteger y más complejidad se agrega al sistema. Hay varias cosas que debe hacer para asegurarse de que la arquitectura proporciona un entorno seguro para ejecutar la aplicación.

Aislamiento de la red

Al ejecutar una arquitectura de n niveles en máquinas virtuales, asegúrese de que cada nivel esté en su propia subred. Esta subred actúa como un límite de seguridad y le permite aislar la conectividad mediante listas de control de acceso de red. La subred también facilita la administración al garantizar que los nuevos sistemas de la subred reciban las mismas reglas. En Azure, esto se hace de forma nativa con los grupos de seguridad de red (NSG). Se deben realizar consideraciones similares para los servicios PaaS, pero las funciones de integración de red varían entre los servicios y se deben evaluar por sí solas. Un procedimiento recomendado consiste en asegurarse de que cada nivel solo se puede comunicar con el siguiente situado debajo de él. El nivel de presentación solo debería poder comunicarse con el nivel de aplicación, y el nivel de aplicación solo con el nivel de datos. Minimizar esta conectividad proporciona un enfoque por capas de la seguridad de red y mejora la posición de seguridad general de una arquitectura.

Firewall de aplicaciones web

Tras implementar el aislamiento de seguridad entre las subredes, le interesará asegurarse de que el front-end expuesto públicamente sea seguro y solo permita el acceso a lo que sea necesario. Solo debe exponer el nivel de presentación al tráfico entrante de Internet. La tecnología de firewall de aplicaciones web (WAF) delante del nivel de presentación mejora la seguridad en este nivel. Los WAF inspeccionan el tráfico en busca de actividades malintencionadas, se aseguran de que las comunicaciones se cifren y le alertan si algo no es normal. En Azure, Application Gateway es un equilibrador de carga HTTP con un firewall de aplicaciones web integrado que puede habilitar.

Comprobación de conocimientos

1.

¿Cuál de las siguientes puede ser una manera de mejorar el rendimiento de una aplicación en una arquitectura de n niveles, mientras se mantienen los costes optimizados?

2.

¿Cuál de las siguientes acciones mejoraría la seguridad de una aplicación?