La nube no es la computadora de otro (bueno, sí… pero no como crees)

Llegas al jale, abres Slack con tu café medio tibio y lo primero que ves: “Se cayó el sitio”. Nadie tocó nada (claro). Te conectas con tu laptop ya medio guerrera, abres la consola y… sorpresa: el “servidor” que buscas “no existe”.

Y no es que desapareciera por arte de magia. Es que ya no estás jugando a “un server y ya”. En cloud hay instancias que nacen y mueren, un balanceador que decide a quién le cae el tráfico, un storage que se siente como carpeta pero te cobra por request, y una factura que si te descuidas se vuelve el susto del mes.

Ahí es cuando alguien suelta la frase: “La nube es la computadora de otro”. Sí… pero si te quedas con esa idea, te vas a equivocar justo en lo importante. La nube no es un lugar: es un modelo de operación. Tiene reglas, límites y un reparto de responsabilidades que, si no lo entiendes, te truena en production cuando el deadline aprieta.

Qué vas a aprender

• Qué significa realmente “la nube” cuando la estás operando (no cuando te la están vendiendo).
• El modelo de responsabilidad compartida y por qué ahí se rompen equipos.
• Cómo pensar en compute, red, storage, identidad y observabilidad sin hacerte bolas.
• Un mini plan para moverte de “un VPS con fe” a algo más cloud-native sin perder la paz.
• Errores típicos que cuestan fines de semana (y cómo evitarlos).

Contexto práctico: lo que sí compras cuando pagas nube

Cuando contratas cloud, no estás rentando “una computadora”. Estás comprando cosas que cambian tu workflow:

1. Abstracciones

   • VMs (EC2/Compute Engine) que se sienten como servidores.
   • Contenedores (ECS/GKE/AKS) que se sienten como “procesos con esteroides”.
   • Functions que parecen magia… hasta que te pega el cold start.

2. Automatización y APIs

   • Todo se crea, destruye y reproduce con IaC (Terraform, Pulumi, CloudFormation).
   • Eso es poder… y también riesgo si cualquiera puede hacer terraform apply a lo loco.

3. Un contrato de operación

   • Disponibilidad, SLAs, regiones, zonas.
   • Pero el SLA no te salva de permisos mal puestos o secretos filtrados.

4. Economía por consumo

   • Lo bueno: no compras fierros.
   • Lo malo: el costo se vuelve un bug más, y a veces el más caro.

En México (y LatAm en general) eso pega doble: presupuesto en pesos, factura en dólares, y el tipo de cambio recordándote que la arquitectura también es finanzas.

Guía principal: úsala como frase de guerra… pero completa

“La nube es la compu de otro” sirve si la terminas así:

“Es la compu de otro… operada por otro, configurada por mí, y cobrada por uso.”

Ahí ya cambia la conversación. Porque ahora toca decidir qué control quieres, qué talacha vas a cargar, y dónde están los riesgos reales.

1) Ubica tu capa: IaaS, PaaS o Serverless (y acepta el tradeoff)

IaaS (VMs, redes, discos):

• Control y familiaridad.
• También talacha: parches, hardening, monitoreo, capacity planning.

PaaS (managed DB, managed Kubernetes, managed queues):

• Menos talacha operativa.
• Menos control fino. Y cuando algo falla, tu “servidor” se vuelve ticket.

Serverless (functions, managed workflows):

• Escala fácil, pagas por uso.
• Debug distinto, límites de ejecución, y cuidado con costos por evento.

Decisión práctica:

• Equipo chico + sistema crítico: PaaS casi siempre es la apuesta sensata.
• Vienes de on-prem/VPS y no quieres romper todo: arranca con IaaS, pero con disciplina.

2) Responsabilidad compartida (donde se rompe la ilusión)

Lo que más confunde a la banda es creer que “como pago cloud, alguien más se encarga”. No.

• El proveedor se encarga de: datacenters, energía, hardware, red física y (según el servicio) capa de virtualización.
• Tú te encargas de: identidades, permisos, datos, configuración, cifrado (muchas veces), parches dentro del SO (en IaaS), seguridad de tu app, secretos, logs.

Escena real:

• “Nos hackearon el bucket”. Neta, casi nunca es “la nube”. Suelen ser permisos mal puestos, un bucket público, o credenciales filtradas en una laptop/runner.

Decisión práctica:

• Si no está claro “quién responde por qué”, escribe un mini RACI (aunque sea en Notion) para:
  • Identidad y accesos (IAM)
  • Datos (backups, retención)
  • Red (firewalls, WAF)
  • Incidentes (on-call, escalación)

3) Identidad primero: IAM antes que Kubernetes

Cloud se rompe por identidad, no por CPU. Puedes tener el mejor cluster, pero una llave expuesta te tumba todo el stack.

