Kubernetes vs Serverless en 2026: La Guía de Decisión Honesta Que Nadie Te Da

Cada pocos meses, alguien en Hacker News publica "Migramos de Serverless a Kubernetes" y recibe 500 upvotes. Una semana después, alguien publica "Dejamos Kubernetes por Serverless y ahorramos un 60%" y recibe otros 500. Ambos tienen razón. Ambos están equivocados. Ninguno te dice qué hacer realmente.

El debate Kubernetes vs Serverless lleva desde 2018, pero 2026 es fundamentalmente diferente. Ahora tenemos serverless basado en Wasm (Serverless 2.0) que elimina los cold starts, autoescalado de Kubernetes que realmente funciona, y arquitecturas híbridas que difuminan las líneas por completo.

Esta guía no te va a decir cuál es "mejor". Te va a dar un framework para tomar la decisión correcta para tu situación específica: tu tamaño de equipo, tus patrones de tráfico, tu presupuesto y tu tolerancia a las alertas a las 3 de la mañana.

El Trade-off Fundamental (Que Nadie Explica Claramente)

La versión en una frase:

Kubernetes te da control a cambio de complejidad. Serverless te da simplicidad a cambio de control.

Todo lo demás son detalles. Pero los detalles importan enormemente, así que vamos a profundizar.

Lo Que Realmente Estás Eligiendo

Kubernetes:                          Serverless:
┌─────────────────────────┐          ┌─────────────────────────┐
│  Tú gestionas:          │          │  Tú gestionas:          │
│  ├── Nodos              │          │  ├── Funciones/Código   │
│  ├── Networking         │          │  └── Configuración      │
│  ├── Políticas de escala│          │                         │
│  ├── Service mesh       │          │  El cloud gestiona:     │
│  ├── Ingress            │          │  ├── Servidores         │
│  ├── Almacenamiento     │          │  ├── Escalado           │
│  ├── Monitorización     │          │  ├── Networking         │
│  └── Parches de seguridad│         │  ├── Parcheo            │
│                         │          │  └── Disponibilidad     │
│  El cloud gestiona:     │          │                         │
│  └── Máquinas físicas   │          │  A cambio pierdes:      │
│                         │          │  ├── Control del runtime │
│  A cambio ganas:        │          │  ├── Duración de ejecución│
│  ├── Control total      │          │  ├── Paridad local      │
│  ├── Cualquier runtime  │          │  └── Portabilidad vendor│
│  ├── Paridad local      │          └─────────────────────────┘
│  └── Portabilidad vendor│
└─────────────────────────┘

Esto no es solo una decisión técnica. Es una decisión organizacional.

Kubernetes en 2026: Qué Cambió

Kubernetes ha madurado significativamente. El argumento de "es demasiado complejo" sigue teniendo algo de verdad, pero mucha menos que hace dos años.

Lo Bueno: De Verdad Se Hizo Más Fácil

1. Kubernetes Gestionado Es (Casi) Indoloro

Los grandes proveedores de cloud han dado pasos enormes para reducir la carga operativa:

# EKS Auto Mode (AWS) - lanzado a finales de 2024
# No más gestión de grupos de nodos, AMIs o tipos de instancia
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: default
spec:
  # EKS se encarga de todo: selección de instancias, actualizaciones de AMI,
  # escalado, parcheo del SO, scheduling de GPUs
  role: arn:aws:iam::123456789:role/eks-node-role

• EKS Auto Mode: AWS gestiona nodos, AMIs, escalado y networking. Tú solo desplegás pods.
• GKE Autopilot: El K8s fully managed de Google. Pagás por pod, no por nodo.
• AKS Automatic: La versión de Azure. Best practices automáticas, autoescalado, autoparche.

2. El Ecosistema Se Consolidó

En 2022, elegir un service mesh, ingress controller y stack de monitorización era un proyecto de investigación. En 2026:

3. El Escalado Funciona de Verdad

# KEDA (Kubernetes Event-Driven Autoscaling)
# Escala basándose en demanda real, no solo CPU
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 0          # ¡Escala a cero!
  maxReplicaCount: 100
  triggers:
    - type: kafka
      metadata:
        topic: orders
        lagThreshold: "10"    # Escala basándose en profundidad de cola
    - type: prometheus
      metadata:
        query: rate(http_requests_total{service="orders"}[2m])
        threshold: "100"      # Escala a 100 req/s por pod

