DevOpsMar 28, 2026

WASI 0.3 und das Ende der Kaltstarts: Server-seitiges Wasm in Produktion

Engineering Team

WASI 0.3 ist da — und es aendert alles

Das WebAssembly System Interface (WASI) 0.3 wurde im Februar 2026 veroeffentlicht und schliesst die letzte Luecke, die server-seitiges Wasm davon abhielt, in den Mainstream der Produktions-Workloads einzutreten. Mit nativem async I/O, erstklassigen Stream-Typen und vollstaendigem TCP/UDP-Socket-Support koennen Wasm-Module jetzt alles tun, was ein Container kann — bei einem Bruchteil der Startkosten.

Wenn Sie Wasm auf dem Server als Spielzeug abgetan haben, ist dieses Release Ihr Signal zum Umdenken. AWS, Google Cloud und Azure haben alle 2025-2026 Wasm-Serverless-Runtimes gestartet, und Unternehmen wie Fermyon, Fastly und Cloudflare betreiben Wasm seit ueber zwei Jahren im Produktionsbetrieb.

Was WASI 0.3 tatsaechlich liefert

WASI 0.2 (Januar 2024) fuehrte das Component Model und grundlegende I/O-Schnittstellen ein. WASI 0.3 baut auf diesem Fundament mit drei kritischen Ergaenzungen auf:

Natives Async I/O

WASI 0.2 bot nur blockierendes I/O. Wenn Ihr Wasm-Modul mehrere gleichzeitige Verbindungen verarbeiten musste, waren Sie auf Threads oder umstaendliche Polling-Schleifen angewiesen. WASI 0.3 fuehrt ein natives asynchrones Modell ein, das direkt auf sprachspezifische async-Primitive abbildet:

Rust: async fn mit tokio oder async-std kompiliert nativ zu WASI 0.3 async
Go: Goroutinen werden auf WASI-async-Tasks abgebildet
Python: Die asyncio-Event-Loop integriert sich mit dem WASI-Scheduler
JavaScript: Promise und async/await funktionieren ueber JCO sofort

Die Runtime (Wasmtime, WasmEdge oder Spin) verwaltet die Event-Loop. Ihr Code schreibt idiomatisches async in der Sprache Ihrer Wahl, und die WASI-Schicht uebernimmt den Rest.

// Rust async HTTP-Handler kompiliert zu WASI 0.3
use wasi::http::types::{IncomingRequest, ResponseOutparam};

async fn handle_request(req: IncomingRequest, resp: ResponseOutparam) {
    // Request-Body asynchron lesen
    let body = req.consume().await.unwrap();
    let bytes = body.read_all().await.unwrap();
    
    // Ausgehenden HTTP-Aufruf (nicht-blockierend)
    let api_response = wasi::http::outgoing_handler::handle(
        build_api_request(&bytes)
    ).await.unwrap();
    
    // Antwort streamen
    let out = resp.set(200, &headers);
    out.body().write_all(&api_response.body()).await.unwrap();
}

Stream-Typen

WASI 0.3 fuehrt stream<T> und future<T> als erstklassige Typen im Component-Model-Typsystem ein. Das bedeutet, dass Komponenten Streaming-Daten ueber Sprachgrenzen hinweg ohne Serialisierung uebergeben koennen:

// WIT-Interface-Definition mit Stream-Typen
interface data-processor {
    process: func(input: stream<list<u8>>) -> stream<record>;
    
    record record {
        id: u64,
        payload: list<u8>,
        timestamp: u64,
    }
}

Dies ermoeglicht echte Streaming-Pipelines, in denen ein Rust-Datenparser in ein Python-ML-Modell speist, das wiederum in einen Go-Serializer speist — alles im selben Prozess ueber Zero-Copy-Streams.

Vollstaendiger Socket-Support

WASI 0.3 bietet vollstaendige TCP- und UDP-Socket-APIs:

tcp::listen und tcp::connect fuer Server- und Client-Sockets
udp::bind und udp::send_to / udp::recv_from fuer Datagramm-Protokolle
TLS-Terminierung ueber wasi:sockets/tls
DNS-Aufloesung ueber wasi:sockets/name-lookup

Das Component Model: Polyglotte Komposition

