Módulo 1: Understanding Deployment Options

1. Introducción: Understanding Deployment Options

Descripción

Esta es la primera cápsula del Módulo 1 de la Guía de Deployment & Cloud Infrastructure. Aquí vas a entender el landscape completo de opciones de deployment para sistemas AI: Local, Serverless, Managed y Self-hosted. Antes de tocar una sola línea de configuración, necesitas un marco mental para decidir dónde y cómo desplegar tu aplicación.

Por qué importa: La mayoría de AI Engineers construye su app, la containeriza con Docker, configura CI/CD, y luego se paraliza: "¿Dónde la despliego? ¿AWS? ¿Render? ¿Mi propio servidor?" Este módulo responde esa pregunta con un framework de decisión, no con una opinión. Sin este marco, los módulos posteriores (Docker Compose, Lambda, LocalStack, AWS, alternativas) serían técnicas sueltas sin criterio de cuándo usar cada una.

Este módulo no es teoría por teoría. Cada concepto se conecta con el Deployment Decision Workshop que construirás al final: una decision matrix que evalúa tu caso de uso real y produce una recomendación documentada. Esa matrix se extiende en el Módulo 7 (plataformas) y se aplica en el Módulo 8 (proyecto integrador). Es la pieza uno de un sistema de decisión que madura a lo largo de toda la guía.

¿Dónde Estamos en la Guía?

Contexto

Esta guía tiene 8 módulos organizados en 3 fases:

Phase 1: Deployment Strategies (Módulos 1-3)
├── Módulo 1: Understanding Deployment Options    ← ESTÁS AQUÍ
├── Módulo 2: Local & Container Deployment
└── Módulo 3: Serverless & Lambda for AI

Phase 2: Cloud Infrastructure & Migration (Módulos 4-6)
├── Módulo 4: LocalStack — AWS Local Development
├── Módulo 5: AWS Services for AI (S3, Lambda, SageMaker Basics)
└── Módulo 6: Cloud Migration Patterns

Phase 3: Alternatives & Production (Módulos 7-8)
├── Módulo 7: Alternative Platforms (Render, Railway, Fly.io)
└── Módulo 8: Proyecto Integrador — Deployed AI System

Duración total estimada: 10-12 horas (self-paced).

¿Hacia dónde vamos?

Este módulo te da el framework de decisión completo. Con esa base, el Módulo 2 profundiza en deployment local multi-container con Docker Compose, y el Módulo 3 en serverless con AWS Lambda para AI.

La progresión es deliberada:

Primero decides (este módulo) — sin criterio, cada herramienta parece "la correcta"
Luego implementas local (módulo 2) — Docker Compose multi-container production-like
Después serverless (módulo 3) — Lambda para AI con cold starts, timeouts
Desarrollas sin coste (módulo 4) — LocalStack para AWS local
Integras AWS (módulo 5) — S3, Lambda, SageMaker basics
Migras (módulo 6) — Patrones LocalStack → AWS
Evalúas alternativas (módulo 7) — Render, Railway, Fly.io
Integras todo (módulo 8) — Sistema AI desplegado en producción

Las Cuatro Categorías de Deployment

Overview rápido

Antes de profundizar en los módulos siguientes, necesitas conocer las cuatro grandes categorías. Cada una tiene un perfil distinto de coste, complejidad, escalabilidad y control:

Categoría	Qué es	Ejemplo	Cuándo
Local	Corres la app en tu máquina o servidor propio con containers	Docker Compose en tu laptop o un VPS	Desarrollo, staging, MVPs con tráfico bajo
Serverless	El cloud provider gestiona la infraestructura, tú solo subes código	AWS Lambda + API Gateway	APIs event-driven, tráfico variable, costes por uso
Managed	Plataformas que abstraen infraestructura con deploy desde Git	Render, Railway, Fly.io, Heroku	Startups, MVPs que necesitan estar online rápido
Self-hosted	Gestionas tus propios servidores (físicos o VMs en cloud)	EC2, DigitalOcean Droplets, bare metal	Control total, compliance, workloads predecibles