KEDA cambió las reglas del juego. Ahora podés escalar deployments de Kubernetes hasta cero y escalar basándote en fuentes de eventos (lag de Kafka, profundidad de SQS, métricas de Prometheus), no solo CPU/memoria. Esto elimina una de las mayores ventajas de serverless.

Lo Malo: Sigue Doliendo

1. El "Impuesto Oculto" de Kubernetes

Nadie habla del costo real de correr Kubernetes. No es solo la factura del cloud:

El Costo Real de Kubernetes:
┌───────────────────────────────────────────────────┐
│                                                   │
│  Factura cloud (lo que ves):          $5,000/mes  │
│  ──────────────────────────────────────────────    │
│  Sueldo platform engineer (1 FTE):    $12,000/mes │
│  Plugins/herramientas de red:         $800/mes    │
│  Monitorización (Datadog/Grafana):    $1,200/mes  │
│  Escaneo seguridad (Snyk/Trivy):      $400/mes   │
│  Mantenimiento CI/CD:                 $600/mes    │
│  Tiempo de respuesta a incidentes:    $1,000/mes  │
│  Formación y capacitación:            $500/mes    │
│  ──────────────────────────────────────────────    │
│  Total real:                          $21,500/mes │
│                                                   │
│  Pensás que gastás $5K.                           │
│  En realidad gastás $21.5K.                       │
└───────────────────────────────────────────────────┘

2. La Montaña de YAML

Un deployment listo para producción todavía requiere una cantidad abrumadora de configuración:

# Para UN microservicio, necesitás:
# - Deployment (template de pod, réplicas, recursos, probes)
# - Service (networking)
# - Ingress/Gateway (acceso externo)
# - HPA o KEDA ScaledObject (autoescalado)
# - PodDisruptionBudget (disponibilidad)
# - NetworkPolicy (seguridad)
# - ServiceAccount + RBAC (permisos)
# - ConfigMap + Secret (configuración)
# - PersistentVolumeClaim (si tiene estado)
#
# Son 9+ archivos YAML por microservicio.
# 20 microservicios = 180+ archivos YAML para mantener.

3. Debuggear Sigue Siendo Difícil

# "¿Por qué no arranca mi pod?"
# Paso 1: Comprobar estado de pods
kubectl get pods -n production | grep -v Running

# Paso 2: Describir el pod problemático
kubectl describe pod order-service-7d8f9c-x2k4n -n production

# Paso 3: Comprobar eventos
kubectl get events -n production --sort-by='.lastTimestamp' | tail -20

# Paso 4: Comprobar logs
kubectl logs order-service-7d8f9c-x2k4n -n production --previous

# Paso 5: Comprobar resource quotas
kubectl describe resourcequota -n production

# Paso 6: Comprobar presión de nodos
kubectl describe node | grep -A5 "Conditions"

# Paso 7: Rendirse y reiniciar todo (todos lo hicimos alguna vez)
kubectl rollout restart deployment order-service -n production

Serverless en 2026: Qué Cambió

Serverless evolucionó drásticamente desde la era de "funciones Lambda de 5 minutos con 256MB de memoria".

Lo Bueno: Ya No Es Solo Lambda

1. Serverless 2.0: WebAssembly Lo Cambia Todo

El mayor cambio en serverless desde su invención: runtimes serverless basados en Wasm.

El serverless tradicional (AWS Lambda, Google Cloud Functions) tiene problemas fundamentales:

• Cold starts: 100ms a 3s para levantar un nuevo contenedor
• Vendor lock-in: Tu código de Lambda no corre en Cloud Functions
• Runtimes limitados: Solo los lenguajes que tu proveedor cloud soporta

Serverless basado en Wasm resuelve los tres:

Serverless tradicional:                Serverless basado en Wasm:
┌─────────────────────────┐            ┌──────────────────────────┐
│  Cold start: 100ms-3s   │            │  Cold start: <1ms        │
│  Runtime: Node/Python    │            │  Runtime: Cualquier lang │
│  Binario: ~200MB         │            │  Binario: ~2MB           │
│  Vendor: Solo AWS        │            │  Vendor: Portable        │
│  Aislamiento: Contenedor │            │  Aislamiento: Wasm sandbox│
│  Escalado: Segundos      │            │  Escalado: Microsegundos │
└─────────────────────────┘            └──────────────────────────┘

