Módulo 1: Understanding Deployment Options

8. Proyecto: Deployment Decision Workshop

Descripción del proyecto

Este es el proyecto integrador del Módulo 1. Vas a tomar todo lo que aprendiste — categorías de deployment, trade-offs en 5 dimensiones, serverless vs containers, cost modeling, decision matrix, y stage-based strategy — y aplicarlo a un caso de uso real. El resultado es un documento de decisión completo que podrías presentar a un equipo, a un manager, o incluir en la documentación de tu proyecto.

No es un ejercicio teórico. Si tienes una app AI propia, usa esa. Si no, usarás un caso de estudio provisto. En ambos casos, el entregable es una decision matrix funcional con recomendación documentada, justificada, y con condiciones de re-evaluación.

Por qué importa: Este documento de decisión es el artefacto que más impacto tiene fuera de esta guía. Es lo que muestras en una entrevista cuando te preguntan "¿cómo decides dónde deployar?" Es lo que le envías a tu tech lead cuando necesitas justificar una inversión en infraestructura. Y es la base que extienes en los Módulos 7 (plataformas) y 8 (proyecto integrador) de esta guía.

Objetivo del proyecto

Producir un Deployment Decision Document completo que incluya:

Contexto del proyecto y requirements
Decision matrix con criterios ponderados
Evaluación de las 4 estrategias
Recomendación con justificación
Estimación de costes a 3 meses
Condiciones de re-evaluación
Migration path si cambian las condiciones

Recap del Módulo

Antes de empezar, asegúrate de dominar estos conceptos del módulo:

Cápsula	Concepto clave	Lo usas para
02	4 categorías (Local, Serverless, Managed, Self-hosted)	Identificar las opciones
03	5 dimensiones (coste, complejidad, escalabilidad, control, time-to-deploy)	Definir criterios
04	Serverless vs Containers	Profundizar la comparación principal
05	Cost modeling	Estimar costes reales
06	Decision Matrix Framework	Estructura del entregable
07	Stage del proyecto	Calibrar los pesos

Caso de Estudio (si no tienes app propia)

DocuSearch AI

Descripción: API de búsqueda inteligente sobre documentación técnica. Los usuarios envían una pregunta en lenguaje natural y reciben una respuesta basada en la documentación interna de la empresa, con las fuentes citadas.

Arquitectura:

User → FastAPI API → Embedding search (ChromaDB) → LLM (GPT-4o-mini) → Response
                   → Redis cache (responses frecuentes)

Datos del proyecto:

project_data = {
    "name": "DocuSearch AI",
    "type": "RAG (Retrieval Augmented Generation)",
    "stage": "Growth early",
    "team": "2 developers (backend + ML)",
    "users": {
        "current": 150,
        "expected_6_months": 500,
        "type": "internal (empresa de 2000 empleados)",
    },
    "traffic": {
        "daily_requests": 3000,
        "peak_hour_multiplier": 3,
        "pattern": "weekday 9am-6pm, minimal weekends",
    },
    "technical": {
        "framework": "FastAPI",
        "llm": "GPT-4o-mini via OpenAI API",
        "embeddings": "text-embedding-3-small via OpenAI API",
        "vector_db": "ChromaDB (in-memory, ~2GB)",
        "cache": "Redis",
        "container": "Docker (Dockerfile exists)",
        "ci_cd": "GitHub Actions (basic pipeline exists)",
    },
    "constraints": {
        "budget": "$50-100/mes para infraestructura",
        "compliance": "Datos internos, no regulados pero prefieren control",
        "latency": "<3 seconds para respuesta completa",
        "availability": "Business hours (no 24/7 critical)",
        "streaming": "No requerido actualmente, nice-to-have futuro",
    },
    "current_deployment": "Docker Compose local en laptop del developer",
}

Especificaciones del Entregable

Formato

Un archivo Markdown llamado deployment-decision.md con la siguiente estructura:

Sección 1: Contexto del Proyecto (10%)