Das Component Model, stabilisiert in WASI 0.2 und verfeinert in 0.3, macht server-seitiges Wasm grundlegend anders als Container. Es ermoeglicht die Komposition mehrerer Wasm-Komponenten — in verschiedenen Sprachen geschrieben — zu einer einzigen Anwendung:

+------------------+     +-------------------+     +------------------+
| Auth Component   |---->| Business Logic    |---->| Data Layer       |
| (Rust)           |     | (Python)          |     | (Go)             |
+------------------+     +-------------------+     +------------------+
        |                         |                         |
    wasi:http                 wasi:keyvalue             wasi:sql
    capability                capability                capability

Jede Komponente:

Laeuft in ihrer eigenen Sandbox mit faehigkeitsbasierter Sicherheit (keine Ambient Authority)
Deklariert benoetigte Systemschnittstellen ueber WIT
Kommuniziert mit anderen Komponenten ueber typisierte Schnittstellen, nicht serialisiertes JSON
Kann unabhaengig aktualisiert werden, ohne die gesamte Anwendung neu zu deployen

Fermyon Spin 3.0, veroeffentlicht im Januar 2026, unterstuetzt Multi-Komponenten-Anwendungen in Produktion.

Leistung: Mikrosekunden-Kaltstarts vs. Container-Sekunden

Metrik	Docker-Container	AWS Lambda	Wasm-Modul (Spin)	Wasm-Modul (Wasmtime)
Kaltstart	500ms - 5s	100ms - 2s	0.5ms - 3ms	0.3ms - 2ms
Warmer Aufruf	1ms - 50ms	1ms - 20ms	0.1ms - 1ms	0.05ms - 0.5ms
Speicherbedarf	50MB - 500MB	128MB - 10GB	1MB - 20MB	1MB - 15MB
Binaergroesse	50MB - 2GB	N/A (zip-Paket)	1MB - 30MB	1MB - 30MB
Start-Overhead	OS + Runtime + App	Runtime + App	Modul-Instanzierung	Modul-Instanzierung
Isolation	Linux namespaces + cgroups	Firecracker microVM	Wasm-Sandbox	Wasm-Sandbox

Der Unterschied ist nicht inkrementell — es sind drei Groessenordnungen.

Warum so schnell?

Wasm-Module ueberspringen die gesamte OS-Boot-Sequenz. Keine Kernel-Initialisierung, kein Dateisystem-Mount, kein dynamisches Bibliotheksladen. Wasmtime 19 (Maerz 2026) fuehrte gepoolte Instanz-Allokation ein — die Instanzierung wird zu einem Pointer-Bump in Nanosekunden.

Cloud-Anbieter-Landschaft

AWS Lambda Wasm Runtime (GA Dezember 2025)

WASI 0.3-Support ueber Wasmtime
Sub-Millisekunden-Kaltstarts
Component-Model-Support fuer mehrsprachige Funktionen
50% guenstiger als aequivalentes Container-Lambda

Google Cloud Run Wasm (GA Februar 2026)

.wasm-Komponenten direkt ueber gcloud run deploy --wasm deployen
Auto-Scaling auf Null mit Mikrosekunden-Kaltstarts
gRPC- und HTTP/2-Support ueber WASI-Sockets

Azure Container Apps Wasm (Preview, GA Q2 2026)

Kubernetes-nativ: Wasm-Workloads neben Containern im selben Cluster
Spin Operator verwaltet den Wasm-Komponenten-Lebenszyklus
KEDA-basiertes Auto-Scaling

Rust + Wasm Entwicklungs-Workflow

# WASI-Target installieren
rustup target add wasm32-wasip2

# Neues Projekt erstellen
cargo init --name my-service

# WASI-Abhaengigkeiten hinzufuegen
cargo add wit-bindgen
cargo add wasi --features "http,keyvalue,sql"

# Wasm-Komponente bauen
cargo build --target wasm32-wasip2 --release

# Lokal mit Wasmtime ausfuehren
wasmtime serve target/wasm32-wasip2/release/my_service.wasm

Container vs. Wasm-Module: Vollstaendiger Vergleich