Cloudflare Workers lo viene haciendo desde 2018. En 2026, Fermyon Spin, Fastly Compute, e incluso AWS Lambda con Wasm lo hacen mainstream:

// Función serverless Spin (Fermyon)
// Cold start: <1ms. Tamaño del binario: ~2MB.
use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

#[http_component]
fn handle_request(req: Request) -> anyhow::Result<impl IntoResponse> {
    let uri = req.uri().to_string();

    // Servidor HTTP completo, acceso a archivos, HTTP saliente
    // Todo en un binario Wasm de <2MB
    Ok(Response::builder()
        .status(200)
        .header("content-type", "application/json")
        .body(format!(r#"{{"path": "{}","runtime": "wasm"}}"#, uri))
        .build())
}

2. Step Functions y Workflows

Los procesos de larga duración eran el talón de Aquiles de serverless. Ahora:

// AWS Step Functions - Orquestación de workflows complejos
{
  "StartAt": "ValidateOrder",
  "States": {
    "ValidateOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:validate-order",
      "Next": "CheckInventory",
      "Retry": [{"ErrorEquals": ["ServiceUnavailable"], "MaxAttempts": 3}]
    },
    "CheckInventory": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.inStock",
          "BooleanEquals": true,
          "Next": "ProcessPayment"
        }
      ],
      "Default": "NotifyBackorder"
    },
    "ProcessPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:process-payment",
      "TimeoutSeconds": 300,
      "Next": "ShipOrder"
    },
    "ShipOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ship-order",
      "End": true
    }
  }
}

3. Pagar Por Uso Es Real

Para cargas de trabajo intermitentes, nada supera la economía serverless:

Escenario: API que maneja 100K peticiones/mes
Ejecución promedio: 200ms
Memoria: 256MB

Costo AWS Lambda:
  Cómputo:    100,000 × 0.2s × 256MB = $0.33/mes
  Peticiones: 100,000 × $0.20/millón = $0.02/mes
  Total:      $0.35/mes

Costo Kubernetes (EKS):
  Control plane:            $73/mes
  2x nodos t3.medium:      $60/mes
  Load balancer:            $16/mes
  Total:                    $149/mes

                ¡425 veces más caro en Kubernetes!

Lo Malo: Los Costos Ocultos Son Reales

1. El Shock de la Factura Serverless

El modelo pay-per-use funciona maravillosamente hasta que no:

Escenario: API que maneja 50M peticiones/mes
Ejecución promedio: 500ms
Memoria: 1024MB

Costo AWS Lambda:
  Cómputo:  50M × 0.5s × 1GB = $417/mes
  Peticiones: 50M × $0.20/millón = $10/mes
  API Gateway: 50M × $3.50/millón = $175/mes    ← ¡OCULTO!
  Logs CloudWatch: ~50GB = $25/mes               ← ¡OCULTO!
  NAT Gateway (si usás VPC): $45/mes + datos     ← ¡OCULTO!
  Total: ~$672/mes (y crece linealmente)

Costo Kubernetes:
  3x nodos c5.xlarge:       $370/mes
  Control plane:             $73/mes
  Load balancer:             $16/mes
  Total:                     $459/mes (se mantiene fijo)

              ¡Serverless es 46% MÁS caro!

2. El Desarrollo Local Sigue Siendo Doloroso

# Kubernetes: ejecutar lo mismo localmente
docker-compose up
# o
minikube start && kubectl apply -f k8s/

# Serverless: buena suerte
# Opción A: SAM Local (lento, incompleto)
sam local start-api

# Opción B: serverless-offline (solo Node.js, faltan features)
npx serverless offline

# Opción C: LocalStack (pesado, necesita Docker igual)
docker run localstack/localstack

# Opción D: Deployar a un stage dev y rezar
serverless deploy --stage dev

# Ninguno se comporta exactamente como producción.

3. El Vendor Lock-in Es Más Profundo de Lo Que Pensás

# Esto parece portable...
def handler(event, context):
    return {"statusCode": 200, "body": "Hello"}

# ...pero ESTO es lo que realmente escribiste:
import boto3  # AWS SDK
from aws_lambda_powertools import Logger  # Específico de AWS
from aws_lambda_powertools.event_handler import APIGatewayRestResolver