# Deployment Decision: [Nombre del Proyecto]
Fecha: [Fecha]
Autor: [Tu nombre]
Stage: [MVP / Growth / Scale]

## Contexto

### Descripción del proyecto
[2-3 párrafos describiendo qué hace tu app AI]

### Datos técnicos
- Framework: [FastAPI, Flask, etc.]
- LLM: [GPT-4o, Claude, etc.]
- Base de datos: [ChromaDB, Pinecone, etc.]
- Cache: [Redis, etc.]
- Container: [Docker sí/no]
- CI/CD: [GitHub Actions, etc.]

### Requirements
- Usuarios: [número actual y esperado]
- Tráfico: [requests/día, patrón]
- Presupuesto: [rango mensual]
- Latencia: [máxima aceptable]
- Disponibilidad: [SLA esperado]
- Compliance: [restricciones]
- Features especiales: [streaming, GPU, etc.]

Sección 2: Decision Matrix (40%)

## Decision Matrix

### Criterios y Pesos

| # | Criterio | Peso | Justificación |
|---|----------|------|---------------|
| 1 | [Criterio] | [Peso] | [Por qué este peso] |
| 2 | [Criterio] | [Peso] | [Por qué este peso] |
| ... | ... | ... | ... |
| **Total** | | **100** | |

### Evaluación (1-5)

| Criterio (Peso) | Local | Serverless | Managed | Self-hosted | Notas |
|-----------------|:-----:|:----------:|:-------:|:-----------:|-------|
| [Criterio 1] ([Peso]) | [1-5] | [1-5] | [1-5] | [1-5] | [Justificación breve] |
| ... | ... | ... | ... | ... | ... |

### Scores Ponderados

| Criterio | Local | Serverless | Managed | Self-hosted |
|----------|:-----:|:----------:|:-------:|:-----------:|
| [Criterio 1] | [peso×score] | ... | ... | ... |
| ... | ... | ... | ... | ... |
| **TOTAL** | **[total]** | **[total]** | **[total]** | **[total]** |

Sección 3: Estimación de Costes (20%)

## Estimación de Costes (3 meses)

### Desglose por estrategia

| Componente | Local | Serverless | Managed | Self-hosted |
|-----------|-------|------------|---------|-------------|
| Infraestructura | $X/mes | $X/mes | $X/mes | $X/mes |
| LLM APIs | $X/mes | $X/mes | $X/mes | $X/mes |
| Ops (tiempo) | $X/mes | $X/mes | $X/mes | $X/mes |
| **Total mensual** | **$X** | **$X** | **$X** | **$X** |
| **Total 3 meses** | **$X** | **$X** | **$X** | **$X** |

### Notas de coste
- [Asunciones sobre tráfico]
- [Asunciones sobre modelo LLM]
- [Riesgos de coste identificados]

Sección 4: Recomendación (15%)

## Recomendación

### Estrategia elegida: [Nombre]
**Score:** [total] de [máximo posible]

### Justificación
[3-5 párrafos explicando por qué esta estrategia es la óptima
para este caso. Incluir los 2-3 criterios que más influyeron.]

### Opciones descartadas
| Opción | Score | Razón principal de descarte |
|--------|-------|-----------------------------|
| [Opción 2] | [score] | [Por qué no] |
| [Opción 3] | [score] | [Por qué no] |
| [Opción 4] | [score] | [Por qué no] |

Sección 5: Plan de Acción y Re-evaluación (15%)

## Plan de Acción

### Pasos para implementar
1. [Paso 1 — con estimación de tiempo]
2. [Paso 2]
3. [Paso 3]
4. [Paso 4]

### Timeline
| Semana | Acción | Entregable |
|--------|--------|-----------|
| 1 | [Acción] | [Entregable] |
| 2 | [Acción] | [Entregable] |

## Condiciones de Re-evaluación

### Triggers para migrar
- [ ] [Trigger 1 con métrica específica]
- [ ] [Trigger 2]
- [ ] [Trigger 3]

