Antes de ubicar cualquier aplicación en la nube (o en cualquier otro centro de datos) es importante conocer la criticidad de la aplicación y, en función de ésta, qué consecuencias estamos dispuestos a asumir en caso de que haya un problema.
Fundamentalmente hay dos parámetros que debemos considerar: el RTO y el RPO. Que son el tiempo máximo de indisponibilidad que se está dispuesto a asumir (Restauration Time Objective) y el tiempo máximo de datos que se pueden perder (Restauration Point Objective). En función de estos dos parámetros vamos a construir nuestras aplicaciones con unas arquitecturas más o menos resilientes y/o redundadas y/o respaldadas.
Hay que entender cómo está distribuido Azure y cómo podemos implementar nuestras aplicaciones. Azure tiene Centros de Datos en distintas regiones. En la misma región Azure está separando físicamente los recursos disponibles en distintas Zonas de Disponibilidad o Availability Zones.
Como siempre hay que evaluar el riesgo/beneficio. Podemos construir aplicaciones que estén distribuidas por varias zonas de disponibilidad y regiones, que soporten la indisponibilidad de toda una región de Azure, pero evidentemente su coste y complejidad serán mayores que aplicaciones desplegadas únicamente en una región.
Hay que evaluar exactamente qué queremos. De cara a tener una aplicación tolerante a fallos, podemos implementar una aplicación que preste servicio desde varias regiones en modo activo-activo, ésta soportará el fallo de una región sin pérdida de servicio, pero podría producirse un problema de corrupción de datos, o de indisponibilidad de los sistemas de autenticación, para el que esta medida es inútil.
Hay que evaluar todas las piezas que conforman el servicio y sus dependencias, así como las eventualidades contra las que queremos estar protegidos:
- el fallo de una máquina virtual?
- de una Zona de disponibilidad?
- de una región entera?
Para hacer nuestras aplicaciones resilientes podemos utilizar principalmente balanceadores y clústeres que nos permitan abstraer de elementos únicos de fallo la prestación de servicio.
De cara a disponer de una contingencia que garantice la continuidad de negocio tenemos que pensar en tener los datos necesarios para restaurar el servicio respaldados, preferiblemente en una ubicación lo menos susceptible de fallar a la vez que la principal. Así mismo tenemos que considerar el tiempo que se tardaría en disponer del servicio operativo de nuevo:
- habría que realizar acciones manuales?
- quiénes tendrían que participar?
- cuál es el procedimiento?
- cuánto se tardaría?
Azure dispone se servicios que pueden gestionar y automatizar todas estas tareas. Azure backup y Azure Site Recovery nos permiten gestionar las copias de seguridad e incluso la replicación de datos y las conmutaciones de servicio en caso de fallo