app = APIGatewayRestResolver()
logger = Logger()
dynamodb = boto3.resource('dynamodb')  # AWS DynamoDB
table = dynamodb.Table('orders')  # Específico de AWS
sns = boto3.client('sns')  # AWS SNS

# Tu "función portable" ahora depende de:
# - Formato de eventos de API Gateway
# - DynamoDB
# - SNS
# - CloudWatch Logs
# - Roles IAM
# - Configuración de VPC
# ¿Migrás a GCP? Reescribí el 80%.

El Framework de Decisión: Guía Práctica

Olvidate del hype. Así es cómo decidís en la vida real.

Factor 1: Tamaño del Equipo y Habilidades

Tamaño del equipo:  Recomendación:
──────────────────  ────────────────────────────────
1-3 desarrolladores Serverless (no podés mantener un equipo de plataforma)
4-8 desarrolladores Depende de otros factores
8-15 desarrolladores Cualquiera, K8s si hay ing. de plataforma
15+ desarrolladores Kubernetes (necesitás el control y lo podés sostener)

Matriz de habilidades:
──────────────────────────────────────────────────
¿Equipo fuerte de DevOps/Infra?       → Kubernetes
¿Mayormente ingenieros de producto?   → Serverless
¿Mezcla de ambos?                     → Híbrido

Factor 2: Patrones de Tráfico

Patrón de tráfico:                    Mejor opción:
──────────────────────────────────    ──────────────
Estable 24/7 (e-commerce, SaaS)       Kubernetes
Con picos (campañas de marketing)     Serverless
Event-driven (IoT, webhooks)          Serverless
Batch processing (ETL, ML)            Cualquiera
Tiempo real (WebSocket, gaming)       Kubernetes
Impredecible (startup, MVP)           Serverless

Factor 3: Arquitectura de la Aplicación

# Ponele puntaje a tu aplicación:

def should_use_kubernetes(app):
    score = 0

    # Arquitectura
    if app.has_stateful_services:           score += 3
    if app.needs_persistent_connections:    score += 3  # WebSocket, gRPC
    if app.needs_gpu:                       score += 5
    if app.has_long_running_tasks:          score += 2  # >15 min
    if app.microservices_count > 10:        score += 2
    if app.needs_custom_networking:         score += 3

    # Operaciones
    if app.team_has_platform_eng:           score += 3
    if app.needs_multi_cloud:               score += 4
    if app.needs_on_premise:               score += 5
    if app.has_strict_compliance:           score += 2

    # Economía
    if app.requests_per_month > 50_million: score += 3
    if app.execution_time_avg > 10_seconds: score += 2
    if app.budget_predictability_required:  score += 2

    return score

# Interpretación del puntaje:
# 0-8:   Serverless
# 9-15:  Enfoque híbrido
# 16+:   Kubernetes

Factor 4: Análisis de Cruce de Costos

La pregunta más frecuente: "¿A qué escala Kubernetes se vuelve más barato?"

Peticiones/mes      Costo Lambda   Costo EKS    Ganador
─────────────────   ───────────    ─────────    ──────────
100K                $0.35          $149         Lambda (425x)
1M                  $3.50          $149         Lambda (42x)
10M                 $35            $149         Lambda (4x)
50M                 $672           $459         EKS (1.5x)
100M                $1,340         $459         EKS (2.9x)
500M                $6,700         $920         EKS (7.3x)

Punto de cruce: ~30-40M peticiones/mes
(asumiendo 200ms de ejecución promedio, 256MB de memoria)

⚠️ Estos números cambian drásticamente según:
   - Duración de ejecución (más larga = Lambda más caro)
   - Uso de memoria (más memoria = Lambda más caro)
   - Costos de API Gateway (puede duplicar el costo de Lambda)
   - Pricing de Reserved Concurrency
   - Eficiencia de utilización de nodos EKS

La Arquitectura Híbrida: Lo Mejor de Ambos Mundos

En la práctica, la mayoría de los equipos en 2026 no van all-in con ninguno. Usan ambos.

El Patrón Que Funciona

