48  N4. Servicios administrados: paga por no administrar

Managed Postgres, storage, DNS, CDN y secretos — lo que la nube te quita

NotaEn una frase

El valor real de la nube no son las máquinas — son los servicios administrados: una Postgres con backups y failover automáticos (RDS), un storage prácticamente indestructible (S3), DNS global, CDN, y un lugar diseñado para secretos. Pagas para no ser DBA ni sysadmin a las 3 de la mañana.

48.1 El problema

En N1 administraste un VPS: SO, nginx, systemd. Ahora imagina hacer lo mismo con PostgreSQL: instalarla, configurar backups diarios, probar que esos backups restauran (los backups que nunca se prueban no existen), montar una réplica por si el servidor muere, aplicar parches de seguridad sin tumbar el servicio, cifrar los discos. Eso es un empleo de tiempo completo llamado DBA — y tu equipo de 3 personas no tiene uno.

48.2 Cómo lo resuelve un equipo

La respuesta de la industria: comprar la administración, no solo la máquina. Un servicio administrado te da el software funcionando y el proveedor absorbe: parches, backups, failover, réplicas, escalado de disco. Tú recibes una connection string y un panel.

Un string es texto entre comillas: "hola". El nombre viene de “cadena de caracteres” — una secuencia de letras. Todo lo que llega de un formulario o una URL llega como string, aunque parezca número.

El intercambio es el patrón de toda esta sección: menos control, menos trabajo, más factura por unidad. Para casi todo equipo, el trato sale ganando — las horas de DBA cuestan más que la diferencia de precio.

48.3 Conceptos nuevos

  • D BD administrada (RDS, Cloud SQL, Azure SQL, Supabase, Neon, PlanetScale): backups, réplicas y parches incluidos
  • Ops Object storage (S3, Blob, GCS): archivos por HTTP, durabilidad de “11 nueves” — NO es un filesystem
  • Ops DNS administrado (Route 53, Cloudflare) y CDN (CloudFront, Cloudflare): tu contenido copiado cerca de cada usuario
  • Ops Secretos administrados (Secrets Manager, Key Vault, Doppler): dónde van las API keys de verdad
  • Ops Observabilidad administrada (CloudWatch, Datadog): logs/métricas sin montar el stack

48.4 La explicación visual

flowchart TB
  subgraph You["Lo que tú ves"]
    CS["DATABASE_URL<br/>S3_BUCKET<br/>SECRET_ARN"]
  end
  subgraph Them["Lo que el proveedor administra"]
    B["Backups diarios + restauración"] --> R["Réplica / failover"] --> P["Parches de seguridad"] --> M["Monitoreo 24/7"]
  end
  You -.->|"connection string"| Them

Servicio Qué te quita de encima Qué NO es
RDS Backups, failover, parches, réplicas, cifrado “Postgres en una VM” — es Postgres con equipo de ops incluido
S3 Discos, RAID, capacidad, replicación “Una carpeta en la nube” — es key→objeto por HTTP, sin directorios reales
CDN Servidores en 100+ ciudades “Un acelerador mágico” — es caché geográfica de tus estáticos
Secrets Manager Rotación, auditoría, cifrado de secretos “Un .env caro” — rota credenciales sin redeploy

48.5 Implementación

Conectar Taskflow a una Postgres administrada — el flujo es idéntico en los tres proveedores porque la app no sabe quién administra la base:

Paso 1 — provisionar (consola o CLI, 5 minutos):

# AWS example — creates a managed Postgres
aws rds create-db-instance \
  --db-instance-identifier taskflow-db \
  --db-instance-class db.t3.micro \
  --engine postgres --master-username app \
  --manage-master-user-password     # secret auto-created in Secrets Manager

Paso 2 — la app solo ve una URL. Esto es lo elegante: tu código de los caps. 8–13 no cambia nada — cambia una variable de entorno:

Una variable es una caja con nombre donde guardas un valor: let total = 42 guarda el 42 bajo el nombre total. Puedes leerla y cambiarla después (total = 50). const = caja que no se puede reemplazar.

Una variable de entorno es configuración que vive fuera del código: DATABASE_URL, JWT_SECRET. El mismo binario corre en dev y prod con distintas vars — los secretos nunca se escriben en el código.

Un entorno es una instancia completa donde corre tu app con su propia config y datos: local (tu máquina), staging (réplica de prueba), producción (la real). Cada entorno tiene sus propias llaves y su propia base de datos.

