El caso
La app está en São Paulo. El cliente, en Londres.
La tienda de Isaac empezó a vender a Europa. Llegaron los pedidos. La paciencia de los clientes, no.
Este post parte de los conceptos de Fundamentos de la nube. Si la elasticidad y el pago por uso todavía no están claros, empieza por ahí.
Si no conoces el concepto de latencia y quieres profundizar, lee este post: Latencia.
El problema
Un único centro de datos
La aplicación funciona y atiende bien a Brasil. Pero, a medida que la tienda crece, aparecen dos problemas: alta latencia para quien está lejos y un punto único de falla.
Solución parcial
Una segunda zona
Una zona es un centro de datos (o un grupo de ellos) aislado dentro de una región, con energía, refrigeración y red independientes. Con dos zonas en la misma región, si la Zona A falla, la Zona B sigue atendiendo.
Esto resuelve la falla local, pero no todo: las dos zonas siguen en São Paulo. Si toda la región se ve afectada, la aplicación cae, y el cliente de Londres sigue lejos.
La solución
Múltiples regiones
Una región es un área geográfica separada, como São Paulo o Londres. Con una segunda región en Londres, la solución queda completa: baja latencia para Europa y resistencia a fallas de zona e incluso de una región entera. Si São Paulo cae, Londres asume.
No los confundas
Región × Zona
Región (region)
“¿Y si la ciudad entera se detiene?”
- Ejemplo
- Un apagón golpea São Paulo, y la región de Londres asume el tráfico.
- Foco
- Recuperación ante desastres, residencia de datos y latencia global.
Zona (zone)
“¿Y si un centro de datos se detiene?”
- Ejemplo
- Se corta la energía en la Zona A, y la Zona B sigue atendiendo.
- Foco
- Alta disponibilidad dentro de la región.
| Región (region) | Zona (zone) | |
|---|---|---|
| Qué es | Área geográfica separada (São Paulo, Londres) | Local aislado dentro de una región |
| Protege contra | La pérdida de una ciudad entera | La caída de un edificio o de una línea eléctrica |
| Objetivo | Sobrevivir a un desastre, cumplir reglas locales de datos, acortar la distancia hasta el usuario | Mantener la aplicación en línea dentro de la región |
El nombre en cada nube
El concepto es el mismo en todos los proveedores. Solo cambia el nombre de la zona:
| Proveedor | Región | Zona |
|---|---|---|
| AWS | Region | Availability Zone (AZ) |
| Azure | Region | Availability Zone |
| Google Cloud | Region | Zone |
| Oracle Cloud | Region | Availability Domain (AD) |
En la práctica
Cómo elegir la región correcta
Las grandes nubes tienen regiones repartidas por el mundo, y la misma ciudad suele tener regiones de varios proveedores.
Cumplimiento normativo (compliance)
Algunas leyes exigen que los datos de los ciudadanos se queden dentro del país.
Latencia (latency)
Elige la región más cercana a la mayoría de tus usuarios.
Servicios disponibles (service availability)
No todo servicio existe en todas las regiones.
Precio (pricing)
Los costos varían entre regiones (impuestos locales, costo de operación).
Prueba rápida
Tres preguntas, estilo examen
01
La aplicación tiene que seguir en línea si un centro de datos entero se queda sin energía. ¿Cuál es el mínimo necesario?
02
La ley exige que los datos de los clientes brasileños se queden en Brasil. ¿Qué criterio decide la región?
03
Un terremoto puede tumbar todas las zonas de una región. ¿Qué protege contra eso?
Las regiones y las zonas existen en cualquier certificación de nube: AWS, Azure, Google Cloud u Oracle Cloud. Cambia el nombre; el razonamiento sobre latencia y fallas es el mismo.