WebAssembly jenseits des Browsers: WASM auf dem Server und an der Edge ausführen
🇬🇧 Read in English~6 min read
webassemblywasmserverlessedge-computingruntime
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
A practical guide to the CNCF Cloud Native Landscape — the tools and categories that actually matter for building production infrastructure.
WebAssembly (WASM) wurde ursprünglich als Browser-Kompilierungsziel für hochperformante Webanwendungen entwickelt. In den letzten Jahren hat es sich jedoch weit über den Browser hinaus ausgedehnt und eine natürliche Heimat in Server-Side-, Edge- und Embedded-Umgebungen gefunden, in denen seine Sandboxing-Eigenschaften, Portabilität und Startup-Performance von einzigartigem Wert sind.
Dieser Artikel untersucht das Ökosystem der WASM-Runtimes außerhalb des Browsers und praktische Anwendungsfälle für das Deployment von WASM-Modulen in der Produktion.
Das Kernwertversprechen von WebAssembly außerhalb des Browsers stützt sich auf drei Eigenschaften:
Jedes WASM-Modul läuft in einer Capability-basierten Sandbox. Im Gegensatz zu Containern, die den Host-Kernel teilen und Isolationsmechanismen auf Root-Ebene (Namespaces, cgroups) erfordern, sind WASM-Module standardmäßig auf Prozessebene isoliert. Kein Dateisystemzugriff, kein Netzwerkzugriff, keine Systemaufrufe – es sei denn, diese wurden explizit gewährt.
Dies macht WASM zu einem idealen Kandidaten für Multi-Tenant-Workloads, bei denen Container zu schwerfällig sind und eine Isolierung auf Prozessebene nicht ausreicht:
WASM-Module können aus C, C++, Rust, Go, Zig und (via WASI) Sprachen wie Python und TypeScript kompiliert werden. Ein aus Rust kompiliertes WASM-Modul läuft identisch auf Linux, macOS, Windows und innerhalb des Browsers. Diese Portabilität eliminiert plattformspezifische Build-Artefakte und ermöglicht ein echtes „Write-Once-Run-Anywhere“ für kompilierten Code.
Ein WASM-Modul startet typischerweise in Mikrosekunden bis Millisekunden – um Größenordnungen schneller als Container (Sekunden) oder VMs (zehn Sekunden). Dies macht WASM zur praktischsten Runtime für Edge-Computing-Szenarien, in denen Funktionen bei jeder Anfrage starten müssen und Cold Starts inakzeptabel sind.
Es existieren mehrere ausgereifte Runtimes für den Betrieb von WASM außerhalb des Browsers:
Wasmtime der Bytecode Alliance ist die am weitesten verbreitete WASM-Runtime für den serverseitigen Einsatz. Sie implementiert sowohl die Core-WASM-Spezifikation als auch den WASI-Standard (WebAssembly System Interface), der einen POSIX-ähnlichen Zugriff auf Systemaufrufe ermöglicht.
Wasmtime ist in Rust geschrieben und bietet SDKs für C, Python, Go und Rust zur Einbettung. Es ist die Runtime hinter vielen produktiven WASM-Deployments:
// Embedding Wasmtime in a Rust application
use wasmtime::{Engine, Module, Store, Linker};
let engine = Engine::default();
let module = Module::from_file(&engine, "my_module.wasm")?;
// Configure limits
let mut store = Store::new(&engine, ());
store.limiter(|state| -> Option<ResourceLimiter> {
Some(WasmResourceLimiter {
memory_size: 10 * 1024 * 1024, // 10MB
table_size: 1000,
})
});
let linker = Linker::new(&engine);
let instance = linker.instantiate(&mut store, &module)?;
WasmEdge ist für Cloud-Native- und Edge-Computing-Anwendungsfälle optimiert. Es unterstützt TensorFlow-basierte Inferenz, AI/ML-Workloads und bietet eine vollständige WASI-Implementierung mit erweitertem Netzwerk-Support.
WasmEdge kann als Sidecar oder als eigenständige Runtime eingesetzt werden. Es integriert sich in containerd, sodass WASM-Module über dieselben Container-Orchestrierungs-Tools verwaltet werden können, die Teams bereits nutzen.
Wasmer bietet eine benutzerfreundliche WASM-Runtime mit einem Paketmanager (WAPM) und Unterstützung für mehrere Compiler (Cranelift, LLVM, Singlepass). Es ist für Desktop- und Serveranwendungen konzipiert, bei denen WASM-Module native Plugins ersetzen.
Im Edge Computing stimmen die Eigenschaften von WASM am perfektsten mit den Anforderungen der Workloads überein:
Cloudflare Workers führen JavaScript/TypeScript aus, das nach WASM kompiliert wurde. Jeder Worker startet in unter 5 ms, läuft in einem isolierten V8-Isolate und ist über mehr als 300 Edge-Standorte verteilt. Das WASM-Kompilierungsziel bedeutet, dass Worker, die in Rust, C oder Zig geschrieben wurden, neben JavaScript-Code laufen können.
Fastly nutzt Lucet (jetzt Teil von Wasmtime), um WASM-Module am Edge auszuführen. Module werden während des Deployments in nativen Code vorkompiliert, wodurch das JIT-Warmup vollständig entfällt. Der Cold Start liegt bei unter 100 µs – schnell genug, dass jede Anfrage ein frisches Isolate erhält, ohne dass Pooling erforderlich ist.
wasmCloud ist eine Open-Source-Plattform für den Aufbau verteilter WASM-Anwendungen. Sie bietet:
WASM ist das ideale Kompilierungsziel für erweiterbare Plugin-Systeme. Anstatt eine Scripting-API (Lua, JavaScript, Python) bereitzustellen oder native Shared Libraries zu erfordern, können Anwendungen WASM-Module aus nicht vertrauenswürdigen Quellen laden:
WASM-basierte Serverless Functions bieten schnellere Cold Starts als Container-basierte Alternativen. Spin (von Fermyon) ist ein Framework für den Bau von Serverless-Anwendungen in WASM, das mehrere Sprachen unterstützt und Bindings für HTTP, Redis und PostgreSQL bereitstellt.
spin new my-function
cd my-function
spin build
spin deploy
Die Ausführung von Datenverarbeitungs-Pipelines am Edge reduziert Bandbreitenkosten und Latenz. WASM-Module können Filterung, Aggregation und Transformation an Streaming-Daten vornehmen, bevor die Ergebnisse an zentrale Systeme weitergeleitet werden:
WASM ist kein universeller Ersatz für Container. Hier sind die wichtigsten Einschränkungen, die man beachten sollte:
Die WASI Preview 2 Spezifikation führt ein Component Model ein, das die serverseitigen Fähigkeiten von WASM erheblich verbessert. Komponenten sind WASM-Module mit typisierten Schnittstellen, die unabhängig voneinander zusammengesetzt, versioniert und verteilt werden können.
Dies wird ein Ökosystem aus wiederverwendbaren WASM-Komponenten ermöglichen – vergleichbar mit NPM für sandboxed, portable und polyglotte Module –, die zu Anwendungen zusammengesetzt werden können, ohne eine gemeinsame Language Runtime oder ein Build-System zu teilen. Die Auswirkungen auf die Softwarearchitektur sind substanziell: Microservices werden zu Micro-Components, die auf der Granularität einzelner Module deploybar und skalierbar sind.
Wenn Sie serverseitiges WASM erkunden möchten, ist dies der einfachste Weg:
curl https://wasmtime.dev/install.sh | bashcargo build --target wasm32-wasiwasmtime target/wasm32-wasi/debug/my_module.wasmspin new, spin build, spin upWebAssembly außerhalb des Browsers ist keine experimentelle Technologie – es wird bereits produktiv bei großen Edge-Providern, in Plugin-Systemen und als sandboxed Execution Environment für nicht vertrauenswürdigen Code eingesetzt. Die verbleibenden Lücken schließen sich mit WASI Preview 2 und dem Component Model schnell.