# .env — the ONLY difference between local and managed Postgres
# Local:          DATABASE_URL=postgresql://app:dev@localhost:5432/taskflow
# Managed (RDS):  DATABASE_URL=postgresql://app:****@taskflow-db.abc.us-east-1.rds.amazonaws.com:5432/taskflow

Paso 3 — el secreto vive en el servicio de secretos, no en tu .env ni en el historial del shell (¿recuerdas el mini reto de N1?):

aws secretsmanager get-secret-value --secret-id taskflow/db
# → {"DATABASE_URL": "postgresql://..."}   fetched at boot, never in a file

El contrato mental: el proveedor te entrega un endpoint + credencial auditable; tú entregas la app configurada por entorno. La frontera de N2 aplicada a la base de datos.

Una base de datos es el programa que guarda datos de forma permanente y los responde rápido. Relacional (Postgres): tablas con relaciones. No relacional: documentos, clave-valor, grafos — cada una para una forma de dato distinta.

Migra mi API de tareas de la Postgres local a una base de datos
administrada [RDS / Cloud SQL / Neon / Supabase]. Dame: los pasos para
provisionar la instancia (tier gratuito), cómo correr mis migraciones
existentes contra ella, qué cambia en mi configuración (pista: solo una
env var), dónde guardar la connection string (secret manager, no .env
commiteado), y cómo verificar backups automáticos habilitados. Incluye
el paso que la mayoría olvida: cerrar el acceso público y abrir solo
desde mi app.

48.6 ¿Por qué no administrarlo todo tú?

Lo único que necesitas llevarte: un servicio administrado convierte conocimiento operativo (que tardas años en ganar) en factura mensual (que puedes pagar hoy). La pregunta correcta nunca es “¿puedo hacerlo yo?” — es “¿quiero mantenerlo yo a las 3am dentro de dos años?”.

Alternativa Qué te cuesta Cuándo elegirla
Managed DB (RDS/Cloud SQL) ~2× el precio de la VM equivalente, menos control fino Casi siempre — es la cimentación por defecto
Postgres en tu VPS/contenedor Toda la operación: backups, failover, parches Aprendizaje, presupuesto cero, o requisitos muy raros
DBaaS nueva gen (Neon, Supabase, Turso) Dependencia de un proveedor más joven MVPs: free tiers generosos, DX excelente
Self-hosted + herramientas (CloudNativePG) Operación Kubernetes + DBA-light Escala grande donde el 2× de RDS pesa

El punto medio moderno: Neon/Supabase/Turso — Postgres administrada con free tier real y DX de startup. Para Taskflow en producción inicial, son la opción más sensata: administrado y barato.

48.7 Errores comunes

Error Por qué pasa Fix
RDS expuesta a internet “Así la pruebo desde mi laptop” Red privada + acceso solo desde la app (o bastion)
Secreto en .env commiteado El repo es eterno aunque borres el commit Secret manager + rotar lo que ya se filtró
S3 usado como filesystem s3://bucket/uploads/ como “carpeta” con millones de archivos y listados Es key→objeto: prefijos sí, ls barato no
Pensar “administrado = infalible” RDS cae también; solo cae menos Backups + réplica + plan de restauración igualmente
Facturación por sorpresa en S3 Cobran por GB, requests y egress (salida de datos) Lifecycle policies + revisar egress en la factura

48.8 Buenas prácticas

  • La app se configura por entorno, no por proveedor: DATABASE_URL apunta a localhost en dev y a RDS en prod — mismo código.

localhost significa “esta misma máquina” — es la dirección que tu computadora usa para hablarse a sí misma. Cuando desarrollas, el “servidor” y el “cliente” viven en tu laptop: por eso todo es localhost:3000.

  • Backups verificados: programa una restauración de prueba. Un backup que nunca restauraste es una esperanza, no un plan.
  • Menor privilegio también en la nube: la BD de la app solo acepta conexiones de la app, no de 0.0.0.0/0.
  • Un secreto, un lugar: mezclar .env, Secrets Manager y variables del CI dispersa la responsabilidad — elige uno por entorno.

EXTRA Cuando un roadmap dice “aprende caching”, son tres capas distintas —

  • CDN — la copia en el borde, cerca del usuario (este capítulo)
  • Caché del lado del servidor — Redis o Memcached: resultados de queries caras, sesiones, rate limits
  • Caché del lado del cliente — el navegador guarda estáticos con headers de expiración