### Migration path
Si [trigger], migrar a [estrategia alternativa]:
1. [Paso 1]
2. [Paso 2]
3. [Paso 3]

### Review programado
- Fecha: [3 meses desde la decisión]
- Revisor: [quién]
- Datos a evaluar: [métricas]

Paso a Paso Guiado

Paso 1: Documenta el contexto (15 min)

Llena la Sección 1 con los datos de tu proyecto (o del caso DocuSearch AI). Sé específico con números — "algunos usuarios" no es un input válido para una decision matrix.

# Verifica que tienes todos los datos necesarios
required_data = [
    "Número actual de usuarios",
    "Requests/día estimados",
    "Presupuesto mensual",
    "Latencia máxima aceptable",
    "¿Necesita streaming?",
    "¿Hay constraints de compliance?",
    "¿Tienes Docker container?",
    "¿Tienes CI/CD?",
    "Stage del proyecto (MVP/Growth/Scale)",
]

for item in required_data:
    # Si no puedes responder, investiga antes de continuar
    print(f"✅ {item}: [tu respuesta]")

Paso 2: Define criterios y pesos (15 min)

Selecciona 5-7 criterios y asigna pesos que sumen 100. Usa las 5 dimensiones estándar como base y agrega criterios AI-specific si aplica.

# Template de criterios y pesos
criteria = {
    # Estándar (ajusta pesos según tu caso)
    "Coste mensual total": 0,         # Incluye infra + ops + APIs
    "Complejidad operativa": 0,       # Hrs/semana de mantenimiento
    "Time-to-deploy": 0,             # De commit a producción
    "Escalabilidad": 0,              # Capacidad de crecer
    "Control": 0,                    # Acceso a configuración
    
    # AI-specific (agrega si aplica)
    "Cold start latency": 0,         # Si latencia importa
    "Streaming support": 0,          # Si chat con streaming
    "Memory for models": 0,          # Si embeddings/modelos en RAM
}

# Ejemplo para DocuSearch AI (Growth, equipo de 2, presupuesto moderado)
criteria_docusearch = {
    "Coste mensual total": 20,
    "Complejidad operativa": 20,
    "Time-to-deploy": 15,
    "Escalabilidad": 15,
    "Control": 10,
    "Memory for models": 10,  # ChromaDB necesita ~2GB RAM
    "Latency < 3s": 10,
}

assert sum(criteria_docusearch.values()) == 100

Paso 3: Evalúa cada estrategia (20 min)

Para cada criterio, evalúa cada estrategia de 1 a 5 con justificación:

evaluation_docusearch = {
    "Coste mensual total": {
        "Local": (4, "VPS $24/mes + APIs $15 = $39"),
        "Serverless": (3, "Lambda $5 + APIs $15 + pero ChromaDB no cabe en Lambda"),
        "Managed": (4, "Railway $20/mes + APIs $15 = $35"),
        "Self-hosted": (1, "EC2 $30 + ops $400 + APIs $15 = $445"),
    },
    "Memory for models": {
        "Local": (5, "VPS con 4GB+ de RAM, ChromaDB cabe"),
        "Serverless": (1, "Lambda max 10GB pero stateless, ChromaDB no persiste"),
        "Managed": (3, "Railway Pro tiene hasta 8GB pero verificar"),
        "Self-hosted": (5, "Ilimitado, elegimos el instance type"),
    },
    # ... completar los demás criterios
}

Paso 4: Calcula scores (10 min)

def calculate_scores(criteria: dict, evaluation: dict) -> dict:
    """Calcula scores ponderados."""
    options = ["Local", "Serverless", "Managed", "Self-hosted"]
    scores = {opt: 0 for opt in options}
    details = {opt: {} for opt in options}
    
    for criterion, weight in criteria.items():
        for option in options:
            score, justification = evaluation[criterion][option]
            weighted = weight * score
            scores[option] += weighted
            details[option][criterion] = {
                "raw": score,
                "weighted": weighted,
                "note": justification
            }
    
    return {
        "totals": dict(sorted(scores.items(), key=lambda x: x[1], reverse=True)),
        "details": details,
        "max_possible": sum(criteria.values()) * 5,
    }