┌──────────────────────────────────────────────────────┐
│                   Tu Aplicación                       │
│                                                       │
│  ┌─────────────────────┐  ┌────────────────────────┐ │
│  │   Kubernetes Core   │  │   Serverless Edge      │ │
│  │                     │  │                        │ │
│  │  ● API Gateway      │  │  ● Procesado de imagen │ │
│  │  ● Servicio usuarios│  │  ● Generación de PDF   │ │
│  │  ● Servicio pedidos │  │  ● Envío de emails     │ │
│  │  ● Servicio pagos   │  │  ● Handlers de webhook │ │
│  │  ● Base de datos    │  │  ● Cron jobs           │ │
│  │  ● Caché (Redis)    │  │  ● Callbacks de auth   │ │
│  │  ● Búsqueda (ES)    │  │  ● Procesado archivos  │ │
│  │  ● Servidor WebSocket│ │  ● Pipelines ETL       │ │
│  │                     │  │  ● Agregación de logs  │ │
│  │  (Estable, stateful,│  │                        │ │
│  │   larga duración)   │  │  (Picos, stateless,    │ │
│  │                     │  │   corta duración)      │ │
│  └─────────────────────┘  └────────────────────────┘ │
│            │                        │                 │
│            └──── Event Bridge ──────┘                 │
└──────────────────────────────────────────────────────┘

Ejemplo de Implementación Híbrida

# Kubernetes: Servicio core de procesamiento de pedidos
# Corre 24/7, mantiene conexiones WebSocket, necesita estado
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: myapp/order-service:v2.3.1
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "1000m"
              memory: "1Gi"
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url

# Serverless: Procesamiento de imágenes disparado por upload a S3
# Se ejecuta de 0 a 1000 veces por hora. Perfecto para Lambda.
import boto3
from PIL import Image
import io

def handler(event, context):
    s3 = boto3.client('s3')
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    # Descargar imagen original
    response = s3.get_object(Bucket=bucket, Key=key)
    image = Image.open(io.BytesIO(response['Body'].read()))

    # Generar thumbnails
    sizes = [(150, 150), (300, 300), (600, 600)]
    for width, height in sizes:
        thumb = image.copy()
        thumb.thumbnail((width, height))

        buffer = io.BytesIO()
        thumb.save(buffer, 'JPEG', quality=85)
        buffer.seek(0)

        s3.put_object(
            Bucket=bucket,
            Key=f"thumbnails/{width}x{height}/{key}",
            Body=buffer,
            ContentType='image/jpeg'
        )

    return {"statusCode": 200, "generated": len(sizes)}

Cuando Lo Híbrido Se Complica

El enfoque híbrido no es gratis. Cuidado con:

Trampas de complejidad híbrida:

1. Dos sistemas de deploy que mantener
   K8s: ArgoCD + Helm charts
   Serverless: SAM/CDK + CloudFormation
   → Tu pipeline de CI/CD ahora es el doble de complejo

2. Dos sistemas de monitorización
   K8s: Prometheus + Grafana
   Serverless: CloudWatch + X-Ray
   → Correlacionar problemas entre ambos es doloroso

3. Networking entre ambos
   Pod K8s → Lambda: necesita config de VPC o API Gateway
   Lambda → servicio K8s: necesita VPC, NAT Gateway ($$$)
   → Solo el NAT Gateway puede costar $100+/mes

4. Dos modelos mentales para tu equipo
   "¿Dónde corre este código?"
   "¿Por qué esta Lambda hace timeout llamando a nuestro servicio K8s?"
   → Impuesto de context-switching para tus ingenieros

Mitigación: Usá un event bus (EventBridge, Kafka) como pegamento entre K8s y serverless. Esto desacopla los dos mundos y reduce la complejidad de networking.

El Comodín de 2026: Serverless Basado en Wasm

El desarrollo más emocionante es la aparición de WebAssembly como runtime serverless. Esto crea una tercera opción que combina lo mejor de ambos mundos.

Cómo Funciona

Cloud tradicional:
  Request → API Gateway → Cold Start Container → Ejecutar Código → Response
  Latencia: 100ms - 3000ms (cold) / 5ms - 50ms (warm)

Wasm Serverless:
  Request → Nodo Edge → Instanciar Wasm → Ejecutar Código → Response
  Latencia: <1ms (siempre a velocidad de cold-start)

Quién Lo Está Haciendo

La Promesa de Lo Mejor de Ambos Mundos

                    Kubernetes    Serverless    Wasm Serverless
                    ──────────    ──────────    ───────────────
