veilletech.frCe qui se passe
Netlify a reconstruit l'infrastructure de ses Edge Functions, qui traitent environ un milliard d'invocations par jour. Jusqu'ici, une requête qui déclenchait une fonction quittait le réseau de Netlify vers un service d'exécution hébergé, à base d'isolates V8, puis revenait. Désormais, la fonction tourne dans une microVM Firecracker, sur des nœuds de calcul internes, avec la technologie d'Unikraft.
C'est déjà en production, au même tarif, sans étape de migration. L'écriture
des fonctions ne change pas : imports d'URL, paquets npm, modules intégrés de
Node, déclarations dans netlify.toml, développement local.
Les chiffres
| Mesure | Avant | Après |
|---|---|---|
| Appel à chaud, médiane | 25 à 40 ms | 5 à 6 ms environ |
| Appel à chaud, p99 | — | 47,4 % plus rapide |
| Disponibilité | — | 99,998 % |
| Livraison des journaux | — | 5 fois plus rapide |
Un appel à froid, quand une région n'a encore jamais vu la fonction, touche environ 1,2 % des invocations et coûte 9 ms en moyenne.
Le trajet d'une requête
- Nœud de bordure. Le plus proche du client termine TLS et compare le chemin aux routes des fonctions du déploiement. Sans correspondance, la requête file vers le cache et l'origine, comme avant.
- Spécification. Sinon, le nœud décrit la machine à lancer : trois images (runtime, plateforme Netlify, code de la fonction) et des limites de CPU, de mémoire et de connexions. Son empreinte, plus des données propres au site, donne un identifiant de service. Deux déploiements dont le code ou les variables d'environnement diffèrent sont deux services, qui ne partagent jamais de microVM.
- Nœud de calcul. Un hachage de rendez-vous envoie toujours le même service au même nœud, ce qui garde code et VM au chaud. Au-delà d'un seuil de trafic, le service s'étale sur plusieurs nœuds, pour qu'un client en pointe n'étouffe pas ceux qui partagent sa machine.
- MicroVM. Créée en moins d'une milliseconde, démarrée en 2 ms au p99 sur un Linux réduit. Le code est monté en image EROFS non compressée et projeté en mémoire : seules les parties utilisées sont lues. Dès que le serveur JavaScript écoute, un instantané est pris ; au repos, les VM s'éteignent et repartent de cet instantané, lui aussi projeté en mémoire.
Chaque microVM ne sert qu'un nombre fixé de requêtes avant d'être remplacée. Les nœuds de calcul ont leurs propres résolveurs DNS, des disjoncteurs pour écarter un nœud défaillant, et de nouvelles métriques : démarrage, ouverture du premier port, lancement du code.
Pourquoi ça compte
L'isolation change de nature. Netlify l'écrit sans détour : un isolate V8 ne garantit pas qu'un déploiement compromis, sorti du runtime, ne puisse pas atteindre ses voisins. Une microVM par service, si.
Et le plafond appartient désormais à Netlify. Trois chantiers annoncés, sans date :
- sortir de la bêta le support des paquets npm, dont les réserves (binaires natifs, import de fichiers à l'exécution) tenaient au modèle des isolates ;
- revoir les limites actuelles, héritées de ce modèle : 50 ms de CPU par requête, 512 Mo de mémoire, 20 Mo de code compressé ;
- proposer des usages qui exigent de maîtriser le chemin réseau.
Source : le billet de Netlify sur le passage des Edge Functions à Firecracker, Netlify, 29 septembre 2026. Voir aussi le récit d'Unikraft.