results = calculate_scores(criteria_docusearch, evaluation_docusearch)
print(f"Ranking: {results['totals']}")
print(f"Score máximo posible: {results['max_possible']}")

Paso 5: Estima costes (15 min)

Usa la calculadora de la Cápsula 05 con tus datos reales:

docusearch_costs = {
    "monthly_requests": 90_000,  # 3K/día × 30
    "avg_input_tokens": 800,     # RAG context + query
    "avg_output_tokens": 400,
    "embedding_requests": 90_000,
}

# LLM cost (GPT-4o-mini)
llm_cost = docusearch_costs["monthly_requests"] * (
    (800 / 1_000_000 * 0.15) + (400 / 1_000_000 * 0.60)
)
embedding_cost = docusearch_costs["embedding_requests"] * 0.0001

api_total = llm_cost + embedding_cost
print(f"API costs: ${api_total:.2f}/mes")

# Infra costs por estrategia
infra = {
    "Local (VPS 4GB)": 24,
    "Serverless (Lambda)": "N/A - ChromaDB no cabe",
    "Managed (Railway Pro)": 20,
    "Self-hosted (EC2)": 30,
}

Paso 6: Escribe la recomendación (15 min)

Con los scores y costes, redacta la recomendación. Incluye la segunda opción y los descartados con razón.

Paso 7: Escribe la recomendación y descartados (15 min)

Estructura tu recomendación en 3 partes:

### Estrategia elegida: [Nombre]
**Score:** [total] / [máximo posible]

### Justificación (3-5 párrafos)
1. Cuál es la estrategia y por qué ganó
2. Los 2-3 criterios que más influyeron en el resultado
3. Por qué la segunda opción no ganó
4. Riesgos conocidos de la estrategia elegida
5. Qué harías diferente si tus constraints cambiaran

### Descartados
- [Opción 2]: Score [X]. No elegida porque [razón principal]
- [Opción 3]: Score [X]. No elegida porque [razón principal]
- [Opción 4]: Score [X]. No elegida porque [razón principal]

Tip: Si tu recomendación contradice el score más alto (por ejemplo, elegiste la segunda opción por un deal-breaker), explícalo explícitamente. "Serverless ganó en score pero descartado por no soportar streaming" es perfectamente válido.

Paso 8: Define condiciones de re-evaluación (10 min)

Sé específico con métricas:

re_evaluation_triggers = [
    "Usuarios > 500 activos → evaluar escalabilidad",
    "Latencia p95 > 3s → evaluar infra más potente",
    "Factura > $100/mes → evaluar VPS vs managed",
    "Requerimiento de streaming → verificar soporte de plataforma",
    "Compliance SOC2 → evaluar self-hosted o AWS con VPC",
]

review = {
    "date": "3 meses desde deploy",
    "metrics_to_check": [
        "Tráfico real vs estimado",
        "Costes reales vs estimados",
        "Incidentes de downtime",
        "Feedback de usuarios sobre latencia",
    ],
}

Checklist de Completitud

Antes de considerar el proyecto terminado, verifica:

Estructura

Sección 1: Contexto con datos específicos (no vagos)
Sección 2: Decision matrix con ≥5 criterios, pesos que suman 100
Sección 3: Estimación de costes con números reales para ≥3 estrategias
Sección 4: Recomendación con justificación y descartados
Sección 5: Condiciones de re-evaluación con métricas

Calidad

Los pesos reflejan TUS prioridades (no son uniformes)
Cada evaluación (1-5) tiene justificación (no solo números)
Los costes incluyen APIs + infra + ops (no solo infra)
La recomendación nombra alternativas descartadas con razón
Hay ≥3 triggers de re-evaluación con métricas específicas
Hay fecha de review programado

Defensa

