2. Landscape de Deployment Options

Descripción

En esta cápsula vas a explorar en profundidad las cuatro categorías de deployment para sistemas AI: Local, Serverless, Managed y Self-hosted. No como conceptos abstractos — con ejemplos concretos de cómo cada categoría se aplica a una app AI real. Al terminar, podrás explicar a un colega cuándo y por qué elegir cada una.

Contexto: La cápsula anterior presentó las 4 categorías como overview. Aquí profundizas en cada una: qué incluye, qué tecnologías la representan, cómo se ve en la práctica, y — crucialmente — qué tipo de sistema AI encaja mejor en cada categoría. Esto no es un catálogo de servicios cloud; es un framework de pensamiento.

Local Deployment

Qué es

Deployment local significa que tu aplicación corre en infraestructura que tú controlas directamente: tu laptop, un servidor en tu oficina, o un VPS (Virtual Private Server) que alquilas. Tú gestionas el sistema operativo, las dependencias, el networking, y el ciclo de vida de la aplicación.

En el contexto de esta guía, "local" se refiere principalmente a Docker Compose multi-container: tu app AI, Redis, una base de datos, todo corriendo en containers orquestados localmente. El Módulo 2 profundiza en esto.

Tecnologías representativas

Local Deployment Stack:
├── Docker + Docker Compose     → Orquestación de containers
├── VPS (DigitalOcean, Linode)  → Infraestructura alquilada
├── Nginx/Caddy                 → Reverse proxy y SSL
├── systemd                     → Process management
└── SSH                         → Acceso remoto

Ejemplo AI-specific

Imagina una app RAG (Retrieval Augmented Generation) para un equipo interno de 20 personas:

# docker-compose.yml — App RAG local
services:
  api:
    build: ./api
    ports:
      - "8000:8000"
    environment:
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - REDIS_URL=redis://cache:6379
    depends_on:
      cache:
        condition: service_healthy

  cache:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 3

  embeddings:
    build: ./embeddings-service
    volumes:
      - ./data/vectors:/app/vectors

Cuándo elegir Local

Perfil rápido

Coste:        Bajo-Medio (VPS ~$5-40/mes fijo)
Complejidad:  Media (tú gestionas infra)
Escalabilidad: Baja (manual, vertical)
Control:      Alto (acceso total)
Time-to-deploy: Medio (setup inicial, luego rápido)

AI use cases comunes en Local

Serverless Deployment

Qué es

Serverless significa que no gestionas servidores. Subes tu código (como una función o container), y el cloud provider se encarga de ejecutarlo, escalarlo, y cobrarte solo por el tiempo de ejecución. "Serverless" no significa "sin servidores" — significa que los servidores no son tu problema.

La implementación más conocida es AWS Lambda, que ejecuta funciones en respuesta a eventos (HTTP requests, mensajes en cola, cambios en S3). El Módulo 3 profundiza en Lambda para AI.

Tecnologías representativas

Serverless Stack:
├── AWS Lambda               → Funciones serverless
├── API Gateway              → HTTP trigger para Lambda
├── Google Cloud Functions   → Alternativa a Lambda
├── Azure Functions          → Alternativa Microsoft
├── Vercel Functions         → Serverless para frontend
└── AWS Fargate              → Containers serverless (sin gestionar EC2)

Ejemplo AI-specific

Un endpoint que recibe un prompt y retorna la respuesta de un LLM:

# lambda_handler.py — Endpoint AI serverless
import json
import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

def handler(event, context):
    """Lambda que invoca un LLM y retorna la respuesta."""
    body = json.loads(event.get("body", "{}"))
    prompt = body.get("prompt", "")

    if not prompt:
        return {
            "statusCode": 400,
            "body": json.dumps({"error": "prompt is required"})
        }

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=500,
        timeout=25  # Lambda timeout awareness
    )

    return {
        "statusCode": 200,
        "body": json.dumps({
            "answer": response.choices[0].message.content,
            "model": "gpt-4o-mini",
            "tokens": response.usage.total_tokens
        })
    }

Cuándo elegir Serverless

Cold starts: el elefante en la habitación

Para AI, cold starts son el factor más importante de serverless. Cuando Lambda no ha ejecutado tu función recientemente, necesita:

1. Provisionar un container
2. Descargar tu código y dependencias
3. Inicializar el runtime de Python
4. Importar librerías (openai, langchain, numpy)

