Was ist Firecracker und warum interessieren sich alle Agent-Infra-Unternehmen dafür?

Jeden Tag führt AWS Lambda Billionen von Funktionsaufrufe aus. AWS Fargate plant Millionen von Containern. Jeder einzelne davon ist eine vollständige virtuelle Maschine mit eigenem Kernel, die in einem Bruchteil einer Sekunde gestartet wird.

Wie? Mit etwa 50.000 Zeilen Rust namens Firecracker, das existiert, weil die Branche endlich zugegeben hat, dass ein Linux-Container, der die Ressourcennutzung kontrolliert, nie als Sicherheitsgrenze konzipiert war.

Das Isolationsproblem

Jeder Docker-Container auf deinem Laptop ist drei Linux-Kernel-Features in einem Trenchcoat:

• Namespaces sind Augenbinden. Ein Prozess darin erhält eine private Sicht auf das System: seine eigene PID-eigene PID-Liste, Netzwerkstack, Mount-Tabelle, Hostname und Benutzer-IDs. PID 1 innerhalb des Containers ist eine zufällige PID auf dem Host; der Container kann nicht einmal die anderen Prozesse sehen.
• cgroups sind Budgets. Control Groups sind die Buchhaltungs- und Drosselungsschicht des Kernels Kernels. Sie begrenzen, wie viel CPU, Speicher, Festplatten-I/O und Netzwerkbandbreite ein Prozessbaum verbrauchen darf.
• seccomp + Capabilities sind Whitelists. Capabilities zerlegen Root-Rechte in ~40 separate Privilegien (niedrige Ports binden, Kernel-Module laden, Dateisysteme einhängen usw.), sodass du nur die gewähren kannst, die du brauchst. seccomp ist ein prozessspezifischer Filter, der entscheidet, welche Syscalls (die einzige API des Userspaces zum Kernel) der Prozess überhaupt tätigen darf.

Du kannst es selbst ohne Docker beweisen:

1$ unshare --fork --pid --mount-proc bash
2# ps aux
3USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
4root           1  0.0  0.0   7236  4184 pts/1    S    12:00   0:00 bash
5root           2  0.0  0.0  10860  3984 pts/1    R+   12:00   0:00 ps aux

Alles andere, was Docker tut (Image-Layer, Registries, DNS), ist Orchestrierung obendrauf.

Der gesamte Schutz läuft durch einen einzigen Linux-Kernel, etwa 30 Millionen Zeilen Code mit 400+ Syscalls. Jeder Container auf dem Host greift auf denselben Kernel zu. Ein Bug in einem dieser Syscalls und es ist vorbei für alle Mandanten auf dieser Maschine.

Vollständige virtuelle Maschinen lösen Isolation durch rohe Gewalt: Jede VM bekommt ihren eigenen Kernel.

Moderne CPUs haben einen „Gastmodus", der Gastanweisungen auf dem echten Silizium ausführt. Der Host wird nur dann eingeschaltet, wenn der Gast etwas Privilegiertes tut (echte Hardware berührt, Fehler auslöst, unterbrochen wird). Ein Hypervisor ist die dünne Schicht, die diese Momente vermittelt.

Linux liefert seinen Hypervisor als Kernel-Modul namens KVM, das unter /dev/kvm verfügbar ist. Es nutzt Hardware-Virt-Erweiterungen (vmx auf Intel, svm auf AMD):

1$ ls -l /dev/kvm
2crw-rw---- 1 root kvm 10, 232 Mar  1 12:00 /dev/kvm

Das Problem mit vollständigen VMs ist, dass sie langsam und fett sind. Eine klassische QEMU-VM emuliert einen ganzen imaginären PC (BIOS, PCI-Bus, IDE-Controller, VGA-Karte, PS/2-Tastatur), weil das ein Betriebssystem von 1998 erwartete, um zu booten. Das Image ist hunderte Megabyte groß. Der Bootvorgang dauert Sekunden. Der Speicherverbrauch liegt bei Hunderten von MiB, bevor deine Arbeitslast überhaupt startet. Für eine Webanfrage, die 40 ms lebt, würdest du das 40-fache für den Start der Maschine ausgeben.

