Netlify hat die Ausführung seiner Edge Functions von V8-Isolaten, die über einen externen Ausführungsdienst liefen, auf Firecracker-MicroVMs umgestellt, die nun direkt im eigenen Edge-Netzwerk laufen. Die am 1. Oktober 2026 veröffentlichte technische Ankündigung verändert keine öffentliche API, prägt aber Latenz und Isolation von Code an der Edge grundlegend neu.
Eine Architektur, die die Ausführung zurückholt
Bisher wurde eine Anfrage an eine Netlify Edge Function zu einem externen Ausführungsdienst weitergeleitet, bevor sie ins Netlify-Netzwerk zurückkehrte. Mit Firecracker-MicroVMs, die durch AWS Lambda für ihren schnellen Start und ihre leichte, hardwarenahe Isolation bekannt wurden, läuft der Code nun direkt innerhalb der eigenen Edge-Infrastruktur von Netlify. Das Unternehmen kontrolliert damit den gesamten Anfrageweg, vom Eingang bis zur Antwort.
Die gemessenen Leistungsgewinne
Netlify veröffentlicht präzise Zahlen aus der eigenen Produktionstelemetrie und vergleicht die alte mit der neuen Architektur für „warme“ Aufrufe, also ohne Kaltstart.
| Kennzahl | Vorher (V8-Isolate) | Nachher (Firecracker-MicroVMs) |
|---|---|---|
| Mediane Latenz (p50) | 25 bis 40 ms | 5 bis 6 ms |
| p99-Latenz | Referenz | -47,4 % |
| Gemessene Verfügbarkeit | – | 99,998 % |
| Kaltstart-Aufruf (≈1,2 % der Anfragen) | – | ≈9 ms inklusive Image-Abruf |
Keine Codeänderung nötig
Für Teams, die bereits Edge Functions einsetzen, verläuft die Umstellung unbemerkt: URL-Importe, verwendete npm-Pakete und bestehende Konfigurationen funktionieren unverändert weiter. Wer sich beim Deployment auf gewohnte Kommandozeilen-Werkzeuge verlässt, muss nichts anpassen.
export default async (request, context) => {
const country = context.geo?.country?.code ?? "DE";
const response = await context.next();
response.headers.set("x-edge-country", country);
return response;
};
export const config = { path: "/*" };
Stärkere Isolation zwischen Kunden
Anders als V8-Isolate, die sich einen Prozess über mehrere Ausführungen hinweg teilen, verfügt jede Firecracker-MicroVM über eigene virtualisierte Kernel-Ressourcen. Eine kompromittierte oder instabile Funktion eines Kunden kann die Workloads eines Nachbarn auf derselben physischen Maschine nicht mehr beeinträchtigen – ein Argument, das Teams, die ihre eigene selbstgehostete Infrastruktur betreiben, aus der umgekehrten Perspektive gut kennen: Je stärker die Isolation, desto weniger muss die Überwachung ausgleichen.
Die mediane Latenz der Netlify Edge Functions sinkt von 25-40 Millisekunden auf 5-6 Millisekunden, ohne dass Entwickler ihren Code ändern müssen.
Was Netlify als Nächstes plant
Da Netlify nun den gesamten Anfragezyklus kontrolliert, will das Unternehmen die Unterstützung großer npm-Pakete aus dem Beta-Status holen, bestimmte Ausführungslimits nach oben anpassen und das Netzwerk-Routing direkt selbst verwalten, statt dafür auf einen externen Anbieter angewiesen zu sein.
Was man sich merken sollte
Der Wechsel zu Firecracker-MicroVMs senkt die mediane Latenz der Netlify Edge Functions deutlich, ohne dass Entwickler migrieren müssen. Der Großteil des Gewinns stammt aus dem Wegfall eines Netzwerksprungs zu einem externen Ausführungsdienst, der nun intern erfolgt.
Solche Ankündigungen sollte man mit etwas Abstand zu den vom Anbieter selbst gelieferten Zahlen lesen: Die mediane Latenz um das Vier- oder Fünffache zu senken, ist ein bemerkenswertes Ergebnis, verdient aber eine Nachprüfung unter realen Bedingungen, bevor es in eine Vertriebsargumentation einfließt. Wichtiger ist hier die grundlegende Entwicklung: Edge-Computing-Plattformen holen zunehmend Bausteine zurück ins eigene Haus, die sie vor zwei Jahren noch ausgelagert hatten – ein Zeichen dafür, dass sich der Markt um eine Handvoll hauseigener Architekturen konsolidiert. — Simon Janvier
Zum Weiterlesen: der technische Beitrag von Netlify, „5x faster Edge Functions: from V8 isolates to Firecracker MicroVMs“.