Cold start          N/A           100ms-3s      <1ms
Vendor lock-in      Bajo          Alto          Bajo (Wasm es std)
Dev local           Fácil         Difícil       Fácil
Escalar a cero      Con KEDA      Nativo        Nativo
Duración máxima     Ilimitada     15 min        Variable (1-30min)
Stateful            Completo      No            Limitado
Costo a baja escala Alto          Muy bajo      Muy bajo
Costo a alta escala Moderado      Alto          Bajo
Portabilidad        Docker image  No            Componente Wasm
Soporte GPU         Sí            Limitado      No

La Misma Función en Tres Plataformas

// Este código Rust se compila a Wasm y corre en:
// - Fermyon Spin (serverless)
// - wasmCloud (orquestado, estilo K8s)
// - Cloudflare Workers (edge)
// - Tu laptop (wasmtime)
//
// UN binario. CERO vendor lock-in.

use spin_sdk::http::{IntoResponse, Request, Response};
use spin_sdk::http_component;

#[http_component]
fn handle_api(req: Request) -> anyhow::Result<impl IntoResponse> {
    match req.uri().path() {
        "/api/orders" => handle_orders(req),
        "/api/health" => Ok(Response::builder()
            .status(200)
            .body("ok")
            .build()),
        _ => Ok(Response::builder()
            .status(404)
            .body("not found")
            .build()),
    }
}

Este es el verdadero punto de inflexión. En 2024, tenías que elegir entre Kubernetes (portable pero complejo) y Serverless (simple pero con lock-in). En 2026, serverless basado en Wasm te da portabilidad Y simplicidad.

Errores Comunes (Y Cómo Evitarlos)

Error 1: "Necesitamos Kubernetes Porque Hacemos Microservicios"

No. Microservicios es un patrón organizacional, no una elección de deploy. Podés correr microservicios en serverless perfectamente, muchas empresas lo hacen.

Suposición común:
  Microservicios → Necesito orquestación de contenedores → Kubernetes

Realidad:
  Microservicios → Necesito deploy y escalado independiente
                → Puede ser pods K8s, funciones Lambda, o componentes Wasm

Error 2: "Serverless Es Siempre Más Barato"

Como mostramos en el análisis de costos, serverless es más barato solo a baja-media escala. Más allá de ~30-40M peticiones/mes, el costo por invocación más las fees ocultas hacen que sea más caro que un cluster Kubernetes bien utilizado.

La trampa de costos serverless:
Mes 1:   $50    (¡genial!)
Mes 3:   $200   (todavía bien)
Mes 6:   $800   (hmm)
Mes 12:  $3,500 (¿dónde quedó el ahorro?)

Qué pasó:
- El tráfico creció 10x (¡bien!)
- Los costos de API Gateway escalaron linealmente
- Los costos de logs de CloudWatch explotaron
- Agregaste VPC para acceso a base de datos (NAT Gateway: $100+/mes)
- Llegaste al límite de concurrencia (reserved concurrency: $$$)

Error 3: "Arranco con Kubernetes Para No Tener Que Migrar Después"

Esto es optimización prematura. Si sos un startup o equipo pequeño:

1. Todavía no sabés tus patrones de tráfico
2. No podés costear un ingeniero de plataforma
3. El time-to-market importa más que la elegancia de infraestructura
4. Migrar de serverless a K8s cuando realmente lo necesitás es un camino conocido

Timeline de un startup:
Día 1-180:    Sacar features (Serverless)
Día 180-365:  Encontrar product-market fit (todavía Serverless)
Día 365-730:  La escala toca los límites serverless (evaluar K8s)
Día 730+:     Migrar hot paths a K8s, mantener async en serverless

K8s prematuro:
Día 1-90:     Montar cluster K8s, CI/CD, monitorización (0 features)
Día 90-180:   Debuggear networking, aprender Helm (todavía 0 features)
Día 180-365:  Por fin sacar features (6 meses detrás del equipo serverless)

Error 4: "No Podemos Usar Serverless Por Los Cold Starts"

En 2026, esto es un problema mayormente resuelto:

Estrategias de mitigación de cold start:
─────────────────────────────────────────────────
1. Provisioned Concurrency (Lambda):
   Mantener N instancias calientes. Caro, pero sin cold starts.

2. Serverless basado en Wasm:
   Cold starts <1ms. Problema eliminado.

