Netlify sacó sus Edge Functions de la plataforma de un tercero y las metió en microVMs que corren dentro de su propia red. El resultado que publicó ayer su equipo de ingeniería: la invocación caliente pasó de 25–40 ms a 5–6 ms en la mediana, con el p99 un 47.4% más rápido. Y el cambio de fondo no es de rendimiento, es de modelo de aislamiento: de V8 isolates a máquinas virtuales separadas por hardware.
Qué pasó
Durante el último año Netlify reconstruyó la infraestructura detrás de Edge Functions junto con Unikraft, que publicó su propia versión de la historia. Hasta ahora, cuando una request coincidía con la ruta de una edge function, la petición salía de la red de Netlify hacia un servicio de ejecución hosted que corría el código en V8 isolates, y regresaba con la respuesta. Ese viaje de ida y vuelta era el que se pagaba en time to first byte.
Hoy la request se queda dentro: el edge node termina TLS, compara la ruta contra las edge functions del deploy y, si hay match, la manda a un compute node de la propia red, que la entrega a un microVM. Una invocación fría —que ocurre en apenas 1.2% de los casos— cuesta unos 9 ms de promedio porque toca descargar las imágenes de la función a ese nodo.
Nada cambia para quien escribe el código: URL imports, paquetes npm, built-ins de Node y las declaraciones de netlify.toml siguen funcionando igual.
Por qué importa
Dos razones, y ninguna es "5x más rápido".
La primera es soberanía sobre el runtime. El proveedor anterior controlaba la ejecución, el balanceo, la asignación de cómputo y —clave— el runtime mismo. Los clientes de Netlify pedían acceso a filesystem, carga de WASM y módulos npm nativos, y Netlify no podía dárselos porque no era dueño de la capa que lo impedía. Es el clásico techo de una arquitectura construida sobre el PaaS de alguien más: tu roadmap termina donde empieza el de tu proveedor. En el análisis interno de finales de 2025 las opciones eran tres —quedarse, construir desde cero, o moverse a Unikraft— y ganó la tercera.
La segunda es el modelo de aislamiento multi-tenant. Un V8 isolate separa tenants con las garantías del motor de JavaScript: barato, rápido, y en la misma superficie de proceso. Un microVM separa con virtualización asistida por hardware. Cualquiera que haya explicado a un cliente regulado por qué su código y el del vecino comparten proceso conoce el valor de esa diapositiva. Netlify se llevó el aislamiento por hardware sin salirse de su presupuesto de latencia, que es la parte difícil.
El detalle técnico
La pieza elegante es cómo se decide dónde corre el código. Antes de mover la request, el edge node escribe una especificación de la máquina: nombra tres imágenes (el runtime, la imagen de plataforma de Netlify y la imagen de la edge function) y fija límites de CPU, memoria y conexiones. El hash de esa spec más los datos del sitio se convierten en un service ID que viaja con cada request.
El compute node revisa si ya existe un service con ese ID. Si sí, lo reutiliza; si no, lo crea y verifica que tenga las imágenes en disco, pidiendo al edge node solo las que falten. Así únicamente se distribuyen las imágenes que reciben tráfico real en esa región, en lugar de replicar toda la flota ante cada deploy. Cada service permite varios microVMs del mismo sitio, con un tope fijo de requests por VM antes de apagarla y arranque anticipado de la siguiente para no quedarse sin capacidad.
El arranque es lo que hace viable todo el esquema: los microVMs de Unikraft bootean directo al workload en ~2 ms, sobre un sistema mínimo hecho para esa carga.
"El arranque rápido y la carga de imágenes on-demand nos permiten poner el código de cualquier cliente en cualquier nodo, en tiempo de request, sin pre-provisionarlo en todos lados." — Equipo de plataforma de Netlify
Netlify se queda con el balanceo, el control plane y la política de colocación; Unikraft aporta la capa de ejecución. Y como apuntan ellos mismos: a 400 millones de creaciones de VM por día, cualquier fallo con probabilidad estadísticamente ridícula está garantizado que va a ocurrir.
Vale la pena el matiz que dominó la discusión en Hacker News: buena parte de la mejora viene de eliminar el salto fuera de la red, no de que un microVM sea intrínsecamente más rápido que un isolate. Cloudflare Workers, que sigue corriendo isolates, jamás sacó la request de su red y opera con overheads comparables. La comparación honesta no es "microVM vs isolate", es "dentro de mi red vs en la red de otro".
Qué hacer
- Si evalúas cómputo en el edge, mete el modelo de aislamiento al comparativo, no solo latencia y precio: isolate ≠ VM cuando hay compliance o multi-tenancy sensible de por medio.
- Pregunta a tu proveedor dónde se ejecuta realmente la función. "Edge" describe a veces el punto de entrada, no el punto de ejecución.
- Mide tú el p50 y el p99 de tus propias funciones antes y después de cualquier migración. Las cifras del vendor son de su flota, no de tu tráfico.
- Firecracker y Unikraft son abiertos: si tu plataforma interna necesita aislamiento fuerte con arranque en milisegundos, ya no hay que construirlo desde cero.