Cold start típico por tipo de función:
├── "Hello World" en Python:     ~200-500ms
├── API call a OpenAI:           ~1-3s (imports)
├── LangChain + embeddings:      ~5-10s (heavy imports)
└── Modelo ML en memoria:        ~10-30s (carga de modelo)

Para una API de chat, 1-3 segundos de cold start pueden ser aceptables. Para un servicio que necesita <200ms de latencia, no lo es.

Perfil rápido

Coste:        Variable (pay-per-invocation, puede ser muy bajo o muy alto)
Complejidad:  Baja-Media (no gestionas infra, pero debugging es diferente)
Escalabilidad: Muy Alta (automática, de 0 a miles)
Control:      Bajo (no controlas el runtime, memory limits, timeouts)
Time-to-deploy: Rápido (deploy en minutos)

AI use cases comunes en Serverless

Anti-patrón: Cargar modelos ML en memoria dentro de Lambda. Cada cold start recarga el modelo, la latencia es inaceptable, y pagas por el tiempo de carga. Si necesitas modelos en memoria, usa containers.

Managed Platforms

Qué es

Managed platforms (también llamadas PaaS — Platform as a Service) son servicios que abstraen la infraestructura y te permiten desplegar desde Git con mínima configuración. Tú subes tu código o Dockerfile, la plataforma buildea, despliega, gestiona SSL, dominios, y scaling básico.

Las opciones más relevantes en 2026 son Render, Railway y Fly.io. El Módulo 7 profundiza en estas tres.

Tecnologías representativas

Managed Platforms:
├── Render          → Deploy desde Git, free tier, databases incluidas
├── Railway         → Developer experience premium, add-ons
├── Fly.io          → Edge deployment, múltiples regiones
├── Heroku          → El OG, más caro, menos innovación reciente
├── Google Cloud Run → Containers managed, pay-per-use
└── AWS App Runner  → AWS version de managed containers

Ejemplo AI-specific

Desplegar tu app FastAPI + AI en Railway:

# railway.json — Config mínima
{
  "build": {
    "builder": "DOCKERFILE"
  },
  "deploy": {
    "startCommand": "uvicorn main:app --host 0.0.0.0 --port $PORT",
    "healthcheckPath": "/health",
    "restartPolicyType": "ON_FAILURE"
  }
}

# main.py — App AI desplegable en cualquier managed platform
from fastapi import FastAPI
from openai import OpenAI
import os

app = FastAPI()
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

@app.get("/health")
def health():
    return {"status": "healthy", "service": "ai-api"}

@app.post("/ask")
def ask(prompt: str):
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=500
    )
    return {"answer": response.choices[0].message.content}

# Deploy en Railway (desde terminal)
railway login
railway init
railway up

# En 2-3 minutos: https://tu-app.railway.app/health

Cuándo elegir Managed

Perfil rápido

Coste:        Medio (free tiers generosos, $5-50/mes para producción)
Complejidad:  Baja (deploy desde Git, mínima config)
Escalabilidad: Media (auto-scale limitado, vertical más que horizontal)
Control:      Medio (configuras tu app, no la infra subyacente)
Time-to-deploy: Muy Rápido (minutos desde git push)

AI use cases comunes en Managed

Consideración AI: Verifica los limits de memoria del plan. ChromaDB con 500K documentos necesita ~2-4GB de RAM. Si tu plan managed ofrece 512MB, no cabe. Revisa antes de elegir.

Self-hosted Deployment

Qué es

Self-hosted significa que tú gestionas la infraestructura completa: servidores (físicos o VMs en cloud), sistema operativo, networking, seguridad, scaling, backups, y todo lo demás. Es el máximo control a cambio de la máxima responsabilidad operativa.

En la práctica, self-hosted para AI suele significar EC2 instances en AWS (o equivalente en GCP/Azure) donde tú instalas y configuras todo. Empresas grandes con equipos de DevOps/SRE operan así.

Tecnologías representativas

Self-hosted Stack:
├── EC2/GCE/Azure VMs     → Compute
├── Kubernetes (EKS/GKE)  → Orquestación (avanzado)
├── Terraform/Pulumi       → Infrastructure as Code
├── Ansible/Chef           → Configuration management
├── Prometheus/Grafana     → Monitoring
└── Nginx/HAProxy          → Load balancing

Ejemplo AI-specific

Un sistema AI enterprise que necesita GPUs para inferencia local de modelos propios:

Arquitectura self-hosted para AI:
┌─────────────────────────────────┐
│  Load Balancer (Nginx)          │
├─────────────────────────────────┤
│  App Server 1    App Server 2   │  ← EC2 instances
│  (FastAPI)       (FastAPI)      │
├─────────────────────────────────┤
│  GPU Instance (p3.2xlarge)      │  ← Para inferencia
│  (Modelo custom, embeddings)    │
├─────────────────────────────────┤
│  Redis Cluster   PostgreSQL     │
│  (Cache)         (Data)         │
└─────────────────────────────────┘

Cuándo elegir Self-hosted

Perfil rápido

Coste:        Alto (VMs, networking, equipo de ops)
Complejidad:  Muy Alta (tú gestionas TODO)
Escalabilidad: Alta (horizontal con load balancers, pero manual o con K8s)
Control:      Máximo (acceso a todo: OS, networking, hardware)
Time-to-deploy: Lento (setup inicial puede tomar días/semanas)

Comparación: Las 4 Categorías

Tabla resumen

Dimensiones AI-specific por categoría

Diagrama de decisión rápido

¿Necesitas GPUs para modelos propios?
├── SÍ → Self-hosted (EC2 con GPU)
└── NO → ¿Tu tráfico es impredecible (picos)?
          ├── SÍ → Serverless (Lambda)
          └── NO → ¿Necesitas estar online en <1 hora?
                    ├── SÍ → Managed (Render/Railway)
                    └── NO → ¿Tienes equipo de ops?
                              ├── SÍ → Self-hosted o Local
                              └── NO → Local (dev) + Managed (prod)

Troubleshooting

Problema 1: "No sé qué categoría aplica a mi caso"

Síntoma: Evalúas las 4 categorías y todas parecen viables o ninguna parece clara.

Solución: Empieza por los deal-breakers. Responde estas 3 preguntas:

1. ¿Necesitas streaming (token-by-token)? → Si sí, descarta Serverless
2. ¿Necesitas modelos en memoria (>4GB RAM)? → Si sí, descarta Serverless y Managed free
3. ¿Tu presupuesto es <$30/mes? → Si sí, descarta Self-hosted

Con 1-2 opciones eliminadas, la decisión es más simple.

Problema 2: "Serverless parece barato pero mi app AI no encaja"

Síntoma: Lambda es atractivo por coste pero tu app tiene dependencias pesadas, necesita state, o las invocaciones son largas.

Solución: Serverless funciona para AI cuando la función es ligera y stateless (API wrapper sobre LLM). No funciona cuando necesitas embeddings en memoria, procesamiento >15 min, o streaming. En ese caso, evalúa Managed o Local.

Lambda funciona:    prompt → LLM API → response (2-5s, stateless)
Lambda NO funciona: query → cargar embeddings → buscar → LLM → stream response

Problema 3: "Managed platforms parecen limitadas"

Síntoma: Railway/Render parecen "demasiado simples" para un proyecto serio.

Solución: Render y Railway sirven producción real con SLAs. El límite es cuando necesitas servicios específicos de AWS (SageMaker, Lambda@Edge) o compliance enterprise. Para el 80% de startups y proyectos, managed platforms son producción legítima.

Problema 4: "Self-hosted parece más seguro por defecto"

Síntoma: Asumes que controlar la infraestructura = mayor seguridad.

Solución: Self-hosted te da control, pero también la responsabilidad de parchear vulnerabilidades, configurar firewalls, gestionar certificados SSL, y rotar secrets. Un managed platform con equipo de seguridad dedicado puede ser más seguro que tu VPS sin actualizar. Seguridad no es control — es disciplina operativa.

Problema 5: "Mi app AI necesita GPU pero no quiero gestionar infra"

Síntoma: Necesitas correr modelos locales (Llama, Mistral) pero self-hosted es demasiado overhead.

Solución: Evalúa servicios de GPU managed: Replicate, Modal, RunPod. No son las 4 categorías clásicas, sino un híbrido. Alternativamente, usa APIs de modelos (OpenAI, Anthropic) y elimina el requerimiento de GPU completamente — esto es lo que el 90% de apps AI hacen en la práctica.

Ejercicios Prácticos

Ejercicio 1: Clasifica estos escenarios

Para cada escenario, identifica la categoría de deployment más apropiada y justifica:

1. Chatbot AI para soporte interno de empresa (50 empleados, datos sensibles)
2. API de generación de imágenes con DALL-E para una startup (tráfico creciente)
3. Sistema RAG para buscar en documentación técnica (uso interno, 200 usuarios)
4. Servicio de transcripción de audio que procesa archivos subidos por usuarios

Ejercicio 2: Perfil de tu app

Toma una app AI que hayas construido (o la del bootcamp/guía anterior) y documenta:

1. ¿Qué tipo de tráfico tiene? (constante, variable, picos)
2. ¿Cuántos usuarios esperas? (10, 100, 1000, 10K+)
3. ¿Necesitas GPUs?
4. ¿Hay constraints de datos (compliance, on-premises)?
5. ¿Cuál es tu presupuesto mensual para infraestructura?

## Perfil: Mi app RAG de documentación

- Tráfico: Variable, picos en horario laboral (9am-6pm)
- Usuarios: ~100 (equipo de ingeniería)
- GPUs: No (uso API de OpenAI para embeddings y chat)
- Compliance: Datos internos, prefiero no enviar a terceros excepto OpenAI
- Presupuesto: <$30/mes

Categorías viables:
- Local (Docker Compose en VPS): $12/mes en DigitalOcean, control total
- Managed (Railway): $5-20/mes, más simple de operar
- Serverless: Posible pero no ideal (necesito embeddings en memoria)
- Self-hosted: Overkill para 100 usuarios

Primera impresión: Local (Docker Compose en VPS) por balance costo/control

Ejercicio 3: Trade-offs en 30 segundos

Sin mirar la tabla, escribe de memoria los trade-offs principales de cada categoría en una frase:

Ejercicio 4: Quick cost comparison

Para cada categoría, estima el coste mensual de una app AI con estas specs: FastAPI + OpenAI API, 5K requests/día, 512MB de RAM necesaria.

LOCAL (VPS DigitalOcean 2GB):    $12/mes fijo
SERVERLESS (Lambda 512MB, 2s):   ~$2.50/mes (150K req × $0.0000169)
MANAGED (Railway free tier):     $0/mes (cabe en free tier)
SELF-HOSTED (EC2 t3.micro):      $8/mes infra + ~$200/mes ops time

Coste de OpenAI API (común a todas): 150K req × $0.003 = ~$450/mes

Insight: La infra es $0-12/mes. El API es $450/mes.
La estrategia de deployment es irrelevante para el coste total.
Lo que importa es optimizar las API calls.

Ejercicio 5: Diagrama de decisión propio

Crea tu propio diagrama de decisión (diferente al de esta cápsula) usando 3-4 preguntas que reflejen TUS criterios más importantes.

¿Tu presupuesto es <$20/mes?
├── SÍ → ¿Necesitas URL pública?
│         ├── SÍ → Managed (Railway free tier)
│         └── NO → Local (Docker Compose)
└── NO → ¿Tienes equipo de ops (>2 personas)?
          ├── SÍ → Self-hosted (EC2 + K8s)
          └── NO → ¿Tráfico impredecible?
                    ├── SÍ → Serverless (Lambda)
                    └── NO → Managed (Render Pro)

Resumen

• Local deployment corre en tu infraestructura (Docker Compose, VPS). Control alto, coste bajo, escalabilidad manual.
• Serverless (Lambda) ejecuta código sin gestionar servidores. Escala automática, pay-per-use, pero cold starts y limits.
• Managed platforms (Render, Railway, Fly.io) abstraen infraestructura. Deploy rápido, simple, pero menos control.
• Self-hosted te da control total. Máxima flexibilidad, pero máxima complejidad operativa.
• Para AI workloads, los factores específicos son: cold starts (afectan inferencia), memory (modelos en RAM), timeouts (prompt chains), y coste de APIs (invocaciones × duración).
• No hay categoría "correcta" universal. Hay categoría correcta para tu caso, tus constraints, tu stage.

Recursos Adicionales

1. AWS Lambda vs EC2 — When to Use Each — Documentación oficial de Lambda con casos de uso
2. Render Documentation — Docs de Render para deployment de apps Python
3. Railway Documentation — Guía completa de Railway
4. Fly.io Documentation — Docs de Fly.io con enfoque en edge deployment
5. Docker Compose Documentation — Referencia oficial de Docker Compose
6. Serverless Framework — Framework para deployer funciones serverless
7. DigitalOcean Pricing — Referencia de costes VPS
8. Cloud Native Computing Foundation — Ecosistema de herramientas cloud native