Podrías explicar la decisión en 2 minutos a un no-técnico
Si un colega cuestiona un peso, puedes justificarlo
Si cambia un constraint (más presupuesto, más usuarios), sabes cómo re-evaluar
El documento es autosuficiente (alguien externo lo entiende sin contexto adicional)

Rúbrica de Evaluación (100 puntos)

Sección 1: Contexto del Proyecto (15 puntos)

Criterio	Puntos	Descripción
Descripción del proyecto	3	Qué hace la app, qué problema resuelve
Datos técnicos completos	4	Framework, LLM, DB, cache, container, CI/CD
Requirements cuantificados	4	Usuarios, tráfico, presupuesto, latencia — con NÚMEROS
Constraints documentados	4	Compliance, streaming, GPUs, disponibilidad

0 puntos si: Los datos son vagos ("algunos usuarios," "presupuesto flexible")

Sección 2: Decision Matrix (35 puntos)

Criterio	Puntos	Descripción
Mínimo 5 criterios relevantes	5	Incluye las 5 dimensiones estándar + AI-specific si aplica
Pesos suman 100	3	Verificable — no hay discusión
Pesos diferenciados	5	NO son uniformes (no todos 20). Reflejan TUS prioridades
Justificación de pesos	5	Cada peso tiene 1 frase explicando por qué ese número
Evaluación 1-5 con justificación	7	Cada score tiene nota explicando por qué ese número
Scores ponderados calculados correctamente	5	Peso × Score, sin errores matemáticos
Ranking claro	5	Se identifica ganador, segundo, y descartados

0 puntos si: Los pesos son todos iguales o no suman 100

Sección 3: Estimación de Costes (20 puntos)

Criterio	Puntos	Descripción
Mínimo 3 estrategias costeadas	5	Idealmente las 4 categorías
Desglose: infra + APIs + ops	5	No solo infra — incluye coste de tu tiempo y LLM APIs
Números reales (no inventados)	5	Basados en precios de proveedores actuales
Proyección a 3 meses	5	Con escenario base y pesimista

0 puntos si: Solo costeas infraestructura sin incluir APIs ni ops

Sección 4: Recomendación (15 puntos)

Criterio	Puntos	Descripción
Estrategia elegida con score	3	Identificada claramente
Justificación en 3-5 párrafos	5	Explica los 2-3 criterios que más influyeron
Opciones descartadas con razón	4	Cada descartada tiene 1 frase de por qué no
Coherencia con la matrix	3	La recomendación coincide con el score más alto (o explica por qué no)

0 puntos si: La recomendación contradice la matrix sin explicar por qué

Sección 5: Re-evaluación (15 puntos)

Criterio	Puntos	Descripción
Mínimo 3 triggers con métricas	5	"Si tráfico > 500/hora" no "si crece mucho"
Migration path documentado	5	Pasos concretos si necesitas cambiar de estrategia
Fecha de review programada	3	Fecha específica, no "en un futuro"
Métricas a verificar en el review	2	Qué datos revisas para decidir si mantener o migrar

0 puntos si: No hay condiciones de re-evaluación

Tabla de calificación

Rango	Calificación	Significado
90-100	Excelente	Documento listo para presentar a un tech lead
75-89	Bueno	Sólido, con áreas menores de mejora
60-74	Aceptable	Cubre lo básico pero le falta profundidad
40-59	Insuficiente	Falta contenido significativo o tiene errores
0-39	No aprobado	No demuestra comprensión del framework

Ejemplo de Implementación Mínima

Este es un ejemplo de cómo se ve un documento de decisión que cumple los requisitos mínimos (calificación "Aceptable," ~65 puntos). No es el mejor documento posible — es el mínimo para pasar:

# Deployment Decision: DocuSearch AI

Fecha: 2026-03-08
Autor: [Tu nombre]
Stage: Growth early

## Contexto

DocuSearch AI es una API RAG que busca en documentación técnica interna.
150 usuarios actuales, esperados 500 en 6 meses.
FastAPI + ChromaDB (2GB RAM) + Redis + OpenAI API.
3000 requests/día, picos 3x en horario laboral.
Budget: $50-100/mes. Latencia: <3s. Sin compliance regulatorio.

