Despliegue Serverless

El Problema

Serverless promete “despliega y olvidate” pero entrega cold starts, timeouts de funciones, limites de memoria y peculiaridades del proveedor que no se parecen en nada a tu entorno de desarrollo local. Tu funcion funciona perfectamente en local pero falla a escala con errores de timeout misteriosos. Entender cuando serverless es la opcion correcta — y como sortear sus limitaciones — marca la diferencia entre una arquitectura rapida y barata, y una costosa e inestable.

El Prompt

Eres un experto en despliegue serverless. Ayudame a desplegar mi aplicacion en una plataforma serverless.

DETALLES DE LA APLICACION:
- Que hace: [ej., API REST, procesamiento de imagenes, jobs programados, handler de webhooks]
- Runtime: [ej., Node.js 20, Python 3.12, Go]
- Dependencias: [ej., ligeras, librerias ML pesadas, conexiones a base de datos]
- Trafico esperado: [ej., 100 req/dia, 10k req/hora, rafagas/constante]
- Preferencia de plataforma: [ej., AWS Lambda, Vercel Functions, Netlify Functions, Cloudflare Workers]

Ayudame con:
1. **Ajuste arquitectonico**: Es serverless adecuado para esta carga de trabajo?
2. **Diseño de funciones**: Como estructurar funciones — responsabilidad unica, layers compartidos, connection pooling.
3. **Mitigacion de cold starts**: Tecnicas especificas de plataforma para minimizar cold starts.
4. **Configuracion**: Configuraciones optimas de memoria, timeout y concurrencia.
5. **Desarrollo local**: Como desarrollar y probar localmente con un entorno similar a serverless.
6. **Pipeline de despliegue**: CI/CD para serverless — infraestructura como codigo, versionado, rollback.
7. **Estimacion de costos**: Costo mensual proyectado basado en mi patron de trafico.

Ejemplo de Salida

Ajuste arquitectonico: API REST → BUEN ajuste (solicitudes cortas, trafico variable)
  Procesamiento de imagenes → PRECAUCION (intensivo en memoria, puede alcanzar timeout de 10s)
  Servidor WebSocket → MAL ajuste (serverless no puede mantener conexiones largas)

Mitigacion de cold starts (AWS Lambda + Node.js):
- Bundlear con esbuild (reducir tamaño de paquete de 50MB a 2MB)
- Provisioned concurrency para endpoints criticos (5 instancias = ~$15/mes)
- Mover imports pesados fuera del handler (inicializados una vez por contenedor)
- Arquitectura ARM64 (20% cold start mas rapido, 20% mas barato)

Costo estimado: 10k req/hora × 200ms promedio × 256MB = ~$8/mes

Cuando Usarlo

Usa este skill al evaluar si serverless se ajusta a tu carga de trabajo, al migrar desde servidores tradicionales, o al optimizar un despliegue serverless existente.

Consejos Pro

• El tamaño del bundle afecta directamente el tiempo de cold start — cada megabyte de dependencias agrega 50-100ms al cold start. Usa tree-shaking y evita importar SDKs completos.
• Las conexiones a base de datos son el talon de Aquiles de serverless — cada instancia de funcion abre su propia conexion. Usa connection pooling (RDS Proxy, PgBouncer).
• Configura alarmas en limites de concurrencia — AWS Lambda tiene por defecto 1000 ejecuciones concurrentes por region. Una funcion descontrolada puede consumir toda tu cuota.
• Las pruebas locales no son pruebas de produccion — las herramientas offline simulan el entorno pero pierden cold starts reales, permisos IAM y latencia de VPC.