WebAssembly jenseits des Browsers: Eine portable Laufzeit für Edge und darüber hinaus

WebAssembly (Wasm) wurde ursprünglich entwickelt, um Code in Browsern mit nahezu nativer Geschwindigkeit auszuführen. Bis 2026 jedoch haben sich die faszinierendsten Anwendungen von Wasm längst über den Browser hinaus ausgedehnt: Serverless‑Funktionen, Plugin‑Systeme, Edge‑Computing und portable Sandbox‑Ausführungsumgebungen.

Der Grund für diese Vielseitigkeit liegt in einer Eigenschaft, die gar nichts mit Browsern zu tun hat: Wasm ist ein kompaktes, portables Binärformat, das in einer deterministischen Sandbox ausgeführt wird. Diese Eigenschaft beruht darauf, dass Wasm als kompaktes, portables Binärformat konzipiert ist, das in einer deterministischen Sandbox läuft.

Es lässt sich aus Dutzenden von Sprachen kompilieren, erreicht nahezu native Ausführungsgeschwindigkeit und startet in Mikrosekunden. Der Zugriff auf das Host‑System ist nur möglich, wenn der Host explizit die entsprechenden Rechte erteilt.

Diese Eigenschaften machen Wasm überall nützlich, wo sichere Ausführung von nicht vertrauenswürdigem oder Drittanbieter‑Code erforderlich ist.

Was WebAssembly tatsächlich ist

Wasm ist ein binäres Anweisungsformat für eine stapelbasierte virtuelle Maschine.

Es ist keine Sprache, sondern ein Kompilierungsziel.

Sprachen wie C, C++, Rust, Go, Python und JavaScript können zu Wasm kompiliert werden.

Die Wasm‑Laufzeit führt das Binärformat in einer Sandbox aus.

Standardmäßig hat ein Wasm‑Modul keinen Zugriff auf das Dateisystem, das Netzwerk, Umgebungsvariablen oder andere Host‑Ressourcen.

Zugriff wird explizit durch Imports gewährt, wobei der Host entscheidet, welche Fähigkeiten das Modul sehen und nutzen darf.

Quellcode (Rust, C, Go, ...)
    ↓ kompilieren
WebAssembly‑Binärformat (.wasm)
    ↓ laden
Wasm‑Laufzeit (Wasmtime, WasmEdge, V8, ...)
    ↓ in Sandbox ausführen
Host‑System (gewährt nur deklarierte Fähigkeiten)

Dieses fähigkeitsbasierte Sicherheitsmodell ist der Grund, warum Wasm außerhalb des Browsers nützlich ist. Durch das explizite Gewähren minimaler Rechte lässt sich ein Plugin, das lediglich das Lesen aus einem bestimmten Verzeichnis und das Schreiben in einen bestimmten Ausgabestrom erlaubt, keinerlei Daten exfiltrieren oder das Host‑System verändern, selbst wenn es bösartigen Code enthält.

WASI: Die System‑Schnittstelle

Das WebAssembly System Interface (WASI) ist eine standardisierte API, mit der Wasm‑Module auf portable Weise mit dem Host‑System interagieren können.

WASI definiert, wie ein Wasm‑Modul Dateizugriff, Netzwerk‑Sockets, Uhren und Zufallszahlen anfordert, ohne an ein bestimmtes Betriebssystem oder eine bestimmte Laufzeit gebunden zu sein.

WASI 0.2 (veröffentlicht im Jahr 2024) führte das Component Model ein, das definiert, wie Wasm‑Module zusammengesetzt werden können und wie sie über typisierte Schnittstellen miteinander kommunizieren.

Dies ist die Grundlage für den Aufbau von Systemen, in denen Wasm‑Komponenten die Kompositionseinheit sind, nicht Container oder Prozesse.

// Ein Wasm‑Modul, das eine Schlüssel‑Wert‑Speicherschnittstelle implementiert
// Die Schnittstelle wird in WIT (WebAssembly Interface Types) definiert und kann von jeder Sprache aufgerufen werden, die das Component Model unterstützt