Du steckst also zwischen:

• Container: 50 ms Boot, 5 MiB Overhead, gemeinsame Kernel-Angriffsfläche.
• VMs: 5+ Sekunden Bootzeit, 300+ MiB Overhead, hardware-isoliert.

Jeder, der unvertrauten Multi-Tenant-Code ausführt (AWS und im Grunde jeder bestehende AI-Sandbox-Anbieter), braucht beide Seiten dieses Kompromisses gleichzeitig.

MicroVirt man MicroVMs

Ein VMM (Virtual Machine Monitor) ist der Userspace-Prozess, der den Hypervisor steuert: er richtet Gastspeicher ein, schaltet virtuelle Geräte an, steckt virtuelle Geräte ein und sagt KVM, dass es Gastcode ausführen soll.

Ein MicroVM ist ein VMM mit dem gelöschten PC von 1998: kein BIOS, kein PCI-Bus, keine VGA, kein USB, kein ACPI (keine der Legacy-Hardware, die ein echter Desktop durchläuft, und nichts davon relevant für einen 40 ms-Funktionsaufruf). Was bleibt: KVM, eine serielle Konsole und eine Handvoll virtio-Geräte (Netz, Block, vsock).

virtio ist die Standard-Schnittstelle für „Ich weiß, dass ich in einer VM laufe". Der Gast kooperiert mit dem Hypervisor durch leichten virtuellen NICs und Festplatten (virtio-net, virtio-block), anstatt so zu tun, als würde er eine echte Intel e1000-Karte oder einen IDE-Controller treiben. Diese Kooperation, plus die fehlende Legacy-Hardware oben, ist der größte Grund, warum MicroVMs schnell booten.

Das Ergebnis:

• ~125 ms Bootzeit vom VMM-Start bis zum Userspace des Gastes, der init ausführt.
• <5 MiB VMM-Speicher-Overhead pro VM (die Buchhaltung, die der Host pro VM zahlt, bevor die Gast-Arbeitslast etwas für sich selbst alloziert).
• 150 VMs/Sekunde Erstellungsrate auf einem einzigen Host.
• ~2–8% Laufzeit-Leistungseinbuße im Vergleich zu Bare Metal.

Dieselbe Hardware-Isolation wie eine vollständige VM mit derselben Größenordnung an Dichte wie ein Container.

Firecracker ist der VMM, der Prozess, der tatsächlich mit /dev/kvm spricht und die MicroVM bootet. Der Rest dieses Beitrags ist dieser Stack von Ende zu Ende.

Firecracker

Im November 2018 hat AWS Firecracker auf der re:Invent als Open Source veröffentlicht. Es lief bereits Lambda in Produktion, das Ding, das deinen import pandas kalt genug startet, um pro Millisekunde abzurechnen. Im Jahr 2020 veröffentlichte das Team die Architektur auf der NSDI '20.

Die Architektur

Abgeleitet von Googles crosvm, in Rust umgeschrieben, mit mehr als der Code entfernt. Jeder Firecracker-Prozess ist eine MicroVM mit genau drei Thread-Typen (dokumentiert in docs/design.md):