Checklist mínimo que sí cambia el juego:

• Usa SSO si puedes (Google Workspace / Entra ID / Okta) y evita usuarios locales.
• Activa MFA para todo lo humano.
• Prohíbe llaves largas viviendo en laptops (sí, también en la tuya).
• Aplica principio de menor privilegio:
  • “Dev” no debería poder borrar recursos/cuentas de prod.
• Separa por ambientes:
  • Cuentas/proyectos distintos para dev/stage/prod si el tamaño lo amerita.

Decisión práctica:

• Si hoy comparten un usuario tipo admin@empresa, frena. Eso no escala: ni en seguridad ni en auditoría ni cuando hay que hacer rollback y nadie sabe quién movió qué.

4) Red y exposición: lo público es más público de lo que crees

En cloud, “abrir el puerto” no es un switch. Es un combo de piezas:

• Security Groups / Firewall Rules
• Rutas y subnets
• Balanceadores
• NAT / Egress
• DNS

Errores típicos que he visto con mis ojos:

• Dejar 0.0.0.0/0 “temporal” en SSH o en una base de datos.
• Exponer un panel admin “porque tiene password”. (Spoiler: bots no se cansan.)

Decisión práctica:

• Regla de equipo: si es admin o DB, no sale a internet. Acceso por VPN, bastion, SSM/Session Manager o Zero Trust.

5) Storage y datos: no es “un disco”, es una política

En cloud tienes storage de objeto, de bloque y de archivos. Cada uno tiene su chiste (y su trampa):

• Objeto (S3/GCS/Blob): ideal para archivos, backups, logs. Ojo con permisos y costos por request.
• Bloque (EBS/Persistent Disk): “disco” para VMs. Ojo con snapshots y lifecycle.
• Archivos (EFS/Filestore): compartido, útil para legacy. Ojo con latencia/costo.

Decisión práctica:

• Si los datos son críticos, define RPO/RTO aunque sea en una línea: “RPO 1 hora, RTO 4 horas”. Eso te obliga a diseñar backups bien y no con esperanzas.

6) Observabilidad: sin logs/metrics/traces, todo es puro rumor

La nube te da herramientas, pero tú las tienes que conectar.

Base mínima que sí te salva a las 2am:

• Logs centralizados (app e infraestructura)
• Métricas (CPU/memoria, latencia, errores, saturación)
• Alertas con dueño (no un canal lleno de notificaciones ignoradas)
• Tracing si ya hay microservicios, colas o llamadas en cadena

Escena conocida:

• On-call en CDMX, internet medio flaky, tu jefe pidiendo “solo un cambio rápido” y tú tratando de adivinar qué pasó sin dashboards. Ese tipo de caos no es mala suerte: es deuda operativa.

7) Costos: el bug silencioso

La nube premia lo eficiente y castiga lo olvidado.

Tres generadores clásicos de facturas feas:

• Recursos sin apagar (VMs, discos, IPs elásticas).
• Egress (salida de datos) no contemplado.
• Overprovisioning “por si acaso”.

Decisión práctica:

• Etiqueta recursos (env, owner, service).
• Pon budgets y alertas.
• Revisa costos semanalmente al inicio; luego cada sprint.

Paso a paso: aterrizaje cloud-native sin perderte (versión “equipo real con deadline”)

Este plan te funciona si vienes de:

• Un VPS con Docker “a mano”,
• un monolito que se deploya por SSH con miedo,
• o un server que “solo lo entiende Juan” (y Juan ya se fue a otro jale).

Paso 1: separa ambientes y define un “camino a prod”

• Dev: rápido y barato.
• Stage: parecido a prod.
• Prod: estable, con controles.

Si todavía no puedes separar cuentas/proyectos, mínimo:

• VPC/VNet separada
• Recursos separados por naming y tags

Paso 2: Infra as Code desde el día 1 (aunque sea chiquito)

Usa Terraform (por ejemplo) para levantar red + cómputo + storage base.

Snippet mínimo de Terraform (conceptual):

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "app_assets" {
  bucket = "mi-app-assets-prod"
}

