Netlify cambia los isolates de V8 por microVMs en sus Edge Functions

Este blog está alojado en Netlify desde 2019, aunque sólo como HTML estático: Hugo genera las páginas y Netlify las sirve, sin funciones ni nada que se ejecute en el servidor. Aun así, el último artículo de su blog, 5x faster Edge Functions: V8 isolates to Firecracker MicroVMs, cuenta un cambio que me parece importante y que va un poco a contracorriente: han dejado de ejecutar sus Edge Functions en isolates de V8 y ahora cada función corre en su propia microVM Firecracker.

Lo curioso es que durante años los isolates han sido la respuesta para ejecutar código en el edge, justo porque las máquinas virtuales se consideraban demasiado pesadas. Netlify dice que con microVMs bien afinadas van cinco veces más rápido y, además, aíslan mejor.

Qué son las Edge Functions y qué ha cambiado

Las Edge Functions son pequeñas funciones JavaScript o TypeScript que se ejecutan delante del sitio, en el nodo más cercano al usuario, en cada petición que coincide con su ruta. Se usan para personalizar páginas, redirigir según una cookie, hacer autenticación… Netlify dice que ejecuta unos mil millones al día.

Hasta ahora, cuando una petición necesitaba una Edge Function, salía de la red de Netlify hacia un servicio de ejecución externo, se ejecutaba allí y volvía. El artículo no lo nombra, pero desde su lanzamiento en 2022 ese servicio era Deno Deploy. Ahora la petición se queda dentro: va a un nodo de cómputo de la propia red de Netlify y se ejecuta en una microVM. Lo han construido junto con Unikraft, que se encarga del ciclo de vida de las máquinas virtuales.

Los números

Las invocaciones en frío, cuando un nodo de una región no ha visto nunca esa función y tiene que descargar las imágenes, ocurren en un 1,2% de los casos y añaden unos 9 ms de media.

Todas las cifras son las que da Netlify, claro. Pero tienen sentido: buena parte de la mejora viene simplemente de no salir de su red en cada petición.

El camino de una petición

Lo que más me ha gustado del artículo es que explica paso a paso qué pasa con cada petición. Resumido:

flowchart LR
    A["Petición"] --> B["Nodo edge · TLS y rutas"]
    B -->|"sin función"| C["Caché · origen"]
    B -->|"con función"| D["Especificación · runtime, plataforma, función"]
    D --> E["Nodo de cómputo · rendezvous hashing"]
    E --> F["MicroVM · snapshot o arranque"]
    F --> G["Respuesta"]

Algunos detalles de diseño que me parecen especialmente buenos:

• Una especificación viaja con cada petición. Indica tres imágenes (el runtime, la plataforma de Netlify y el código de la función) y los límites de CPU, memoria y conexiones. Su hash es el identificador del servicio, así que dos despliegues con código o variables de entorno distintos nunca comparten microVM.
• El mismo servicio va siempre al mismo nodo gracias al rendezvous hashing. Así la microVM sigue caliente y el código ya está en disco. Cuando una función recibe demasiado tráfico, relajan esa regla y la reparten entre varios nodos para no crear un punto caliente que perjudique a los demás.
• Arranques en milisegundos. Las microVMs se crean en menos de un milisegundo y arrancan en unos 2 ms en el p99, porque cargan un Linux mínimo y no un sistema operativo completo. El código de la función se monta como una imagen EROFS y se mapea en memoria, de forma que sólo se lee lo que se usa.
• Snapshots y escalado a cero. Cuando la microVM arranca y el servidor JavaScript empieza a escuchar, sacan un snapshot. Si la función no recibe tráfico, las microVMs se apagan, y la siguiente invocación arranca desde ese snapshot, también mapeado en memoria.
• Cada microVM atiende un número limitado de peticiones y luego se apaga, para que ninguna se quede corriendo indefinidamente. Antes de que se apague, arrancan otra en paralelo.

Y una frase que me ha hecho gracia: entre los problemas que han tenido a esta escala citan quedarse sin puertos en los switches virtuales y el DNS, “nos sorprendió, pero no siempre era el DNS”. Por si acaso, ahora cada nodo de cómputo tiene su propio resolvedor DNS local.

Isolates frente a microVMs

La parte de seguridad es la que más me interesa. En febrero escribí sobre el aislamiento de filesystems en contenedores y sobre Vercel Sandbox, que también usa Firecracker, y la idea de fondo era la misma: cuando ejecutas código de otros, cuánto aislamiento necesitas.

Un isolate de V8 separa el código de cada cliente dentro del mismo proceso, con el motor de JavaScript como frontera. Es muy ligero y muy rápido, pero si alguien encuentra un fallo en V8, está en el mismo proceso que el código de otros clientes. Netlify lo dice sin rodeos: “Los isolates de V8, por mucho que se llamen así, no dan este nivel de aislamiento”.

Con Firecracker, cada función tiene su propia máquina virtual con su propio kernel. Para llegar a otro cliente habría que escapar primero del runtime y después de la virtualización. En palabras de Netlify, un despliegue comprometido “no puede envenenar a otros clientes ni a la capa de cómputo”.

Durante años, la elección parecía obligada: isolates para la velocidad, máquinas virtuales para el aislamiento. Lo interesante de este artículo es que, con snapshots, imágenes mapeadas en memoria y un Linux mínimo, las microVMs consiguen las dos cosas.

Lo que cambia para quien las usa

Nada, y es probablemente lo mejor del anuncio. Las importaciones por URL, los paquetes npm, los módulos de Node, la configuración en netlify.toml y el desarrollo local siguen funcionando igual. Ya está en producción, con el mismo precio y sin ningún paso de migración.

Lo que sí cambia es lo que viene después. Con una máquina virtual de verdad y un sistema de ficheros real, Netlify apunta a tres mejoras:

• Sacar de beta el soporte de paquetes npm, que ahora tiene limitaciones con binarios nativos y con importar ficheros en tiempo de ejecución.
• Revisar los límites actuales (50 ms de CPU por petición, 512 MB de memoria y 20 MB de código comprimido), que venían del modelo de isolates.
• Construir servicios que dependan de controlar la red, ahora que el cómputo está dentro de su propia red.

Lo que me llevo

Como decía al principio, a este blog no le afecta en nada: es HTML estático. Pero el artículo me parece un buen ejemplo de algo que vemos cada vez más: las microVMs se están convirtiendo en la opción por defecto para ejecutar código de terceros. Lambda, Vercel, los sandboxes de agentes y ahora las Edge Functions de Netlify van en la misma dirección.

Y me quedo con la explicación detallada, que no es tan habitual. Contar cómo viaja una petición, qué se cachea, cómo evitan los puntos calientes y qué falló por el camino es mucho más útil que un “ahora es cinco veces más rápido”. Para quien diseñe cualquier sistema que ejecute código de otros, aunque no tenga nada que ver con el edge, merece la pena leerlo entero.