3. Trade-offs por Estrategia de Deployment

Descripción

En esta cápsula vas a evaluar cada estrategia de deployment en cinco dimensiones concretas: coste, complejidad operativa, escalabilidad, control y time-to-deploy. No como opiniones cualitativas ("Lambda escala bien") sino con métricas y números que puedes usar para comparar. Al terminar, tendrás una tabla de evaluación cuantitativa que alimenta directamente la decision matrix del proyecto.

Contexto: La cápsula anterior presentó las 4 categorías. Ahora las evalúas con rigor. La diferencia entre "sé qué existe" y "sé cuándo elegir cada una" es la capacidad de medir trade-offs. Esta cápsula te da esa capacidad.

Las 5 Dimensiones de Evaluación

Por qué 5 dimensiones

Los frameworks de decisión que usan una sola dimensión ("¿cuál es más barato?") producen decisiones malas. Una estrategia barata pero que no escala, o una que escala pero tarda semanas en deployar, no sirve si tus constraints incluyen crecimiento rápido o time-to-market.

Las 5 dimensiones capturan los factores que más impactan decisiones de deployment para AI:

La trampa del "lo quiero todo"

No puedes maximizar las 5 dimensiones simultáneamente. Si quieres máximo control (self-hosted), pagas con complejidad y time-to-deploy. Si quieres mínimo time-to-deploy (managed), sacrificas control. La ingeniería de deployment es gestión de trade-offs, no búsqueda de perfección.

        Coste bajo ←──────────→ Control alto
                     \        /
                      \      /
         TRADE-OFF     \    /     TRADE-OFF
          ZONE          \  /       ZONE
                         \/
              Simplicidad vs Flexibilidad

Dimensión 1: Coste

Modelos de pricing

Cada estrategia tiene un modelo de pricing fundamentalmente diferente:

# Modelo de coste simplificado por estrategia
def cost_local(monthly_vps_price: float, traffic: int) -> float:
    """Coste fijo. No importa si tienes 100 o 10K requests."""
    return monthly_vps_price  # $12-48/mes típico

def cost_serverless(invocations: int, avg_duration_ms: int, memory_mb: int) -> float:
    """Pay-per-use. Escala linealmente con el tráfico."""
    price_per_gb_second = 0.0000166667  # AWS Lambda pricing
    gb_seconds = (invocations * avg_duration_ms / 1000) * (memory_mb / 1024)
    request_cost = invocations * 0.0000002  # $0.20 per 1M requests
    return gb_seconds * price_per_gb_second + request_cost

def cost_managed(plan_price: float, add_ons: float = 0) -> float:
    """Pricing escalonado. Precio fijo por plan + add-ons."""
    return plan_price + add_ons  # $0 (free) a $25-100/mes

def cost_selfhosted(instances: int, instance_price: float, ops_hours: float, ops_rate: float) -> float:
    """Coste de infra + coste de equipo que la gestiona."""
    return (instances * instance_price) + (ops_hours * ops_rate)

Números reales para AI workloads

Escenario: App AI con FastAPI que invoca GPT-4o-mini, 10K requests/día, duración promedio 2 segundos.

Monthly requests: 300K

LOCAL (DigitalOcean Droplet 4GB):
  VPS:           $24/mes
  Total:         $24/mes
  Nota:          Tráfico ilimitado, coste fijo

SERVERLESS (AWS Lambda 512MB):
  GB-seconds:    300K × 2s × 0.5GB = 300K GB-s
  Compute:       300K × $0.0000166667 = $5.00
  Requests:      300K × $0.0000002 = $0.06
  Total:         ~$5/mes
  Nota:          Muy barato a este volumen

MANAGED (Railway Pro):
  Plan:          $5/mes + $0.000463/vCPU-min
  Estimado:      ~$15-25/mes
  Nota:          Pricing predecible, incluye SSL/dominio

SELF-HOSTED (EC2 t3.medium):
  Instance:      $30/mes (on-demand)
  Ops time:      4 hrs/mes × $50/hr = $200/mes
  Total:         ~$230/mes
  Nota:          El coste real es el tiempo de tu equipo

Insight clave: A 10K req/día, serverless es el más barato en infraestructura. Pero si incluyes el coste de tiempo de debugging de Lambda (cold starts, timeout issues), la ecuación cambia.

Cuándo el coste se invierte

Punto de inflexión (Lambda vs VPS):

A 10K req/día:     Lambda $5   vs VPS $24    → Lambda gana
A 100K req/día:    Lambda $50  vs VPS $24    → VPS gana
A 1M req/día:      Lambda $500 vs VPS $48    → VPS gana por mucho