La analogía del transporte

Piensa en deployment como elegir transporte para un viaje:

Local = Tu propio coche. Control total, sabes exactamente cómo funciona, pero tú lo mantienes, tú pagas gasolina, y si se rompe en la carretera, tú lo resuelves.
Serverless = Uber/taxi. Solo pagas por viaje, no te preocupas del mantenimiento del vehículo, pero no controlas la ruta ni el coche.
Managed = Autobús express. Ruta predefinida, precio fijo, llegas rápido sin gestionar nada, pero no puedes desviarte.
Self-hosted = Comprar y operar tu propia flota de camiones. Máximo control, puedes optimizar cada aspecto, pero necesitas mecánicos, choferes, y garage.

Ninguna opción es "mejor." Depende de tu destino (requirements), presupuesto, equipo, y urgencia.

Cada categoría en contexto AI

Veamos cómo se ve cada categoría en la práctica para un AI Engineer. Estos son snapshots rápidos — la cápsula 02 profundiza en cada uno.

Local — Tu app AI en containers que tú gestionas:

# Lo que corre en local deployment típico para AI:
# docker-compose.yml orquesta 3 containers:
#   - FastAPI API (tu app, recibe prompts, retorna respuestas)
#   - ChromaDB (vector store para RAG, ~2GB en memoria)
#   - Redis (cache de responses para reducir costes de API)
# Total: 1 comando (docker compose up) → sistema AI completo corriendo

Tu app RAG con FastAPI + ChromaDB + Redis corre en Docker Compose en un VPS de $24/mes. Tus embeddings están en memoria, Redis cachea responses, y tú controlas todo. Si el VPS se cae a las 3am, eres tú quien lo arregla.

Serverless — Funciones que se ejecutan bajo demanda:

# Lo que corre en serverless para AI:
# - 1 función Lambda (recibe prompt, llama LLM, retorna respuesta)
# - API Gateway como trigger HTTP
# - Sin containers permanentes, sin VPS
# Pagas: ~$0.000017 por invocación × número de requests

Tu función Lambda recibe un prompt, llama a GPT-4o-mini, y retorna la respuesta. El primer request del día tarda 3 segundos (cold start) mientras Lambda importa el SDK de OpenAI. Los siguientes son rápidos.

Managed — Deploy desde Git, la plataforma hace el resto:

# Lo que haces en managed deployment:
git push origin main
# Railway detecta el cambio, buildea tu container, despliega
# https://tu-app.railway.app está live en 2 minutos con SSL incluido

Conectas tu repo de GitHub a Railway, haces push, y en 2 minutos tienes URL pública con SSL. Railway gestiona el container por ti. Si necesitas Redis, agregas un add-on con un click.

Self-hosted — Control total, responsabilidad total:

# Lo que gestionas en self-hosted para AI:
# - 3 EC2 instances (app servers con load balancer)
# - 1 GPU instance p3.2xlarge (inferencia de modelo local)
# - Prometheus + Grafana (monitoring)
# - Nginx (reverse proxy + SSL)
# - Tu equipo de ops mantiene todo 24/7

Tienes EC2 instances con load balancer, una GPU para correr Llama 3 en local, Prometheus para monitoring, y un equipo dedicado a mantener la infra. Máximo control, máximo overhead.

Objetivo del Módulo

Al terminar este módulo serás capaz de:

✅ Diferenciar las cuatro categorías de deployment (Local, Serverless, Managed, Self-hosted) con ejemplos concretos para sistemas AI
✅ Evaluar trade-offs en cinco dimensiones: coste, complejidad operativa, escalabilidad, control y time-to-deploy
✅ Construir una decision matrix funcional que mapee requirements de un proyecto real a la estrategia óptima
✅ Identificar cómo el stage del proyecto (MVP, growth, scale) cambia la estrategia recomendada
✅ Explicar cost modeling básico: fixed vs variable costs por estrategia
✅ Documentar criterios de decisión de forma que otro ingeniero pueda entender y cuestionar tu elección

