En este artículo se muestra cómo planear una implementación del 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, Contoso Fiber, quería ampliar su aplicación web local del sistema de gestión de cuentas de clientes (CAMS) para llegar a otras regiones. Para hacer frente al aumento de la demanda de la aplicación web, establecieron los siguientes objetivos:
- 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
Contoso Fiber determinó que su infraestructura local no era una solución rentable para escalar la aplicación. Así que decidieron que migrar su aplicación web CAMS 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 del traslado a la nube, la aplicación web CAMS de Contoso Fiber era una aplicación web de Java monolítica local. Es una aplicación Spring Boot con una base de datos PostgreSQL. La aplicación web es una aplicación de soporte técnico a la línea de negocio. Está orientada a los empleados. Los empleados de Contoso Fiber utilizan la aplicación para gestionar los casos de asistencia de sus clientes. La aplicación web local afronta los retos habituales. Estos retos incluyen escalas de tiempo amplias para compilar y enviar nuevas características y dificultad en el escalado de distintos componentes de la aplicación bajo una carga mayor.
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: Contoso Fiber eligió Azure App Service como plataforma de aplicaciones por los siguientes motivos:
Progresión natural. Contoso Fiber implementó un archivo Spring Boot
jaren su servidor local y quería minimizar la cantidad de rearquitectura para ese modelo de implementación. App Service proporciona una sólida compatibilidad con la ejecución de aplicaciones de Spring Boot y era una progresión natural para que Contoso Fiber usara App Service. Azure Spring Apps también es una alternativa atractiva para esta aplicación. Si la aplicación web Contoso Fiber CAMS usaba Jakarta EE en lugar de Spring Boot, Azure Spring Apps sería una mejor opción. Para obtener más información, consulte ¿Qué es Azure Spring Apps? y Java EE, Jakarta EE y MicroProfile en Azure.SLA elevado Tiene un Acuerdo de Nivel de Servicio elevado que cumple los requisitos del entorno de producción.
Menor sobrecarga de administración. Es una solución de hospedaje totalmente administrada.
Capacidad de contenedorización. App Service funciona con registros de imágenes de contenedor privados, como Azure Container Registry. Contoso Fiber puede utilizar estos registros para contenerizar la aplicación web en el futuro.
Escalabilidad automática. La aplicación web puede rápidamente escalarse y reducirse verticalmente, así como escalarse y reducirse horizontalmente, 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: Contoso Fiber eligió Microsoft Entra ID por los siguientes motivos:
Autenticación y autorización. Controla la autenticación y autorización de los empleados.
Escalabilidad. Se escala para admitir escenarios más grandes.
Control de identidad de usuario. Los empleados pueden usar sus identidades empresariales existentes.
Admite protocolos de autorización. Admite OAuth 2.0 para las 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: Contoso Fiber eligió Azure Database for PostgreSQL y la opción servidor flexible por los siguientes motivos:
Reliability. El modelo de implementación de servidor flexible admite alta disponibilidad con redundancia de zona en varias zonas de disponibilidad. Esta configuración mantiene un servidor en espera semiactiva en una zona de disponibilidad diferente dentro de la misma región de Azure. La configuración replica los datos de forma sincrónica en el servidor en espera.
Replicación entre regiones. Tiene una característica de réplica de lectura que permite replicar datos de forma asincrónica a una base de datos de réplica de solo lectura en otra región.
Rendimiento. Proporciona un rendimiento predecible y una optimización inteligente para mejorar el rendimiento de la base de datos mediante datos de uso reales.
Menor sobrecarga de administración. Es un servicio de Azure totalmente administrado que reduce las obligaciones de administración.
Compatibilidad con la migración. Admite la migración de bases de datos desde bases de datos PostgreSQL locales de servidor único. Pueden usar la herramienta de migración para simplificar el proceso de migración.
Coherencia con configuraciones locales. Es compatible con diferentes versiones de la comunidad de PostgreSQL, incluida la versión que usa actualmente Contoso Fiber.
Resistencia. La implementación del servidor flexible crea automáticamente copias de seguridad del servidor y las almacena en el almacenamiento con redundancia de zona (ZRS) dentro de la misma región. Se puede restaurar su base de datos a cualquier momento dado dentro de su período de retención de copia de seguridad. La capacidad de copia de seguridad y restauración crea un RPO (cantidad aceptable de pérdida de datos) mejor que el que Contoso Fiber podría crear en el entorno local.
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: Contoso Fiber agregó Application Insights por los siguientes motivos:
Detección de anomalías. Se detectan automáticamente las anomalías de rendimiento.
Solución de problemas. Ayuda a diagnosticar problemas de la aplicación en ejecución.
Telemetría. Recopila información sobre cómo los usuarios usan la aplicación y le permite enviar fácilmente eventos personalizados de los que quiera realizar un seguimiento en la aplicación.
Brecha de visibilidad local. 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: Contoso Fiber necesitaba una memoria caché que ofreciera las siguientes ventajas:
Velocidad y volumen. Tiene un alto rendimiento de datos 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 externo. 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 memoria caché permite que la aplicación web externalice el estado de la sesión mediante sesiones no permanentes. La mayoría de las aplicaciones web de Java que se ejecutan de forma local usan el almacenamiento en caché del lado cliente en la memoria. El almacenamiento en caché del lado cliente en la memoria no se escala bien y aumenta la superficie de memoria en el host. Mediante el uso de Azure Cache for Redis, Contoso Fiber tiene un servicio de caché escalable y totalmente administrado para mejorar la escalabilidad y el rendimiento de sus aplicaciones. Contoso Fiber usaba un marco de abstracción de caché (Spring Cache) y solo necesitaba cambios mínimos de configuración para cambiar el proveedor de caché. Les permitió cambiar de un proveedor de Ehcache al proveedor de Redis.
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: Contoso Fiber eligió Front Door como equilibrador de carga global por los siguientes motivos:
Flexibilidad de facturación. 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 nivel 3-4 integrada.
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: Contoso Fiber eligió Web Application Firewall por las siguientes ventajas:
Protección global. Proporciona una mejor protección global de aplicaciones web sin sacrificar el rendimiento.
Protección frente a redes de bots. Puede configurar reglas de protección contra bots para supervisar los ataques de red de robots (botnet).
Paridad con el entorno local. La solución en el entorno local se ejecutaba detrás del firewall de aplicaciones web administrado por TI.
Administrador de secretos
Use Azure Key Vault si debe administrar secretos en Azure.
Ejemplo: Contoso Fiber tiene secretos que se deben administrar. Usaron Key Vault por los siguientes motivos:
Cifrado. Admite cifrado de datos en reposo y en tránsito
Compatibilidad con identidades administradas. 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. Admite dos métodos para que la aplicación web acceda a los secretos. Contoso Fiber puede usar la configuración de la aplicación en la plataforma de hospedaje (App Service) o puede hacer referencia al secreto en el código de la aplicación (archivo de propiedades de la aplicación).
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: Contoso Fiber eligió Private Link por los siguientes motivos:
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 proteger 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 la configuración local existente, por lo que se requieren cambios mínimos.
Elección de la arquitectura adecuada
Después de definir los medios disponibles para la aplicación web y seleccionar los servicios en la nube adecuados, debe determinar la mejor arquitectura para la aplicación web. Su arquitectura debe cumplir sus requisitos empresariales, técnicos y de nivel de servicio.
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: La implementación de referencia usa dos regiones en una configuración activa-pasiva. Contoso Fiber tenía un SLO del 99,9 % y necesitaba usar dos regiones para cumplir el SLO. La configuración activa-pasiva se alinea con el objetivo de Contoso Fiber de cambios mínimos en el código para esta fase del recorrido en la nube. La configuración activa-pasiva proporciona una estrategia de datos sencilla. Evita tener que configurar la sincronización de datos basada en eventos, las particiones de datos o alguna otra estrategia de administración de datos. Todo el tráfico entrante se dirige a la región activa. Si se produce un error en la región activa, Contoso Fiber inicia manualmente su plan de conmutación por error y enruta todo el tráfico a la región pasiva.
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: Contoso Fiber 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.
Ejemplo: Para Azure Database for PostgreSQL, la implementación de referencia usa alta disponibilidad con redundancia de zona con servidores en espera en dos zonas de disponibilidad. La base de datos también se replica de forma asincrónica en la réplica de lectura en la región pasiva. Contoso Fiber creó un plan de conmutación por error de ejemplo. La réplica de lectura de Azure Database for PostgreSQL es fundamental para el plan de conmutación por error de Contoso Fiber.
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.