En este artículo se muestra cómo aplicar el patrón Reliable Web App. El patrón Reliable Web App es un conjunto de principios y técnicas de implementación que definen cómo se deben modificar las aplicaciones web (plataforma) al migrar a la nube. Se centra en las actualizaciones mínimas de código que hay que hacer para tener éxito en la nube.
Para facilitar la aplicación de esta guía, hay una implementación de referencia del patrón Reliable Web App que puede implementar.
Arquitectura de la implementación de referencia. Descargue un archivo de Visio de esta arquitectura.
En las siguientes instrucciones se usa la implementación de referencia como ejemplo. Para planear una implementación del patrón Reliable Web App, siga estos pasos:
Definir los objetivos empresariales
El paso inicial en la transición a la computación en nube es articular sus objetivos empresariales. El patrón Reliable Web App hace hincapié en la importancia de establecer objetivos tanto inmediatos como futuros para su aplicación web. Estos objetivos influyen en la elección de servicios en la nube y en la arquitectura de la aplicación web en la nube.
Ejemplo: La empresa ficticia Relecloud vende entradas a través de su aplicación web local. Relecloud tiene una previsión de ventas positiva y prevé un aumento de la demanda en su aplicación web de venta de entradas. Para satisfacer esta demanda, definieron los objetivos de la aplicación web:
- Aplicar cambios de bajo costo y alto valor
- Alcanzar un objetivo de nivel de servicio (SLO) del 99,9 %
- Adoptar las prácticas de DevOps
- Crear entornos con costes optimizados
- Mejorar la confiabilidad y la seguridad
La infraestructura local de Relecloud no era una solución rentable para alcanzar estos objetivos. Así que decidieron que migrar su aplicación web a Azure era la manera más rentable de alcanzar sus objetivos inmediatos y futuros.
Elección de los servicios administrados correctos
Al trasladar una aplicación web a la nube, debe seleccionar los servicios de Azure que satisfagan sus requisitos empresariales y se ajusten a las funciones actuales de la aplicación web local. La alineación ayuda a minimizar el esfuerzo de cambio de plataforma. Por ejemplo, utilice servicios que le permitan mantener el mismo motor de base de datos y sean compatibles con el middleware y los marcos existentes. Las siguientes secciones proporcionan orientación para seleccionar los servicios Azure adecuados para su aplicación web.
Ejemplo: Antes de trasladarse a la nube, la aplicación web de venta de entradas de Relecloud era una aplicación ASP.NET monolítica y local. Se ejecutaba en dos máquinas virtuales y tenía una base de datos Microsoft SQL Server. La aplicación web sufría los problemas habituales de escalabilidad e implementación de características. Este punto de partida, sus objetivos empresariales y el SLO impulsaron su elección de servicios.
Plataforma de aplicaciones
Elija la mejor plataforma de hospedaje de aplicaciones para su aplicación web. Azure tiene muchas opciones de computación diferentes para satisfacer una amplia gama de requisitos de aplicaciones web. Si necesita ayuda para limitar las opciones, consulte el árbol de decisión de proceso de Azure.
Ejemplo: Relecloud eligió Azure APP Service como plataforma de aplicaciones por los siguientes motivos:
Contrato de nivel de servicio (SLA) elevado: Tiene un SLA elevado que cumple el SLO del entorno de producción del 99,9 %.
Reducción de los gastos generales de gestión: Es una solución totalmente administrada que controla el escalado, las comprobaciones de estado y el equilibrio de carga.
Compatibilidad con .NET: Admite la versión de .NET en la que se escribe la aplicación..
Capacidad de contenedorización: La aplicación web puede converger en la nube sin contenedorizar, pero la plataforma de aplicaciones también admite la contenedorización sin cambiar los servicios de Azure.
Escalabilidad automática: La aplicación web puede escalar verticalmente, reducir y reducir verticalmente automáticamente en función del tráfico y la configuración del usuario.
Administración de identidades
Elija la mejor solución de administración de identidades para la aplicación web. Para obtener más información, consulte Comparar soluciones de administración de identidades y métodos de autenticación.
Ejemplo: Relecloud eligió Microsoft Entra ID por los siguientes motivos:
Autenticación y autorización: La aplicación debe autenticar y autorizar a los empleados del centro de llamadas.
Escalable: Se escala para admitir escenarios más grandes.
Control de identidad de usuario: Los empleados del centro de llamadas pueden usar sus identidades empresariales existentes.
Compatibilidad con el protocolo de autorización: Admite OAuth 2.0 para identidades administradas.
Base de datos
Elija la mejor base de datos para la aplicación web. Si necesita ayuda para limitar las opciones, consulte el árbol de decisión del almacén de datos de Azure.
Ejemplo: La aplicación web usaba SQL Server local y Relecloud quería usar el esquema de base de datos, los procedimientos almacenados y las funciones existentes. Hay varios productos SQL disponibles en Azure, pero Relecloud eligió Azure SQL Database por los siguientes motivos:
Confiabilidad: El nivel de uso general proporciona un acuerdo de nivel de servicio elevado y redundancia multirregión. Puede admitir una carga de usuario elevada.
Reducción de los gastos generales de gestión: Proporciona una instancia administrada de SQL Database.
Compatibilidad con la migración: Admite la migración de bases de datos desde SQL Server local.
Coherencia con configuraciones locales: Admite los procedimientos almacenados, funciones y vistas existentes.
Resistencia: Copias de seguridad automatizadas y restauración a un momento dado.
Experiencia y retrabajo mínimo: La base de datos SQL aprovecha la experiencia interna y su adopción requiere un trabajo mínimo.
Supervisión de rendimiento de aplicaciones
Elija una supervisión del rendimiento de la aplicación para la aplicación web. Application Insights es la solución de administración del rendimiento de aplicaciones (APM) nativa de Azure. Es una característica de la solución de supervisión de Azure, Azure Monitor.
Ejemplo: Relecloud optó por usar Application Insights por los siguientes motivos:
Integración con Azure Monitor: Proporciona la mejor integración con Azure Monitor.
Detección de anomalías: Detecta automáticamente las anomalías de rendimiento.
Solución de problemas: Ayuda a diagnosticar problemas de la aplicación en ejecución.
Supervisión: Recopila información sobre cómo los usuarios usan la aplicación y permite realizar un seguimiento sencillo de los eventos personalizados.
Brecha de visibilidad: La solución local no contaba con una solución de supervisión del rendimiento de las aplicaciones. Application Insights proporciona una integración sencilla con la plataforma y el código de la aplicación.
instancias y claves
Elija si quiere agregar caché a la arquitectura de la aplicación web. Azure Cache for Redis es la solución de caché principal de Azure. Es un almacén de datos en memoria administrado basado en el software Redis.
Ejemplo: La carga de la aplicación web Relecloud está muy sesgada hacia la visualización de conciertos y detalles del lugar. Agregó Azure Cache for Redis por los siguientes motivos:
Reducción de los gastos generales de gestión: Es un servicio totalmente administrado.
Velocidad y volumen: Tiene un rendimiento de datos alto y lecturas de baja latencia para los datos a los que se accede con frecuencia y que cambian poco.
Amplia compatibilidad: Se trata de una ubicación de caché unificada para que todas las instancias de la aplicación web la usen.
Almacén de datos externos: Los servidores de aplicaciones locales realizaron el almacenamiento en caché local de la máquina virtual. Esta configuración no ha descargado datos muy frecuentes y no ha podido invalidar los datos.
Sesiones no permanentes: La externalización del estado de la sesión admite sesiones no permanentes.
Equilibrador de carga
Elija el mejor equilibrador de carga para la aplicación web. Azure tiene varios equilibradores de carga. Si necesita ayuda para limitar las opciones, consulte Elegir el mejor equilibrador de carga para la aplicación web.
Ejemplo: Relecloud necesitaba un equilibrador de carga de capa 7 que pudiera enrutar el tráfico entre varias regiones. Relecloud necesitaba una aplicación web de varias regiones para cumplir el SLO del 99,9 %. Relecloud eligió Azure Front Door por los siguientes motivos:
Equilibrio de carga global: Es un equilibrador de carga de capa 7 que puede enrutar el tráfico a través de varias regiones.
Firewall de aplicaciones web: Se integra de forma nativa con Azure Web Application Firewall.
Flexibilidad de enrutamiento: Permite que el equipo de la aplicación configure las necesidades de entrada para admitir los cambios futuros en la aplicación.
Aceleración de tráfico: Usa cualquier difusión para llegar al punto de presencia de Azure más cercano y encontrar la ruta más rápida a la aplicación web.
Dominios personalizados: Admite nombres de dominio personalizados con validación de dominio flexible.
Sondeos de estado: La aplicación necesita una supervisión inteligente del sondeo de estado. Azure Front Door usa las respuestas del sondeo para determinar el mejor origen para enrutar las solicitudes de los clientes.
Compatibilidad con la supervisión: Análisis de informes integrados con un panel todo en uno que integre los patrones de Front Door y de seguridad. Puede configurar alertas que se integren con Azure Monitor. Permite que la aplicación registre cada solicitud y los sondeos de estado con errores.
Protección contra DDoS: Tiene protección contra DDoS de capa 3-4 integrada.
Red de entrega de contenido: Posiciona a Relecloud para usar una red de entrega de contenidos. La red de entrega de contenido proporciona aceleración del sitio.
Firewall de aplicaciones web
Elija un firewall de aplicaciones web para proteger la aplicación web frente a ataques web. Azure Web Application Firewall (WAF) es el firewall de aplicaciones web de Azure y proporciona protección centralizada frente a vulnerabilidades web comunes.
Ejemplo: Relecloud necesitaba proteger la aplicación web frente a los ataques web. Utilizaron Azure Web Application Firewall por los siguientes motivos:
Protección global: Proporciona una mejor protección global de aplicaciones web sin sacrificar el rendimiento.
Protección frente a redes de bots: El equipo puede supervisar y configurar para abordar los problemas de seguridad de las botnets.
Paridad con el entorno local: La solución local se ejecutaba detrás de un firewall de aplicaciones web administrado por el departamento de TI.
Facilidad de uso: Web Application Firewall se integra con Azure Front Door.
Almacenamiento de la configuración
Elija si desea agregar el almacenamiento de configuración de aplicaciones a su aplicación web. Azure App Configuration es un servicio para la administración central de la configuración de la aplicación y las marcas de características. Revise procedimientos recomendados de App Configuration para decidir si este servicio es una buena opción para la aplicación.
Ejemplo: Relecloud quería reemplazar la configuración basada en archivos por un almacén de configuración central que se integra con la plataforma y el código de la aplicación. Agregaron App Configuration a la arquitectura por los siguientes motivos:
Flexibilidad: Admite marcas de características. Las marcas de características permiten a los usuarios optar por recibir o no en las características de versión preliminar anticipada de un entorno de producción sin volver a implementar la aplicación.
Compatibilidad con la canalización de Git: El origen de verdad para los datos de configuración debe ser un repositorio de Git. Canalización necesaria para actualizar los datos en el almacén de configuración central.
Compatibilidad con identidades administradas: Admite identidades administradas para simplificar y ayudar a proteger la conexión al almacén de configuración.
Administrador de secretos
Use Azure Key Vault si debe administrar secretos en Azure. Puede incorporar Key Vault en aplicaciones .NET mediante el objeto ConfigurationBuilder.
Ejemplo: La aplicación web local de Relecloud almacena secretos locales en archivos de configuración de código, pero externalizar secretos es una práctica de seguridad más recomendable. Aunque las identidades administradas son la solución preferida para conectarse a recursos de Azure, Relecloud tenía secretos de aplicaciones que necesitaban para administrar. Relecloud usó Key Vault por los siguientes motivos:
Cifrado: Admite cifrado de datos en reposo y en tránsito
Identidades: Los servicios de aplicación pueden usar identidades administradas para acceder al almacén de secretos.
Supervisión y registro: Facilita el acceso de auditoría y genera alertas cuando cambian los secretos almacenados.
Integración: Proporciona integración nativa con el almacén de configuración de Azure (App Configuration) y la plataforma de hospedaje web (App Service).
Solución de almacenamiento
Elija la mejor solución de almacenamiento para su aplicación web. Para más información, consulte Revisión de las opciones de almacenamiento.
Ejemplo: En el entorno local, la aplicación web tenía almacenamiento en disco montado en cada servidor web, pero el equipo quería usar una solución de almacenamiento de datos externo. Relecloud eligió Azure Blob Storage por los siguientes motivos:
Acceso seguro: La aplicación web puede eliminar los puntos de conexión para acceder al almacenamiento expuesto a la red pública de Internet con acceso anónimo.
Cifrado: Cifra datos en reposo y en movimiento.
Resistencia: Admite almacenamiento con redundancia de zona (ZRS). El almacenamiento con redundancia de zona replica los datos de Azure Storage de forma sincrónica en tres zonas de disponibilidad de Azure en la región primaria. Cada zona de disponibilidad es una ubicación física individual con alimentación, refrigeración y redes independientes. Esta configuración debería hacer que las imágenes de emisión de billetes sean resistentes a las pérdidas.
Seguridad de los puntos de conexión
Elija habilitar el acceso solo privado a los servicios de Azure. Azure Private Link proporciona acceso a soluciones de plataforma como servicio a través de un punto de conexión privado en la red virtual. El tráfico entre la red virtual y el servicio viaja por la red troncal de Microsoft.
Ejemplo: Relecloud usó Private Link por los siguientes motivos:
Comunicación de seguridad mejorada: Permite que la aplicación acceda de forma privada a los servicios de la plataforma Azure y reduce la superficie de red de los almacenes de datos para ayudar a protegerse frente a la pérdida de datos.
Esfuerzo mínimo: Los puntos de conexión privados admiten la plataforma de aplicaciones web y la plataforma de base de datos que usa la aplicación web. Ambas plataformas reflejan las configuraciones locales existentes para que el cambio sea mínimo.
Seguridad de red
Elija si desea agregar servicios de seguridad de red a sus redes virtuales. Azure Firewall es un firewall de estado que inspecciona el tráfico de red. Azure Bastion permite conectarse a máquinas virtuales de forma segura sin exponer puertos RDP/SSH.
Ejemplo: Relecloud adoptó una topología de red en estrella tipo hub-and-spoke y quiso situar los servicios de seguridad de red compartidos en el concentrador. Azure Firewall mejora la seguridad inspeccionando todo el tráfico saliente desde los radios para aumentar la seguridad de red. Relecloud necesitaba Azure Bastion para realizar implementaciones seguras desde un host de salto en la subred de DevOps.
Elección de la arquitectura adecuada
Después de definir los medios disponibles para la aplicación web y seleccionar los mejores servicios en la nube, debe determinar la mejor arquitectura para la aplicación web. Su arquitectura debe ser compatible con sus requisitos empresariales, técnicos y de SLO.
Elección de la redundancia de arquitectura
Los objetivos empresariales determinan el nivel de infraestructura y redundancia de datos que necesita la aplicación web. El SLO de la aplicación web proporciona una buena línea base para comprender los requisitos de redundancia. Calcule el contrato SLA compuesto, teniendo en cuenta todas las dependencias de la ruta de acceso crítica de disponibilidad. Las dependencias deben incluir servicios de Azure y soluciones que no son de Microsoft.
Asigne una estimación de disponibilidad a cada dependencia. Los contratos de nivel de servicio (SLA) son un buen punto de partida, pero no tienen en cuenta el código, las estrategias de implementación y las decisiones arquitectónicas de conectividad.
Ejemplo: Relecloud identificó los servicios en la ruta crítica de disponibilidad. Usaron los SLA de Azure para las estimaciones de disponibilidad. Según el cálculo del SLA compuesto, Relecloud necesitaba una arquitectura multirregión para cumplir el SLO del 99,9 %.
Elección de una topología de red
Elija la topología de red adecuada para los requisitos web y de red. Una topología de red en estrella tipo hub-and-spoke es una configuración estándar en Azure. Proporciona ventajas de costos, administración y seguridad. También admite opciones de conectividad híbrida con redes locales.
Ejemplo: Relecloud optó por una topología de red en estrella tipo hub-and-spoke para aumentar la seguridad de su implementación en varias regiones a un costo y un gasto general de administración reducidos.
Elección de la redundancia de datos
Garantice la confiabilidad de los datos distribuyéndolos por las regiones y zonas de disponibilidad de Azure; cuanto mayor sea su separación geográfica, mayor será la confiabilidad.
Establezca un objetivo de punto de recuperación (RPO). El RPO define la pérdida de datos máxima tolerable durante una interrupción, guiando la frecuencia con la que es necesario replicar los datos. Por ejemplo, un RPO de una hora significa aceptar hasta una hora de pérdida de datos recientes.
Implemente la replicación de datos. Alinee la replicación de datos con la arquitectura y el RPO. Azure normalmente admite la replicación sincrónica dentro de las zonas de disponibilidad. Use varias zonas para mejorar la confiabilidad fácilmente. Para las aplicaciones web de varias regiones en una configuración activa-pasiva, replique los datos en la región pasiva según el RPO de la aplicación web, lo que garantiza que la frecuencia de replicación supere el RPO. Las configuraciones activas-activas requieren sincronización de datos casi en tiempo real entre regiones, lo que podría requerir ajustes de código.
Cree un plan de conmutación por error. Desarrolle un plan de conmutación por error planeada (recuperación ante desastres) que describa estrategias de respuesta a interrupciones, determinadas por tiempo de inactividad o pérdida de funcionalidad. Especifique los objetivos de tiempo de recuperación (RTO) para el tiempo de inactividad máximo aceptable. Asegúrese de que el proceso de conmutación por error sea más rápido que RTO. Decida los mecanismos de conmutación por error automatizados o manuales para garantizar la coherencia y el control, y detalle el proceso de vuelta a la normalidad. Pruebe el plan de conmutación por error para garantizar la eficacia.
Paso siguiente
En este artículo se muestra cómo planear la implementación del patrón Reliable Web App. El siguiente paso es aplicar las técnicas de implementación del patrón Reliable Web App.