## Decision Matrix

### Criterios y Pesos

| # | Criterio | Peso | Justificación |
|---|----------|------|---------------|
| 1 | Coste mensual | 20 | Budget moderado, no es la constraint #1 |
| 2 | Complejidad operativa | 20 | Equipo de 2, preferimos simple |
| 3 | Time-to-deploy | 15 | No urgente pero queremos iterar |
| 4 | Escalabilidad | 15 | Crecimiento esperado de 3x |
| 5 | Control | 10 | Sin compliance especial |
| 6 | Memory (ChromaDB) | 10 | ChromaDB necesita 2GB mínimo |
| 7 | Latencia < 3s | 10 | SLA interno |
| **Total** | | **100** | |

### Evaluación y Scores

| Criterio (Peso) | Local | Serverless | Managed | Self-hosted |
|-----------------|:-----:|:----------:|:-------:|:-----------:|
| Coste (20) | 80 | 60 | 80 | 20 |
| Complejidad (20) | 60 | 80 | 100 | 20 |
| Time-to-deploy (15) | 45 | 60 | 75 | 15 |
| Escalabilidad (15) | 30 | 75 | 45 | 60 |
| Control (10) | 40 | 20 | 30 | 50 |
| Memory (10) | 50 | 10 | 30 | 50 |
| Latencia (10) | 50 | 30 | 40 | 50 |
| **TOTAL** | **355** | **335** | **400** | **265** |

## Estimación de Costes (3 meses)

| Componente | Local | Managed |
|-----------|-------|---------|
| Infra | $24/mes | $20/mes |
| APIs (OpenAI) | $45/mes | $45/mes |
| Ops (tiempo) | $150/mes | $25/mes |
| **Total mensual** | **$219** | **$90** |
| **Total 3 meses** | **$657** | **$270** |

## Recomendación

**Managed (Railway Pro)** — Score 400/500.

Railway gana por baja complejidad y time-to-deploy rápido. El equipo de 2
no quiere dedicar tiempo a mantener infra. ChromaDB cabe en Railway Pro
(hasta 8GB). Serverless descartado: ChromaDB necesita state persistente
que Lambda no ofrece.

## Re-evaluación

- Si usuarios > 500 → verificar limits de Railway
- Si latencia p95 > 3s → evaluar VPS dedicado
- Si factura > $150/mes → evaluar VPS como alternativa
- Review: Junio 2026

Este ejemplo cumple los requisitos mínimos. Para llegar a "Excelente":

Agrega justificación a cada evaluación (1-5)
Incluye escenario pesimista en costes
Detalla el migration path paso a paso
Agrega sensitivity analysis (¿qué pasa si cambio un peso?)

Troubleshooting Específico del Proyecto

"No tengo app AI propia, ¿uso el caso DocuSearch?"

Sí. El caso DocuSearch tiene datos suficientemente reales para producir una matrix genuina. Ajusta los parámetros si quieres simular un escenario diferente (más usuarios, menos presupuesto, streaming requerido).

"Dos estrategias tienen scores muy cercanos (<5% diferencia)"

Buena señal — tu caso no tiene constraints extremas. Opciones:

Haz sensitivity analysis (cambia un peso ±10, ¿cambia el ganador?)
Elige por factor no cuantificable (developer experience, familiaridad)
Documenta ambas como viables y elige la más simple de migrar

"Serverless no funciona para mi caso (ChromaDB en memoria)"

Correcto. No fuerces la evaluación — dale un 1 o 2 en criteria de memory y documenta por qué. Una matrix honesta que descarta una opción con datos es más valiosa que una que fuerza opciones que no encajan.

"Mi manager no le importan los scores, solo quiere una respuesta"

El documento es para ti y para tu futuro yo. Pero para el manager, extrae un resumen de 3 frases: "Recomiendo X porque Y. Cuesta $Z/mes. Re-evaluamos en N meses." El detalle está en el documento para quien quiera profundizar.