El libro lo deja como decisión (Ap. K #14): el caché se agrega cuando un problema medido lo pide — antes es complejidad sin beneficio.

48.9 Ejercicio

  1. Nombra cuatro cosas que RDS hace por ti y que tendrías que implementar a mano en un VPS.
  2. Un junior dice: “S3 es como Google Drive del servidor”. ¿Qué dos diferencias técnicas rompen la analogía?
  3. ¿Dónde debe vivir DATABASE_URL en producción y por qué no en un .env del servidor?
  1. Backups automáticos con restauración point-in-time, failover a réplica (si muere el nodo, otro toma el lugar), parches de seguridad aplicados sin downtime, réplicas de lectura, cifrado de disco, monitoreo. Cualquiera de las cuatro es correcta.
    1. S3 es key→objeto por HTTP — no hay directorios reales ni ls barato (listar millones de objetos cuesta). (b) La durabilidad es por diseño (11 nueves: objetos replicados entre instalaciones) — no es “un disco que puedes formatear”, es un servicio de objetos.
  3. En un secret manager (Secrets Manager, Key Vault, las env vars del PaaS). El .env del servidor queda en disco en texto plano, en backups del filesystem, y en la historia del repo si se commitea — el secret manager da cifrado, rotación y auditoría.

48.10 Mini reto

Tu Taskflow ya corre en un VPS (N1) y la Postgres vive en la misma máquina. Enumera tres escenarios donde esa decisión duele — y cuál es la primera señal de que debes moverla a un servicio administrado.

Escenarios: (a) el VPS muere → pierdes app y datos en un solo incidente; (b) el disco se llena de WAL/ backups improvisados → nadie los prueba hasta el desastre; (c) necesitas reiniciar/parchear el SO → también tumbas la base. La primera señal de migración: el momento en que la base guarda datos que no puedes volver a generar — típicamente el primer usuario real. Desde ese día, “Postgres en la misma caja” es una deuda con vencimiento desconocido.

48.11 Vocabulario técnico del capítulo

Un objeto es una colección de datos con nombre: {name: "Ana", age: 30} — cada dato es una propiedad (clave → valor). Python los llama dict, Go los arma con struct, TS con objetos/interface.

Una clase es el molde de un objeto: define qué datos y qué métodos tiene. class Task es el molde; new Task() es una instancia concreta. Go no tiene clases — usa struct + métodos sueltos.

Un log es el diario del programa: qué pasó, cuándo, con qué request. Estructurado = en JSON con campos (request_id, user_id), para filtrar por máquina y no con los ojos.

Un secreto es un dato que no puede publicarse: contraseñas de BD, llaves de API, el secreto que firma los JWT. Viven en .env (fuera de git) o en un secret manager — nunca en el código ni en el repo.

El DNS es la agenda telefónica de internet: traduce nexus.com → 203.0.113.10. Tu dominio apunta vía DNS a tu load balancer o servidor — por eso “propagación de DNS” toma minutos.

Una CDN (Content Delivery Network) es una red de copias: tu estático se cachea en servidores cercanos al usuario. El de Buenos Aires no viaja a Virginia por una imagen — la recibe del nodo local.

Un caché es una copia rápida de algo costoso de obtener: el resultado de una query pesada, la sesión. Redis es el caché estándar. La regla de oro: cachear es fácil, invalidar (saber cuándo el caché ya no vale) es lo difícil.

La terminal (consola, línea de comandos) es la interfaz de texto con el sistema operativo: escribes comandos, lees resultados. Es como hablarle a la computadora por cartas en vez de señalar con el mouse.

Un CLI (Command Line Interface) es un programa que se usa escribiendo comandos en la terminal: git, npm, docker son CLIs. Lo contrario es una GUI (interfaz gráfica con botones).

Un commit es una foto guardada del código con un mensaje que dice por qué cambió. La historia del proyecto es una cadena de commits: puedes volver a cualquiera, ver qué cambió y quién lo hizo.

Un repositorio (repo) es la carpeta del proyecto con todo su historial Git adentro. GitHub/GitLab son servicios que hospedan repos para compartirlos y respaldarlos.

Un puerto es una puerta numerada dentro de una computadora: la IP llega al edificio, el puerto al departamento. :3000 = “la app que escucha en el departamento 3000”. Postgres suele usar 5432, HTTP el 80, HTTPS el 443.

Una migración es un cambio versionado del esquema: un archivo que dice “crea esta columna” (up) y “bórrala” (down). Son el historial Git de la estructura de la BD — se aplican en orden y no se editan una vez aplicadas.

El cifrado convierte datos en basura legible solo con la llave — y a diferencia del hash, se puede revertir. HTTPS cifra el cable; las contraseñas NO se cifran, se hashean (no hay por qué revertirlas).

48.12 Lo que deberías saber hacer ahora