Cloud computing: rentar fronteras de fallo

Una región es un mercado geográfico que contiene varias zonas de disponibilidad aisladas. Una zona es uno o más centros de datos con energía, enfriamiento y redes separados. Los proveedores conectan las zonas con enlaces privados rápidos, pero la latencia y los cargos por transferencia siguen existiendo. Elige la región por tus usuarios, la residencia de datos, la disponibilidad de servicios y tus necesidades de recuperación. Elige las zonas para sobrevivir la caída de una instalación local.

Region: eu-west
  Availability Zone A: web-1, database replica A
  Availability Zone B: web-2, database replica B
  Availability Zone C: spare capacity or third replica

Single-zone app  → zone outage can stop the service
Multi-zone app   → needs load balancing and replicated state
Multi-region app → needs explicit data and failover design

Infraestructura como servicio te da máquinas virtuales, discos y redes. Los servicios de plataforma administran más del runtime, el despliegue, el escalado o la base de datos. Software como servicio te da la aplicación terminada. Cada escalón hacia arriba te quita control y trabajo operativo a la vez. La pregunta correcta no es "¿cuál es más cloud native?". Es "¿qué trabajo que no nos diferencia podemos dejar de tener a cargo sin riesgo?".

On-premises: hardware + network + OS + runtime + app + data
IaaS:        network + OS + runtime + app + data
PaaS:                    app + data + configuration
SaaS:                            users + configuration

# Ownership never disappears completely
You still own: identity, data classification, access decisions,
configuration, monitoring, recovery tests, and your application code.

Mi opción por defecto para un equipo pequeño es una base de datos administrada y el cómputo administrado más simple que aguante la carga. Correr una base de datos en una VM armada a mano no es una medalla de seriedad técnica. Hazlo solo cuando un requisito justifique encargarte tú de parches, replicación, respaldos, failover y recuperación.

Una máquina virtual se comporta como una computadora con CPU, memoria, interfaces de red y discos virtuales. Sirve para software heredado, requisitos raros de sistema operativo, procesos de larga duración y cargas que necesitan control del kernel o del host. También hace a tu equipo responsable de imágenes, parches, supervisión de procesos, crecimiento de discos, certificados y reemplazo.

# VM bootstrap should be repeatable, not a shell history
1. Launch from a versioned image
2. Attach a machine role, never a copied user key
3. Fetch configuration and secrets at runtime
4. Start under a process supervisor
5. Emit logs and health signals centrally
6. Replace the VM to test reproducibility

# Useful Linux evidence
systemctl status my-app
journalctl -u my-app --since "15 minutes ago"
df -h
ss -lntp

Una imagen de contenedor empaqueta una aplicación y sus dependencias de espacio de usuario. Los contenedores comparten el kernel del host, arrancan rápido y vuelven consistentes los artefactos de despliegue. Un servicio de contenedores u orquestador los agenda, revisa su salud, reemplaza los fallidos y puede escalar réplicas. No hace desaparecer el estado, las redes, la seguridad ni la depuración.

# Build once; identify the immutable artifact
docker build -t registry.example.com/orders:git-a1b2c3 .
docker push registry.example.com/orders:git-a1b2c3

# Runtime rules
listen on 0.0.0.0:$PORT
write logs to stdout/stderr
store durable data outside the writable container layer
handle SIGTERM and stop before the platform deadline
expose separate liveness and readiness signals

Las funciones serverless y los runtimes administrados arrancan código en respuesta a peticiones o eventos. El proveedor se encarga de asignar máquinas y escala instancias dentro de los límites configurados. En muchos productos pagas por petición y por tiempo de ejecución. Es excelente para APIs con picos, webhooks, colas, trabajos programados y código de pegamento. Es malo para una carga constante que necesita hosts especiales, ejecución larga o latencia baja predecible todo el tiempo.

Design each invocation as disposable:
input event → validate → perform idempotent work → record result

Keep outside the instance:
- durable state
- job ownership
- secrets
- retry counters

Configure explicitly:
- timeout
- memory and CPU allocation
- maximum concurrency
- retry policy and dead-letter destination
- warm or provisioned capacity when latency demands it

Los arranques en frío son solo un problema. Las tormentas de conexiones a la base de datos, la entrega duplicada, los reintentos escondidos y la concurrencia desbocada causan incidentes más dolorosos. Haz idempotentes tus handlers. Acota la concurrencia antes de que los servicios de abajo colapsen. Ponle un deadline a cada llamada de red. Serverless elimina el mantenimiento de hosts, no el diseño de sistemas.

