Serverless en producción: lecciones aprendidas tras dos años

Introducción

Hace dos años, en Tanok Tech, decidimos migrar nuestra plataforma de procesamiento de eventos a una arquitectura serverless. AWS Lambda, API Gateway y DynamoDB se convirtieron en nuestros mejores aliados. Sin embargo, el camino no fue un lecho de rosas. Hoy compartimos las lecciones aprendidas para que no repitas nuestros errores.

Lo que promete serverless (y no siempre cumple)

Serverless suena ideal: sin servidores que administrar, escalabilidad automática, pago por uso. Pero en producción, la realidad es más compleja. Aquí tienes lo que encontramos:

1. Cold starts: el enemigo silencioso

Cada vez que una función Lambda se invoca después de un período de inactividad, sufre un cold start. En Java o .NET, esto puede añadir segundos de latencia. Lo solucionamos:

• Usamos provisioned concurrency para funciones críticas (mínimo 2 instancias siempre activas).
• Elegimos runtime ligeros como Node.js o Python para funciones de baja latencia.
• Minimizamos el tamaño del deployment (menos paquetes npm/pip).

Ejemplo de configuración de provisioned concurrency en Serverless Framework:

functions:
  procesarPedido:
    handler: handler.procesar
    provisionedConcurrency: 2

2. Costos: el monstruo bajo la cama

La factura puede dispararse si no monitoreas. Un bucle infinito o una mala configuración de tiempo de espera pueden generar miles de invocaciones en minutos.

Recomendaciones:

• Establece alertas de presupuesto en AWS Budgets.
• Configura timeouts realistas (ej: 30 segundos en lugar de 3 minutos por defecto).
• Revisa los logs de CloudWatch para detectar picos anómalos.

3. Observabilidad: más allá de CloudWatch

Lambda envía logs a CloudWatch, pero estructurarlos es clave. Implementamos powertools para AWS Lambda (Python) y creamos métricas personalizadas.

Ejemplo de log estructurado con Powertools:

from aws_lambda_powertools import Logger
logger = Logger()

def handler(event, context):
    logger.info("Procesando pedido", extra={"pedido_id": event["id"], "usuario": event["user"]})
    # lógica...

También usamos X-Ray para trazado distribuido y detectar cuellos de botella.

Estrategias que funcionaron

4. Patrón Saga para transacciones distribuidas

Cuando un paso falla (por ejemplo, cobro exitoso pero inventario insuficiente), necesitas compensar. Implementamos el patrón Saga con Step Functions:

• Una máquina de estado orquesta las funciones.
• Cada función tiene una compensate lambda que revierte la acción.

5. Bases de datos: DynamoDB vs Aurora Serverless

Para lecturas intensivas, DynamoDB con indexación adecuada es imbatible. Pero necesitábamos consultas complejas. Aurora Serverless v2 nos dio compatibilidad SQL con escalado automático.

Consejo: usa DynamoDB para cargas predecibles y Aurora para consultas ad-hoc.

Herramientas que nos salvaron

• Serverless Framework: infraestructura como código simple.
• Lambda Power Tuning: para encontrar el punto óptimo entre memoria y velocidad.
• Dashbird: monitoreo de costos y errores en tiempo real.

Lecciones duras

• No todo es serverless: procesos batch largos (más de 15 minutos) mejor en ECS Fargate.
• Las dependencias nativas son un dolor: si usas librerías con binarios (.so), prepárate para empaquetar en Amazon Linux.
• Los límites de Lambda existen: 10 GB de memoria, 15 minutos de timeout, 6 MB de payload en request/response.

Conclusión

Serverless no es una bala de plata, pero para aplicaciones con tráfico variable y equipos pequeños, sigue siendo una opción potente. Planifica, monitorea y acepta que la gestión de la complejidad se traslada del servidor a la configuración y el código.

Referencias

• AWS Lambda Best Practices (AWS Docs)
• Serverless Observability: A Practical Guide (Dashbird)