Contexte et objectifs
Netlify exécute chaque jour près d’un milliard d’Edge Functions. Chaque fonction doit être invoquée, routée, et exécutée en quelques millisecondes, sous peine d’alourdir le temps de réponse perçu par l’utilisateur final. L’infrastructure précédente reposait sur des V8 isolates hébergés dans un service externe, ce qui imposait un temps d’invocation médian de 25 à 40 ms. L’enjeu était donc de réduire cet overhead tout en conservant la compatibilité avec les API Node, les imports npm et les déclarations netlify.toml.
Nouvelle architecture avec Firecracker
Le nouveau moteur utilise des MicroVMs Firecracker déployées directement dans le réseau d’edge de Netlify. Chaque requête transporte une spécification décrivant trois images – runtime, image de plateforme et image de fonction – ainsi que les limites CPU, mémoire et connexion. Cette spécification est hachée pour former un service ID, garantissant qu’un même déploiement crée toujours le même service et, par conséquent, le même MicroVM. La création d’un service s’effectue sur le nœud de calcul choisi par rendezvous hashing, assurant que les requêtes d’un même service atterrissent sur le même nœud tant que le MicroVM reste chaud.
Un service peut regrouper plusieurs MicroVMs afin de gérer le trafic. Netlify impose un nombre maximal de requêtes par MicroVM avant de le stopper, évitant ainsi que des VM restent actives indéfiniment. En parallèle, le système déclenche le démarrage anticipé d’une nouvelle VM dès que le compteur approche de la limite, ce qui minimise les temps de latence lors du basculement.
Performances et mesures
Les chiffres publiés montrent une latence médiane (p50) de 5‑6 ms pour une invocation « chaude », contre 25‑40 ms auparavant, soit un gain d’environ 5×. Le p99 est 47,4 % plus rapide, et la disponibilité globale atteint 99,998 %. Les invocations froides, qui représentent 1,2 % du trafic, nécessitent le téléchargement des images manquantes et coûtent en moyenne 9 ms. Cette distribution montre que la majorité des requêtes bénéficient d’un démarrage quasi‑instantané grâce à la persistance des MicroVMs dans chaque région.
Sécurité et isolation
Le passage aux MicroVMs renforce l’isolation : chaque service possède son propre environnement, séparé des autres déploiements même si le code ou les variables d’environnement diffèrent. Un compromis dans un déploiement ne peut pas « s’échapper » vers d’autres clients, car le conteneur Firecracker ne partage aucun noyau avec les VM voisines. Les V8 isolates, bien qu’utiles pour l’exécution JavaScript, ne garantissent pas ce niveau d’isolation, ce qui rend la nouvelle approche plus robuste face aux attaques potentielles. De plus, la localisation des images sur disque uniquement dans les régions où le trafic existe réduit la surface d’exposition aux fuites de données.