El almacenamiento de objetos guarda blobs con nombre detrás de una API. Es la opción por defecto para subidas, respaldos, logs, activos estáticos y data lakes. El de bloques presenta un disco a una máquina y sirve para sistemas operativos y bases de datos. El de archivos presenta directorios compartidos y operaciones de archivo familiares. Elige por patrón de acceso, consistencia, latencia, compartición, durabilidad y recuperación, no por el nombre de producto que recuerdas.

Object: bucket/key → GET, PUT, LIST
  use for: photos, archives, artifacts, backups

Block: volume → filesystem → one or limited hosts
  use for: VM boot disk, database data volume

File: share/path → concurrent filesystem clients
  use for: shared content, legacy file workflows

# A backup policy needs all four
frequency + retention + separate failure boundary + restore test

Una red virtual contiene rangos de direcciones y subredes. Las tablas de rutas eligen a dónde van los paquetes. Un gateway de internet o un balanceador público acepta tráfico público. Un gateway NAT le da salida a las cargas privadas sin aceptar conexiones entrantes no solicitadas. Los security groups y las reglas de firewall deciden qué flujos se permiten. DNS le da nombres estables a direcciones que cambian.

internet
   ↓ HTTPS :443
public load balancer  [public subnets, zones A and B]
   ↓ app port
application replicas [private subnets, zones A and B]
   ↓ database port only
database              [private subnets, no public address]

Outbound from private subnet:
private route → NAT gateway → internet gateway → destination

La gestión de identidad y acceso combina un principal, una acción, un recurso y condiciones. Las personas deberían usar identidades federadas con autenticación fuerte. Las cargas de trabajo deberían usar identidades de máquina de corta duración que la plataforma les adjunta. Las políticas deberían otorgar el permiso más pequeño que sirva. Las llaves de acceso de larga vida copiadas en archivos de código o de entorno de una VM son riesgos evitables.

Decision = principal + action + resource + conditions

Example intent:
principal: orders-production workload
allow:     object:Get
resource:  receipts-production/*
condition: request comes through approved network endpoint

Do not grant:
principal: every workload
allow:     *
resource:  *

Las facturas de la nube combinan capacidad provisionada, tiempo de ejecución, almacenamiento, operaciones, soporte, direcciones públicas, planos de control administrados y transferencia de datos. Cantidades pequeñas por hora se vuelven compromisos mensuales reales. Los datos que se mueven entre zonas, entre regiones o hacia internet pueden dominar un diseño que se veía barato en una calculadora de cómputo.

Before launch, estimate:
compute hours or request volume
+ database instances, replicas, storage, and backups
+ object operations and retained versions
+ inter-zone, inter-region, and internet transfer
+ load balancers, NAT processing, logs, metrics, support

During operation:
owner tag + service tag + environment tag
budget alerts at useful thresholds
weekly anomaly review
actionable rightsizing, not automatic blind downsizing

Alta disponibilidad significa que el servicio sigue funcionando a pesar de los fallos esperados. Recuperación ante desastres significa que puedes restaurarlo después de una pérdida mayor. Decide el objetivo de tiempo de recuperación, o sea cuánto puede tardar la restauración, y el objetivo de punto de recuperación, o sea cuántos datos recientes se pueden perder. Esos números deberían guiar la arquitectura y las pruebas.

Workload
[ ] Region chosen for users, law, latency, and service support
[ ] Capacity runs across zones; health checks test real readiness
[ ] Compute is replaceable from versioned artifacts
[ ] Timeouts, retries with jitter, and concurrency are bounded

Data
[ ] Replication matches the failure boundary
[ ] Backups are versioned or immutable where needed
[ ] Restore is tested; measured RTO and RPO meet the target

Access and network
[ ] Workloads use short-lived identities and least privilege
[ ] Databases have no unnecessary public path
[ ] Routes, firewall intent, DNS, and certificates are documented

Operations and cost
[ ] Logs, metrics, traces, alerts, owners, and runbooks exist
[ ] Budgets and anomaly alerts reach someone who will act
[ ] Zone loss, bad deploy, expired credential, and restore are drilled

No arranques con multirregión activo-activo porque un diagrama se veía maduro. Empieza con cómputo reemplazable repartido entre zonas, un servicio de datos administrado, respaldos probados, identidades acotadas y fallos observables. Agrega otra región cuando un requisito de recuperación medido pague la complejidad de consistencia, enrutamiento, operación y costo.