WebAssembly auf dem Server: Hype oder Zukunft?

Im Jahr 2019 veröffentlichte Docker-Mitbegründer Solomon Hykes etwas, das seitdem zitiert wird: Wenn WebAssembly und WASI 2008 existiert hätten, hätten sie Docker nicht erstellen müssen. Das ist ein großer Anspruch. Einige Jahre später, wo steht Server-seitige WebAssembly eigentlich?

Wasm außerhalb des Browsers

WebAssembly (Wasm) Begonnen als eine Möglichkeit, schneller, kompilierten Code in Webbrowsern zu laufen: Spiele, Video-Editoren, Design-Tools. Es ist ein kompaktes Binärformat, in das viele Sprachen (Rust, C/C++, Go, C#, Zig und andere) kompilieren können, und das in einer Sandbox-Virtuellen Maschine ausgeführt wird.

Die Eigenschaften, die es in Browsern großartig machen, sind auch auf Servern interessant:

• Schnell starten: Module starten in Mikrosekunden bis Millisekunden, viel schneller als Container.
• Kleine: Module sind oft Kilobyte bis zu wenigen Megabyte.
• Sicherung standardmäßig: ein Wasm-Modul kann nicht auf Dateien, Netzwerk oder irgendetwas anderes zugreifen, es sei denn, es wird ausdrücklich zugelassen. Eine starke Sandbox.
• mit einem Durchmesser von: dasselbe Modul läuft auf jedem Betriebssystem und jeder CPU-Architektur mit einer Wasm-Laufzeit.

Um außerhalb des Browsers zu arbeiten, braucht Wasm eine Möglichkeit, mit dem System zu sprechen: Dateien, Uhren, Steckdosen. Das ist... WASI (WebAssembly System Interface) WASI 0, 2 Die Modell der Komponente, mit dem Wasm-Komponenten, die in verschiedenen Sprachen geschrieben sind, über gut definierte Schnittstellen zusammenarbeiten können. Weitere Versionen fügen Async-Unterstützung und mehr hinzu.

Container packen ein Betriebssystem um Ihre App. Wasm packt nur deine App ein und bittet um Erlaubnis für alles andere.

Ich habe es auf Kubernetes ausgeführt.

Wasm muss nicht deine Plattform ersetzen. Es kann neben Containern laufen:

• Behälter-Schimmeln (wie die vom Runwasi-Projekt) lassen Kubernetes Wasm-Workloads durch eine normale RuntimeClass- Ich weiß . Eine Kapsel kann ein Wasm-Modul anstelle eines Container-Bildes ausführen.
• SpinKube - läuft Apps, die mit Dreh (von Fermyon) auf Kubernetes, mit sehr hoher Dichte und schneller Skalierung.
• WasmCloud (ein CNCF-Inkubatorprojekt) ist eine Plattform für verteilte Wasm-Anwendungen in Clouds, Edge und Kubernetes.
• Wasm-Module können in OGI-Register, genau wie Containerbilder.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmtime-spin
handler: spin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-wasm
spec:
  replicas: 3
  selector:
    matchLabels: { app: hello-wasm }
  template:
    metadata:
      labels: { app: hello-wasm }
    spec:
      runtimeClassName: wasmtime-spin
      containers:
      - name: hello
        image: ghcr.io/acme/hello-wasm:1.0.0
        command: ["/"]

Wo es passt

Wasm wird bereits an Orten produziert , die man vielleicht nicht bemerkt:

• Edge Computing: Cloudflare-Arbeiter, Fastly Compute und andere Edge-Plattformen betreiben Wasm (oder ähnliche Isolate) aufgrund des schnellen Starts und der starken Isolation. Code läuft in der Nähe der Benutzer ohne fast einen kalten Start.
• Plugins und Erweiterungen: Proxy-Filter, Datenbank-Erweiterungen und Tools wie das Plugin-System von Helm 4 verwenden Wasm, um Code von Drittanbietern sicher auszuführen.
• Funktionen ohne Server wo Kälte anfängt, kommt die Materie.
• Mehrfache Plattformen Die notwendigen Daten, um unzuverlässigen Benutzercode sicher auszuführen.
• IoT und eingebettete Geräte mit begrenzten Ressourcen.

Wo es noch nicht ist

• Reife des Ökosystems: viele Bibliotheken, insbesondere solche, die auf Threads, Netzwerke oder Systemanrufe angewiesen sind, funktionieren noch nicht vollständig in WASI. Es verbessert die Freigabe nach Freigabe.
• Sprachunterstützung variiert: Rost ist ausgezeichnet; andere Sprachen sind gut, aber mit Vorbehalten; einige populäre Sprachen haben noch rauhe Kanten.
• Werkzeugbau und Debugging sind weniger reif als für Behälter.
• Bestehende Anwendungen: Das Umschreiben oder Neukomponieren einer großen vorhandenen Anwendung für Wasm ist selten sinnvoll. Container laufen heute mit jeder Linux-Software.
• Langfristige und schwere ArbeitsbelastungenDie Kontainer sind immer noch die natürliche Passform.

Also, Hype oder Zukunft?

Beides, ehrlich gesagt. Wasm wird die Container für die meisten Arbeitslasten nicht bald ersetzen. Container haben ein riesiges Problem gelöst und sie sind überall. Wasm ist die Zukunft für bestimmte Bereiche: Edge, Plugins, serverlose Dichte und sichere Ausführung von nicht vertrauenswürdigem Code. Diese Bereiche wachsen.

Für DevOps-Ingenieure lohnt es sich jetzt zu verstehen: wie es auf Kubernetes läuft, wie es in OCI-Registern verpackt ist und wo es in Ihrem Stack erscheinen könnte.

Wasm ist nicht der nächste Container. Das ist das, was man greifen kann, wenn ein Container zu schwer, zu langsam oder zu vertrauensvoll ist.

Desly