WASI 0.3 trae async nativo a WebAssembly: la apuesta real no es reemplazar contenedores, sino eliminar el 83% de gasto idle

El 83% de tu presupuesto en contenedores paga por servidores inactivos

Segun el informe State of Cloud Costs 2024 de Datadog, el 83% de los costos asociados a contenedores corresponde a recursos inactivos. Desglosado: un 54% proviene de clusters sobredimensionados y un 29% de workloads con resource requests inflados respecto al consumo real. Los datos son claros: de cada 100 dolares que una organizacion invierte en infraestructura containerizada, 83 financian capacidad que no procesa ni una sola peticion.

Cualquier SRE que haya pasado una semana ajustando HPA y VPA en Kubernetes sabe exactamente lo que significan esos numeros.

Decir que WebAssembly es un "container killer" queda bien en un titular. No resiste un analisis serio. Lo que Wasm propone no es un reemplazo universal de Docker o Kubernetes, sino una alternativa para el segmento donde los contenedores son mas ineficientes: workloads efimeros y stateless que se despliegan, permanecen inactivos la mayor parte del tiempo y se destruyen. La propuesta es radical en ese nicho concreto: no optimizar el idle, sino eliminarlo.

Cloudflare procesa mas de 10 millones de requests por segundo en WebAssembly distribuidos en 330+ ubicaciones edge. Produccion real, no benchmarks de laboratorio.

WASI 0.3: el async nativo que faltaba

Hasta ahora, WebAssembly fuera del navegador tenia un problema fundamental que ninguna optimizacion de cold starts en serverless podia resolver: la ausencia de I/O asincrono nativo. WASI 0.2 obligaba a los modulos a operar de forma sincrona, lo que significaba que cualquier operacion de red o disco bloqueaba el hilo de ejecucion. Para workloads HTTP reales —donde una request puede implicar consultas a bases de datos, llamadas a APIs externas o lecturas de almacenamiento— esa limitacion convertia a Wasm en una curiosidad tecnica mas que en una alternativa viable.

WASI 0.3, cuya finalizacion se espera en febrero de 2026, introduce tipos stream<T> y future<T> directamente en el Component Model. No es un wrapper sobre callbacks ni un polyfill. Es async de primera clase a nivel de Canonical ABI.

Que resuelve concretamente

El "function coloring problem" desaparece: un componente puede exportar una funcion sincrona que internamente consume imports asincronos, y viceversa. El runtime (Wasmtime 37.0.0 ya lo soporta como opt-in experimental) gestiona la conversion de forma transparente. Un desarrollador escribe codigo Rust o Go sincrono y lo despliega en un entorno que maneja miles de conexiones concurrentes sin reescribir la logica.

Once resource types menos. Cada uno que un runtime debe implementar es superficie de ataque, es documentacion que mantener, es una decision de diseno que un SDK debe abstraer. Reducir de 11 a 5 permite que el ecosistema de tooling madure mas rapido.

Wasmtime 37.0.0 incluye soporte inicial para Linux PAGEMAP_SCAN, que acelera la instanciacion serverless al reutilizar paginas de memoria pre-inicializadas. Optimizacion a nivel de kernel. Esto ya no es un proyecto academico.

Quien esta apostando dinero real

En diciembre de 2025, Akamai adquirio Fermyon por una suma no revelada. Fermyon habia levantado 20 millones de dolares de Insight Partners para construir Spin, una plataforma FaaS basada en WebAssembly que logra cold starts de menos de 0.5 milisegundos y tiempos de relanzamiento de aplicaciones de 52 milisegundos. No fue un acqui-hire. Akamai tiene mas de 4,000 Points of Presence globales, y la integracion de Spin y SpinKube (proyecto CNCF) en esa infraestructura significa que la CDN con mayor cobertura del mundo esta construyendo su estrategia de edge compute sobre WebAssembly. Cuando una empresa con capitalizacion de mercado de aproximadamente 15,000 millones de dolares toma esa decision, la direccion es inequivoca.

Adobe aporta cifras concretas desde el otro lado: tras migrar a wasmCloud, reporto una reduccion del 30% en costos de infraestructura, un 80% de mejora en velocidad de despliegue y cold starts sub-millisegundo.

