Diseño de aplicaciones de Azure confiables

La compilación de una aplicación confiable en la nube es diferente al desarrollo de aplicaciones tradicionales. Aunque históricamente puede que haya adquirido niveles de hardware redundante de gama alta para reducir al mínimo la probabilidad de que se produzca un error en toda la plataforma de aplicaciones, en la nube reconocemos por adelantado que se producirán errores. En lugar de intentar evitar todos los errores, el objetivo es minimizar los efectos que pueden provocar los errores de un único componente. Los errores que cabe esperar aquí son inherentes a los sistemas altamente distribuidos, no a una característica de Azure.

Puntos clave

• Use zonas de disponibilidad donde corresponda para mejorar la confiabilidad y optimizar los costos.
• Diseñe aplicaciones para que funcionen en caso de error.
• Use las funcionalidades de resistencia nativas de PaaS para mejorar la confiabilidad general de la aplicación.
• Diseñe de un modo orientado al escalado horizontal.
• Valide que la capacidad necesaria se encuentra dentro de las cuotas y los límites de escalado del servicio de Azure.

Uso de zonas de disponibilidad en una región

Si sus requisitos exigen un aislamiento de errores superior al que pueden ofrecer las zonas de disponibilidad por sí mismas, considere la posibilidad de implementar en varias regiones. Se deben usar varias regiones con fines de conmutación por error en un estado de desastre. Se deben tener en cuenta los costos adicionales. Algunos ejemplos de necesidades de costos son los datos y las redes, y algunos servicios como Azure Site Recovery.

Diseñe la arquitectura de la aplicación para que use zonas de disponibilidad en una región. Las zonas de disponibilidad se pueden usar para optimizar la disponibilidad de la aplicación dentro de una región, ya que proporcionan tolerancia a errores en el nivel del centro de datos. Sin embargo, la arquitectura de la aplicación no debe compartir dependencias entre las zonas para usarlas de forma eficaz.

Considere si se requiere la proximidad de componentes por motivos de rendimiento de la aplicación. Si toda la aplicación o parte de esta es extremadamente sensible a la latencia, puede exigir la colocalización del componente, lo que puede limitar la aplicabilidad de las estrategias para varias regiones o zonas.

Respuesta a errores

Es imposible evitar errores en la nube pública y, como resultado, las aplicaciones requieren resistencia para responder a interrupciones y ofrecer confiabilidad. Por lo tanto, la aplicación debe diseñarse para que funcione incluso cuando se vea afectada por errores de componentes, servicio, zonas o regiones en escenarios críticos tanto para esta como para su funcionalidad. Las operaciones de las aplicaciones pueden experimentar una funcionalidad reducida o un rendimiento degradado durante una interrupción.

Defina una estrategia de disponibilidad para capturar el modo en que la aplicación sigue estando disponible cuando se produce un error. Debe aplicarse a todos los componentes de la aplicación y al stamp de implementación de la aplicación como conjunto, por ejemplo, mediante el enfoque de implementación de unidades de escalado de varias zonas geográficas. También hay implicaciones en el costo: se deben aprovisionar más recursos de antemano para proporcionar alta disponibilidad. La configuración activa-activa, aunque es más costosa que la implementación única, puede equilibrar el costo reduciendo la carga de un stamp y la cantidad total de recursos necesarios.

Además de una estrategia de disponibilidad, defina una estrategia de recuperación ante desastres de continuidad del negocio (BCDR) para la aplicación o sus escenarios clave. Una estrategia de recuperación ante desastres debe capturar el modo en que la aplicación responde ante una situación de desastre, como una interrupción regional o la pérdida de un servicio de plataforma crítico, mediante un enfoque de reimplementación, de reserva semiactiva (activa-pasiva) o de reserva activa (activa-activa).

Para reducir los costos, considere la posibilidad de dividir los componentes de la aplicación y los datos en grupos. Por ejemplo:

• Se deben proteger.
• Es recomendable protegerlos.
• Efímeros/se pueden volver a generar o perder, en lugar de proteger todos los datos con la misma directiva.

Consideraciones para mejorar la confiabilidad

¿La aplicación está diseñada para usar servicios administrados?

Los servicios administrados de Azure proporcionan funcionalidades de resistencia nativas para mejorar la confiabilidad general de la aplicación. Se deben usar ofertas de plataforma como servicio (PaaS) para aprovechar estas funcionalidades. Las opciones de PaaS son más fáciles de configurar y administrar. No es necesario aprovisionar máquinas virtuales, configurar redes virtuales, administrar revisiones y actualizaciones, y toda la sobrecarga asociada a la ejecución de software en una máquina virtual. Para obtener más información, consulte Uso de servicios administrados.

¿La aplicación se ha diseñado para el escalado horizontal?

Azure proporciona escalabilidad elástica y el diseño debería orientarse al escalado horizontal. Sin embargo, las aplicaciones deben aprovechar un enfoque de unidad de escalado para navegar por los límites de servicio y suscripción con el fin de garantizar que los componentes individuales y la aplicación como un todo puedan escalarse horizontalmente. No olvide la reducción vertical, que es importante para reducir costos. Por ejemplo, el escalado horizontal y la reducción vertical, para App Service, se realiza mediante reglas. A menudo, los clientes escriben reglas de escalado horizontal y no de reducción horizontal. Esto hace que App Service resulte más caro.

¿La aplicación se implementa en varias suscripciones de Azure?

Comprender el panorama de la suscripción de la aplicación y cómo se organizan los componentes dentro de las suscripciones o entre ellas es importante a la hora de analizar si se puede navegar por los límites o cuotas de suscripción pertinentes. Revise los límites de suscripción y servicio de Azure para validar que la capacidad necesaria se encuentra dentro de los límites y las cuotas de escalado de servicio de Azure. Para obtener más información, consulte Límites de suscripción y servicios de Azure.

Paso siguiente

Vínculos relacionados

• Para obtener información sobre cómo minimizar las dependencias, consulte Minimizar la coordinación.
• Para obtener más información sobre los puntos de error y los modos de error, consulte Análisis del modo de error para aplicaciones de Azure.
• Para obtener información sobre los servicios administrados, vea Uso de las opciones de plataforma como servicio (PaaS).

Volver al artículo principal: Diseño