Conclusión: Serverless es barato para tráfico bajo/variable.
Para tráfico alto y constante, coste fijo gana.

Dimensión 2: Complejidad Operativa

Qué incluye "operativa"

Complejidad operativa no es solo setup inicial. Es el esfuerzo continuo de mantener tu sistema corriendo en producción:

• Actualizar dependencias y patches de seguridad
• Diagnosticar y resolver incidencias
• Monitorear health y performance
• Gestionar secrets y credenciales
• Backup y disaster recovery
• Scaling manual (si aplica)

Complejidad por estrategia

LOCAL:
  Setup:           ████████░░ (8/10) — Docker Compose, networking, SSL
  Mantenimiento:   ██████░░░░ (6/10) — Updates del OS, Docker, dependencias
  Debugging:       ████░░░░░░ (4/10) — Acceso directo a logs y containers
  Total semanal:   2-4 hrs/semana

SERVERLESS:
  Setup:           ████░░░░░░ (4/10) — Lambda + API Gateway config
  Mantenimiento:   ██░░░░░░░░ (2/10) — AWS gestiona infra
  Debugging:       ████████░░ (8/10) — CloudWatch logs, distributed tracing
  Total semanal:   1-2 hrs/semana (si todo va bien), 5-10 hrs (si algo falla)

MANAGED:
  Setup:           ██░░░░░░░░ (2/10) — Git push y env vars
  Mantenimiento:   ██░░░░░░░░ (2/10) — La plataforma gestiona casi todo
  Debugging:       ██████░░░░ (6/10) — Logs disponibles pero limitados
  Total semanal:   0.5-1 hrs/semana

SELF-HOSTED:
  Setup:           ██████████ (10/10) — Todo: OS, networking, security, monitoring
  Mantenimiento:   ████████░░ (8/10) — Patches, scaling, backups, on-call
  Debugging:       ██░░░░░░░░ (2/10) — Acceso total, SSH directo
  Total semanal:   5-15 hrs/semana

La paradoja de serverless

Serverless tiene la complejidad operativa más baja cuando todo funciona. Pero cuando algo falla (cold starts inesperados, timeout en una prompt chain, memory leak en una invocación), debuggear Lambda es significativamente más difícil que debuggear un container Docker al que puedes hacer exec.

Serverless debugging flow:
1. User reporta error
2. Buscas en CloudWatch logs (interfaz no ideal)
3. Identificas la invocación que falló
4. No puedes reproducir localmente (entorno diferente)
5. Despliegos fix, esperas cold start, pruebas
6. Total: 30min-2hrs por incidencia

Local debugging flow:
1. User reporta error
2. docker compose logs api | grep ERROR
3. docker compose exec api python -c "reproduce_bug()"
4. Fixes, rebuild, test
5. Total: 5-30min por incidencia

Dimensión 3: Escalabilidad

Tipos de escalamiento

Vertical scaling:   Más CPU/RAM al mismo servidor
                    Simple pero tiene límite físico
                    Ej: DigitalOcean 4GB → 8GB → 16GB

Horizontal scaling: Más instancias del mismo servicio
                    Complejo pero sin límite teórico
                    Ej: 1 container → 3 containers → 10 containers

Auto-scaling:       El sistema escala automáticamente según demanda
                    Requiere configuración, no es mágico
                    Ej: Lambda, Cloud Run, Kubernetes HPA

Escalabilidad por estrategia

AI-specific: ¿Cuánta escala necesitas realmente?

Un error común es sobre-dimensionar la escalabilidad. Pregúntate:

# Cálculo de capacidad necesaria
daily_requests = 10_000
peak_multiplier = 3  # Pico = 3x el promedio
hours_of_peak = 4    # Las 4 horas de más tráfico

peak_requests_per_second = (daily_requests * peak_multiplier) / (hours_of_peak * 3600)
# = 30,000 / 14,400 = ~2 requests/segundo en pico

# Un solo container FastAPI con uvicorn maneja ~100-500 req/s
# Conclusión: 10K req/día NO necesita auto-scaling

Si tu app AI atiende 10K requests/día, un solo container es suficiente. No necesitas Lambda ni Kubernetes. Antes de optimizar escalabilidad, verifica que realmente la necesitas.

Dimensión 4: Control

Qué significa "control" en deployment

Control es tu capacidad de acceder, configurar y modificar cada capa del stack:

Nivel de control por capa:

                    Local  Serverless  Managed  Self-hosted
