Universell portabel. Schneller als Linux-Container Die „serverlose“ Edge mit Wasm

Was einst das Java-Ökosystem versprochen hatte, lässt sich jetzt offenbar mit WebAssembly erreichen, nur um Einiges performanter. WebAssembly, eine universelle Ausführungsplattform für hochperformanten, portablen und modularen Code, der in einer leichtgewichtigen virtuellen Maschine systemagnostisch läuft, macht in Cloud-Umgebungen vom Rechenzentrum über Embedded-Systeme bis hin zu Edge-Clouds die Runden.

Im Bestreben, mehr Datenintelligenz aus dem Rechenzentrum an die Edge zu bringen, müssen sich Unternehmen mit Leistungsengpässen, Anforderungen der Datensouveränität, strengen Datenschutzrichtlinien, dem Kostendruck, der Cyber-Sicherheit und einer Reihe anderer Herausforderungen auseinandersetzen. Anwenderorganisationen stoßen zudem nahezu universell auf eine Reihe von Herausforderungen im Zusammenhang mit Cloud-nativer Skalierbarkeit einer verteilten Bereitstellung und Edge-freundlicher Latenz.

Die Bereitstellung von Echtzeit-Anwendungen wie Messaging-Apps, Streaming-Diensten und Multiplayer-Spielen, die auf eine Round-Trip-Anfrage in weniger als 200 Millisekunden reagieren müssen, unter Verwendung von Linux-Containern setzt voraus, dass die betreffenden Anwendungen bereits im Leerlauf laufen, bevor die Anfragen eintreffen. Das führt zur planmäßigen Überprovisionierung zwecks Vermeidung von Container-Kaltstarts.

Die Kosten des Leerlauf-Betriebs addieren sich für jede Anwendung und multiplizieren sich mit der Anzahl der Kubernetes-Stützpunkte einer hybriden Multicloud. (siehe hierzu: „10 Jahre Kubernetes: Wie Orchestrierung die Cloud-Native-Welt eroberte“). Zudem müssen die Anwendungen in jeder Datacenter-Region auch schon mal vorab „auf Verdacht“ skalieren, um die erwartete Nachfrage unter Einhaltung der erforderlichen Latenz erfüllen zu können.

In solchen echtzeitnahen Szenarien laufen sogar stark optimierte Kubernetes-Bereitstellungen oft mit beachtlicher Leerlaufkapazität. Das hätte längst nicht sein müssen.

Fastly, ein globaler Anbieter von Edge-freundlichen Diensten zur Gewährleistung von Anwendungsperformance aus dem kalifornischen San Francisco, macht es anders. Fastly macht aus WebAssembly (Wasm) ausgiebig Gebrauch (siehe dazu auch den Bericht „Was ist Wasm?“).

Das Resultat: Der Internet-Beschleuniger initialisiert Edge-Anwendungen seiner Kunden mit einer Kaltstartzeit von gerade einmal einer halben Millisekunde (gerade einmal 500 Mikrosekunden) – rund 100mal schneller als das menschliche Nervensystem braucht, um ein Nervenimpuls vom menschlichen Gehirn zur „Peripherie“ im Arm zu übertragen. „Fastly Compute“, die serverlose Plattform des Anbieters, baut auf WebAssembly auf.

WebAssembly (Wasm) ermöglicht es Unternehmen, Softwarecode in Sprachen wie Go, Rust, C/C++ und Java in Bytecode zu kompilieren und in einer Stack-basierten virtuellen Maschine (VM) auf einem nahezu beliebigen System mit nahe-nativer Performance der Hardware auszuführen. WASM-Code startet typischerweise innerhalb von Millisekunden, benötigt weniger Ressourcen als traditionelle Container, nimmt eine geringere Dateigröße in Anspruch (was wiederum auch Bandbreite spart) und trumpft auch noch mit einer verbesserten Anwendungsisolation auf.

„Als wir anfingen, konnte es Stunden dauern, Inhalte auf Akamai oder EdgeCast zu invalidieren und zu modifizieren“ erinnert sich Simon Wistow, Mitgründer und VP Strategic Initiatives bei Fastly. Der Fastly-Stack schafft es durchschnittlich in 150 Millisekunden.