• API-Thread ist der Bestellschalter. Ein REST-Server, der an einen Unix-Socket gebunden ist (ein lokaler Socket, der als Datei auf der Festplatte lebt, kein TCP-Port). Akzeptiert Konfiguration vor dem Booten und begrenzte Aktionen danach.
• VMM-Thread ist die Hardware-Werkstatt. Er gibt vor, jedes Gerät zu sein, das der Gast sehen kann. Wenn der Gast auf das stößt, was er für ein NIC-Register hält, pausiert die CPU den Gast, der VMM behandelt den Stoß („Gast hat die TX-Warteschlange getreten, leeren") und setzt fort. Der Mechanismus: Der Gast liest/schreibt magische Adressen; die CPU fängt diese zum Host ab.[^mmio]
• vCPU-Threads sind die Läufer. Einer pro Gast-CPU, jeder in einer engen Schleife: KVM bitten, den Gast auszuführen, bis etwas Interess etwas Interessantes passiert (Gerätestoß, Interrupt, Halt), behandeln, Schleife.

Sie kommunizieren über Rust-Kanäle (prozessinterne, sperrfreie Nachrichtenwarteschlangen zwischen Threads). Der Gast sieht genau vier Geräte.

Die vier Geräte

• virtio-net ist die NIC der VM, keine 1998-Emulation. Der Gast schreibt Pakete in eine virtqueue (einen Ringpuffer im gemeinsamen Speicher); der VMM leert sie über ein hostseitiges TAP-Gerät (eine virtuelle Ethernet-Schnittstelle, die der Kernel als Datei bereitstellt), gesteuert von io_uring oder epoll, damit der VMM-Thread nicht blockiert.
• virtio-block ist die Festplatte der VM, nur Datei-I/O auf dem Host. Der Gast stellt Sektor-Anfragen in eine virtqueue; der VMM gibt plain pread/pwrite gegen eine Host-Datei aus. Kein IDE, kein AHCI, kein SCSI.
• virtio-vsock ist die Gegensprechanlage der VM zum Host. Adressiert durch ein (Kontext-ID, Port)-Tupel anstelle eines IP/Port-Paares, sodass der Gast-Agent nach Hause telefonieren kann (Logs, Health-Pings, Snapshot-Metadaten) ohne Gast-IP und nichts auf der Leitung, um zu spoofen.
• 8250 serielle UART ist die Boot-Konsole. Ein winziger Legacy-Serial-Chip, der an einer festen Adresse emuliert wird. Wird für frühe Boot-Logs und Crash-Dumps verwendet, bevor virtio hochkommt. Günstig, universell, wird nie verschwinden.

Booten einer MicroVM, Ende zu Ende

Die API ist die gesamte gesamte Kontrollebene: der Konfigurationskanal, die bewusst von der Datenebene (den vCPU-Threads, die tatsächlich Gastcode ausführen) getrennt gehalten wird. Du startest das Binary, das auf einen Unix-Socket zeigt:

1$ firecracker --api-sock /tmp/firecracker.sock

Dann PUT-Konfiguration hinein:

1$ curl --unix-socket /tmp/firecracker.sock -i \
2    -X PUT 'http://localhost/boot-source' \
3    -H 'Content-Type: application/json' \
4    -d '{
5        "kernel_image_path": "/path/to/vmlinux",
6        "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
7    }'

Vier HTTP-Aufrufe. Das ist die gesamte Kontrollebene Kontrollebene.

Die Sicherheitszwiebel

Eine einzige KVM-Grenze ist bereits stark. Firecracker wickelt zwei weitere Schichten darum.

Der Jailer ist ein Sandbox-Bauer. Seine einzige Aufgabe ist es, den VMM zu verpacken, bevor er jemals läuft. Er erstellt ein chroot (ein Linux-Feature, das einen Prozess auf einen einzigen Verzeichnisbaum sperrt, als ob dieses Verzeichnis die Wurzel des Dateisystems wäre; der Prozess kann buchstämlich nichts darüber benennen), wechselt in einen neuen PID-Namespace, damit er die anderen Prozesse des Hosts nicht sehen kann, wechselt zu einer unprivilegierten uid/gid, wendet cgroup-CPU-/Speicherlimits an und führt erst dann die Firecracker-Binärdatei in diesem Gefängnis aus:

1$ jailer --id 42 --chroot --exec-file /usr/bin/firecracker --uid 1000 --gid 1000

Jetzt hat der VMM-Prozess selbst kein Dateisystem außer einem dedizierten chroot, keine Sicht auf andere Prozesse auf dem Host und keine Root-Fähigkeiten. Wenn eine Flucht vom Gast zum Host durch virtio oder KVM landet, landet der Angreifer in diesem chroot mit cgroup-Limits.