Hardware           ──────  ──────────  ───────  ──────────
  Acceso físico      No       No         No       Sí*
  GPU selection      No       No         No       Sí

OS / Runtime       ──────  ──────────  ───────  ──────────
  Elegir OS          Sí       No         No       Sí
  System packages    Sí       Limitado   No       Sí
  Python version     Sí       Parcial    Sí       Sí

Networking         ──────  ──────────  ───────  ──────────
  Puertos custom     Sí       No         Parcial  Sí
  Firewall rules     Sí       Parcial    No       Sí
  VPN/VPC            Sí       Sí (AWS)   No       Sí

Application        ──────  ──────────  ───────  ──────────
  Code              Sí       Sí         Sí       Sí
  Config            Sí       Sí         Sí       Sí
  Secrets           Sí       Sí         Sí       Sí

* Self-hosted con bare metal

Cuándo necesitas control alto

• Modelos custom en GPU: Necesitas elegir tipo de GPU, instalar CUDA drivers, optimizar memory
• Compliance regulatorio: Controlar exactamente dónde están los datos, quién accede
• Performance tuning: Configurar kernel params, network buffers, caching layers
• Debugging profundo: SSH al servidor, strace, tcpdump, profiling

Cuándo el control es un overhead innecesario

Para la mayoría de apps AI que llaman APIs externas (OpenAI, Anthropic), no necesitas control del OS ni del hardware. Tu app es un proxy inteligente: recibe request, construye prompt, llama a LLM API, retorna respuesta. Para esto, managed platforms dan control suficiente.

Dimensión 5: Time-to-Deploy

De commit a producción

LOCAL (Docker Compose en VPS):
  git push → SSH → docker compose pull → docker compose up
  Tiempo: 5-15 min (con CI/CD: 3-8 min)
  Setup inicial: 2-4 horas (VPS, Docker, dominio, SSL)

SERVERLESS (Lambda):
  git push → GitHub Actions → deploy Lambda → actualizar API Gateway
  Tiempo: 2-5 min (con CI/CD)
  Setup inicial: 1-3 horas (Lambda, Gateway, IAM, permisos)

MANAGED (Railway/Render):
  git push → auto-build → auto-deploy
  Tiempo: 1-3 min
  Setup inicial: 15-30 min (conectar repo, env vars, dominio)

SELF-HOSTED (EC2 + K8s):
  git push → CI/CD → build image → push to registry → rolling update
  Tiempo: 5-20 min
  Setup inicial: 1-5 días (infra, K8s, networking, monitoring)

Time-to-deploy importa más de lo que crees

En AI development, iteración rápida es crítica. Estás ajustando prompts, cambiando modelos, tuneando parámetros. Si cada deploy tarda 20 minutos, haces 3 deploys/día. Si tarda 2 minutos, haces 20+. La velocidad de iteración impacta directamente la calidad de tu sistema AI.

Tabla de Evaluación Cuantitativa

Scoring: 1 (peor) a 5 (mejor) por dimensión

*Serverless coste: 5 a bajo volumen, 2 a alto volumen

¿Serverless gana? Solo si todas las dimensiones tienen el mismo peso. En tu caso, quizás el control pesa más (porque tienes datos sensibles), o el coste pesa menos (porque tu empresa paga). La decision matrix del proyecto permite asignar pesos por dimensión.

Ejemplo concreto: Scoring ponderado paso a paso

Supongamos que tu app es un chatbot AI con streaming para un equipo de 100 personas. Tus prioridades:

weights = {
    "Coste":           20,  # Presupuesto limitado pero no extremo
    "Complejidad":     25,  # Solo 1 developer, complejidad es key
    "Escalabilidad":   10,  # 100 usuarios, no necesitas auto-scale
    "Control":         15,  # Datos internos, prefiero controlar
    "Time-to-deploy":  30,  # Necesito estar online esta semana
}

scores = {
    #                    Local  Serverless  Managed  Self-hosted
    "Coste":           [  4,      5,          4,        1  ],
    "Complejidad":     [  3,      4,          5,        1  ],
    "Escalabilidad":   [  2,      5,          3,        4  ],
    "Control":         [  4,      2,          3,        5  ],
    "Time-to-deploy":  [  3,      4,          5,        1  ],
}

options = ["Local", "Serverless", "Managed", "Self-hosted"]
totals = {opt: 0 for opt in options}

for dim, weight in weights.items():
    for i, opt in enumerate(options):
        totals[opt] += weight * scores[dim][i]

