Warum der Vergleich keine Glaubensfrage ist – und wie beide Technologien zusammenspielen
Die Diskussion um Docker und WebAssembly greift oft zu kurz. In der Praxis geht es nicht um die Wahl eines Tools, sondern um eine grundlegende Strategiefrage: Was ist die kleinste sinnvolle Deploy-Einheit – und wie viel Verantwortung soll sie tragen?
Container und WebAssembly beantworten diese Frage sehr unterschiedlich. Dieser Artikel analysiert beide Ansätze als Entscheidungsgrundlage.
Container als Architekturentscheidung
Die Stärken von Containern
Container sind ein universelles Transportmittel für Software. Sie erlauben beliebige Sprachen und Runtimes, native Libraries ohne Einschränkung, komplexe Laufzeitannahmen und vollständige Kontrolle über das Userland.
Architektonisch bedeutet das: Die Anwendung bringt ihre Umgebung mit. Das Deployment ist selbstbeschreibend. Die Plattform muss wenig über die App wissen.
| Szenario | Warum Container passen |
|---|---|
| Monolithische Services | Komplexe interne Abhängigkeiten |
| Datenbanknahe Systeme | Native Treiber, spezifische Libraries |
| Legacy-Code | Keine Portierung nötig |
| Rechenintensive Workloads | Volle CPU-Nutzung, keine Sandbox-Overhead |
Die Grenzen von Containern
Diese Freiheit hat einen Preis:
- Große Artefakte: Container-Images erreichen schnell mehrere hundert Megabyte bis Gigabyte. Das bedeutet längere Übertragungszeiten, mehr Speicherbedarf in Registries und langsamere Rollouts.
- Startzeit: Das Starten eines Containers dauert typischerweise Sekunden bis Minuten. Für Serverless-Szenarien oder schnelle Skalierung ist das ein Nachteil.
- Sicherheitsarbeit auf OS-Ebene: Base-Images müssen regelmäßig auf CVEs geprüft und aktualisiert werden. Die Verantwortung für Patches liegt beim Entwicklerteam.
- Image-Drift: Unterschiede zwischen Entwicklungs- und Produktions-Images entstehen leicht. Debugging wird schwieriger, wenn Container-Versionen divergieren.
Container skalieren gut technisch, aber jede noch so kleine Logik wird zu einem vollständigen System mit eigenem Betriebssystem, eigenen Dependencies und eigenem Lifecycle.
WebAssembly als Architekturentscheidung
Die Stärken von WebAssembly
WebAssembly dreht das Modell um. Es gibt kein Betriebssystem, kein Filesystem per Default, keine impliziten Abhängigkeiten. Berechtigungen basieren auf Capabilities – alles muss explizit erlaubt werden.
Architektonisch bedeutet das: Die Anwendung ist reiner Code. Fähigkeiten müssen explizit gewährt werden. Die Plattform trägt mehr Verantwortung.
| Szenario | Warum WebAssembly passt |
|---|---|
| Klar abgegrenzte Services | Keine versteckten Abhängigkeiten |
| Funktionale Bausteine | Stateless, Input zu Output |
| Edge-Logik | Schneller Start, kleine Artefakte |
| Security-sensitive Komponenten | Sandboxing by Default |
Die Grenzen von WebAssembly
Wasm ist kein Alleskönner:
- Eingeschränkter Systemzugriff: Direkter Zugriff auf Filesystem oder Netzwerk ist nur über WASI (WebAssembly System Interface) möglich. Nicht alle Systemaufrufe sind implementiert.
- Native Libraries: C-Dependencies müssen nach Wasm portiert werden. Das ist aufwändig und nicht immer möglich – etwa bei Bibliotheken, die direkt auf Hardware zugreifen.
- Stateful Workloads: Datenbanken oder langlebige Prozesse passen nicht ins Wasm-Modell. Die Sandbox ist für kurzlebige, zustandslose Ausführung optimiert.
WebAssembly skaliert konzeptionell gut, aber nicht für jede Art von Software.
Der eigentliche Unterschied: Verantwortungsverteilung
Der Kernunterschied ist nicht Technik, sondern Verantwortungsverteilung:
| Frage | Container | WebAssembly |
|---|---|---|
| Wer bringt die Laufzeit mit? | App | Plattform |
| Wer kontrolliert Abhängigkeiten? | App | Plattform |
| Security-Default | Großzügig (alles erlaubt) | Minimal (nichts erlaubt) |
| Artefaktgröße | Groß (MB-GB) | Klein (KB-MB) |
| Denkmodell | System | Funktion |
| Startzeit | Sekunden | Millisekunden |
Das erklärt, warum der Vergleich oft emotional wirkt: Er zwingt Teams, ihre Architekturannahmen offenzulegen.
Wer gewohnt ist, in Services mit eigener Infrastruktur zu denken, sieht in Wasm Einschränkung. Wer in Funktionen mit klaren Grenzen denkt, sieht in Containern Overhead.
Strategische Entscheidung statt Entweder-oder
Eine realistische Zielarchitektur nutzt oft beide Technologien:
Container bleiben die Basis für:
- Datenbanken
- Core Services mit komplexen Dependencies
- Legacy-Systeme
- Stateful Workloads
WebAssembly ergänzt bei:
- Auth-Filter
- Request- und Response-Transformation
- Validierung
- Edge-Logik
- Kleine, isolierte Worker
Container werden zur Plattformbasis. WebAssembly wird zur feingranularen Deploy-Einheit.
Technischer Stand und praktischer Einsatz
Reifegrad
Der Wasm-Core in Version 1.0 ist produktionsreif. WASI definiert eine verbindliche Schnittstelle zur Außenwelt für Filesystem und Netzwerk. Runtimes wie Wasmtime, Wasmer und WasmEdge haben sich in der Produktion bewährt. Die Toolchains für Rust, Go und C/C++ sind ausgereift, andere Sprachen ziehen nach.
Wo WebAssembly heute produktiv läuft
Etablierte Einsatzgebiete:
- Edge-Computing bei Cloudflare Workers und Fastly Compute
- API-Gateways mit Envoy und Kong
- CDN-nahe Logik
- Plugins und Extensions bei Figma und Shopify
Weniger verbreitet:
- Klassische Backend-Monolithen
- Stateful Systeme
- Datenbanknahe Services
Wasm ist reif für gezielte Einsätze, nicht für pauschale Ablösung.
Best Practices
Bewährte Muster
Kleine, klar abgegrenzte Module: Ein Modul sollte eine Aufgabe erfüllen. Wenn sich die Funktion nicht in einem Satz beschreiben lässt, ist das Modul zu groß.
Stateless Design: Input rein, Output raus. Kein versteckter State im Modul.
Explizite Capability-Definition: Was darf das Modul? Filesystem? Netzwerk? Nur das Nötigste freigeben.
Paralleler Betrieb: Wasm ergänzt bestehende Services, ersetzt sie nicht sofort.
Klare Ownership: Kein geteilter Wasm-Blob ohne klare Verantwortlichkeit.
Häufige Fehler
Wasm als Container-Ersatz denken: Beide Technologien lösen unterschiedliche Probleme.
Zu große Module bauen: Microservices-Denken auf Wasm übertragen führt zu unnötiger Komplexität.
Native Abhängigkeiten erzwingen: Nicht jede Library lässt sich sinnvoll nach Wasm portieren.
State in Wasm pressen: Die Sandbox ist für zustandslose Ausführung optimiert.
Leitfragen für die Entscheidung
| Frage | Container wahrscheinlich | Wasm wahrscheinlich |
|---|---|---|
| Braucht der Service ein eigenes OS? | Ja | Nein |
| Wie groß darf das Artefakt sein? | Egal | Klein wichtig |
| Wie viel implizite Abhängigkeit tolerieren wir? | Viel | Wenig |
| Ist das ein System oder Logik? | System | Logik |
| Läuft das zentral oder nah am Edge? | Zentral | Edge |
| Wie kritisch ist Startzeit? | Egal | Sehr wichtig |
| Wie wichtig ist Security-Isolation? | Standard | Sehr wichtig |
Wenn die Antwort oft in Richtung Logik statt System geht, ist ein Container wahrscheinlich Overkill.
Entwicklung in den nächsten Jahren
Wahrscheinliche Entwicklungen
Wasm wird zum Standard für Edge-Logik. Plattformen bieten Wasm nativ an. Container werden zu Runtime-Trägern für komplexe Systeme. Entwickler denken wieder stärker in Funktionen statt Systemen.
Unwahrscheinliche Entwicklungen
Eine vollständige Ablösung von Containern ist nicht zu erwarten. Wasm wird kein Allzweck-Backend für alles. Es wird keine einheitliche Runtime für alle Anwendungsfälle geben.
Drei strukturelle Gründe für WebAssembly
Sicherheit als Default
Das Capability-basierte Modell gewährt keinen impliziten Zugriff. Die Angriffsfläche ist deutlich kleiner als bei Containern. Das passt zu Zero-Trust-Architekturen.
Ökonomischer Druck
Kleinere Artefakte bedeuten weniger Speicher und schnellere Deploys. Schnellere Starts ermöglichen bessere Skalierung. Weniger Patch-Aufwand reduziert Wartungskosten. Geringere Supply-Chain-Komplexität senkt das Risiko.
Edge und Verteilung
Logik wandert näher an Nutzer. Klassische Servermodelle werden fragmentierter. Wasm skaliert gut über geografisch verteilte Standorte.
Container und Wasm: Keine Konkurrenten
Container und WebAssembly sind keine direkten Konkurrenten, sondern Werkzeuge für unterschiedliche Architekturentscheidungen.
| Technologie | Optimiert auf |
|---|---|
| Container | Flexibilität, Universalität |
| WebAssembly | Begrenzung, Isolation, Effizienz |
Gute Architekturen nutzen beides bewusst, nicht reflexartig.
WebAssembly ist keine Revolution im Sinne von allem neu. Es ist eine Korrektur: weniger implizite Komplexität, klarere Verantwortungsgrenzen, kleinere und sicherere Deploy-Einheiten.
Teams, die Wasm gezielt einsetzen, gewinnen Kontrolle. Teams, die es pauschal einsetzen wollen, verlieren Zeit.
WebAssembly systematisch lernen
Sie möchten WebAssembly von Grund auf verstehen und fundierte Architekturentscheidungen treffen?
👉 WebAssembly lernen – Der komplette Praxis-Kurs
Im Kurs lernen Sie:
- WebAssembly Grundlagen und Konzepte
- Rust + WASM Toolchain Setup und Workflow
- Praktische Integration in Web-Projekte
- Performance-Optimierung und Debugging
- Browser APIs und DOM-Manipulation mit Rust
- Deployment und Best Practices
Weiterführende Artikel
- Rust + WebAssembly: Einstieg für Webentwickler – Praktischer Einstieg in die Wasm-Entwicklung mit Rust