Objetivo profesional

Cuando alguien te pregunte "¿dónde deberíamos deployar nuestra app AI?", no vas a responder "AWS porque es lo que todo el mundo usa." Vas a responder: "Depende. ¿Cuál es tu presupuesto? ¿Cuánto tráfico esperas? ¿Tienes equipo de ops? ¿Qué latencia necesitas para inferencia?" Y vas a tener un framework para transformar esas respuestas en una recomendación documentada.

Roadmap del Módulo

Mapa de cápsulas

#	Cápsula	Qué aprenderás	Tipo
01	Introducción (esta)	El landscape de deployment, por qué decidir antes de implementar	Intro
02	Landscape de Deployment Options	Las 4 categorías en profundidad con ejemplos AI-specific	Técnica
03	Trade-offs por Estrategia	Evaluación en 5 dimensiones, comparativa detallada	Técnica
04	Serverless vs Containers para AI	Comparación profunda de las dos opciones más comunes	Técnica
05	Cost Modeling para AI Deployment	Fixed vs variable costs, estimaciones reales, calculadoras	Técnica
06	Decision Matrix Framework	Cómo construir y usar una decision matrix	Técnica
07	Stage del Proyecto y Deployment	MVP vs Growth vs Scale, cómo cambia la estrategia	Técnica
08	Proyecto: Deployment Decision Workshop	Construir tu decision matrix para un caso real	Proyecto

Flujo de aprendizaje

Primero entenderás las cuatro categorías en profundidad con contexto AI-specific (cápsula 02). Luego evaluarás trade-offs en 5 dimensiones para cada estrategia (cápsula 03). Después compararás en detalle serverless vs containers — las dos opciones más habituales (cápsula 04). Aprenderás a estimar costes reales para AI workloads (cápsula 05). Construirás un framework de decision matrix para sistematizar la elección (cápsula 06). Entenderás cómo el stage del proyecto cambia la ecuación (cápsula 07). Y finalmente integrarás todo en un workshop donde produces tu decision matrix real (cápsula 08).

La progresión es: categorías → trade-offs → comparación → costes → framework → contexto → proyecto.

Duración estimada del módulo: 1.0-1.25 horas.

Conexión con el Proyecto

Proyecto de este módulo: Deployment Decision Workshop

El Deployment Decision Workshop es un ejercicio estructurado donde tomas un caso de uso real (tu propia app AI o uno provisto) y produces:

Una decision matrix que evalúa cada estrategia contra tus requirements
Un documento de decisión con la estrategia recomendada y justificación
Criterios documentados que otro ingeniero puede revisar y cuestionar

Input: Requirements de tu app AI
  - Tráfico esperado: ~5K requests/día
  - Presupuesto: <$50/mes
  - Equipo: 1-2 developers
  - Latencia: <3s para inferencia
  - Stage: MVP

Output: Decision Matrix + Recomendación
  - Estrategia recomendada: Managed (Railway)
  - Justificación: Budget limitado, equipo pequeño,
    simplicidad > control, free tier cubre MVP
  - Alternativa si escala: Serverless (Lambda)
  - Review en: 3 meses o al alcanzar 50K requests/día

Conexión con el proyecto final: Deployed AI System

La decision matrix del Módulo 1 es la semilla del Módulo 8. En el proyecto integrador, tu sistema AI desplegado en producción incluye documentación de por qué elegiste esa estrategia y esa plataforma — con la matrix como evidencia.

Módulo 1: Decision Matrix → framework para decidir
    ↓
Módulo 7: Decision Matrix v2 → extendida con criterios de plataforma
    ↓
Módulo 8: Decision Matrix aplicada → justifica el deployment final

Prerequisitos

Conocimientos necesarios