Seccomp ist eine prozessweite Syscall-Whitelist. Alles, was nicht auf der Liste steht, wird getötet (oder gibt EPERM zurück), bevor es den Syscall-Handler des Kernels erreicht. Firecracker liefert drei Stufen:

1. Stufe 0: Aus. Nicht in Produktion verwenden.
2. Stufe 1: Whitelist nach Syscall-Nummer.
3. Stufe 2. Stufe 2**: Auch Argumentwerte einschränken (z.B. ioctl ist in Ordnung, aber nur mit KVM_RUN als Befehl). Standard und empfohlen.

Jeder Thread bekommt die minimal mögliche Oberfläche: Der API-Thread braucht kein ioctl(KVM_RUN); die vCPU-Threads brauchen kein socket(). Eine vereinfachte Ansicht, wie eine Regel aussieht:

1# Stufe 2 für vCPU-Thread
2allow write, read, open, close, mmap, munmap, exit_group, rt_sigreturn, ioctl (nur KVM_RUN)

Jede Schicht muss unabhängig versagen, damit ein Angreifer den Host erreicht.

Snapshots: Der Cheat-Code hinter Lambda SnapStart

Erstelle einen Snapshot einer laufenden MicroVM. Stelle sie in Millisekunden auf einem anderen Host in einem brandneuen VMM-Prozess wieder her. Überspringe Kernel-Boot, überspringe init, überspringe JIT-Aufwärmphase.

Du frierst die laufende VM ein und schreibst Speicher + Gerätezustand auf die Festplatte:

1# Snapshot erstellen
2curl --unix-socket /tmp/firecracker.sock -i \
3    -X PUT 'http://localhost/vm/snapshot/create' \
4    -H 'Content-Type: application/json' \
5    -d '{
6        "snapshot_type": "Full",
7        "snapshot_path": "/snapshots/my-vm.snap",
8        "mem_file_path": "/snapshots/my.mem"
9    }'

Ein Snapshot erfasst den Zustand nach dem Aufwärmen, sodass die wiederhergestellte VM in der Mitte ihres Lebens aufwacht, nicht am Anfang.

Genau das macht AWS Lambda SnapStart: eine Java Lambda einmal initialisieren, die MicroVM snapshoten und diesen Snapshot bei jedem folgenden Kaltstart wiederherstellen (Ankündigung). JVM-Kaltstarts gehen plötzlich von 8+ Sekunden auf unter eine Sekunde.

Wie sie zusammenpassen

gVisor ist ein anderes Design: ein Userspace-Kernel in Go, eine Neuimplementierung der Linux-Syscall-Schnittstelle, die als normaler Prozess läuft. Die Syscalls des Gastes treffen auf gVisor anstatt auf den Host-Kernel, und gVisor entscheidet, was (falls überhaupt) nachgelagert weitergeleitet wird. Schneller zu starten als eine MicroVM, 10–30% Syscall-Overhead auf dem heißen Pfad und eine andere Vertrauensgrenze.

Firecracker sitzt in der Box „eigener Kernel, aber kein PCI-BIOS": Hardware-Isolation, winziges Gerätemodell und Boot in Millisekunden.

Wähle dein Werkzeug:

• MicroVM: eigener Kernel, hardware-isoliert, aber etwas langsamer zu starten.
• gVisor: Userspace-Kernel, kein eigener Kernel, aber eine andere Sicherheitsgrenze.

Wer das nutzt

Es ist fast schneller, die serverlosen Plattformen aufzulisten, die nicht auf MicroVMs verwenden.

Firecracker in Produktion:

