FaaS en 2026: Costos Ocultos y el Salto a WebAssembly

El serverles o scomputación sin servidor, es un modelo de ejecución donde el proveedor de nube asigna recursos de máquinas virtuales bajo demanda y asume la responsabilidad total sobre los servidores físicos y su mantenimiento. Los desarrolladores no necesitan planificar capacidad, configurar políticas de autoescalado ni gestionar parches de seguridad del sistema operativo. El término sugiere ausencia de hardware, pero la realidad técnica se sostiene en servidores gestionados de forma invisible para el consumidor, lo que permite tratar los recursos informáticos como servicios puros.

AWS Lambda, introducido en 2014, se convirtió en el referente del modelo abstracto de computación serverless. Cada instancia de función se ejecuta en un entorno aislado y ligero mediante microVMs Firecracker, que se inician con entornos de ejecución basados en Amazon Linux optimizados para cargas de trabajo nativas de la nube.

Firecracker busca un aislamiento basado en virtualización de hardware con un rendimiento cercano al metal y una sobrecarga mínima. Estas unidades de ejecución se lanzan en milisegundos, lo que facilita una ejecución de código segura y rápida con una huella de memoria reducida. El soporte de lenguajes incluye Node.js, Python, Java, Go, .NET, Ruby y runtimes personalizados.

El esquema de precios en FaaS se basa típicamente en dos dimensiones: el número de solicitudes y la duración de la ejecución. Las solicitudes se contabilizan cada vez que el código comienza a ejecutarse en respuesta a un evento o a una llamada de invocación; la duración se calcula desde que el código inicia hasta que devuelve una respuesta o termina, redondeada habitualmente al milisegundo más cercano.

La memoria asignada es un factor determinante en el gasto. En AWS Lambda, elegir el volumen de memoria para una función asigna automáticamente una capacidad proporcional de CPU y otros recursos, de modo que un incremento en el tamaño de la memoria dispara un aumento equivalente en la potencia de procesamiento disponible. Esta relación lineal puede forzar a sobredimensionar la memoria solo para obtener más velocidad de CPU, lo que infla los costos si la carga de trabajo no requiere tanta RAM.

Investigaciones sobre plataformas públicas registran que las prácticas de facturación pueden inflar los recursos facturables hasta 4.35 veces por encima del consumo real. El fenómeno ocurre porque la facturación se basa en el tiempo de reloj de pared (wall-clock time), que incluye los periodos en que la función mantiene recursos asignados pero permanece inactiva, por ejemplo mientras espera la respuesta de una llamada a una API remota.

Más del 65% de las solicitudes utiliza menos del 50% de la CPU asignada, y cerca del 76% emplea menos de la mitad de la memoria permitida, según los mismos datos. La falta de correlación lineal entre el uso de CPU y memoria indica que desacoplar ambas configuraciones reduciría el gasto innecesario. La mayoría de los proveedores aplica además un costo fijo por invocación que, aunque parece mínimo, representa una carga desproporcionada para funciones de muy corta duración.

Recomendado Inteligencia Artificial

Edge AI: cómo la inteligencia artificial está dejando de depender de la nube

Hace 44 días Leer ahora

El arranque en frío (cold start) es una de las principales causas de degradación del rendimiento en aplicaciones FaaS. El retraso ocurre cuando el proveedor debe inicializar un nuevo sandbox de ejecución para una función que no tiene instancias calientes disponibles. Para mitigarlo, los proveedores mantienen los sandboxes activos durante un periodo tras cada solicitud, práctica conocida como keep-alive.

Desde agosto de 2025, AWS incluye la fase de inicialización dentro de la duración facturable, un cambio orientado a compensar el costo del despliegue de infraestructura para el proveedor.

La arquitectura de servicio elegida por cada proveedor añade una latencia adicional. Las plataformas que usan servidores HTTP internos, como Google Cloud o Azure, presentan una sobrecarga mayor que el modelo de runtime API long polling de AWS Lambda o la ejecución binaria de Cloudflare Workers.