Fastly verfügt über ein globales Servernetzwerk mit Rechenzentren weltweit. In Deutschland betreibt das Unternehmen mehrere Standorte in Co-Location-Rechenzentren von Anbietern wie Equinix und Digital Realty, darunter in Frankfurt am Main und in München.

Fastly Compute kompiliert benutzerdefinierten Code in WebAssembly und führt ihn an der Fastly-Edge mithilfe von „WASI“ aus. Eine anfragespezifische Isolation und leichtgewichtiges Sandboxing schaffen eine hochperformante und sichere Umgebung mit rekordverdächtiger Latenz.

Typische Anwendungsfälle umfassen dynamische Inhaltsbereitstellung, Echtzeitdatenverarbeitung und andere Nutzungsszenarien mit gehobenen Sicherheitsanforderungen und Ansprüchen an extrem geringe. Jede Anfrage wird in einer isolierten Umgebung verarbeitet.(zu Fastly siehe auch: „Fast, faster, Fastly! Mithilfe von Wasm wächst die schnellste Cloud der Welt“)

Fast, faster, Fastly!

Mithilfe von Wasm wächst die schnellste Cloud der Welt

Das Unternehmen legt einen hohen Wert auf Sicherheits- und Leistungsoptimierungen seiner „Lucet“-Runtime und nutzt Maschinelles Lernen am Netzwerkrand unter Verwendung von Lösungen wie „wasi-nn“.

Inzwischen machen sich auch die Mitbewerber von Fastly, darunter Unternehmen wie Cloudflare oder Cosmonic, ausgiebig WebAssembly zu Nutze. Die Eclipse Foundation versucht mit „Jakarta EE“ Vertrauen zurückzugewinnen.

Wasm und Java

Java-Anwenderorganisationen stoßen in „cloudifizierten“ Umgebungen auf eine ganze Reihe von Herausforderungen, die sich mit Wasm entschärfen lassen – denn auch Java lässt sich zu WebAssembly kompilieren. Zu den offensichtlichsten dieser Java-Schmerzpunkte zählen:

• Unzureichende Skalierbarkeit: Die Herausforderungen der Bereitstellung von Oracle Java-Anwendungen im Cloud-Maßstab sind viele und vielfältig;

• Unzureichende Leistung: Performance-Engpässe machen sich insbesondere in Cloud-nativen Umgebungen und in hybriden Multiclouds unter anderem durch Latenzzeiten bemerkbar (automatische Garbage Collection in verteilten Systemen lässt grüßen);

• Verzwicktes Management der Cyber-Sicherheit: Die Komplexität und der schiere Umfang von Java-Anwendungen schaffen eine umfangreiche Angriffsfläche und bieten einen geringen Grad an Isolation; die Abhängigkeit von Drittanbieter-Bibliotheken kann zusätzliche Sicherheitslücken aus der Softwareversorgungskette einschleusen;

• Herangehensweisen zu Integration (Stichwort: Enterprise Integration Patterns) und Interoperabilität, zum Beispiel mit anderen JVM-Sprachen wie Kotlin, Scala und Groovy, von Java sind für viele Anwenderorganisationen zu viel des Guten;

• Widerspenstige Anwendungsarchitekturen (Stichwort: Altlasten-Monolithen) erschweren die Wartung und Modernisierung von Java-Anwendungen.

• Der hohe Ressourcenverbrauch von Java – CPU, Speicher und Netzwerkbandbreite – lässt sich innerhalb des Java-Ökosystems nur mit Mühe und Not und nur in eingeschränktem Umfang in den Griff bekommen. Wer monolithische Java EE-Anwendungen mit Kubernetes orchestrieren möchte, kann es gerne mit Tools wie „Red Hat JBoss Enterprise Application Platform“ a.k.a. JBoss EAP (@URL=““) und mit der „Red Hat Openshift Container Platform“ tun.

JBoss EAP ist übrigens Jakarta-EE-zertifiziert und beherrscht „out-of-the-box“ wichtige Enterprise-Performance-Features wie Failover, Clustering, Caching und intelligentes Load-Balancing. Aber selbst die beste Orchestrierung ändert nichts an der Tatsache: Unterm Strich geht der Betrieb von anspruchsvollen Java-Anwendungen im Cloud-Maßstab entsprechend im Cloud-Maßstab ans Geld.

Der wohlüberlegte Einsatz von WebAssembly bietet Unternehmen eine Reihe von verlockenden Vorteilen, Java hin oder her. Zu diesen Vorteilen zählen:

• Bessere Ausführungsgeschwindigkeit als Linux-Container: Das Kompilieren von bestehenden Anwendungen zu Wasm kann in vielen Fällen die Leistung gegenüber anderen Möglichkeiten der Bereitstellung erheblich verbessern, insbesondere bei Anwendungen, die intensive Berechnungen durchführen oder lange Leerlaufzeiten aufweisen (und von kurzem Kaltstart profitieren können).

• Plattformübergreifende Kompatibilität: Zu Wasm kompilierte Anwendungen (konkret: Codes in nahezu beliebigen Sprachen) können auf jedem Gerät oder Betriebssystem laufen, das eine WebAssembly-Runtime unterstützt. WebAssembly erhöht dadurch die Portabilität von Anwendungen.

• Sandbox-Umgebung: WebAssembly läuft in einer Sandbox, welche den Anwendungscode vom Host-System isoliert.

• Serverless- und Edge-freundlich: Die geringe Binärgröße und latenzfreie Initialisierung von Wasm ermöglichen die Umsetzung serverloser, ereignisgetriebener Anwendungsarchitekturen an der Edge genauso wie im Rechenzentrum. Dies erhöht die Skalierbarkeit, reduziert den Fußabdruck der Infrastrukturbereitstellung und optimiert die Kosteneffizienz.

• Integration mit modernen Toolchains: Wasm integriert sich gut in moderne Entwicklungs-Toolchains und CI/CD-Pipelines.

Kubernetes-Nutzer wollten schon länger lambda-ähnliche serverlose Funktionen in Kubernetes-Clustern implementieren, nur blieben die ursprünglichen Implementierungen hinter den Erwartungen zurück. Keine davon konnte mit der Leistungsdichte, der Ausführungsgeschwindigkeit und Startlatenz von Wasm mithalten. Die Integration von Wasm in Kubernetes war unvermeidlich.

Besucher der Wasm I/O und der KubeCon zeigten reges Interesse daran, Wasm innerhalb von Kubernetes auszuführen. Auf der KubeCon war Wasm das meistdiskutierte Thema. Auf der KubeCon zeigte die ZEISS Group einige Anwendungsfälle von Wasm aus der gelebten Praxis.

WebAssembly in Container-Ökosystemen

Fermyon, Microsoft, Suse, Liquid Reply und andere haben gemeinsam das Open-Source-Projekt mit der Bezeichnung „Spinkube“ veröffentlicht, um Unternehmen zu ermöglichen, Spin-optimierte Wasm-Anwendungen auf Kubernetes zu betreiben (siehe dazu auch: „ Das „serverlos“ bewölkte Rechenzentrum; Wasm trifft auf Kubernetes-Orchester“).

Der Support der Industrie für Wasm in Kubernetes ist enthusiastisch. Suse unterstützt WebAssembly in „Rancher Desktop“ unter Verwendung der Kubernetes-Runtime „K3s“. Das „Wasmcloud“-Projekt der Cloud Native Computing Foundation (CNCF) integriert sich in Kubernetes.

NGINX Unit will die Ausführung von Spin-Apps innerhalb ihrer Anwendungsplattform unterstützen. Spin ist ein quelloffenes Entwicklungswerkzeug von Fermyon für die Bereitstellung von Wasm auf Plattformen wie „Raspberry Pis“, „Docker Desktop“, Kubernetes, „Nomad“ bis hin zur „Fermyon Cloud“.

Die Plattform von Fermyon kann 5.000 Wasm-Apps pro Kubernetes-Knoten ausführen. Die serverlose Architektur von Fermyon erreicht mit WebAssembly Latenzen von unter 1 Millisekunde.

Latenzminimierung mit Wasm

Methoden zur Ausführung von Wasm-Modulen in Container-Ökosystemen gibt es mittlerweile mehrere. Im Grunde genommen stehen Unternehmen drei Optionen offen:

• durch das Verpacken von Wasm-Bytecode in Linux-Container-Images mit Tools wie „Buildah“ und „Podman“; das Linux-Betriebssystem innerhalb des Containers wird zwar auf die für Wasm erforderlichen Komponenten reduziert, aber der Ansatz erfordert immer noch das Starten eines Linux-Containers und selbst das abgespeckte Linux-Betriebssystem macht immer noch 80 Prozent der Größe des Container-Image aus.