resource "aws_s3_bucket_public_access_block" "block_public" {
  bucket                  = aws_s3_bucket.app_assets.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Nota humana: aunque no uses AWS, la idea se repite: declara, versiona, revisa por pull request.

Paso 3: CI/CD que haga lo aburrido (y evite el “deploy con rezo”)

Objetivo realista:

• Build
• Tests
• Security checks básicos
• Deploy a stage
• Aprobación manual a prod

Ejemplo de pipeline (GitHub Actions, simplificado):

name: deploy
on:
  push:
    branches: ["main"]

jobs:
  build_test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  deploy_stage:
    needs: build_test
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy a stage aquí"

Decisión práctica:

• Si han sufrido en prod, mete aprobación manual para producción. Automatizar el caos solo lo hace más rápido.

Paso 4: secretos bien (adiós .env en el repo y en el WhatsApp)

• Usa Secret Manager / Parameter Store / Vault.
• Rota secretos.
• Nunca metas credenciales en imágenes Docker.

Tip de guerra: si alguna vez mandaste una key por chat “solo tantito”, asume que ya es pública. Rótala.

Paso 5: elige tu runtime con intención

• Si estás empezando cloud-native: un managed container service suele ser mejor primer paso que Kubernetes.

  • Menos piezas.
  • Menos “¿por qué no schedulea el pod?”

• Kubernetes cuando:

  • ya tienes varios servicios,
  • necesitas portabilidad,
  • tienes capacidad operativa (o un managed Kubernetes bien llevado).

Paso 6: resiliencia mínima (sin fantasías)

• Health checks
• Auto-scaling (si aplica)
• Rollback claro
• Backups probados
• Runbooks

Si no has probado restaurar un backup, no tienes backups; tienes esperanzas.

Screenshots sugeridos

• Diagrama simple de “Responsabilidad compartida”: proveedor vs tu equipo (IAM, datos, OS, app).
• Captura de consola de cloud:
  • Reglas de firewall/SG con ejemplo de regla segura vs 0.0.0.0/0.
• Dashboard de costos con un pico marcado y etiquetas owner/env.
• Vista de un pipeline CI/CD con etapa de aprobación a prod.
• Alertas/monitoreo: latencia p95, tasa de errores, saturación.

Errores comunes + solución (de los que cuestan fines de semana)

Error 1: “Le doy admin a todos para avanzar rápido”

• Síntoma: nadie sabe quién borró qué; riesgo enorme.
• Solución: roles por función + permisos mínimos + MFA + auditoría.

Error 2: “Abrí la DB a internet porque el proveedor lo hizo difícil”

• Síntoma: intentos de login, bots, riesgo de exfiltración.
• Solución: DB privada; acceso por VPN/bastion/SSM. Si necesitas exponer algo, expón una API con auth, no la DB.

Error 3: “No tengo tags, luego los pongo”

• Síntoma: factura imposible de explicar; nadie se hace responsable.
• Solución: política de tags obligatorios + budgets + alertas.

Error 4: “Kubernetes para todo desde el primer día”

• Síntoma: más tiempo en YAML que en producto; incidentes raros.
• Solución: empieza con managed containers o PaaS; llega a K8s cuando el equipo y el problema lo justifiquen.

Error 5: “Monitoreo al final”

• Síntoma: incidentes sin visibilidad; culpas cruzadas.
• Solución: logs/metrics desde el MVP; alertas con dueño; runbook mínimo.

Checklist final (para que la nube no te coma vivo)

• Tengo ambientes separados (aunque sea por red y naming).
• IAM con MFA y roles; sin usuarios compartidos.
• Nada crítico expuesto a internet (DB/admin).
• Infra como código versionada y revisada por PR.
• CI/CD con deploy a stage y gate a prod.
• Secretos en un manager, no en repos ni imágenes.
• Backups configurados y restauración probada.
• Observabilidad mínima: logs + métricas + alertas con dueño.
• Tags + budgets + alertas de costo.
• Runbook corto para incidentes (cómo ver logs, rollback, contactos).

FAQ

1) Entonces… ¿sí es la computadora de otro o no?

Sí, físicamente corre en infraestructura de un proveedor. Pero lo que te rompe (o te salva) es que tú decides configuración, accesos, datos y operación. No es “otra compu”; es “otro datacenter con tu responsabilidad encima”.

2) ¿Qué tan cloud-native debo ser para empezar?

Lo suficiente para dejar de hacer deploys manuales y para poder reproducir tu infraestructura. Cloud-native no es un badge: es bajar fricción con automatización, observabilidad y buenas prácticas.

3) ¿Necesito Kubernetes para decir que uso nube bien?

No. Mucha gente se dispara en el pie subiéndose a K8s sin necesidad. Si tu problema es simple, un PaaS o contenedores administrados te dan más valor con menos complejidad.

4) ¿Qué aseguro primero?

Identidad (IAM) y exposición (red). Luego secretos, backups y observabilidad. La mayoría de incidentes graves empiezan por credenciales o permisos.

5) ¿Cómo evito sorpresas en la factura?

Tags obligatorios, budgets con alertas, revisión semanal al inicio y entender egress. Y apaga lo que no uses: recursos huérfanos son el “cargo fantasma” de la nube.

Siguiente episodio

De “la nube” a lo operativo: cómo armar tu primer workflow serio de deploy (sin que production sea tu entorno de pruebas). Vamos a aterrizar CI/CD, ambientes y rollback con decisiones que sí aplican cuando el deadline no perdona.