Serverless arrastra una promesa comercial muy repetida —pagas solo por ejecución, olvídate de los servidores— y una realidad más matizada. No es más barato por definición ni más caro por definición: depende casi por completo del patrón de carga y del tipo de trabajo que ejecuta.
La aritmética, sin marketing
El modelo de precio de serverless penaliza el uso continuo y premia el uso intermitente. Un servicio que recibe tráfico constante las 24 horas casi siempre sale más caro en funciones que en instancias reservadas: se está pagando la comodidad de no gestionar capacidad cuando la capacidad no hace falta gestionarla, porque es estable.
Al revés, un proceso que se ejecuta cuarenta veces al día durante dos segundos, o un pico que llega tres veces al año y multiplica la carga por cincuenta, es exactamente el caso para el que serverless fue diseñado. Ahí la alternativa es mantener capacidad ociosa el 99% del tiempo.
La regla práctica: si tu carga es predecible y sostenida, serverless te va a costar dinero. Si es impredecible o esporádica, te lo va a ahorrar.
Dónde encaja casi siempre
- Procesamiento por eventos. Reaccionar a la subida de un fichero, a un mensaje en una cola, a un cambio en una tabla. Es el caso canónico y el que mejor resultado da.
- Tareas programadas. Informes nocturnos, sincronizaciones, limpiezas. Sustituyen a una máquina encendida todo el mes para trabajar veinte minutos.
- Integraciones y pegamento entre sistemas. La lógica que conecta dos servicios y que nadie quiere alojar en ninguno de los dos.
- Picos extremos y poco frecuentes. Campañas, matrículas, cierres fiscales. Absorber ese pico con capacidad propia significa pagarla todo el año.
Dónde suele salir mal
Latencia sensible con arranques en frío. Si el compromiso de servicio se mide en decenas de milisegundos, el arranque en frío es un problema real. Se puede mitigar con capacidad aprovisionada, pero entonces se está pagando reserva y se ha perdido buena parte del argumento económico.
Procesos largos o intensivos. Hay límites de ejecución y de recursos. Forzarlos partiendo el trabajo en trozos añade una complejidad que rara vez compensa.
Conexiones a bases de datos tradicionales. Cientos de ejecuciones simultáneas abriendo conexiones agotan el pool. Es un problema conocido y resoluble, pero es trabajo adicional que nadie contempla en la estimación inicial.
Arquitecturas enteras construidas a base de funciones. Cien funciones con sus permisos, sus versiones y sus dependencias cruzadas son más difíciles de razonar que un servicio bien estructurado. La complejidad no desaparece, se traslada.
El compromiso que se asume
Conviene decirlo claro porque suele quedar en letra pequeña: serverless es, de todas las opciones de cómputo, la que más ata a un proveedor concreto. El modelo de eventos, los permisos y las integraciones son específicos, y migrar una arquitectura serverless a otra nube es prácticamente reescribirla.
Eso no lo descarta. Significa que la decisión debe tomarse sabiéndolo, y que conviene mantener la lógica de negocio separada de las particularidades del proveedor para que lo que haya que reescribir sea la envoltura y no el contenido.
La conclusión práctica
Serverless funciona muy bien como parte de una arquitectura y bastante mal como principio único. Las implantaciones que mejor resultado nos dan combinan servicios permanentes para el núcleo de tráfico estable y funciones para todo lo que es esporádico, reactivo o estacional.
¿Estáis valorando dónde encaja en vuestro caso? Contrastemos los números →
Sigue leyendo
- Tu factura cloud no baja sola: cómo recuperar el control del gasto
- ¿Multi-cloud o un solo proveedor? Cómo decidirlo sin dogmas
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.