Serverless‑Funktionen

Cold‑Start‑Latenz ist das primäre Performance‑Problem bei container‑basierten Serverless‑Funktionen.

Der Start einer Node.js‑Lambda‑Funktion kann zwischen 100 und 500 Millisekunden dauern – die Zeit, die benötigt wird, um eine MicroVM bereitzustellen, die Container‑Laufzeit zu starten und den Node.js‑Prozess zu initialisieren.

Im Gegensatz dazu dauert ein Wasm‑Funktions‑Cold‑Start nur Mikrosekunden, da kein OS‑Prozess gestartet, kein Container initialisiert und keine Laufzeit gebootet werden muss.

Das Wasm‑Binärformat wird direkt in die bereits laufende Wasm‑Laufzeit geladen, wodurch die zusätzlichen Schichten entfallen.

Cloudflare hat Benchmark‑Daten veröffentlicht, die Workers‑Cold‑Starts konstant unter 5 Millisekunden zeigen; Fastly berichtet ähnliche Werte für Compute@Edge.

Fermyon Spin ist ein Open‑Source‑Framework für den Aufbau Wasm‑basierter Serverless‑Anwendungen, die auf jeder WASI‑kompatiblen Laufzeit ausgeführt werden können.

// Fermyon Spin: eine Wasm‑Serverless‑Funktion in Rust

Während Wasm‑Serverless‑Funktionen im Cold‑Start‑Verhalten erhebliche Vorteile gegenüber container‑basierten Funktionen bieten, müssen sie eine kleinere API‑Oberfläche akzeptieren.

Bibliotheken, die OS‑Threads, Fork oder direkte Systemaufrufe verwenden, kompilieren möglicherweise nicht zu Wasm oder erfordern WASI‑kompatible Alternativen.

Entwickler zwingt das Prinzip der portabilität und Asynchronität, wobei der Code sich klarer und deterministischer gestaltet.

Plugin‑Systeme

Wasm ist eine ausgezeichnete Grundlage für Plugin‑Systeme.

Die Host‑Anwendung lädt ein Wasm‑Modul, gewährt ihm bestimmte Fähigkeiten und ruft seine exportierten Funktionen auf.

Das Plugin kann auf nichts zugreifen, was der Host nicht explizit bereitstellt.

So implementiert der Envoy‑Proxy sein Erweiterungsmodell (Envoy‑WASM‑Filter), ebenso der Zed‑Editor und verschiedene Datenbanksysteme wie SingleStore oder TiDB, die benutzerdefinierte Funktionen bereitstellen.

// Host: ein Wasm‑Plugin laden und aufrufen
use wasmtime::*;

let engine = Engine::default();
let module = Module::from_file(&engine, "plugin.wasm")?;
let mut store = Store::new(&engine, ());
let instance = Instance::new(&mut store, &module, &[])?;

// Die exportierte Funktion des Plugins aufrufen
let process = instance.get_typed_func::<(i32, i32), i32>(&mut store, "process")?;
let result = process.call(&mut store, (input_ptr, input_len))?;

Der Sicherheitsvorteil gegenüber nativen Plugins (Shared Libraries) ist entscheidend.

Ein natives Plugin, das in einen Prozess geladen wird, hat vollen Zugriff auf den Speicher des Prozesses und kann jede Systemfunktion aufrufen.

Ein Wasm‑Plugin kann nur das tun, was der Host explizit erlaubt.

Edge‑Computing

Edge‑Computing führt Berechnungen nahe am Nutzer aus – in CDN‑Knoten, in regionalen Rechenzentren oder auf dem Gerät – um Latenz zu reduzieren und Daten lokal zu halten.

Wasm ist gut für Edge‑Umgebungen geeignet, weil:

• das Binärformat klein ist (typischerweise 100 KB–2 MB, verglichen mit einem Container‑Image von 50–500 MB);
• der Start schnell ist (Mikrosekunden, nicht Sekunden);
• dasselbe Binärformat auf jeder WASI‑kompatiblen Laufzeit läuft, unabhängig vom zugrunde liegenden OS oder der CPU‑Architektur;
• die Sandbox verhindert, dass ein kompromittierter Edge‑Knoten verwendet wird, um die Host‑Infrastruktur anzugreifen.

Cloudflare Workers, Fastly Compute@Edge und Vercel Edge Functions verwenden alle Wasm (oder zu Wasm kompiliertes JavaScript) als Ausführungsmodell.

Die aktuellen Einschränkungen

Wasm ist kein universeller Ersatz für Container oder nativen Code.

Aktuelle Einschränkungen:

• Garbage‑collected Sprachen produzieren große Binärformate. Go und Python, zu Wasm kompiliert, enthalten ihre Laufzeit und produzieren Binärformate von 5–20 MB. Rust und C erzeugen deutlich kleinere Binärdateien.
• Threading ist begrenzt. WASI‑Threads werden noch standardisiert. Multi‑threaded Wasm‑Programme erfordern sorgfältiges Design und greifen häufig auf asynchrone Primitive zurück.
• Nicht alle Bibliotheken kompilieren zu Wasm. Bibliotheken, die OS‑spezifische Features, Fork oder direkte Systemaufrufe verwenden, funktionieren möglicherweise nicht in einer Wasm‑Umgebung.
• Debugging ist schwieriger. Source‑Maps und DWARF‑Debug‑Info werden unterstützt, doch das Tooling ist weniger ausgereift als beim nativen Debugging.
• Das Component Model ist neu. WASI 0.2 und das Component Model wurden 2024 veröffentlicht. Das Ökosystem kompatibler Werkzeuge und Bibliotheken wächst, ist aber noch nicht so reif wie das Container‑Ökosystem.

Warum Wasm kein schnellerer Container ist

Der Cold‑Start‑Vorteil ist real, aber er ist eine Folge eines tieferen architektonischen Unterschieds: Wasm‑Module sind keine Prozesse.

Ein Container ist ein isolierter OS‑Prozess mit eigenem Dateisystem, eigenem Netzwerk‑Namespace und eigener Prozesstabelle.

Ein Wasm‑Modul ist ein kompiliertes Binärformat, das innerhalb einer Host‑Laufzeit läuft, ohne OS‑Ebene‑Isolation – die Isolation wird durch die Wasm‑Spezifikation selbst über das Fähigkeitsmodell durchgesetzt.

Das bedeutet, Wasm und Container konkurrieren nicht um dieselben Anwendungsfälle.

Container sind die richtige Einheit für langlebige Dienste, die OS‑Ebene‑Isolation, volle POSIX‑Kompatibilität und die Fähigkeit benötigen, beliebige Software auszuführen.

Wasm ist die richtige Einheit für kurzlebige, ereignisgesteuerte Funktionen, bei denen die Startzeit wichtig ist, für Plugin‑Systeme, bei denen nicht vertrauenswürdiger Code sicher innerhalb eines Host‑Prozesses ausgeführt werden muss, und für Edge‑Deployments, bei denen Binärgröße und Portabilität Einschränkungen sind.

Beide Modelle ergänzen sich.

Ein Kubernetes‑Cluster, der Container ausführt, kann eine Wasm‑Laufzeit hosten (via containerd’s runwasi‑Shim), die Wasm‑Workloads neben Container‑Workloads ausführt – das jeweils richtige Isolationsmodell für jede Aufgabe verwendend.

Was zu beobachten ist

Das WASI Component Model ist die bedeutendste Entwicklung im Wasm‑Ökosystem.

Es ermöglicht zusammensetzbare, sprachunabhängige Systeme, in denen in verschiedenen Sprachen geschriebene Komponenten ohne FFI‑Klebe‑Code kombiniert werden können.

Das wasmCloud‑Projekt und die Bytecode Alliance sind die primären Organisationen, die diese Arbeit vorantreiben.