"Quiero usar una herramienta visual (spreadsheet, Notion)"

El formato no importa — lo que importa es el contenido. Si prefieres Google Sheets con fórmulas automáticas para los scores ponderados, úsalo. El template Markdown de este proyecto es una guía, no un requisito de formato.

"No sé cómo estimar costes de LLM APIs"

Usa esta fórmula rápida:

# Fórmula rápida de coste LLM
monthly_requests = 3000 * 30  # req/día × 30 días
avg_tokens_per_request = 1200  # input + output promedio

# GPT-4o-mini: ~$0.75/1M tokens promedio
monthly_llm_cost = monthly_requests * avg_tokens_per_request / 1_000_000 * 0.75
# = 90,000 * 1200 / 1M * 0.75 = ~$81/mes

print(f"Estimación LLM: ${monthly_llm_cost:.2f}/mes")

Si no sabes los tokens promedio, usa 1000-1500 como estimación conservadora para una app RAG.

"Mi matrix tiene 10 criterios y se siente demasiado compleja"

Reduce a 5-7 criterios. Agrupa criterios relacionados: "Cold starts" + "Latencia" → "Performance de inferencia." Más criterios no significa mejor análisis — significa más ruido. Si un criterio pesa <5, probablemente no merece ser un criterio separado.

"¿Puedo cambiar la decisión después de empezar a implementar?"

Sí, y es más común de lo que piensas. Si después de 2 semanas implementando Railway descubres que necesitas más RAM que la que ofrece su plan, migra. Tu Docker container es portable — ese es el beneficio de haber containerizado primero. Actualiza tu matrix con los datos reales y documenta el cambio.

Tips para un Proyecto Excelente

Lo que separa un proyecto "Bueno" de uno "Excelente"

Datos específicos, no genéricos. "50K requests/mes con duración promedio de 2.3 segundos" en vez de "tráfico moderado."
Justificación en cada evaluación. No solo "Serverless: Coste = 5." Sino "Serverless: Coste = 5 — Lambda a este volumen cuesta $1.25/mes vs $24/mes de VPS."
Sensitivity analysis incluido. "Si cambio el peso de coste de 25 a 15, el ganador sigue siendo Managed. La decisión es robusta."
Migration path concreto. No "migrar a AWS si crece." Sino "si > 10K req/día: (1) exportar Docker image, (2) crear EC2 t3.medium, (3) docker compose up, (4) redirigir DNS. Tiempo estimado: 4 horas."
Honestidad sobre incertidumbre. "El scoring de escalabilidad es estimado — no tenemos datos reales. Re-evaluamos en 4 semanas con métricas de producción."

Resultado Funcional

Al completar este proyecto, tendrás:

deployment-decision.md (o equivalente)
├── Contexto: Datos concretos de tu proyecto AI
├── Matrix: 5-7 criterios × 4 estrategias, ponderados
├── Costes: Estimación a 3 meses, 3+ estrategias
├── Recomendación: Con justificación y descartados
├── Re-evaluación: 3+ triggers con métricas
└── Review: Fecha y métricas a verificar

Este documento es:

Portfolio-worthy: Demuestra capacidad de tomar decisiones de infraestructura con criterio
Reutilizable: El framework aplica a cualquier decisión de deployment futura
Extensible: Se extiende en Módulo 7 (plataformas) y Módulo 8 (proyecto integrador)
Defendible: Cualquier ingeniero puede revisarlo, cuestionarlo, y entender tu razonamiento

Conexión con la Guía

¿Qué sigue?

Con tu decision matrix completada:

Módulo 2: Implementarás la estrategia "Local" con Docker Compose multi-container — independientemente de tu recomendación, porque necesitas dominar deployment local como base.
Módulo 3: Implementarás la estrategia "Serverless" con Lambda — para tener la habilidad en tu toolkit.
Módulos 4-6: Aprenderás AWS con LocalStack sin coste — para tener la opción cloud sin barreras.
Módulo 7: Extenderás tu decision matrix con criterios de plataforma (Render vs Railway vs Fly.io vs AWS).
Módulo 8: Aplicarás tu decision matrix actualizada para desplegar tu sistema AI en producción real.

