Netlify migra Edge Functions a Firecracker MicroVMs: 5x más rápido

Netlify reescribe su compute edge: de V8 isolates a Firecracker MicroVMs

Netlify procesa alrededor de mil millones de Edge Functions al día — desde Sunweb personalizando páginas hasta Loto-Québec enrutando tráfico con una cookie — y durante años dependió de V8 isolates ejecutándose en un servicio externo. Ese modelo tenía un techo: las invocaciones warm costaban entre 25 y 40 ms en la mediana (p50), y cada request salía de la red de Netlify, iba por internet, ejecutaba la función y volvía. Hoy, ese mismo tráfico corre en Firecracker MicroVMs dentro de la propia red edge de Netlify, con una mediana de 5 a 6 ms: cerca de 5 veces más rápido, según los datos publicados por el equipo de ingeniería de Netlify en su blog.

El cambio ya está en producción, al mismo precio, sin migración y sin modificar una sola línea de código del usuario. Lo que sigue es lo que un founder técnico debería entender de esta decisión arquitectónica.

Qué cambió técnicamente, en una pasada por la petición

Netlify publicó el recorrido completo de una request. La idea central: en lugar de invocar un isolate compartido a través de internet, cada función corre en su propio MicroVM dentro de la red de Netlify.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Edge node recibe la petición, termina TLS y compara la ruta contra las Edge Functions del deploy.
El edge node escribe un "spec" con tres imágenes (runtime, plataforma y código del cliente) más CPU, memoria y límites de conexión. Ese spec viaja con cada request y su hash se convierte en un service ID.
Rendezvous hashing elige el compute node: la misma función cae siempre en el mismo nodo, manteniendo caliente la imagen y la caché.
El MicroVM arranca desde snapshot en unos 2 ms al p99, gracias a Firecracker (un kernel Linux mínimo, no un sistema operativo completo) y a que los archivos se montan como imágenes EROFS comprimidas y memory-mapped — el VM lee solo las partes que usa.
Snapshots permiten escalar a cero cuando no hay tráfico y restaurar en milisegundos la próxima vez.

El ciclo de vida del VM (boot, snapshot, restore, scale-to-zero) lo aporta Unikraft, socio tecnológico de la migración. Netlify destaca en el post que mantener todo el trayecto dentro de su red elimina el salto a un tercero y le da control sobre el ciclo completo.

Los números que importan

El equipo de Netlify reportó estos resultados en producción:

Mediana (p50) warm: 5–6 ms, frente a 25–40 ms del esquema anterior.
p99 un 47,4 % más rápido.
Disponibilidad 99,998 %.
Entrega de logs de Edge Functions 5 veces más rápida.
Cold starts en ~9 ms, ocurriendo solo en 1,2 % de las invocaciones (cuando llega una request a una región donde ningún compute node ha visto antes esa función).

Para un founder que usa Edge Functions para personalizar, autenticar o enrutar, esa caída de veinte a treinta milisegundos por petición se traduce en un Core Web Vitals como Time to First Byte (TTFB) más bajo y, según el caso, en conversiones menos penalizadas.

Por qué importa el aislamiento: más allá de la velocidad

Netlify fue explícito en un punto: los V8 isolates, sin importar su marca, no ofrecen el mismo nivel de aislamiento que un MicroVM. En el modelo anterior, un deploy comprometido podía, en el peor caso, afectar a otros clientes que compartieran el runtime.

Con MicroVMs dedicados por deploy:

Cada servicio corre en su propio VM, identificado por el hash del spec (código + variables de entorno).
Si un deploy escapa del runtime, no envenena a otros clientes ni a la capa de cómputo.
Netlify gana margen para relajar límites operativos como 50 ms de CPU por request, 512 MB de memoria y 20 MB de código comprimido, que provenían justamente del modelo basado en isolates.

Qué se habilita a partir de ahora

Netlify listó tres frentes que el cambio deja "al alcance" y antes no:

Soporte de paquetes npm saliendo de beta. Un VM real con sistema de archivos real elimina la mayoría de las caveats actuales alrededor de binarios nativos e importación de archivos en runtime.
Revisión de los límites operativos documentados (CPU, memoria, tamaño de bundle), heredados del modelo basado en isolates.
Compute dentro de la propia red, abriendo la puerta a features que dependen de controlar la ruta de red sin salir a internet.

Qué significa esto para tu startup

Si tu producto corre sobre Netlify Edge Functions, no tienes que mover nada: el cambio ya está sirviendo tu tráfico. Lo que sí cambia es lo que podés aspirar a construir encima.

Audita qué Edge Functions tienes y mide el TTFB antes y después. Una mejora de 20-30 ms en p50 no se nota igual en una landing estática que en un checkout con autenticación, A/B routing o personalización por cookie — prioriza las que están en el camino crítico de conversión.
Empieza a probar paquetes npm en beta donde antes dependías de polyfills o de duplicar lógica en el origen. Casos típicos: validación con zod, parseo de JWT, SDKs de analítica. Verifica si los caveats sobre binarios nativos siguen aplicando a tu stack.
Repensa los límites de 50 ms / 512 MB / 20 MB en tu diseño. Si tu función estaba al borde de cualquiera de los tres, vale la pena revisar si con MicroVM puedes mover lógica más pesada al edge (por ejemplo, armado de respuestas HTML parciales o composición de respuestas multi-origen) sin tocar el precio.
Piensa en edge como compute de producto, no solo como pegamento. Con latencias consistentes y un VM real por deploy, patrones que antes eran riesgosos — feature flags server-side, autenticación custom, rate limiting fino por usuario — entran en territorio razonable.

¿Y los competidores?

El movimiento de Netlify se inscribe en una tendencia del sector: llevar cómputo más pesado al edge sin sacrificar aislamiento. Plataformas como Cloudflare Workers, Vercel Edge Functions y AWS Lambda@Edge / CloudFront Functions están en carreras parecidas. Lo distintivo del enfoque de Netlify es apoyarse en Firecracker (la misma tecnología de microvirtualización que usa AWS Lambda y Fly Machines) y delegar el ciclo de vida del VM en Unikraft, un proyecto especializado en unikernels. Esa separación les permitió reconstruir la plataforma sin tocar la API pública: URL imports, paquetes npm, Node built-ins, configuración en netlify.toml y desarrollo local siguen funcionando exactamente igual.