Netlify cambio los isolates por Firecracker: sus Edge Functions ahora son 5 veces mas rapidas

Netlify acaba de quietly gutear su propia infraestructura y casi nadie se entero. La empresa que hospeda millones de sitios cambio por completo la forma en que ejecuta funciones de servidor, reemplazando los V8 isolates por micro-maquinas virtuales de Firecracker. El resultado medido: las invocaciones calientes pasaron de 25-40ms a 5-6ms en mediana. Cinco veces mas rapido. Sin cambiar una sola linea de tu codigo.

Esto parece un detalle de ingenieria. No lo es. Es la decision tecnica mas interesante del ultimo ano en infraestructura serverless, y revela algo que casi nadie admite en publico sobre como funcionaba internet hasta hace poco.

El problema: los isolates no eran maquinas virtuales

Hasta hace poco, cuando alguien ejecutaba una funcion serverless, no estaba ejecutando un servidor. Estaba ejecutando un pequeno espacio de memoria aislado dentro de un solo proceso de Node.js. Multiple tenants, multiples funciones, multiples clientes, todos conviviendo en el mismo proceso del sistema operativo.

Es la forma mas rapida posible de arrancar codigo: no hay sistema operativo que cargar, no hay kernel, no hay boot. Por eso todo el mundo lo uso durante anos. Es ingeniosamente barato.

Pero tiene un techo, y Netlify lo estaba chocando de frente. Con alrededor de mil millones de invocaciones de Edge Functions al dia —personalizacion de Sunweb, enrutamiento de trafico de Loto-Quebec, cientos de miles de sitios mas— el aislamiento a nivel de proceso se estaba quedando corto para computo mas complejo.

La cita clave del equipo de Netlify lo admite sin rodeos: "Los V8 isolates, sin importar su nombre, no ofrecen este nivel de aislamiento." Suena a marketing, pero es la verdad tecnica.

La solucion: una VM de 2 milisegundos

Firecracker es el hypervisor que AWS creo para AWS Lambda.siempre fue un isolate. Ahora, en vez de meter funciones en un hueco de memoria, Netlify arranca una micro-Maquina virtual completa por funcion, con su propio kernel de Linux.

Y aqui esta el truco que hace posible la locura: esa VM arranca en menos de 2 milisegundos en p99. Eso es imposible para una VM tradicional y posible aqui porque Firecracker no emula hardware. Arranca un Linux despojado, sin BIOS, sin dispositivos virtuales innecesarios. Solo el minimo.

Los archivos de la funcion se montan como una imagen EROFS sin comprimir y se mapean en memoria. La VM lee unicamente las partes del bundle que realmente usa, en vez de cargarlo todo. Es la diferencia entre abrir un libro por la pagina que necesitas y leer el libro entero.

El truco del snapshot

Cuando la MicroVM arranca y el servidor JavaScript escucha en un puerto, Netlify toma un snapshot de su memoria. Cuando la funcion no se esta invocando, las MicroVMs bajan a cero en lugar de quedarse idle. En la siguiente llamada, una MicroVM nueva arranca desde ese snapshot.

El snapshot esta mapeado en memoria, asi que la VM empieza a ejecutar codigo sin esperar a que todo el snapshot vuelva a leerse. Es arranque lazy de una VM entera.

Para el usuario el resultado es casi transparente. Las invocaciones calidas cuestan ~5-6ms. Las frias —cuando la peticion llega a una region donde ninguna maquina ha visto esa funcion antes y tiene que descargar las imagenes— ocurren en about 1.2% de las invocaciones y cuestan unos 9ms. Disponibilidad: 99.998%.

Lo que nadie te dice: la red era el cuello de botella real

Este es el detalle que revela que tan profundo era el problema anterior. Antes de esta reconstruccion, cada peticion salia de la red de Netlify por internet, iba a un servicio de ejecucion alojado, corria ahi y volvia. Ida y vuelta. Por cada funcion. Por cada request.

Ahora todo pasa dentro de la red propia. Nada sale. "Todo lo que depende de controlar el camino de red, en lugar de alcanzar a un tercero por internet, ahora es algo que podemos construir."

Eso tambien elimina una fuente entera de fallos. El equipo admite que a escala se-atascaron desde agotar puertos en switches virtuales hasta problemas de DNS —nos sorprendiamos, pero no siempre era DNS. Ahora los nodos de computo ejecutan resolvers DNS locales.

Por que te importa aunque no seas dev

Tres cosas se abren ahora que antes eran fisicamente imposibles:

1. Paquetes npm fuera de beta. Soportaban npm en edge functions, pero en beta, con salvedades porque porque los binarios nativos y la importacion de archivos en runtime no funcionaban bien. Una VM real con un sistema de archivos real elimina la mayoria de esas razones.

2. Los limites_operation se pueden revisar. Los limites documentados de 50ms de CPU por peticion, 512MB de memoria y 20MB de codigo comprimido venian del modelo de isolates. Ese techo ya no es el mismo.

3. Ya esta en produccion. Mismo precio, sin paso de migracion, nada que cambiar en tus proyectos. Solo reinicia si quieres notar la diferencia.

La lectura incomoda para los devs

Mi opinion sin filtro: esto es una victoria de la ingenieria y una critica a la arquitectura de la nube que todos aceptamos sin cuestionar.

Multiples empresas empujaron durante anos la idea de que "serverless" significaba "sin servidor". La realidad es que si hubo servidores todo el tiempo —solo que compartidos, silenciosos e invisibles. Netlify acaba de admitir, con numeros, que ese modelo tinha un techo, y que para bajar ese techo habia que traatar de vuelta las maquinas virtuales, solo que ridiculamente eficiente.

La paradoja final: la revolution del serverless volvio a las VMs, pero en 2 milisegundos. Si eso no es el mejor argumento de que la ingenieria de software nunca es un viaje lineal, no se cual es.

Comparte esto con alguien que sigue pensando que "sin servidor" significa literalmente sin servidor. Y tu, developer o LATAM: ¿estas pagando por el servidor invisible o estas pagando la factura del? La respuesta cambia como disenas todo lo demas.