Durante años, el modelo serverless fue una pequeña revolución dentro del mundo cloud: nos prometía olvidarnos de los servidores, de la infraestructura, y centrarnos solo en escribir funciones que “simplemente funcionaban”. AWS Lambda, Google Cloud Functions o Azure Functions transformaron por completo cómo pensábamos en el despliegue de aplicaciones.
Pero hoy, en 2025, el entusiasmo inicial se ha estabilizado. Las empresas ya no preguntan qué es serverless, sino cuándo y cómo usarlo bien… y sobre todo: ¿hay algo más allá?
¿El final de la euforia?
Serverless ha traído beneficios muy reales: escalado automático, pago por uso, facilidad de despliegue. Pero no es una varita mágica. En arquitecturas complejas, pueden surgir nuevos retos:
- Observabilidad limitada: depurar y monitorizar funciones serverless sigue siendo más complejo que en entornos más tradicionales.
- Límites por diseño: muchas plataformas imponen restricciones que obligan a diseñar con cuidado. Por ejemplo, en AWS Lambda, la cantidad de CPU disponible para una función está directamente ligada a la cantidad de memoria asignada. Si necesitas más CPU, tendrás que asignar también más RAM —aunque no la necesites—, lo que afecta directamente al coste.
- Acoplamientos invisibles: muchas funciones acaban unidas por triggers, colas o eventos cuya relación no siempre es fácil de seguir, generando arquitecturas difíciles de auditar o modificar.
Serverless sigue siendo útil, pero está lejos de ser el modelo perfecto para todos los escenarios.
WebAssembly: ¿el siguiente paso natural?
En este contexto, WebAssembly (Wasm) ha emergido como una alternativa potente para imaginar el siguiente paso más allá del serverless tradicional. Como ya hemos explorado en otras entradas de este blog, Wasm ofrece una forma de ejecutar código de forma portable, rápida y segura, tanto en el cloud como en el edge.
Su propuesta resulta especialmente atractiva para las limitaciones del serverless actual: contenedores ligeros, carga casi instantánea, mayor control sobre los recursos, y entornos de ejecución más flexibles. Además, Wasm es agnóstico respecto al proveedor: se puede ejecutar en múltiples plataformas sin necesidad de adaptaciones profundas.
Proyectos como Fermyon, Spin, WasmCloud o Suborbital están empezando a construir un nuevo “runtime cloud-native”, que no depende del modelo tradicional de funciones ni de contenedores pesados.
¿El resultado? Una forma de computación donde el arranque es inmediato, la portabilidad es real, y el control sobre los recursos está mucho más afinado.
¿Un futuro multiruntime?
Donde antes había una opción dominante —la función serverless clásica—, ahora se abre un paisaje más variado: runtimes ligeros, despliegues en el edge, ejecución basada en WebAssembly o incluso híbridos entre serverless y long-running services.
En este nuevo escenario, pensar en “serverless vs. contenedores” puede quedarse corto. El foco está cambiando hacia algo más profundo: elegir el runtime más adecuado para cada caso, y diseñar sistemas que puedan adaptarse con flexibilidad al contexto, la carga y los requisitos.
Conclusión
Serverless no ha muerto: ha madurado. Se ha convertido en una herramienta estable dentro del ecosistema cloud. Pero como todo lo que madura, ha dejado de ser revolucionario para convertirse en una pieza más del puzzle.
Y mientras tanto, nuevas piezas —como Wasm— están empezando a encajar en ese puzzle con formas que todavía estamos aprendiendo a interpretar.
La pregunta ya no es si habrá algo después de serverless, sino cómo y cuándo lo adoptaremos.
Leave a Reply