3. SnapStart (Java en Lambda):
   Snapshots de JVM inicializada. Cold starts ~200ms.

4. Response streaming:
   Enviar headers inmediatamente, streamear body.
   El usuario percibe respuesta instantánea.

5. Patrones arquitectónicos:
   Poner paths sensibles al cold start detrás de un caché.
   Usar connection pooling (RDS Proxy).
   Mantener las funciones pequeñas y enfocadas.

El Checklist de Decisión

Antes de tu próxima reunión de arquitectura, respondé estas 10 preguntas:

□  1. ¿Cuántos ingenieros tenés?
     Menos de 5: Serverless
     5-15: Cualquiera
     15+: Kubernetes

□  2. ¿Tenés equipo dedicado de plataforma/DevOps?
     Sí: Kubernetes es viable
     No: Serverless o K8s gestionado (GKE Autopilot)

□  3. ¿Cuál es tu patrón de tráfico?
     Estable: Kubernetes
     Picos/impredecible: Serverless

□  4. ¿Necesitás conexiones persistentes? (WebSocket, gRPC streaming)
     Sí: Kubernetes
     No: Cualquiera

□  5. ¿Cuánto duran tus procesos?
     < 15 minutos: Cualquiera
     > 15 minutos: Kubernetes

□  6. ¿Qué tan importante es la portabilidad de vendor?
     Crítica: Kubernetes o Wasm serverless
     No importa: Serverless tradicional está bien

□  7. ¿Cuál es tu volumen mensual de peticiones?
     < 30M: Serverless probablemente es más barato
     > 30M: Hacé el análisis de costos

□  8. ¿Necesitás acceso a GPU?
     Sí: Kubernetes
     No: Cualquiera

□  9. ¿Tenés requisitos de compliance? (residencia de datos, etc.)
     Estrictos: Kubernetes (más control)
     Estándar: Cualquiera

□  10. ¿Cuál es tu prioridad?
     Sacar rápido: Serverless
     Control total: Kubernetes
     Ambos: Híbrido o Wasm serverless

Qué Viene

2026 Q1-Q2 (Ahora)

• ✅ EKS Auto Mode disponibilidad general
• ✅ Fermyon Spin 3.5 con WASI P3 y soporte HTTP/2
• ✅ KEDA 2.19 con triggers de escalado ampliados
• 🔄 AWS Lambda Wasm runtime en preview

2026 Q3-Q4

• GKE integrando cargas Wasm nativamente
• Convergencia Serverless-Kubernetes
• Componente Model habilitando composición cross-platform

2027 y Más Allá

• Serverless basado en Wasm se vuelve mainstream
• La complejidad de Kubernetes se oculta detrás de mejores abstracciones
• La pregunta "K8s vs Serverless" se vuelve irrelevante, todo es solo "cómputo"

Conclusión

El debate Kubernetes vs Serverless en 2026 no es sobre qué tecnología es mejor. Es sobre qué trade-offs podés aceptar.

Elegí Kubernetes cuando:

• Tenés el equipo para soportarlo (o usás GKE Autopilot/EKS Auto Mode)
• Necesitás control total sobre networking, runtime y escalado
• Tus cargas de trabajo son estables, stateful o de larga duración
• Estás a escala (30M+ peticiones/mes)
• La portabilidad de vendor importa

Elegí Serverless cuando:

• Sos un equipo chico que necesita sacar cosas rápido
• Tus cargas son event-driven y con picos
• El costo a baja escala importa más que a alta escala
• Podés aceptar vendor lock-in
• No necesitás conexiones persistentes

Elegí Wasm Serverless cuando:

• Querés la simplicidad de serverless con cold starts casi cero
• La portabilidad importa pero no querés la complejidad de K8s
• Estás construyendo en el edge
• Es un proyecto nuevo en 2026 y Rust/Go está en tu stack

Elegí Híbrido cuando:

• Tenés tanto cargas estables como con picos
• Querés optimizar costos por tipo de carga
• Tu equipo es lo suficientemente grande para gestionar ambos

La mejor decisión de infraestructura es la que permite a tu equipo enfocarse en construir el producto. No dejes que la infraestructura se convierta en el producto.

La pregunta real no es "¿Kubernetes o Serverless?". Es "¿Qué nos permite entregar valor más rápido mientras seguimos pudiendo dormir de noche?"