Introducción
El dilema que muchos equipos enfrentan al diseñar arquitecturas serverless: ¿cuánta granularidad es suficiente? En este post exploramos por qué las funciones Lambda no deberían confundirse con «funciones» en el sentido de programación, sino tratarse como microservicios.
El Problema: Sobre-Fragmentación
Escenario típico: necesitas crear un sistema para gestionar pedidos/ventas con una arquitectura serverless (API Gateway + Lambda). La pregunta crítica es:
¿cuántas funciones Lambda necesitas?
Si este mismo sistema se implementara en Kubernetes, ¿cuántos microservicios crearías? La respuesta debería ser la misma independientemente de la plataforma.
Antipatrón: Una Lambda por Endpoint
Problema de este enfoque:
- Acoplamiento fuerte con API Gateway: cada Lambda debe conocer la estructura exacta del payload
- Proliferación descontrolada: decenas de funciones para un solo dominio
- Complejidad operacional: pipelines de CI/CD más complejos, más difícil de mantener
- Código duplicado: lógica compartida repetida entre múltiples Lambdas
Ventajas (que no compensan)
- Cold start potencialmente menor por función específica
- Escalado independiente por operación
- Cambios muy localizados
Enfoque Recomendado: Lambda por Dominio
Principios clave:
- Una Lambda por bounded context/dominio, no por endpoint
- API Gateway como router inteligente: transforma y estandariza el payload
- La Lambda maneja el routing interno: determina qué operación ejecutar según el request
Beneficios:
- Alineación con principios de microservicios
- Menos complejidad operacional
- Código compartido más fácil de mantener
- Mejor cohesión del dominio de negocio
Consideraciones técnicas:
- Usa VTL (Velocity Template Language) o transformaciones en API Gateway
- Implementa un router interno en la Lambda (ej: basado en
httpMethodyresource) - Mantén las Lambdas enfocadas en un dominio específico
¿Cuándo dividir en múltiples Lambdas?
Divide cuando:
- Dominios diferentes: Ventas vs. Inventario vs. Usuarios
- Requisitos de escalado muy distintos: operaciones de lectura masiva vs. escrituras poco frecuentes
- Límites de Lambda: tiempo de ejecución o memoria insuficientes
- Equipos diferentes: cada equipo gestiona su dominio
Conclusión
Las funciones Lambda son un modelo de despliegue para microservicios, no una razón para sobre-fragmentar tu arquitectura. Aplica los mismos principios de diseño que usarías en cualquier arquitectura de microservicios.
En el próximo post: Implementación práctica con código real, patrones de routing, y configuración de API Gateway.
Referencias
https://docs.aws.amazon.com/apigateway/latest/developerguide/models-mappings.html
Deja una respuesta