Funciones serverless y sus trade-offs
Serverless no es no tener servidores: es no administrarlos y pagar por ejecución. Eso cambia el modelo de costo, el de concurrencia y el de latencia, y cada uno tiene un caso donde conviene y otro donde sale carísimo.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
La promesa es difícil de resistir: subís una función, el proveedor la ejecuta cuando alguien la llama, escala sola y cuando nadie la usa no se paga nada. Sin instancias, sin parches, sin balanceador.
Todo eso es cierto. Lo que la promesa no dice es que a cambio cambian tres reglas del juego —cómo se cobra, cómo escala y cuánto tarda la primera invocación— y que hay arquitecturas donde esas tres reglas juegan en contra.
Qué cambia respecto de una instancia
- Tu equipo
Datos
Lo que cargan tus usuarios y su clasificación
- Compartida
Identidad y permisos
Quién entra, con qué rol y hasta dónde llega
- Tu equipo
Aplicación
Tu código y su configuración
- Proveedor
Runtime y dependencias
Intérprete, bibliotecas, servidor de aplicaciones
- Proveedor
Sistema operativo
Kernel, parches, usuarios del sistema
- Proveedor
Virtualización
Hipervisor, aislamiento entre inquilinos
- Proveedor
Hardware y red física
Servidores, discos, switches, cableado
- Proveedor
Instalaciones
Edificio, energía, refrigeración, acceso físico
5 de 8 capas las opera el proveedor · 1 compartida · 2 quedan de tu lado · 5 menos que con un servidor propio
| Instancia o contenedor siempre prendido | Función serverless | |
|---|---|---|
| Unidad de cobro | Tiempo encendido | Invocaciones y tiempo de ejecución por memoria asignada |
| Con cero tráfico | Se paga igual | No se paga |
| Escalado | Autoescalado, de minutos | Por invocación, de milisegundos |
| Estado en memoria | Persiste entre requests | Sólo mientras el entorno siga tibio |
| Duración máxima | La que haga falta | Un tope del servicio, del orden de minutos |
| Primera invocación | Ya está caliente | Puede pagar un arranque en frío |
La consecuencia que más sorprende: la memoria asignada también determina la CPU. Subir la memoria de una función que hace trabajo de cómputo puede bajar el costo total, porque termina proporcionalmente más rápido. Es el único caso donde pedir más recursos sale más barato.
El arranque en frío, sin mitología
Cuando no hay un entorno listo, el proveedor tiene que crear uno: descargar el código, levantar el tiempo de ejecución, correr la inicialización del módulo y recién ahí ejecutar el manejador.
Qué domina el tiempo de arranque
- El tamaño del paquete: un artefacto con cien megabytes de dependencias tarda en bajarse y descomprimirse.
- El tiempo de ejecución: los lenguajes interpretados y los binarios nativos arrancan rápido; una JVM o un .NET con mucha inicialización, no tanto.
- Lo que se hace fuera del manejador: leer secretos, abrir conexiones y construir clientes al cargar el módulo se paga una vez por entorno nuevo, y conviene que sea así.
- Estar dentro de una red privada: históricamente era el costo más grande; hoy los proveedores lo resolvieron en gran medida con interfaces de red preasignadas.
Antes de seguir, predecí
Concurrencia: escala sola hasta que choca contra algo
El modelo de concurrencia de una función es simple: una invocación por entorno a la vez. Diez requests simultáneas son diez entornos. Eso es lo que hace que escale sin configurar nada, y también lo que hace que el sistema de al lado sufra.
Los tres límites que aparecen en orden
- El límite de concurrencia de la cuenta, compartido entre todas las funciones de la región. Una función que se dispara puede dejar sin capacidad a las demás; por eso existe reservar concurrencia por función.
- Lo que hay detrás: la base, la API de terceros, el sistema heredado. Escalar a mil invocaciones concurrentes sobre un servicio que tolera cincuenta no es escalar, es un ataque propio.
- El presupuesto: con pago por ejecución, un bucle de invocaciones o un evento que se retroalimenta se traduce en factura, no en caída. Conviene un tope de concurrencia y una alerta de gasto.
Dónde está el cruce de costos
Con pago por uso, la pregunta no es “¿cuánto sale?” sino “¿a partir de qué nivel de uso deja de convenir?”.
Bajo demanda
US$ 10,00
Pagás lo encendido. Apagar ahorra.
Compromiso a 1 año
US$ 21,90
Se paga el mes entero. Conviene a partir de 438 h.
Compromiso a 3 años
US$ 14,60
Se paga el mes entero. Conviene a partir de 292 h.
Capacidad interrumpible
US$ 2,00
Te la pueden sacar con poco aviso. Sólo para trabajo que tolera cortes.
Sobre un precio de referencia de US$ 0,05 por hora. Los descuentos son órdenes de magnitud típicos: el número real sale de la calculadora del proveedor.
La regla práctica que resume el cruce: a tráfico bajo o muy irregular, serverless es imbatible; a tráfico alto y parejo, una instancia o un contenedor siempre prendido sale menos. En el medio pesan más otras cosas: cuánto tiempo de operación se ahorra y qué tan bien encaja el trabajo en el modelo de ejecución.
Antes de seguir, predecí
Cuándo conviene y cuándo no
| Caso | Encaja | Por qué |
|---|---|---|
| Reaccionar a un evento del proveedor | Muy bien | El disparador ya existe y el trabajo es corto |
| API de tráfico bajo o irregular | Bien | Con cero tráfico no se paga y escala sin configurar |
| Tareas programadas | Bien | Corren minutos por día y una instancia estaría ociosa |
| API de latencia muy estricta | Mal | El arranque en frío es difícil de acotar del todo |
| Proceso largo o que necesita estado | Mal | Tope de duración y entorno efímero |
| Tráfico alto y parejo | Regular | Funciona, pero el costo por invocación deja de convenir |
Más a fondo · nivel seniorEl costo que no está en la factura: probar y observar
Lo que más se subestima de una arquitectura de funciones no es el precio por invocación sino la dificultad de entenderla cuando falla. El flujo deja de ser una pila de llamadas y pasa a ser una cadena de eventos entre servicios gestionados, así que hace falta trazado distribuido desde el primer día: sin un identificador de correlación que viaje con el evento, reconstruir qué pasó es leer logs de cinco servicios y adivinar el orden.
Y probar localmente deja de ser gratis: los emuladores cubren una parte, pero los permisos, los disparadores y los límites de concurrencia sólo se comportan de verdad en la nube. La respuesta habitual es un entorno desplegable por rama —barato justamente porque con cero tráfico no se paga— y tests de integración contra ese entorno en vez de simulaciones locales que dan falsa confianza.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica