40  N2. IaaS, PaaS y SaaS: la frontera de responsabilidad

Quién administra qué — la pregunta que responde todo modelo de nube

NotaEn una frase

La única pregunta que importa en la nube: ¿hasta dónde llega tu responsabilidad? IaaS te da la máquina y administras todo desde el SO; PaaS te da la plataforma y solo subes tu código; SaaS solo la usas. Mismo problema, distinta línea donde terminas tú y empieza el proveedor.

40.1 El problema

En N1 viste el VPS: tú instalas Ubuntu, Node, nginx, systemd, firewall. Funciona, pero ¿qué pasa si no quieres administrar todo eso? Cada modelo de nube es una respuesta distinta a “¿qué parte de la pila quiero olvidar?”. No son opciones buenas/malas — son fronteras distintas entre tu trabajo y el del proveedor.

La nube son computadoras de otro que rentas por hora: AWS, Azure, GCP te prestan máquinas, redes y servicios administrados. Pagas por no comprar hardware — y por no administrarlo tú.

Un firewall (security group en AWS) es la lista de puertos que aceptan tráfico: “443 abierto a todos, 5432 solo desde la app”. Cada puerto abierto es una puerta a vigilar — abre lo mínimo.

40.2 Cómo lo resuelve un equipo

La analogía clásica es la pizza:

Modelo Análogo Tú traes Ellos traen
On-premise Cocinar en casa Todo: horno, ingredientes, mesa La receta quizá
IaaS Cocinar en cocina rentada Ingredientes y cocinar Local, horno, luz
PaaS Pizza congelada en casa ajena Elegirla y calentarla Cocina, horno, pizza hecha
FaaS Delivery Pedirla por teléfono Todo lo demás
SaaS Restaurante Sentarte a comer Absolutamente todo

Traducido a la pila técnica (hardware → virtualización → SO → runtime → app → datos):

El runtime es el motor que ejecuta tu código: Node.js es el runtime de JavaScript fuera del navegador; CPython es el de Python; Go compila a binario y el runtime va empaquetado dentro. Es “quien corre” lo que escribiste.

  • IaaS (EC2, Azure VM, Droplet): ellos hardware + virtualización. Tú desde el SO: parches, runtime, nginx, app, datos. “Te alquilo la cocina vacía.”
  • PaaS (Heroku, Render, Railway, App Engine): ellos hasta el runtime. Tú git push con tu código. “Cocina equipada: trae tu receta.”
  • FaaS/serverless (Lambda, Functions): ellos hasta el handler. Tú una función. “Delivery por evento.”
  • SaaS (Gmail, Notion, Stripe): ellos todo. Tú eres el usuario.

40.3 Conceptos nuevos

  • U IaaS: EC2, VMs — tú desde el SO en adelante
  • U PaaS: Heroku, Render, App Engine, Elastic Beanstalk — solo tu app
  • U SaaS: Gmail, Notion — solo lo usas
  • Ops CaaS (Containers as a Service: ECS, Cloud Run) y FaaS (Lambda) — puntos intermedios: el primero sube un contenedor, el segundo sube una función

40.4 La explicación visual

flowchart TB
  subgraph S["La pila: quién administra cada capa"]
    direction LR
    HW["Hardware"] --> VI["Virtualización"] --> OS["SO"] --> RT["Runtime"] --> AP["Tu app"] --> DA["Tus datos"]
  end
  IaaS["IaaS: tú desde el SO"] -.-> OS
  PaaS["PaaS: tú desde la app"] -.-> AP
  SaaS["SaaS: tú nada — solo usas"] -.-> DA

Capa On-prem IaaS CaaS PaaS FaaS SaaS
App tú tú tú tú tú (función) ellos
Runtime tú tú tú ellos ellos ellos
SO tú tú ellos ellos ellos ellos
Virtualización tú ellos ellos ellos ellos ellos
Hardware tú ellos ellos ellos ellos ellos

La lectura: cada paso a la derecha te quita trabajo operativo y te cuesta control + dinero + dependencia del proveedor (lock-in).

Una dependencia es código de terceros que tu proyecto usa: npm install, pip install, go get las traen. Cada una es deuda — ahora funciona, pero hay que mantenerla, actualizarla y confiar en ella.

40.5 Implementación

Misma app — Taskflow — en los dos extremos que ya conoces:

# On your VPS — YOU own everything from the OS up
sudo apt update && sudo apt install -y nodejs npm nginx
git clone https://github.com/you/taskflow.git && cd taskflow
npm ci && npm run build
sudo systemctl enable taskflow && sudo systemctl start taskflow
# + firewall, + TLS certs, + log rotation, + OS patches... all yours
# On your laptop — you own only the code
git push render main
# They: build, runtime, process manager, TLS, restarts, OS patches
# You see: "Deploy live at https://taskflow.onrender.com"

En IaaS ejecutaste ~10 comandos operativos; en PaaS, uno. El PaaS interiorizó todo lo del capítulo N1 (systemd, nginx, firewall, parches) detrás de git push. Eso es lo que pagas.

IaaS: rentas la máquina, administras todo lo de adentro. PaaS: rentas la plataforma, solo traes tu código. SaaS: usas el software hecho (Gmail, RDS administrado). Menos control, menos trabajo.

Quiero desplegar mi API de tareas [Express/FastAPI/Go] en un PaaS
[Render / Railway / Heroku / Fly.io]. Dame: el archivo de configuración
necesario (Procfile, render.yaml o equivalente), qué cambios necesita mi
código (puerto desde variable de entorno, build command), las variables
de entorno que debo configurar en el dashboard, y cómo hacer deploy.
Después explícame exactamente qué partes del servidor de N1 está
administrando el PaaS por mí.

