Das überzeugendste Einsatzgebiet von WebAssembly liegt außerhalb des Browsers

Als WebAssembly 2017 erstmals in den großen Browsern ausgeliefert wurde, war das Versprechen einfach: Code mit nahezu nativer Geschwindigkeit im Browser ausführen, ohne JavaScript. Frühe Anwender portierten C++-Spiele-Engines, Python-Interpreter und Bildverarbeitungsbibliotheken ins Web. Es funktionierte, aber die Anwendungsfälle wirkten nischenhaft – die meisten Webanwendungen benötigten keine C-schnelle Berechnung, und das JavaScript-Ökosystem war tief genug, dass WASM es selten für die typische Entwicklung ersetzte.

Die überzeugendere Anwendung war jedoch vollständig außerhalb des Browsers zu finden. In den letzten zwei Jahren hat sich WebAssembly als glaubwürdige Laufzeitumgebung für drei verschiedene serverseitige Kontexte etabliert – serverless functions, plugin systems und edge computing – wo sein Sicherheitsmodell und seine Portabilität mehr zählen als die rohe Leistung.

Die entscheidende Eigenschaft von WASM auf dem Server

Das entscheidende Merkmal ist das standardmäßige Sandboxing. Ein WASM-Modul läuft in einem isolierten Speicherbereich ohne Zugriff auf das Hostsystem, es sei denn, dieser wird explizit über die WebAssembly System Interface (WASI) gewährt. Es kann ohne explizite Berechtigungen des Hosts keine Dateien lesen, Netzwerkverbindungen öffnen oder Prozesse starten. Für Browser war dies eine Sicherheitsanforderung; für Serverumgebungen ist es ein architektonischer Vorteil.

Vergleichen Sie dies mit dem traditionellen Plugin-Problem. Wenn Sie Code von Drittanbietern in Ihrer Anwendung ausführen möchten – ein Plugin, eine Erweiterung, eine benutzerdefinierte Funktion – waren die Optionen historisch gesehen schmerzhaft. Sie vertrauen entweder dem Plugin-Entwickler implizit und setzen Ihren Prozess allen Fehlern oder bösartigem Code aus, oder Sie führen Plugins in einem Unterprozess mit vollem IPC-Overhead aus, oder Sie implementieren eine komplexe Berechtigungs-Whitelist, die laufzeitspezifisch und schwer zu prüfen ist. WASM löst dies mit einem einzigen Primitive: Module laufen in ihrer eigenen Sandbox, und Sie definieren genau, welche Host-Funktionen sie über eine typisierte Schnittstelle aufrufen können.

Serverless Functions: Der Kaltstart-Vorteil

Cloudflare Workers war eine der frühesten Produktionswetten auf WASM für Serverless. Workers führen JavaScript und WASM in V8-Isolates im Edge-Netzwerk von Cloudflare aus, mit der zentralen Behauptung, dass die Kaltstartzeiten drastisch sinken, weil WASM-Module kein Betriebssystem booten müssen. Cloudflare berichtet von medianen Kaltstartzeiten unter 5 Millisekunden für Worker-Aufrufe, verglichen mit 100–500 ms für containerbasierte Lambda-Funktionen.

Fastly verfolgte einen ähnlichen Ansatz mit seiner Compute-Plattform, die ausschließlich WASM ausführt und es als Ersatz für VCL (Varnish Configuration Language) positioniert. Entwickler schreiben in Rust, Go, JavaScript oder einer anderen WASM-zielenden Sprache, kompilieren zu einem Modul und stellen es als Fastly-Service bereit – keine Container, keine bereitgestellte Kapazität, kein Kaltstart-Management.

Fermyons Spin-Framework erweitert diesen Ansatz auf die allgemeine Anwendungsentwicklung. Spin ermöglicht es, Microservices zu erstellen, die zu WASM kompilieren und ohne Container oder Kubernetes ausgeführt werden. Jede Funktion ist ein Modul, das in Millisekunden startet, eine Anfrage bearbeitet und beendet wird. Kein warmer Container-Pool, keine pro-Funktion Sidecar-Infrastruktur, kein zu wartendes Container-Image-Registry.

Plugin Systems: Wo sich das Sicherheitsmodell auszahlt

