Diseñar una aplicación en la nube exige entender dos conceptos que definen su resiliencia: alta disponibilidad y tolerancia a fallos. Si trabajas con arquitecturas cloud y quieres que tu aplicación siga operando aunque falle un componente, esta guía te muestra cómo aplicarlos con un caso real: Platzi Wallet.

¿Qué es la alta disponibilidad en arquitecturas cloud?

La alta disponibilidad es la forma en la que despliegas tu aplicación para que siga funcionando aunque uno de sus componentes falle. Si despliegas Platzi Wallet en una sola zona de disponibilidad y esa zona cae, tu aplicación deja de operar y dejas de ser altamente disponible.

De ahí sale la primera regla práctica que vale la pena tatuarse: toda aplicación en la nube debe ejecutarse en al menos dos zonas de disponibilidad. Así, si una se cae, la otra sigue atendiendo el tráfico.

¿Qué es alta disponibilidad? Es la capacidad de una aplicación de seguir operativa cuando uno de sus componentes falla, gracias a desplegarla en al menos dos zonas de disponibilidad.

¿Cómo funciona la alta disponibilidad con Platzi Wallet?

Imagina que un usuario hace un pago. El request llega al balanceador de aplicaciones, que busca el microservicio de pagos desplegado en la zona 1 y la zona 2. Si la zona 2 se cae, el balanceador redirige el request a la zona 1 y el pago se procesa.

La aplicación sigue disponible. Eso es alta disponibilidad en acción [03:45].

¿Qué son el RTO y el RPO y por qué importan?

Para dimensionar bien la alta disponibilidad necesitas dos métricas hermanas que siempre van juntas: RTO y RPO. Una habla de tiempo, la otra habla de datos.

¿Qué es el RTO o recovery time objective?

El RTO (Recovery Time Objective) es el tiempo máximo que tu aplicación puede estar caída sin afectar la continuidad del negocio. Si decides que Platzi Wallet puede tardar 10 minutos en volver a operar tras un desastre regional, tu RTO es de 10 minutos. En esos 10 minutos automatizas el redespliegue usando infraestructura como código y vuelves a estar operativo [01:30].

Y aquí viene lo interesante: a menor RTO, el costo crece de forma exponencial. ¿Cómo logras un RTO casi cero? Teniendo dos Platzi Wallet corriendo en paralelo en regiones distintas bajo un modelo activo-pasivo, listo para hacer switch de DNS cuando una región caiga.

¿Qué es el RPO o recovery point objective?

El RPO (Recovery Point Objective) es el volumen de datos que estás dispuesto a perder antes de volver a estar operativo. No mide tiempo de caída, mide pérdida de información.

¿Cuál es la diferencia entre RTO y RPO? El RTO mide cuánto tiempo puedes estar caído. El RPO mide cuántos datos puedes perder. Uno es tiempo, el otro es punto de recuperación.

Un ejemplo claro: si haces backup de la base de datos de Platzi Wallet todos los días a las 8:00 a.m. y la base se rompe a las 7:59 a.m., perdiste casi 24 horas de registros. Tu RPO es de 24 horas. Si haces backup cada dos horas, en el peor caso pierdes dos horas de datos [02:50].

Cuando preguntas a un cliente cuál quiere que sea su RPO, casi siempre responde "cero". Lograrlo es posible con replicación activo-activo a nivel de base de datos, pero la complejidad técnica y el costo son altos.

¿Qué es la tolerancia a fallos y en qué se diferencia de la alta disponibilidad?

La tolerancia a fallos es la capacidad de soportar fallas en los sistemas y mantener la disponibilidad sin caída ni degradación del servicio. Es un concepto más grande que la alta disponibilidad y la contiene [04:20].

Aquí entran los SLA (Service Level Agreement), los acuerdos de nivel de servicio. Si le prometes a tu usuario que la aplicación estará inactiva como máximo una hora al mes, ese compromiso es tu SLA.

¿Cuándo una aplicación es tolerante a fallos y no solo altamente disponible?

Volvamos al ejemplo. Platzi Wallet tiene dos microservicios de pagos por zona. Si la zona 2 cae, sigues operando con dos microservicios en la zona 1, pero pasaste de cuatro a dos atendiendo el tráfico. La aplicación está disponible, pero hay degradación del servicio mientras escala.

Para ser tolerante a fallos deberías tener al menos cuatro microservicios por zona, de modo que ante una caída no haya degradación perceptible.

¿Una app tolerante a fallos es siempre altamente disponible? Sí. Si es tolerante a fallos, implícitamente es altamente disponible. Pero al revés no aplica: puedes ser altamente disponible sin ser tolerante a fallos.

¿Cómo aplicar estos conceptos en una estrategia de disaster recovery?

Definir RTO y RPO no es un ejercicio teórico. Es la base de tu estrategia de disaster recovery: si pasa algo, en cuánto tiempo vuelves a estar operativo y cuánta información pierdes.

Algunas ideas para guiar tus decisiones:

• Si tu RTO es de un segundo, necesitas una arquitectura activo-activo con replicación en tiempo real.
• Si tu RTO es de ocho horas, basta con backups periódicos y restaurarlos cuando ocurra el incidente.
• Define RTO y RPO por cada aplicación según su criticidad para el negocio.
• Prueba las estrategias antes de necesitarlas, no después.

Ahora te toca a ti: piensa en una aplicación que estés diseñando, define su RTO y RPO, y ajusta la arquitectura según esos números. ¿Qué estrategia de disaster recovery elegirías y por qué? Cuéntame en los comentarios.