40.6 ¿Por qué existen tantos modelos?

Lo único que necesitas llevarte: elige la frontera según lo que tu equipo puede administrar bien, no según lo que “debería” usarse. Un equipo de 2 sin sysadmin no compra IaaS — compra PaaS y se dedica a su producto. Un equipo con 50 ingenieros y requisitos raros sí justifica IaaS. El modelo correcto es el que minimiza tu costo total, no el que minimiza la factura del proveedor.

Alternativa Qué es Qué te cuesta Cuándo elegirla
PaaS Subes código Control limitado, precio/unidad más alto, lock-in moderado Equipos pequeños, MVPs, la opción por defecto sana
CaaS Subes contenedor Debes saber Docker (cap. 30-32) Cuando PaaS se queda corto pero no quieres VMs
IaaS Subes SO completo Todo el trabajo de N1 + parches + seguridad Control fino, compliance, escala con equipo ops
FaaS Subes función Cold starts, límites de tiempo, lock-in alto Eventos, webhooks, tráfico irregular (cap. N5)
SaaS+backend Auth0/Supabase/Firebase hacen tu backend Dependencia fuerte, pero velocidad extrema MVPs donde el backend no es tu diferencial

40.7 Errores comunes

Error Por qué pasa Fix
IaaS “para aprender cloud” en el primer deploy Se confunde “nube” con “VM” Empieza en PaaS; baja a IaaS cuando tengas razón concreta
“PaaS = no hay ops” Siguen existiendo: config, secretos, costos, límites PaaS quita sysadmin, no responsabilidad
Elegir por factura y no por tiempo El VPS de $5 te cuesta 10h/mes de ops Costo real = factura + horas de equipo
Miedo al lock-in prematuro “¿Y si cambio de proveedor?” en un MVP El lock-in se paga; la velocidad perdida no se recupera

40.8 Buenas prácticas

  • La app no debe saber en qué modelo corre: puerto desde env var, configuración por entorno, estado fuera del proceso — así puedes cambiar de frontera después.

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.

Un proceso es un programa en ejecución: el sistema operativo le da memoria propia y un lugar en la fila del CPU. Tu API es un proceso; Postgres es otro; el navegador es varios. Que “se caiga el proceso” = el programa murió.

  • Documenta qué frontera elegiste y por qué — el próximo deploy parte de esa decisión, no de cero.
  • PaaS no es “para novatos”: la mayoría de productos reales vive en PaaS durante años. Administrar VMs no es un logro, es un costo.

40.9 Ejercicio

  1. Clasifica: Gmail, EC2, Heroku, un Droplet, Notion, Lambda, Cloud Run.
  2. Tu startup de 3 personas lanza su API. ¿IaaS o PaaS? Justifica con la frontera, no con el precio.
  3. ¿Qué capa comparten IaaS y PaaS como responsabilidad del proveedor?

Serverless = no piensas en servidores: subes una función y el proveedor la ejecuta por evento, escalando de 0 a 1000 sola. Pagas por ejecución. Lambda (AWS), Cloud Functions (GCP), Azure Functions.

  1. SaaS: Gmail, Notion · IaaS: EC2, Droplet · PaaS: Heroku · FaaS: Lambda · CaaS: Cloud Run (punto medio: subes un contenedor, ellos el SO y runtime).
  2. PaaS. Con 3 personas, cada hora de sysadmin es una hora que no va al producto. La frontera correcta es “nosotros código, ellos plataforma” hasta que exista una razón concreta (requisito de red, costo a escala, compliance) que la mueva.
  3. Ninguna más allá del hardware — espera, trampa: IaaS delega hardware+virtualización; PaaS delega además SO+runtime. La capa compartida como del proveedor en ambos es hardware+virtualización.

40.10 Mini reto

Un equipo dice: “Pasamos de Heroku a EC2 para ahorrar $200/mes”. Tres meses después tienen un sysadmin parcial. Haz la cuenta honesta.

La factura bajó $200, pero el costo subió: si el sysadmin cuesta aunque sea 5h/mes a $50/h = $250 + el tiempo de los devs en parches/incidentes + el riesgo de errores operativos. El ahorro era ilusorio — compararon factura contra factura e ignoraron las horas. Regla: migra de frontera cuando el costo total (factura + tiempo + riesgo) mejora, no cuando solo una línea baja.

40.11 Vocabulario técnico del capítulo

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 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.

HTTPS = HTTP viajando cifrado por TLS: nadie en el camino puede leer ni alterar el tráfico. El certificado es la credencial que prueba que el servidor es quien dice — lo emite una autoridad y hay que renovarlo.

Docker empaqueta tu app con todo lo que necesita (runtime, librerías, config) en una imagen — el mismo paquete corre idéntico en tu laptop y en producción. Es la respuesta a “en mi máquina sí funcionaba”.

Un webhook es una llamada HTTP invertida: en vez de tú preguntarle a Stripe “¿llegó el pago?”, Stripe te llama a tu endpoint cuando pasa. Se verifica la firma (es público) y se responde 200 rápido.

Vertical: máquina más gorda (más CPU/RAM) — fácil, tiene techo. Horizontal: más máquinas — el camino de internet, pero requiere que la app no guarde estado local (por eso todo va a BD/Redis).

El build (construcción) es el proceso que convierte tu código fuente en algo ejecutable/entregable: compilar TypeScript a JS, empaquetar el frontend, armar la imagen Docker. Lo que se despliega es el resultado del build, no tu código crudo.

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.

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.

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 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.

Un deploy es poner tu código a correr en el servidor: copiar la imagen, iniciar el proceso, verificar que responde. El objetivo es que sea aburrido — automático, repetible, con rollback.

40.12 Lo que deberías saber hacer ahora