• innerhalb von WASI-kompatiblen Container-Runtimes wie „Wasmedge“, „Krustlet“, Spinkube und „Wasmtime“ für allgemeine WASI-Integration und den Zugriff auf Systemressourcen;

• mit Proxy-Wasm, einem SDK und ABI (Application Binary Interface) zur Erweiterung von Netzwerkproxys wie „Envoy“ mit WebAssembly innerhalb von Container-Umgebungen.

Container-Laufzeiten lassen sich im Allgemeinen in zwei Ebenen unterteilen: hochrangige und niedrigrangige. Beide arbeiten zusammen, um die Bereitstellung von Wasm-Anwendungen zu ermöglichen.

• Bei niedrigrangigen Container-Runtimes wie „Wasmer“ handelt es sich um OCI-konforme Implementierungen. Sie verfügen über ein ausführbares Dateisystem (Rootfs) und eine Konfigurationsdatei (config.json), um isolierte Prozesse auszuführen.

• Hochrangige WebAssembly-Runtimes wie Wasmedge, Krustlet, Spinkube und Wasmtime bieten umfangreiche Funktionen zur Ausführung von WebAssembly-Bytecode und Integrationen in komplexe Umgebungen wie Kubernetes.
  Eine hochrangige Container-Laufzeitumgebung übernimmt den Transport und die Verwaltung von Container-Images, entpackt sie und übergibt sie an eine niederrangige Runtime zur Ausführung. Eine hochrangige Container-Runtime abstrahiert die Komplexitäten der niederrangiger Runtimes, die sie steuert. Benutzer können so verschiedene Runtimes der niedrigen Ebene über dieselbe Laufzeit der höheren Ebene verwalten.

Beim Ausführen von Wasm-Modulen über High-Level-Container-Laufzeiten wie „CRI-O“ oder „containerd“ ruft die hochrangige Runtime typischerweise die niederrangige Laufzeitumgebung auf. Es gibt aber auch eine andere Herangehensweise. Diese macht sich containerd mit einem Unterprojekt namens „runwasi“ für die Entwicklung eines „containerd-wasm-shim“ zu Nutze, der dann direkt mit der betreffenden Wasm-Laufzeitumgebung wie Wasmedge und Wasmtime interagiert.

Dadurch kann containerd Wasm-Module ausführen, ohne auf Low-Level-Laufzeitumgebungen angewiesen zu sein. Stattdessen ruft er nämlich die Wasm-Runtime direkt auf. Dies verkürzt den Aufrufpfad und verbessert die Effizienz.

Die Ausführung von Wasm-Workloads

Zur Ausführung von Wasm-Workloads auf Kubernetes benötigt man außerdem zwei Schlüsselkomponenten, und zwar Worker-Nodes und „Runtimeclass“-Objekte. Hochrangige Container-Laufzeitumgebungen wie containerd und CRI-O werden hierzu mit niederrangigen Wasm-konformen Runtimes wie „runc“, „crun“, „gvisor“, „kata“ oder „youki“ integriert, um die Worker-Nodes zu initialisieren.

Runtimeclass-Objekte sind auf Knoten mit einer WebAssembly-Laufzeitumgebung abgebildet. Runtimeclass löst das Problem, dass in einem Kubernetes-Cluster mehrere Container-Runtimes vorhanden sein können, wobei einige Knoten eine Wasm-Laufzeitumgebung unterstützen, während andere reguläre Container-Laufzeitumgebungen verwenden. Mit Runtimeclass lassen sich Wasm-Workloads gezielt auf Knoten mit Wasm-Runtimes bereitstellen.

Um die Wasm-Unterstützung auf Kubernetes-Knoten zu aktivieren, kommt zum Beispiel der „Kwasm Operator“ zum Zuge, um den Prozess zu automatisieren, anstatt manuell eine Container-Laufzeitumgebung mit der Wasm-Laufzeitbibliothek zu installieren. Kwasm ist ein Kubernetes-Operator, der automatisch WebAssembly-Unterstützung zu Kubernetes-Knoten hinzufügt. Der Operator macht sich das Projekt „kwasm-node-installer“ zu Nutze, um die zugrunde liegenden Kubernetes-Knoten zu modifizieren.

(ID:50155145)