Extism ist ein Open-Source-Plugin-Entwicklungskit, das WASM nutzt, um Entwicklern das sichere Einbetten von Drittanbieter-Code zu ermöglichen. Anstatt zu verlangen, dass Plugins in der Host-Sprache geschrieben werden, erlaubt Extism, dass Plugins aus jeder Sprache kompiliert werden, die auf WASM abzielt – Go, Rust, Python, JavaScript. Der Host definiert eine kleine typisierte Schnittstelle; das Plugin kommuniziert nur durch diese Schnittstelle. Ein fehlerhaftes oder bösartiges Plugin kann die Sandbox nicht verlassen.

Grafana Labs hat dieses Modell für Backend-Plugins übernommen. Neuere Grafana-Plugin-Typen werden als WASM-Module im Grafana-Backend ausgeführt, isoliert voneinander und vom Grafana-Prozess. Dies eliminiert eine Klasse von Supply-Chain-Angriffen, bei denen ein kompromittiertes Plugin vollen Prozesszugriff erlangt – eine echte Sorge in einem Ökosystem mit Hunderten von Drittanbieter-Beiträgen.

Envoy Proxy hat WASM-Erweiterungsunterstützung aus demselben Grund hinzugefügt: Ein Absturz eines WASM-Moduls bringt weder den Proxy-Prozess zum Absturz noch beeinträchtigt es den Verkehr, der durch andere Erweiterungen fließt. Für Edge-Infrastrukturen, die verfügbar bleiben müssen, ist diese Fehlerisolation wichtiger als die rohe Leistung.

Das Component Model: Das fehlende Stück kommt jetzt

Die wichtigste aktuelle Entwicklung im WASM-Ökosystem ist das Component Model, das Anfang 2024 mit WASI 0.2 eingeführt wurde. Bisher kommunizierten WASM-Module über gemeinsam genutzte Speicherpuffer – low-level und fehleranfällig. Das Component Model führt typisierte Schnittstellen ein, die Module implementieren und nutzen können, und ermöglicht Komposition ohne gemeinsamen Speicher.

In der Praxis bedeutet das, dass Sie eine typisierte Schnittstelle definieren können und Plugins diese unabhängig von ihrer Quellsprache implementieren lassen können. Ein Rust-Host kann ein Python- oder Go-Plugin über dieselbe typisierte Schnittstelle aufrufen, wobei die WASM-Laufzeitumgebung die Übersetzung übernimmt. Dies löst den größten Reibungspunkt in WASM-Plugin-Systemen: die Notwendigkeit von FFI-Bindungen oder einer gemeinsamen Laufzeitumgebung.

Die Bytecode Alliance – Mozilla, Intel, Fastly, Microsoft und Google – ist die wichtigste Organisation, die WASM außerhalb des Browsers vorantreibt. Ihre Laufzeitumgebung Wasmtime ist die Referenzimplementierung für WASI 0.2 und die Grundlage der meisten Produktionsdeployments.

Aktuelle Einschränkungen, die man kennen sollte

WASM außerhalb des Browsers ist für bestimmte Workloads produktionsreif, aber nicht universell ausgereift. Threading erfordert gemeinsamen Speicher, was mit dem Isolationsmodell der meisten serverless-Runtimes kollidiert – daher sind die meisten Deployments single-threaded, was die anwendbaren Workloads einschränkt. WASM GC (Garbage Collection), das es verwalteten Laufzeitumgebungen ermöglicht, zu WASM zu kompilieren, ohne ihre eigene GC mitzubringen, wurde erst Ende 2023 in den großen Browsern ausgeliefert und wird in Server-Runtimes noch nicht breit unterstützt. Die Qualität der Toolchains variiert erheblich: Rust und Go haben die ausgereiftesten WASM-Ziele; Python und JavaScript funktionieren, aber mit höherer Betriebskomplexität.

Für Entwickler, die Plattformen bauen, die Code von Drittanbietern akzeptieren – API-Gateways, Automatisierungstools, Observability-Produkte, Developer-Marktplätze – ist WASM jetzt eine ernsthafte architektonische Option für die Plugin-Ebene. Das Sicherheitsmodell ist real, die Leistung ist für anforderungsbezogene Workloads akzeptabel, und das Component Model macht sprachübergreifende Komposition praktikabel. Die serverseitigen Anwendungsfälle sind diejenigen, bei denen sich die architektonischen Eigenschaften, die WASM interessant machen, am deutlichsten von Alternativen abheben.