En mediciones de funciones mínimas, el modelo de servidor HTTP añade hasta 5.93 ms de latencia promedio por el mantenimiento de listeners, conexiones y enrutamiento de handlers. AWS Lambda mantiene una sobrecarga estable de aproximadamente 1.17 ms, y Cloudflare Workers entrega latencias cercanas a cero.

Llegado 2026, la decisión entre orquestación de contenedores y FaaS se volvió más matizada. Kubernetes ofrece control total sobre el entorno y el escalado al costo de una complejidad operativa elevada; Serverless prioriza la simplicidad, sacrificando parte del control sobre el runtime.

Para cargas de trabajo intermitentes, el modelo FaaS resulta difícil de superar en costo. Una API que gestiona 100,000 solicitudes al mes puede costar apenas 0.35 dólares en AWS Lambda, mientras que mantener un clúster mínimo de Kubernetes (EKS), con su plano de control y nodos básicos, asciende a unos 149 dólares mensuales.

El ahorro se desvanece al escalar. El análisis de cruce de costos indica que, entre 30 y 40 millones de solicitudes mensuales, Kubernetes suele volverse la opción más económica; superado ese umbral, el costo por invocación y los cargos por servicios adyacentes —como API Gateway o NAT Gateway— en Serverless superan el gasto operativo y de infraestructura de un clúster de contenedores bien optimizado.

Una innovación relevante en el ecosistema es el surgimiento de runtimes basados en WebAssembly (Wasm), que aborda tres problemas críticos del FaaS tradicional.

Recomendado Arquitectura de Software

WebAssembly y Rust: el código que corre en cualquier lugar del planeta

Hace 44 días Leer ahora

Plataformas como Cloudflare Workers, Fermyon Spin y Fastly Compute ya operan bajo este paradigma, mientras AWS Lambda comenzó a integrar vistas previas de runtimes Wasm personalizados.

Un hallazgo técnico relevante es el impacto de la programación (scheduling) del kernel Linux en la ejecución de funciones cortas. La mayoría de los proveedores utiliza planificadores como CFS (Completely Fair Scheduler) o EEVDF. En entornos FaaS, donde los tiempos de ejecución suelen ser menores que el tick del reloj del sistema operativo, se producen fenómenos de sobreasignación de CPU.

Cuando una función solicita una fracción de CPU —por ejemplo, 0.5 vCPUs—, el sistema operativo a menudo le permite consumir el 100% del procesador durante breves ráfagas antes de aplicar limitaciones (throttling). Esta cuantización provoca que las funciones se ejecuten más rápido de lo esperado en teoría, pero también introduce fluctuaciones de rendimiento (jitter) cuando las asignaciones están cerca de los límites de cuantización. Los proveedores absorben este uso de recursos no contabilizado mediante tarifas de invocación elevadas y una granularidad de facturación que históricamente favoreció el redondeo al alza.

Las organizaciones maduras en 2026 raramente eligen una opción exclusiva; la tendencia dominante es la arquitectura híbrida, que combina un núcleo estable con un borde elástico.

La clave para gestionar esta dualidad está en el uso de buses de eventos, como EventBridge o Kafka, que actúan como puente entre ambos mundos y reducen la complejidad del networking y el acoplamiento entre servicios.

Al evaluar el paso a serverless, no basta con considerar la factura de infraestructura. El TCO se compone de tres pilares.

En términos operativos, si una función serverless está activa durante tres cuartas partes del mes, solo necesita generar 10 minutos de ahorro en tareas de mantenimiento para superar en rentabilidad a una máquina virtual tradicional.

La elección de una infraestructura debería permitir que el equipo se concentre en el producto, no que la infraestructura se convierta en el producto. Serverless no es solo una forma de ahorrar en servidores: funciona como acelerador de agilidad cuando la prioridad es la velocidad de salida al mercado, con las asimetrías de costo que muestran los datos de FinOps como el precio de esa simplicidad. Los volúmenes masivos y constantes de tráfico, en cambio, siguen inclinando la balanza hacia la precisión económica de Kubernetes o hacia la eficiencia recién ganada del Serverless 2.0 basado en Wasm; la pregunta ya no es qué modelo gana, sino en qué punto de la curva de tráfico conviene cruzar de uno a otro.