• AWS Lambda und AWS Fargate: der ursprüngliche Anwendungsfall. Jeder Lambda-Aufruf landet in einer Firecracker-MicroVM; Fargate-Aufgaben sind Firecracker-VMs mit einer dünnen Container-Laufzeit im Inneren.
• [Fly.io Machines](https://fly.io/docs/machines/): Jede Fly-Maschinenlauf ist eine Firecracker-MicroVM, global verteilt, mit Kaltstarts unter einer Sekunde und persistenten Festplatten.
• Fast jeder AI-Agent-Code-Execution-Sandbox, den du in den letzten achtzehn Monaten genutzt hast, lebt in einer Firecracker-MicroVM.

Die Form einer Sandbox-API ist bei den Anbietern in etwa gleich:

1from sandbox import Sandbox
2
3with Sandbox() as sandbox:
4    result = sandbox.run("pip install numpy && python-diffusers")
5    result = sandbox.run("python generate -p 'a cat'")

In etwa vier Zeilen Code: eine Firecracker-MicroVM bootet, ein Kernel initialisiert, ein Agent-Prozess im Gast empfängt deinen Befehl über vsock, führt ihn aus, streamt Ergebnisse zurück, und die VM stirbt.

Die Agent-Ära: warum das jetzt wichtig ist

Vor einem Jahr war „Was ist eine AI-Sandbox?" eine Nischenfrage. Wenn ein LLM Code generierte, war es wahrscheinlich nicht 100% sicher, auf irgendeiner Maschine auszuführen, also würde man ihn in einer flüchtigen Sandbox ausführen.

Heute liefert jedes ernsthafte AI-Produkt einen Agenten aus. Ihre Sandboxes wurden auch besser, aber die Form der Agenten hat sich geändert, und die alten Laufzeitantworten passen nicht mehr.

In-Prozessinterne Agenten vs. Host-Level-Agenten

Runde eins der AI-Agenten lebte in deiner Anwendung. Du hast eine Bibliothek importiert, eine Schleife verdrahtet und sie in deinem vorhandenen Backend ausgeführt:

1from agents import Agent
2
3agent = Agent(
4    tools=[search, calculator],
5    model="gpt-4"
6)
7
8response = agent.run("What is the capital of France?")

Jeder Aufruf war ein HTTP-Roundtrip zu einem Modell. Jeder Tool-Aufruf war eine Funktion in deinem eigenen Prozess. Die „Sandbox" war dein eigener Server. Das ist die Welt des Vercel AI SDK, LangChain und OpenAI Agents SDK. Sie funktioniert großartig und liefert auch heute noch einen großen Teil der Produktionsagenten aus.

Runde zwei ist anders. Claude Code, Codex und OpenCode sind Host-Level-Agenten: Binärdateien, die eine Maschine übernehmen, keine Bibliotheken, die in deiner leben. Sie erwarten eine echte Shell, einen Paketmanager und eine beschreibbare Festplatte. Wenn du Claude Code eine Aufgabe gibst, führt er so etwas aus:

1$ claude "Find all unused dependencies in this project and remove them"

Das ist eine Shell/bash. Sie braucht ein echtes Dateisystem, ein echtes fork/exec, einen Paketmanager, eine Festplatte, auf die du schreiben kannst, ein Netzwerk, das du erreichen kannst. Nichts davon ist als Chat-Completion-Tool-Schema ausdrückbar, und nichts davon ist sicher, in einem Container mit gemeinsamem Kernel neben anderen Mandanten ausgeführt zu werden.

Die Labore trainieren ihre Modelle direkt auf diesen Harnessen (dem Gerüst um das Modell): der Shell, dem Datei-Editor, dem Test Runner, der Agenten-Schleife selbst. Das bedeutet, dass die Lücke zwischen „Modell + Harness, auf dem es trainiert wurde" und „Modell + DIY-Gerüst" jedes Quartal größer wird.

Eine ganze Linux-Maschine pro Agent, die unvertrauten Code ausführt, den der Agent gerade erfunden hat, ist genau die Arbeitslast, für die Firecracker gebaut wurde. Die obige Konvergenz war kein Zufall.

Wir sehen mehr Experimente mit Agenten, die Compute und Harness trennen. Anthropic Managed Agents ist ein Beispiel dafür, bei dem der Agenten-Harness neben der Sandbox ausgeführt wird, nicht darin.

Einige Unternehmen bauen sogar vollständig gehostete Dateisysteme (wie Archil und Mesa), um Agenten bessere Suche und Speicherung zu bieten.

Da Agenten besser werden und sich im Laufe der Zeit ändern, wird es viele weitere interessante Infrastrukturangebote geben, die auf Firecracker aufbauen.

Was du eigentlich für Agenten-Infrastrunde Plattformen bezahlst

Die generischen „beliebigen Code ausführen"-Sandboxes sind jetzt eine Ware. Die Infrastruktur ist vollständig Open Source. Die MicroVM-Ebene ist Firecracker oder Cloud Hypervisor, verfügbar unter Apache 2.0 verfügbar. Die Container-zu-Rootfs-Konvertierung ist ein 200-zeiliges Go-Skript. Talentierte Ingenieure können an einem Wochenende eine funktionierende Sandbox-Plattform aufbauen.

Du bezahlst für das, was mit der VM verbunden ist. Die bloße MicroVM ist der Tisch Einsatz.

Die interessante Produktoberfläche:

• Beobachtbarkeit ist das Produkt, kein Debug-Hilfsmittel. Alles, was der Agent tut (stdout, Syscalls, Dateischreibvorgänge, Netzwerkanfragen), fließt durch einen einzigen Socket zu einem hostseitigen Sammler. Agentenentwickler brauchen vollständige Sitzungswiedergabe und die pro-Aktion-Artefakte, um die besten Produkte zu erstellen.
• Geheimnisse werden am Draht vermittelt, nie dem Gast übergeben. Der Gast sieht nur Platzhalter-Umgebungsvariablen; echo $SECRET in der Sandbox gibt den Platzhalter zurück. Ein hostseitiger Egress-Proxy (jedes ausgehende Paket muss ihn passieren) ersetzt die echten Anmeldedaten auf der hostseitigen TAP (das kernelgehörte Ende der virtuellen NIC der VM, das der Gast nicht sehen oder adressieren kann), gegen eine explizite Whitelist, mit einer Sitzungsprüfpfad. Der Agent kann beliebigen Code ausführen, den er vor fünf Sekunden generiert hat, und kann dennoch kein Geheimnis exfiltrieren, das er nie hatte.
• Identität wird am Host signiert, nicht im Agenten signiert. Ausgehende Anfragen können eine kryptografische Sitzungsidentität tragen (einschließlich Web Bot Auth-Signaturen, aufgebaut auf HTTP Message Signatures + Ed25519), die vom Host geprägt wird, bevor das Paket die Brücke verlässt. Der Signaturschlüssel gelangt nie in die MicroVM.
• Der andere Compute ist in derselben MicroVM wie die Laufzeit gebündelt. Browserbase paart jede Agentenlaufzeit 1:1 mit einem Browser auf demselben Host, oft derselben MicroVM. Die physische Distanz zwischen dem Agentenprozess und Chromium ist effektiv null: CDP-Befehle (das Chrome DevTools Protocol, das JSON-über-WebSocket-Wire-Format, das verwendet wird, um Chrome programmgesteuert zu steuern) gehen über einen Unix-Socket, nicht über ein Netzwerk von Diensten, sodass die Aktionslatenz einstellige Millisekunden beträgt. Screencast-Frames müssen nicht das öffentliche Internet durchqueren, um in der Sitzungswiedergabe zu landen.

Und du kannst das alles nicht sauber auf Docker zusammenstricken. Die Nähte sind nicht da. Unsere Wette ist, dass der Agenten-Laufzeitmarkt nicht mit rohem Compute gewonnen wird, sondern mit der besten Beobachtbarkeit, Geheimnissen, Identität, Partnerschaften und dem zusammengelegten Compute in einer Produktoberfläche.

Laufzeit-Alternativen, die einen Blick wert sind

• **Bubblewrap: unprivilegierte User-Namespace-Sandboxing. Ein Nicht-Root-Benutzer kann eine Sandbox ohne sudo aufsetzen, dieselben Kernel-Primitive, die Flatpak verwendet, um Desktop-Apps einzuschränken. Leichter als eine VM, teilt immer noch den Host-Kernel, also kein Ersatz für MicroVMs gegen wirklich unvertrauten Code. Aber es ist eine großartige verschachtelte Isolationsschicht, die innerhalb einer MicroVM läuft, oder eine gute Wahl für einigermaßen vertrauenswürdigen Code auf deinem eigenen Host.
• **V8-Isolate](https://blog.cloudflare.com/cloud-computing-without-containers/): Cloudflare Workers-Modell. Jedes Isolate ist ein separater JS-Ausführungskontext mit eigenem Heap, die alle einen einzigen V8-Prozess mit potenziell Tausenden anderen Mandanten teilen. Der Start dauert ~5 ms, zwei Größenordnungen schneller als eine MicroVM. Die Vertrauensgrenze ist V8s eigene Sandbox; historisch hat sie sich gut gehalten, aber sie ist eine viel dünnere Linie als ein Hypervisor. Der andere Haken: Du bekommst nur Node-artige Semantik. Kein fork, kein exec, keine nativen Module, simulierte Dateisysteme. Verheerend für reinen JS-Agenten-Code; nutzlos, wenn du pip install numpy installieren musst.
• gVisor: Googles Userspace-Kernel in Go. Starke Isolation ohne verschachtelte Virt (eine Gast-VM, die innerhalb einer anderen VM läuft, die die meisten Cloud-Anbieter standardmäßig deaktivieren; gVisor braucht sie nicht, funktioniert also in GKE out of the box). Zahlt ~10–30% bei syscall-intensiven Arbeitslasten. Ein solider Mittelweg, wenn Hardware-Virt nicht verfügbar ist.
• WASM-Sandboxes (wasmtime, wasmer: deterministisch, klein, schnell, aber das Ökosystem ist flach. WASI (die standard Syscall-API für WASM) reift heran. Noch kein Drop-in-Ziel für „führe diese beliebige Python/Node-Binärdatei aus".

Wenn du für unvertrauten Allzweckcode baust: Firecracker (oder Cloud Hypervisor, ein ähnliches VMM/virtio-Design). Wenn du für bekannte JS-Arbeits baust: V8-Isolate. Alles andere ist eine spezialisierte Antwort auf eine spezialisierte Frage.

Das größere Bild

Firecracker hat eine der ältesten Ideen der Informatik, eine virtuelle Maschine, genommen und genug davon gelöscht, um sie billig zu machen. Es wettet, dass hardwaregestützte Isolation es wert ist, wenn du sie schnell genug machen kannst.

Diese Wette hätte sich immer für Serverless ausgezahlt. Was sich geändert hat, ist, dass die Arbeitslast „unvertrauter Multi-Tenant-Code" von „einer Webfunktion, die ich nicht sandboxen möchte" zu „einem Agenten, der beliebige Befehle generiert, die die Produktion berühren könnten" gewachsen ist. Der Perimeter hat sich verschoben, und die Toleranz für Fluchten aus dem gemeinsamen Kernel ging von „akzeptables Risiko" zu „nicht auslieferbar".

Und es hat funktioniert. Es ist eine Rust-Binärdatei, 50.000 Zeilen lang, die mit /dev/kvm spricht.

Container verpacken Software. MicroVMs isolieren sie. Die interessante Ingenieursarbeit des nächsten Jahrzehnts ist alles, was du um die Box herum.

→ Kyle

Dieser Blogbeitrag enthält interaktive Komponenten und Animationen (die in X-Artikeln nicht angezeigt werden. Wenn du diese Version sehen möchtest, findest du sie hier: https://www.browserbase.com/blog/what-is-firecracker.