Tu matrix del Módulo 1 es v1. La del Módulo 7 es v2. La del Módulo 8 es v_final — aplicada y verificada con un sistema real.

Evolución del documento

Módulo 1 (ahora): deployment-decision-v1.md
  → Evalúa 4 categorías, elige estrategia general

Módulo 7 (futuro): deployment-decision-v2.md
  → Agrega criterios de plataforma específica (Render vs Railway vs Fly.io)
  → Actualiza con datos reales si ya estás en producción

Módulo 8 (final): deployment-decision-final.md
  → Matrix aplicada al sistema desplegado en producción
  → Incluye métricas reales, costes verificados, lecciones aprendidas

Especificaciones Técnicas Extendidas

Formato del entregable

Tu deployment-decision.md debe ser un archivo Markdown autosuficiente. Cualquier persona del equipo debería poder abrir el archivo, leerlo de arriba a abajo, y entender: (1) qué app es, (2) qué opciones evaluaste, (3) por qué elegiste lo que elegiste, y (4) cuándo re-evaluar.

# Verifica que tu archivo es completo
wc -l deployment-decision.md
# Esperado: 100-200 líneas mínimo

# Verifica que tiene todas las secciones
grep "^## " deployment-decision.md
# Esperado:
# ## Contexto
# ## Decision Matrix
# ## Estimación de Costes
# ## Recomendación
# ## Re-evaluación (o similar)

Criterios de calidad del código Python (si incluyes scripts)

Si incluyes calculadoras o scripts Python en tu documento:

# ✅ Bueno: función reutilizable con parámetros
def estimate_cost(monthly_requests: int, model: str = "gpt-4o-mini") -> float:
    """Estima coste mensual de LLM APIs."""
    prices = {"gpt-4o-mini": 0.003, "gpt-4o": 0.06}
    return monthly_requests * prices.get(model, 0.003)

# ❌ Malo: números hardcoded sin contexto
cost = 50000 * 0.003  # ¿Qué es 50000? ¿Qué es 0.003?

Versionado del documento

Tu decision matrix es un documento vivo. Versiona con Git:

git add deployment-decision.md
git commit -m "feat: decision matrix v1 - Módulo 1"

# Después de re-evaluación:
git commit -m "update: decision matrix v1.1 - datos reales mes 1"

Resumen

El Deployment Decision Workshop es el proyecto integrador del Módulo 1 que produce un documento de decisión completo.
El entregable es un archivo deployment-decision.md con 5 secciones: contexto, matrix, costes, recomendación, y re-evaluación.
La rúbrica de 100 puntos evalúa: contexto (15), matrix (35), costes (20), recomendación (15), y re-evaluación (15).
Puedes usar el caso DocuSearch AI si no tienes app propia — tiene datos suficientemente reales.
Los pesos deben sumar 100 y reflejar tus prioridades reales, no valores uniformes.
Los costes incluyen 3 componentes: infraestructura + LLM APIs + tiempo de operación.
La matrix se reutiliza y extiende en los Módulos 7 (plataformas) y 8 (proyecto integrador).
Documenta cuándo re-evaluar con triggers específicos y métricas — es lo que convierte un documento estático en una herramienta viva.

Recursos para el Proyecto

Architecture Decision Records (ADR) — Formato estándar para documentar decisiones de arquitectura
AWS Well-Architected Framework — Framework de evaluación de arquitectura
Decision Matrix Template — Miro — Template visual de decision matrix
Cloud Cost Calculator — Vantage — Calculadora de costes cloud
Railway Pricing — Para estimación de costes managed
DigitalOcean Pricing — Para estimación de costes VPS

← Anterior7. Stage del Proyecto y Deployment Siguiente →1. Introducción: Local & Container Deployment