Docker básico: Sabes qué es un container, image, Dockerfile (guía #15)
CI/CD básico: Entiendes pipelines de deployment, GitHub Actions (guía #16)
Python intermedio: FastAPI, Pydantic, async/await
Experiencia AI: Has construido al menos una app AI funcional (RAG, chatbot, agent)
REST APIs: Entiendes HTTP, requests, responses, endpoints

Si no tienes estos prerequisitos

Te falta	Recurso recomendado
Docker	Docker Essentials Guide (#15) — NIEVA
CI/CD	CI/CD for AI Systems Guide (#16) — NIEVA
Python + FastAPI	Python REST APIs for AI Guide — NIEVA
Apps AI	AI Engineering Bootcamp — NIEVA
REST APIs	Backend Python Developer Bootcamp — NIEVA

Setup Técnico

Herramientas necesarias

Para este módulo no necesitas instalar herramientas nuevas — es estratégico y conceptual. Pero verifica que tienes lo que necesitarás en módulos posteriores:

# Docker (prerequisite de guía #15)
docker --version
# Docker version 24.0+ esperado

# Docker Compose
docker compose version
# Docker Compose version v2.20+ esperado

# Python
python --version
# Python 3.10+ esperado

# Git
git --version

Para este módulo específicamente

Solo necesitas un editor de texto para crear tu decision matrix. Puedes usar:

Un archivo Markdown (recomendado — versionable con Git)
Una hoja de cálculo (Google Sheets, Excel)
Notion, Obsidian, o cualquier herramienta de documentación

# Crea directorio para tu trabajo
mkdir -p deployment-cloud-guide/module-01
cd deployment-cloud-guide/module-01

# Crea archivo para tu decision matrix
touch decision-matrix.md

Tecnologías que usarás en este módulo

Aunque este módulo es estratégico, usarás herramientas concretas para documentar y calcular tus decisiones:

Herramienta	Para qué	Dónde la usas
Python 3.10+	Calculadoras de costes, scripts de evaluación	Cápsulas 05 y 06
Markdown	Documentar tu decision matrix y recomendación	Proyecto final (cápsula 08)
Git	Versionar tu documento de decisión	Todo el módulo
Editor de texto	Crear y editar archivos Markdown	Todo el módulo

# Verifica que puedes correr Python (lo necesitas para las calculadoras)
python3 -c "print('Python OK — listo para calculadoras de costes')"

Entorno de trabajo para los scripts

Las cápsulas 05 y 06 incluyen calculadoras de costes en Python. Para poder ejecutarlas:

# Crea un entorno virtual para este módulo
python3 -m venv .venv
source .venv/bin/activate  # macOS/Linux

# No necesitas librerías externas para este módulo
# Los scripts usan solo la standard library de Python
python3 -c "import json, hashlib; print('Standard library OK')"

Si quieres ir más allá y crear una calculadora interactiva, puedes instalar rich para tablas formateadas en terminal — pero es totalmente opcional:

# Opcional: para tablas bonitas en terminal
pip install rich

Estructura de archivos recomendada

deployment-cloud-guide/
├── .env                         # API keys (módulos posteriores)
├── module-01/
│   └── decision-matrix.md       # Tu decision matrix (proyecto)
├── module-02/                   # Docker Compose (próximo módulo)
├── module-03/                   # Lambda (siguiente)
└── ...

Límites: Qué NO Cubre Este Módulo

❌ Implementación de ninguna estrategia — Este módulo es decisión, no ejecución. La implementación viene en Módulos 2-7.
❌ Kubernetes — No se cubre en toda la guía. Es una herramienta de orquestación que va más allá del scope.
❌ DevOps avanzado — No se profundiza en Terraform, Ansible, o herramientas de Infrastructure as Code.
❌ Comparación de cloud providers (AWS vs GCP vs Azure) — El foco es en categorías de deployment, no en vendors específicos.
❌ Networking avanzado — VPCs, subnets, load balancers se mencionan pero no se enseñan a configurar.

Evidencia de Éxito

Al terminar este módulo, sabrás que tuviste éxito si:

✅ Puedes explicar las 4 categorías de deployment con un ejemplo AI-specific de cada una
✅ Dado un caso de uso ("tengo una app RAG con 10K usuarios/mes"), identifies la estrategia correcta con justificación
✅ Tu decision matrix tiene al menos 5 criterios evaluados numéricamente para cada estrategia
✅ Puedes estimar el coste mensual de una app AI en Lambda vs un VPS vs Railway
✅ Tu documento de decisión es lo suficientemente claro para que otro ingeniero lo revise
✅ Puedes argumentar cuándo tu recomendación dejaría de ser válida (cambio de stage, tráfico, presupuesto)

Test rápido de autoevaluación

Si puedes responder estas preguntas, vas por buen camino:

¿Cuáles son las 4 categorías de deployment y un ejemplo de cada una?
¿Qué 5 dimensiones usas para evaluar trade-offs?
¿Por qué Lambda puede ser costoso para AI workloads de alto volumen?
¿Qué cambia en tu estrategia cuando pasas de MVP a scale?

Ejercicio rápido de calibración

Antes de avanzar a la siguiente cápsula, intenta este ejercicio mental. Dado este escenario:

App AI: chatbot de soporte para e-commerce

500 usuarios/día

Streaming de respuestas (token-by-token)

Presupuesto: $30/mes

Equipo: 1 developer

Stage: MVP

¿Qué categoría elegirías? Escribe tu respuesta antes de ver la solución.

Ver respuesta

Managed (Railway/Render) o Local (Docker Compose en VPS).

Serverless queda descartado: streaming no es nativo en Lambda.
Self-hosted es overkill para 1 developer y $30/mes.
Managed es la opción más rápida si Railway soporta WebSockets (sí lo hace).
Local (VPS) funciona si prefieres más control por el mismo precio (~$24/mes).

Si contestaste algo similar con justificación, vas bien. Si elegiste "AWS porque es lo que usan las empresas," este módulo es exactamente lo que necesitas.

Indicadores de que necesitas este módulo

Si te identificas con alguno de estos escenarios, este módulo te va a cambiar la forma de tomar decisiones:

"Siempre uso Heroku/Vercel/AWS sin evaluar alternativas"
"No sé cuánto debería costar mi infra al mes"
"Containerizo todo pero luego no sé dónde desplegarlo"
"Elijo la tecnología que aparece primero en el tutorial de YouTube"
"No puedo explicar a mi equipo por qué elegí esta plataforma"

Si ninguno te aplica y ya tomas decisiones de deployment con criterio documentado — este módulo te dará un framework más riguroso y reutilizable para hacerlo.

Resumen

Deployment decisions deben tomarse con criterio, no por inercia ("usamos AWS porque siempre usamos AWS").
Las 4 categorías (Local, Serverless, Managed, Self-hosted) cubren el landscape completo de opciones.
Cada categoría tiene trade-offs en coste, complejidad, escalabilidad, control y time-to-deploy.
No hay deployment "correcto" universal — hay deployment correcto para TU caso, TUS constraints, TU stage.
La decision matrix es la herramienta que sistematiza esta elección.
Este módulo es estratégico: decidir antes de implementar.
El proyecto del módulo es un Deployment Decision Workshop con decision matrix real.

Recursos Adicionales

AWS Well-Architected Framework — Operational Excellence — Framework de AWS para decisiones de arquitectura
The Twelve-Factor App — Principios para apps cloud-native que informan decisiones de deployment
CNCF Cloud Native Landscape — Mapa visual del ecosistema cloud native
Serverless vs Containers — AWS — Guía de decisión oficial de AWS
Render vs Railway vs Fly.io — Comparison — Comparativa de plataformas managed
Lambda Power Tuning — Herramienta para optimizar costes de Lambda
Cloud Cost Handbook — Referencia de costes cloud por servicio

Siguiente →2. Landscape de Deployment Options