Dimension	Container (Docker/OCI)	Wasm-Module (WASI 0.3)
Kaltstart	500ms - 5s	0.3ms - 3ms
Speicher-Overhead	50MB - 500MB Baseline	1MB - 20MB Baseline
Binaergroesse	50MB - 2GB Images	1MB - 30MB Komponenten
Isolationsmodell	Linux namespaces + cgroups	Wasm-Sandbox (memory-safe by design)
Sprachunterstuetzung	Alle (native Binaries)	Rust, Go, Python, JS, C/C++, C#, Kotlin
Netzwerk	Vollstaendiger OS-Netzwerkstack	WASI-Sockets (TCP, UDP, TLS)
Dateisystem	Vollstaendiges POSIX-Dateisystem	Faehigkeitsbasiertes virtuelles FS
GPU-Zugriff	NVIDIA Container Toolkit	Experimentell (wasi-nn)
Oekosystem-Reife	12+ Jahre, riesiges Oekosystem	3 Jahre, schnell wachsend
Orchestrierung	Kubernetes, ECS, Nomad	SpinKube, wasmCloud, Kubernetes (via Shim)

Wann Wasm verwenden

Serverless-Funktionen — wenn Kaltstart-Latenz wichtig ist
Edge Computing — wenn Binaergroesse und Speicher begrenzt sind
Plugin-Systeme — wenn sichere Drittanbieter-Codeausfuehrung benoetigt wird
Multi-Tenant-Plattformen — wenn Isolationsdichte wichtig ist
Polyglotte Microservices — wenn Teams verschiedene Sprachen verwenden

Wann bei Containern bleiben

GPU-Workloads (ML-Training/Inferenz) — WASI-GPU-Support ist noch experimentell
Legacy-Anwendungen — abhaengig von spezifischen OS-Features
Stateful Services — die persistenten lokalen Speicher benoetigen
Komplexe Debugging-Szenarien — die vollstaendiges OS-Level-Tooling erfordern

Produktions-Fallstudien

Shopify: Edge Commerce

Shopify migrierte sein Storefront-Rendering 2025 zu Wasm am Edge und verarbeitet 2,3 Millionen Anfragen pro Sekunde ueber Cloudflare Workers. Ergebnis: 68% Reduktion der TTFB fuer globale Kunden.

Midokura (Sony): IoT-Gateway

Sonys Tochterunternehmen Midokura nutzt Wasm fuer Geraeteprotokoll-Handler auf IoT-Gateways mit 256MB RAM. Mit Wasm laufen 40 Protokoll-Handler im Speicherbedarf von zuvor 4 Containern.

Fermyon Platform: Multi-Tenant SaaS

Fermyons Cloud-Plattform betreibt Kunden-Workloads als Wasm-Komponenten mit 12.000 Instanzen pro Knoten. Durchschnittlicher Kaltstart 0,8ms, Kosten pro Anfrage 10x niedriger als aequivalente Lambda-Funktionen.

Sicherheitsmodell

Standardmaessig verweigert — Wasm-Module koennen auf nichts zugreifen, es sei denn, der Host gewaehrt explizit Faehigkeiten
Speichersicherheit — Linearer Speicher verhindert Buffer-Overflow-Escapes
Keine Ambient Authority — jede Faehigkeit muss einzeln gewaehrt werden
Formale Verifikation — die Wasm-Spezifikation ist einfach genug fuer formale Verifikationstools

Haeufig gestellte Fragen

Ist WASI 0.3 produktionsreif?

Ja. WASI 0.3 ist die erste Version, die die Bytecode Alliance als produktionsreif fuer Server-Workloads betrachtet.

Kann Wasm Kubernetes ersetzen?

Nicht vollstaendig. Wasm ersetzt die Container-Runtime fuer geeignete Workloads, aber Orchestrierung wird weiterhin benoetigt.

Wie sieht es mit Datenbank-Treibern aus?

Der vollstaendige Socket-Support von WASI 0.3 ermoeglicht native Datenbank-Treiber. Das wasi:sql-Interface bietet eine standardisierte SQL-API.

Wie handhabt WASI 0.3 State?

Wasm-Module sind standardmaessig zustandslos. Fuer State verwenden Sie wasi:keyvalue, wasi:sql oder externe Services ueber WASI-Sockets.

Wie steil ist die Lernkurve fuer Rust + Wasm?

Wenn Sie Rust bereits kennen, ist der zusaetzliche Lernaufwand minimal. Wenn Rust neu fuer Sie ist, rechnen Sie mit 2-4 Wochen bis zur Produktivitaet.