Trabajar con Serverless Framework en AWS suena ideal hasta que la producción te enseña la letra pequeña. Aquí están las experiencias reales que cambian la forma de diseñar funciones Lambda, gestionar variables y elegir cuándo no usar serverless.

¿Qué pasa cuando una Lambda escala dentro de una red con pocas IPs?

Uno de los errores más memorables ocurre cuando se combina Lambda con una red privada de máscara muy pequeña, tipo /29 o /30. En desarrollo y QA todo funciona, pero cuando producción recibe usuarios reales, las Lambdas escalan por su naturaleza serverless y cada una pide una IP dentro de la VPC [01:35].

El resultado es predecible: la red colapsa porque no hay direcciones disponibles para las nuevas instancias. La aplicación se cae no por un bug de código, sino por una decisión de infraestructura que no contempló el comportamiento de escalado.

¿Por qué una Lambda dentro de una VPC se queda sin IPs? Porque cada Lambda concurrente necesita una ENI con su propia IP. Si la subnet tiene máscara /29 o /30, hay menos de 8 direcciones disponibles y el escalado se rompe.

Tumbar producción no es el fin del mundo. Es la forma más cara, pero más efectiva, de aprender lo que la documentación no siempre deja claro.

¿Cómo evitar el rate limit al leer variables desde Parameter Store?

Otra trampa frecuente: definir un cliente de Systems Manager Parameter Store dentro del código de la Lambda para traer variables en cada invocación [02:45]. Cuando la función escala, miles de invocaciones golpean Parameter Store al mismo tiempo y se llega al rate limit de la cuenta en esa región.

La solución elegante está en la sintaxis nativa de Serverless Framework. Usar la referencia tipo ${ssm:/ruta/variable} directamente en el archivo serverless.yml permite que el framework resuelva la variable en tiempo de despliegue, no en tiempo de ejecución.

• Define las variables en serverless.yml, no en el handler.
• Usa la sintaxis ${ssm:...} para Parameter Store.
• Reserva los clientes SDK dentro del código solo para datos que realmente cambian en runtime.

La moraleja es simple: serverless no es infinito. Se comporta como infinito en muchos escenarios, pero las cuotas, los límites de concurrencia y las dependencias externas siguen existiendo.

¿Cuándo no deberías usar serverless en AWS?

AWS suele recomendar Lambda para procesamiento de datos y ETL, pero no siempre es la mejor opción [04:20]. Cuando el procesamiento es muy pesado, requiere mucho cómputo continuo y debe correr 24/7, el modelo de cobro por uso de Lambda termina siendo más caro y menos eficiente que una instancia EC2 dedicada o un clúster específico para procesamiento.

¿Sirve Lambda para ETL pesados? Para cargas puntuales o por eventos, sí. Para procesos continuos 24/7 con alto cómputo, suele ser más rentable EC2, ECS o un clúster dedicado.

La estrategia ganadora suele ser híbrida. Plataformas grandes mezclan serverless con Kubernetes, contenedores y servidores tradicionales para atender distintas capas lógicas según el caso de uso.

¿Dónde aprender serverless más allá de la documentación oficial?

El ecosistema serverless evoluciona rápido y los recursos prácticos están repartidos. Estos son los lugares donde el conocimiento real circula:

• Serverless First y Serverless Land para guías y patrones.
• Twitter, siguiendo a los referentes que publican novedades del ecosistema.
• Medium, con artículos técnicos de casos reales.
• Foros y blogs de Platzi para fortalecer skills de código.

Leer no basta. Probar, fallar y reintentar es parte del proceso.

¿Qué falta para llevar una app serverless a producción real?

Un proyecto de curso es digno de portafolio, pero producción exige más. Cuando solo trabajas con el stage dev, te pierdes la complejidad de gestionar múltiples ambientes como UAT, QA y producción con flujos independientes en GitHub Actions [08:30].

Los conceptos que marcan la diferencia entre un demo y una aplicación productiva son:

• Monitoring para visibilidad operativa.
• Observability con trazas, métricas y logs estructurados.
• CI/CD con pipelines diferenciados por ambiente.
• Custom domains por stage.
• Buenas prácticas de código e infraestructura.

Ninguno de estos conceptos es exclusivo de serverless. Aplican igual a una app en máquina virtual o en Kubernetes, con matices propios de cada paradigma.

¿Serverless reemplaza a Kubernetes o conviven?

La historia va de un servidor con NGINX como balanceador, a contenedores orquestados con Kubernetes, hasta llegar a funciones sin servidor. Cada paso es evolución, no reemplazo [11:10]. Las aplicaciones legacy seguirán existiendo durante años, y muchos sistemas modernos usan un mix de Lambda, EKS, ECS con Fargate y contenedores según la necesidad.

Un caso típico de arquitectura mixta: un clúster de Kubernetes para la lógica principal y serverless para el custom authorizer en API Gateway que redirige tráfico interno al clúster.

¿Serverless Framework, Terraform, CDK o Pulumi?

Cada herramienta de infrastructure as code tiene su lugar. Serverless Framework brilla cuando defines código e infraestructura en el mismo archivo, reduciendo la brecha entre desarrollo y operaciones. Terraform es poderosísimo para recursos cloud estables, pero resulta incómodo para empaquetar y actualizar Lambdas constantemente.

¿Por qué Serverless Framework gana frente a Terraform en apps Lambda? Porque integra código e infraestructura en un solo flujo, mientras Terraform está optimizado para recursos cloud que no cambian con cada despliegue.

Una combinación frecuente: Serverless Framework para las funciones y APIs, Terraform o CDK o Pulumi para la infraestructura base que rara vez cambia, como clústeres de Kubernetes, VPCs y bases de datos [14:50].

¿Desaparece la brecha entre desarrolladores e infraestructura?

La respuesta honesta es: depende. Algunos prefieren olvidarse del servidor y delegar todo a Serverless Framework. Otros disfrutan aprovisionar máquinas, conectarse por SSH y ajustar Linux a mano. Y muchos quieren lo mejor de ambos mundos según el caso.

No somos fans de una herramienta, somos cloud developers. El objetivo es que la aplicación funcione, escale y entregue buena experiencia al usuario.

¿Ya conocías estas prácticas? ¿Te gustaría un curso avanzado sobre Serverless Framework en AWS con monitoring, observability y CI/CD multi-ambiente? Cuéntanos en los comentarios qué herramienta de orquestación usas hoy.