for opt in sorted(totals, key=totals.get, reverse=True):
    print(f"{opt:15} → {totals[opt]:>4} / 500")

# Output:
# Managed         →  430 / 500   ← GANADOR
# Serverless      →  405 / 500
# Local           →  320 / 500
# Self-hosted     →  175 / 500

Pero espera — este chatbot necesita streaming. Lambda no soporta streaming nativo. Aunque Serverless tiene buen score numérico, tiene un deal-breaker funcional. El scoring te da el ranking; tú aplicas el juicio.

Resultado final: Managed (Railway) gana por score Y por funcionalidad (soporta WebSockets). Serverless queda descartado por deal-breaker, no por score.

Comparación: Trade-offs AI-specific

Cold starts y latencia de inferencia

Memory para modelos AI

Latencia de inferencia por estrategia

La latencia de inferencia — el tiempo desde que el usuario envía un prompt hasta que recibe la respuesta — depende de múltiples factores. Pero la estrategia de deployment añade latencia base:

# Desglose de latencia total para una request AI típica

latency_breakdown = {
    "local": {
        "network_to_server": "1-50ms",
        "cold_start": "0ms (siempre running)",
        "app_processing": "10-50ms",
        "llm_api_call": "500-3000ms",
        "total_typical": "600-3100ms",
    },
    "serverless": {
        "network_to_api_gw": "10-50ms",
        "cold_start": "1000-15000ms (primera request)",
        "app_processing": "10-50ms",
        "llm_api_call": "500-3000ms",
        "total_cold": "1600-18000ms",   # Inaceptable para chat
        "total_warm": "600-3100ms",      # Comparable a local
    },
    "managed": {
        "network_to_platform": "10-100ms",
        "cold_start": "0ms (plan pago) o 30000ms (free tier sleep)",
        "app_processing": "10-50ms",
        "llm_api_call": "500-3000ms",
        "total_typical": "600-3200ms",
    },
    "self_hosted": {
        "network_to_server": "1-50ms",
        "cold_start": "0ms (siempre running)",
        "app_processing": "10-50ms",
        "llm_api_call": "500-3000ms (o 50-500ms con modelo local)",
        "total_api": "600-3100ms",
        "total_local_model": "100-600ms",  # Ventaja con modelo propio
    },
}

Insight clave: Para apps que llaman a LLM APIs externas (OpenAI, Anthropic), la latencia del LLM domina (500-3000ms). La diferencia entre estrategias (0-100ms extra) es marginal. El cold start de serverless es la excepción — esos 1-15 segundos adicionales sí se notan.

Para apps con modelos locales (Llama, Mistral en GPU), self-hosted gana en latencia total porque elimina la llamada de red al LLM.

Troubleshooting

Problema 1: "No sé qué dimensión priorizar"

Solución: Empieza por la constraint más dura. Si tu presupuesto es <$20/mes, eso elimina self-hosted y restringe managed. Si necesitas <500ms de latencia, eso complica serverless. La constraint más restrictiva reduce opciones rápido.

Problema 2: "Todas las estrategias parecen viables"

Solución: Buena señal — significa que tu caso no tiene constraints extremas. Elige por time-to-deploy: empieza con la que te pone en producción más rápido (probablemente managed), y re-evalúa cuando alcances el límite de esa estrategia.

Problema 3: "Mi evaluación cambió después de implementar"

Solución: Normal. La evaluación pre-implementación es estimación. Después de implementar, tienes datos reales. Actualiza tu evaluación y decision matrix con datos reales — es una herramienta viva, no un documento estático.

Problema 4: "Los pesos de mi evaluación se sienten arbitrarios"

Solución: Usa la técnica de "eliminación forzada." Si solo pudieras optimizar UNA dimensión, ¿cuál sería? Esa recibe peso 30-40. Luego de las restantes, ¿cuál sacrificarías primero? Esa recibe peso 5-10. Trabaja de los extremos hacia el centro para que los pesos reflejen preferencias reales, no números inventados.

Problema 5: "Necesito explicar estos trade-offs a alguien no-técnico"

Solución: Simplifica a 3 dimensiones: dinero, esfuerzo, rapidez. "Serverless cuesta menos pero es más lento al inicio. Managed es el más rápido pero tenemos menos control. Self-hosted nos da control total pero es el más caro en tiempo del equipo." Tres frases, sin jerga.

Ejercicios Prácticos

Ejercicio 1: Evaluación cuantitativa de tu caso

Usando la tabla de scoring (1-5), evalúa cada estrategia para TU app AI. Agrega pesos a cada dimensión según tus prioridades.