El ecosistema institucional refuerza la tendencia. La Bytecode Alliance —el consorcio que gobierna las especificaciones de Wasm server-side— cuenta con Microsoft, Google, Intel, Fastly, Arm, Shopify y Mozilla entre sus miembros. wasmCloud alcanzo el nivel Incubating de la CNCF en noviembre de 2024 con 3,275 contribuidores (+21% interanual) y 1,172 organizaciones participantes (+16% interanual). Mi experiencia analizando metricas de proyectos CNCF durante la ultima decada sugiere que un health score de 76 y crecimiento de doble digito en contribuidores corporativos es un indicador fiable de traccion real, no de hype temporal.

El asterisco que nadie menciona

12,000 de 29,000 programas simples en C compilan a binarios Wasm estables. Una tasa de exito del 41.4%.

Ese dato deberia aparecer en negrita en cada articulo que proclame que WebAssembly va a "reemplazar contenedores". No aparece. Es mas comodo hablar de cold starts rapidos que de la realidad del toolchain para lenguajes que no son Rust.

Rust tiene soporte de primera clase para Wasm. Go funciona con limitaciones. Java esta mejorando gracias a GraalVM. Python es experimental. Y el vasto universo de codigo C/C++ existente —el que mueve bases de datos, proxies, runtimes— se enfrenta a una barrera de compilacion que WASI 0.3 no resuelve, porque el problema no es el I/O asincrono sino la cobertura del compilador. Es frustrante que en 2026 todavia no tengamos metricas publicas de compilacion exitosa por lenguaje mas alla de los benchmarks que cada vendor publica selectivamente.

Y luego esta el problema de fondo: Wasm no soporta servicios stateful de larga duracion. Si tu workload es una base de datos, un cache distribuido o una cola de mensajes, los contenedores siguen siendo la unica opcion. El Component Model esta en Fase 2/3 del W3C y no tiene soporte en navegadores web, lo que limita la promesa de "write once, run anywhere" al server-side. WASI 1.0 —la version que las empresas necesitan para estandarizar con confianza— no llegara hasta finales de 2026 o principios de 2027.

Disclaimer: mi analisis se basa en datos publicos disponibles. No tengo acceso a las metricas internas de compilacion de los vendors ni a los datos de adoption rate de sus clientes enterprise.

Contenedores y Wasm: coexistencia, no extincion

Solomon Hykes, cofundador de Docker, ha sido explicito: WebAssembly "no es en absoluto un reemplazo" de los contenedores y todavia carece de "un caso de uso mainstream en el servidor". Viniendo de alguien que en 2019 dijo que si Wasm y WASI hubieran existido antes, Docker no habria sido necesario, la matizacion resulta reveladora (y conveniente para alguien cuyo legado depende de que los contenedores sigan siendo relevantes).

Docker Desktop ya soporta la ejecucion nativa de contenedores Wasm junto a contenedores tradicionales. Docker, como era de esperar, prefiere el discurso de la complementariedad. En terminos practicos, la estrategia de Docker apunta a una arquitectura hibrida donde los workloads efimeros y stateless corren en Wasm (cold starts por debajo del milisegundo, binarios de 2-10 MB, footprint de memoria de 1-10 MB) y los servicios stateful y de larga duracion permanecen en contenedores.

El mercado laboral lo confirma: aproximadamente 80 posiciones de WebAssembly en LinkedIn US frente a miles de roles Kubernetes/Docker. La adopcion en produccion esta creciendo —el 5.5% de los page loads de Chrome usan WebAssembly, subiendo desde el 4.5%— pero el ecosistema de talento aun no acompana.

Si tus costos de contenedores superan los 50,000 dolares mensuales y mas del 60% de tus workloads son stateless y efimeros, ejecuta un piloto con Fermyon Spin o wasmCloud en un segmento no critico. Mide el delta de costos durante 90 dias. Si la reduccion supera el 20% (Adobe logro 30%), tienes un business case. Si no, los contenedores optimizados con rightsizing siguen siendo la opcion racional. No se trata de fe en una tecnologia. Se trata de medir.