Patrones de arquitectura cloud que no requieren Kubernetes | Backend Survivor

Patrones de arquitectura cloud que no requieren Kubernetes

Por Backend Survivor
cloudarquitecturakubernetesdevops

Hay una enfermedad en la industria: “Kubernetes por defecto”. Equipos de 3 personas con 10 servicios deployan un cluster de Kubernetes, instalan Helm charts, configuran service meshes, y terminan gastando más tiempo en infraestructura que en producto.

Este post es para esos equipos.

El principio: complejidad justificada

Cada componente de tu arquitectura tiene un coste:

  • Coste económico: lo que pagás al cloud provider
  • Coste operativo: lo que tu equipo gasta manteniéndolo
  • Coste cognitivo: lo que un nuevo developer necesita aprender para ser productivo

Kubernetes tiene los tres costes en máximo. Eso está bien si tenés 50 microservicios, 3 equipos de platform engineering, y tráfico que requiere auto-scaling granular. Para el resto, es un impuesto que pagás por seguir la moda.

Patrón 1: Static + Edge (para contenido y marketing)

Cloudflare Pages / Vercel
├── Astro / Next.js (SSG)
├── API routes → Cloudflare Workers / Vercel Functions
└── Assets → CDN global

Para qué: landing pages, blogs, docs, marketing sites. Coste: $0-20/mes. Complejidad: mínima.

Si tu sitio es mayormente contenido (como Backend Survivor), no necesitás un servidor. Generás HTML estático en build time, lo deployás a un CDN, y usás edge functions para lo dinámico (formularios, API calls).

Patrón 2: Managed containers (para APIs y backends)

Cloud Run / ECS Fargate / Fly.io
├── Container Docker (tu app)
├── Cloud SQL / RDS / Neon (base de datos)
├── Cloud Memorystore / Upstash Redis (caché)
└── Cloud Storage / S3 (archivos)

Para qué: APIs REST/GraphQL, backends de aplicaciones, workers de background. Coste: $50-500/mes dependiendo de tráfico. Complejidad: baja-medium.

Un container en Cloud Run o Fargate con auto-scaling a 0 (o a N instancias) resuelve el 90% de los casos de uso de “tengo una API que necesita escalar”. No necesitás Kubernetes para esto.

# cloudrun.yaml — deploy simple
service: mi-api
image: gcr.io/my-project/api:latest
autoscaling:
  minInstances: 0
  maxInstances: 10
  targetCPUUtilization: 70

Patrón 3: Serverless first (para event-driven)

Event-driven:
├── S3 upload → Lambda → procesa archivo → DynamoDB
├── API Gateway → Lambda → negocio → SQS → Lambda worker
└── EventBridge → Lambda → notificación / email

Para qué: procesamiento de archivos, integraciones, webhooks, tareas programadas. Coste: $0-100/mes (pay per execution). Complejidad: medium (debugging distribuido).

Serverless brilla cuando tu workload es event-driven y sporádico. No pagás por capacidad ociosa. Pero el debugging es más difícil y el cold start es real para aplicaciones Java/Python pesadas.

Patrón 4: Monolito modular deployado simple (para la mayoría)

VPS / VM simple (2-4 cores, 8-16GB RAM)
├── Docker Compose
│   ├── App (monolito modular)
│   ├── PostgreSQL
│   ├── Redis
│   └── Caddy (reverse proxy + TLS automático)
└── Backups automáticos a S3

Para qué: MVP, startups early-stage, proyectos internos, herramientas de equipo. Coste: $20-80/mes. Complejidad: mínima.

Un monolito bien estructurado (módulos internos, no microservicios) en un VPS con Docker Compose es la arquitectura más subestimada de 2026. Podés empezar así y migrar a servicios gestionados cuando el tráfico lo justifique.

¿Cuándo SÍ necesitás Kubernetes?

Kubernetes tiene sentido cuando:

  1. Tenés > 20 servicios que necesitan deployarse independientemente
  2. Tu equipo tiene > 10 developers que trabajan en servicios diferentes
  3. Necesitás auto-scaling granular (escalar solo el servicio de búsqueda, no todo)
  4. Tenés requisitos de multi-cloud o multi-region complejos
  5. Tu equipo tiene experiencia operativa con K8s y herramientas del ecosistema

Si none de estas condiciones se cumple, no necesitás Kubernetes. Y probablemente nunca lo necesites.

La decisión práctica

¿Tu app es mayormente contenido? → Patrón 1 (Static + Edge)
¿Tu app es una API con tráfico variable? → Patrón 2 (Managed containers)
¿Tu app procesa eventos esporádicos? → Patrón 3 (Serverless)
¿Estás empezando y no sabés qué hacer? → Patrón 4 (Monolito + VPS)

La mejor arquitectura es la que tu equipo puede operar sin despertarse a las 3am. Si Kubernetes no es esa arquitectura, no la uses. La simplicidad operativa es una feature, no una limitación.