Pesos (suman 100):
- Coste: 30 (constraint principal)
- Complejidad: 25 (equipo de 1 persona)
- Escalabilidad: 10 (no espero mucho tráfico aún)
- Control: 15 (datos internos pero no regulados)
- Time-to-deploy: 20 (necesito iterar rápido)

Evaluación ponderada:
                  Local  Serverless  Managed  Self-hosted
Coste (×30):      120      150        90        30
Complejidad(×25): 75       100        125       25
Escalab.(×10):    20       50         30        40
Control(×15):     60       30         45        75
Time-to(×20):     60       80         100       20
TOTAL:            335      410        390       190

Recomendación: Serverless (410) > Managed (390) > Local (335) > Self-hosted (190)

Ejercicio 2: Encuentra el punto de inflexión

Para cada par de estrategias, identifica el punto donde una se vuelve mejor que la otra:

1. Serverless vs Local: ¿a cuántos requests/mes Lambda es más caro que un VPS?
2. Managed vs Self-hosted: ¿a qué escala managed platforms se quedan cortas?

Lambda (512MB, 2s promedio):
  Coste por request: ~$0.0000167 + $0.0000002 = ~$0.000017
  Break-even vs VPS $24/mes: $24 / $0.000017 = ~1.4M requests/mes

  A <1.4M req/mes: Lambda más barato
  A >1.4M req/mes: VPS más barato

Railway Pro: ~$20-100/mes, pero limits de memoria (8GB max)
Si tu app necesita >8GB RAM (embeddings locales, modelos en memoria):
  → Managed se queda corto
  → Self-hosted con EC2 16GB o 32GB es necesario

También: si necesitas >100 concurrent connections constantes,
managed platforms pueden throttlear.

Ejercicio 3: Worst-case scenario

Para cada estrategia, describe el peor escenario y cómo mitigarlo:

Ejercicio 4: Calcula la latencia total

Tu app RAG tiene: (a) network latency de 30ms, (b) app processing de 40ms, (c) embedding search de 100ms, (d) LLM API call de 1500ms promedio. Calcula la latencia total para cada estrategia, considerando cold starts.

base_latency = 30 + 40 + 100 + 1500  # = 1670ms

latency_by_strategy = {
    "Local":       f"{base_latency}ms (sin cold start)",
    "Serverless":  f"{base_latency + 5000}ms cold / {base_latency}ms warm",
    "Managed":     f"{base_latency + 50}ms (plan pago, sin sleep)",
    "Self-hosted": f"{base_latency}ms (sin cold start)",
}

# Local:       1670ms — consistente
# Serverless:  6670ms cold / 1670ms warm — primer request problemático
# Managed:     1720ms — marginal overhead de routing
# Self-hosted: 1670ms — consistente

# Insight: El LLM API call (1500ms) domina.
# Solo serverless cold start cambia la experiencia del usuario.

Ejercicio 5: Pitch de 1 minuto

Prepara un pitch de 1 minuto explicando a tu equipo por qué elegiste la estrategia X para tu app AI. Incluye: qué evaluaste, qué descartaste, y cuándo re-evaluar.

Resumen

• Las 5 dimensiones (coste, complejidad, escalabilidad, control, time-to-deploy) te dan un framework cuantitativo para evaluar estrategias.
• Coste varía dramáticamente: serverless es barato a bajo volumen, caro a alto volumen. Local tiene coste fijo. Self-hosted incluye coste de equipo.
• Complejidad operativa es la dimensión más subestimada. Managed platforms la minimizan; self-hosted la maximiza.
• Escalabilidad es la dimensión más sobre-valorada. La mayoría de apps AI no necesitan auto-scaling — verifica tu tráfico real antes de optimizar.
• Control importa cuando tienes constraints de compliance, GPUs, o debugging profundo. Para APIs que llaman a LLMs, es menos crítico.
• Time-to-deploy impacta tu velocidad de iteración. En AI development, iterar rápido = mejor sistema.
• Los pesos cambian todo. Una evaluación sin pesos es una opinión disfrazada de framework.

Recursos Adicionales

1. AWS Pricing Calculator — Estima costes de servicios AWS
2. Cloud Cost Handbook — Referencia de costes cloud por servicio
3. Vantage Cost Reports — Herramienta de monitoreo de costes cloud
4. The Pragmatic Engineer — Platform Teams — Blog sobre decisiones de infraestructura
5. InfoQ — Cloud Architecture — Artículos sobre arquitectura cloud
6. Railway Pricing — Pricing detallado de Railway