Was macht WASM? Mit WebAssembly an Kubernetes vorbei

WebAssembly-Runtimes drängen an die Edge und ins Kern-Datacenter vor. Und, kaum zu glauben: Ultra-leichtgewichtige WASM-Anwendungen in einer serverlosen Bereitstellung verdrängen Kubernetes mit ihrer latenzarmen Initialisierung und ihrer rekordbrechenden Leistung.

„Kubernetes-ierte“ Arbeitslasten sind zu träge für latenzkritische Nutzungsszenarien und zu plattformgebunden für die extreme Portabilität von Edge-Clouds. Abhilfe könnte WebAssembly (a.k.a. WASM) schaffen.

Die serverlose Edge mit WASM

Edge-Computing nimmt an Bedeutung zu. Sogar in nicht-latenzkritischen Szenarien hat es gewisse Rechenaufgaben an die Edge verschlagen, sei es aus datenschutztechnischen Überlegungen oder zur Optimierung der Energiebilanz.

Doch Edge-Computing mit Cloud-nativen Arbeitslasten ist kein leichtes Bier. Das Auslagern von Arbeitslasten auf die Edge erfordert die reibungslose Portabilität von ausführbarem Code zwischen beliebigen Edge-Rechenknoten – und damit die Kompatibilität der Arbeitslasten über die verschiedensten Gerätetypen hinweg.

Edge-Geräte zeichnen sich im Hinblick auf ihre Aufgaben und ihre Systemarchitektur durch eine immense Vielfalt aus. Zugleich steht einer leistungsoptimierten Implementierung von Edge-Arbeitslasten über verschiedene Geräteklassen hinweg stets das Gespenst von Vendor-Lock-In im Wege. Die Unternehmen wollen sich auf die Hardwareplattform eines einzelnen Anbieters nicht einlassen, wenn sie proprietär sein will.

WebAssembly schafft Abhilfe mit einer portablen Ausführungsumgebung für beliebig granulierte Aufgabenstellungen, vor allem im Bereitstellungsmodell Serverless.

„Stapelverarbeitung“ auf der CPU

Bei WebAssembly (WASM) handelt es sich um ein binäres Befehlsformat für eine leichtgewichtige Abstraktionsebene zur Ausführung von rechenintensiven Anwendungen. Gemeint ist hierbei eine so genannte „Stackmaschine“, also eine Ausführungsumgebung auf der Basis eines Stack-Datenmodells.

WebAssembly wurde entwickelt, um einfachen Anwendungscode in nahezu beliebigen Sprachen höherer Ordnung schnell und effizient auszuführen, ursprünglich im Browser. Das erklärte Ziel bestand darin, Javascript - angesichts dessen hoher Komplexität, geringer Eignung für mathematische Berechnungen und der trägen Ausführungsgeschwindigkeit - abzulösen. Ein Stack-basiertes Datenmodell ermöglicht eine weitaus effizientere Verarbeitung von Anweisungen als ein Register-basiertes oder ein Speicher-basiertes Datenmodell.

Eine Stackmaschine liest bei den meisten Anweisungen Daten vom Stapel und schreibt ihre Berechnungsresultate zurück auf den Stapel. Diese Vorgehensweise reduziert die Notwendigkeit für den Datenaustausch mit CPU-Registern (kleinen Speicherbereichen in der CPU für Zwischenwerte und andere temporäre Daten mit geringen Zugriffszeiten und beschränkter Kapazität) und dem Arbeitsspeicher und befreit diese Ressourcen. Dadurch verbessert sich die Ausführungsgeschwindigkeit und der Energieverbrauch sinkt.

Im Stack-basierten Datenmodell können allerdings Zugriffe auf Variablen und einige Daten auf dem Stapel langsamer ablaufen als Zugriffe auf CPU-Register oder den Cache. Dies liegt daran, dass der Stapel auf dem Arbeitsspeicher abgebildet wird und daher langsamer ist als der direkte Zugriff auf die CPU-Register oder den Cache. Einige CPU-Architekturen können den Stapel im CPU-Cache statt im Arbeitsspeicher aufbewahren, um die Ausführung zu beschleunigen.

WebAssembly ist auf Leistung und Simplizität ausgelegt. Anwendungsarchitekturen von hoher Komplexität lassen sich mit diesem Ansatz nicht implementieren; dafür ist das Stack-Datenmodell zu stark limitiert. Für die Ausführung von serverlosen Funktionen kommt es wie gerufen.

„Wenn es WASM+WASI im Jahr 2008 gegeben hätte, hätten wir Docker nicht gebraucht. So wichtig ist [diese Technologie],“ kommentierte Docker-Gründer Solomon Hykes in einem Tweet und urteilte daraufhin: „WebAssembly auf dem Server ist die Zukunft des Computing.“

Die ursprüngliche Spezifikation von WebAssembly hatte W3C (World Wide Web Consortium) im Jahre 2017 veröffentlicht. Rund zwei Jahre später stellte das W3C-Mitglied Mozilla eine quelloffene Systemschnittstelle für WebAssembly (kurz WASI für WebAssembly System Interface) vor.

Mit der Einführung von WASI konnten WebAssembly-Anwendungen plötzlich auf Systemressourcen zugreifen, aus dem Webbrowser ausbrechen und in Cloud-nativen Umgebungen Einzug halten. Mit WASI konnten Content Delivery Networks (CDNs) WebAssembly zur Bereitstellung von Anwendungen ihrer Kunden nutzen, ohne diesen Unternehmen den Zugriff auf die zugrunde liegende Infrastruktur gewähren zu müssen.

Trumpfkarte Agilität und Wiederverwendung

Im Gegensatz zu herkömmlichen Programmiersprachen, die auf festgelegte Betriebssysteme und Prozessorarchitekturen beschränkt sind, läuft WebAssembly-Code auf jedem Gerät mit einer WASM-kompatiblen CPU. Die CPU kann die Anweisungen direkt interpretieren und umsetzen, ohne eine Zwischenschicht wie ein Betriebssystem zu benötigen oder eine VM initialisieren zu müssen.

Diese Eigenschaft von WebAssembly verbessert die Portabilität von Code, ohne einen Teil der Leistung zu verschenken oder die Energieeffizienz aufs Spiel zu setzen. Dadurch bietet WebAssembly eine verlockende Möglichkeit, maschinenähnlichen Bytecode auf einer Vielzahl von ressourcenarmen Endgeräten ohne plattformspezifische Anpassungen direkt auszuführen. Entwickler brauchen den benötigten Anwendungscode genau nur einmal zu schreiben.

Eine vergleichbare Anwendungsbereitstellung in Container-Umgebungen an der Netzwerkkante mag zwar dank leichtgewichtiger Kubernetes-Distributionen wie „K3s“, „MicroK8s“ oder „Microshif“ die Ressourcenknappheit überwinden, sie kann jedoch nicht mit der nötigen Portabilität aufwarten, um es mit WASM aufzunehmen.

Im Edge-Computing

Im Edge-Computing-Umfeld kommen verschiedene Geräte und Betriebssysteme in direkter Proximität zueinander zum Einsatz. Dank der direkten Ausführung auf der CPU umgeht WebAssembly den Overhead von Zwischenschichten des Host-Systems, einschließlich der Virtualisierung (ob in einer klassischen VM oder in einem Container).

Viele moderne CPUs, einschließlich der meisten Desktop- und Mobilgeräte, unterstützen mittlerweile WebAssembly. Das gibt Entwicklern die Freiheit, ihren Code auf verschiedenen Geräten und Plattformen bereitzustellen, ohne erst noch zusätzlichen Aufwand in die Anpassung an spezifische Betriebssysteme oder Hardware investieren zu müssen. Dies ist insbesondere im Kontext des Edge Computing von Vorteil, wo die heterogene Gerätelandschaft und die Vielfalt an Betriebssystemen eine wahre Herausforderung darstellen.

Im Gegensatz zu WebAssembly sind traditionelle Programmiersprachen typischerweise an ein bestimmtes Betriebssystem oder eine bestimmte Architektur gebunden. Dies kann die Portabilität von Anwendungen erheblich einschränken. WASM trumpft zudem mit einer hohen Ablaufgeschwindigkeit, geringer Latenz und einer bemerkenswerten Energie-Effizienz.

Effizienz

WebAssembly punktet unter anderem auch im wissenschaftlich-technischen Umfeld und macht sogar vor anspruchsvollen Analytics-Berechnungen nicht halt. Zudem kommt es ohne den üblichen Rattenschwanz endloser Abhängigkeiten und reduziert so Supply-Chain-Verwundbarkeiten. Das erleichtert die Einhaltung von Compliance u.a. mit PCI-Richtlinien.

Serverloses Computing punktet gegenüber Alternativen wie Kubernetes sowohl im Hinblick auf die Entwicklung als auch die resultierende Infrastrukturbereitstellung. Das Analystenhaus Omdia prognostiziert, dass der Markt für Serverless-Computing von 10 Milliarden Dollar im Jahr 2021 auf über 40 Milliarden Dollar im Jahr 2026 anwachsen wird.

Der „serverlose“ Ansatz ist jedoch nicht ganz ohne. Zu den größten Herausforderungen zählen Verwundbarkeiten der Software-Versorgungskette, die schleichende Abhängigkeit von dem (proprietären) Softwarestack des Infrastrukturanbieters und dessen unbeschränkter Zugriff auf Daten und Anwendungscode. Das alles reduziert für Unternehmen die Motivation, in Sachen Serverless über einen gewissen Punkt hinauszugehen. WebAssembly verspricht, diese Dynamik zu verändern.

Serverlose Edge mit WASM

Eine Erweiterung von WebAssembly speziell für den Einsatz in Edge-Computing-Szenarien namens WASM Edge bietet Unternehmen eine Möglichkeit, Anwendungen und Dienste in WebAssembly direkt auf Edge-Geräten auszuführen, ohne die Notwendigkeit, erst noch eine Übersetzung in die Maschinensprache des Hosts vorzunehmen.

WASM Edge will eine „leichtgewichtige, hochperformante und erweiterungsfähige Runtime für Cloudnatives, Edge und dezentralisierte Anwendungen“ sein. Die Laufzeitumgebung unterstützt Serverless, eingebettete Funktionen, Microservices, intelligente Verträge und IoT-Geräte als Hosts. Es kommt mit C, Rust, Go und Javascript zurecht.

WASM Edge schafft eine latenz- und portabilitätsfreundliche Ausführungsumgebung für serverlose Funktionen an der Netzwerkkante. Sie ermöglicht das Verlagern rechenintensiver Arbeitslasten näher an den Benutzer - unabhängig von der CPU-Architektur oder dem Betriebssystem des Hosts.

Nanosekunden

WASM Edge lässt sich um bis zu 100-mal schneller initialisieren als Linux-Container; zur Laufzeit sind die resultierenden Dienste um bis zu 20 Prozent performanter - nicht umwerfend, aber immerhin. Da die meisten Edge-Geräte über arg begrenzte CPU-Ressourcen verfügen, ist der Performance-Vorsprung von WASM Edge manchmal der Unterschied zwischen „es läuft“ und „es läuft nicht“. Eine WASM Edge-Anwendung benötigt höchstens 1/100 der Größe einer vergleichbaren „containerisierten“ Softwarelösung unter Linux.

Unternehmen wie Adobe Systems experimentieren auch mit dem serverseitigen Einsatz von WASM im Kern-Datacenter. Adobe Systems hat zum Beispiel mit dem quelloffenen Framework WasmCloud eine Handvoll von Proof-of-Concept-Anwendungen entwickelt.

Serverseitiges WASM im Kernrechenzentrum

„WasmCloud“ verbindet Anwendungen mit Softwarebibliotheken für verschiedene Betriebssysteme, Prozessortypen, Kubernetes-Distributionen und Cloud-APIs. „Wir lassen wasmCloud innerhalb von Kubernetes als Sidecar laufen“, enthüllte Sean Isom, Engineering Manager bei Adobe. Der Ansatz habe die Kaltstartzeit gegenüber Containern um 90% reduziert.

WebAssembly-Compiler für verschiedene Sprachen entstehen unter der Obhut der Bytecode Alliance, eines gemeinnützigen Konsortiums von Anbietern. Serverseitiges WebAssembly stößt hier auf großes Interesse im Zusammenhang mit traditionellen Programmiersprachen wie Python, Java und .NET.

BMW möchte künftig einen Teil seiner Altlasten-Codebasis, die ursprünglich für 32-Bit-Windows entstanden ist, in WebAssembly modernisieren. Außerdem ist WASM bei BMW als die Plattform der Wahl für ML-Anwendungen der Fahrzeug-nahen Edge im Gespräch. Eine Herausforderung stellt die Erschaffung von Schnittstellen zur physischen Welt dar. WASI fehlen unter anderem eine ausgereifte Unterstützung für Multi-Threading sowie Fähigkeiten zum Umgang mit Dateisystemen und dem Netzwerk.

Zu den Nutzern von WASM an der Netzwerkkante zählen Unternehmen wie Vercel, Fastly, Shopify und Cloudflare. Fermyon baut eine Plattform für die Ausführung von WASM-Microservices in der Cloud.

Docker+WASM

Die wachsende Bedeutung von WASM verdeutlicht die Tatsache, dass Docker die Technologie “verinnerlichen” will (Stichwort: Embrace and Extend). Docker hat hierzu die Zwischenschicht runwasi containerd shim von WasmEdge in Docker Desktop integriert (das zuvor in einem Technical Preview Build bereitgestellt wurde). Dies ermöglicht es Entwicklern, Wasm-Anwendungen auszuführen und Wasm-Anwendungen mit anderen containerisierten Workloads, wie z.B. einer Datenbank, in einem einzigen Application-Stack zusammenzustellen.

Docker hat eine WASM-Laufzeitumgebung „containerisiert“. So können Entwickler ihre Anwendungen mit Hilfe der Docker-CLI in WebAssembly-Modulen verpacken und bereitstellen, um Docker-eigene Technologien in WASM-Anwendungen verfügbar zu machen.

Die WebAssembly-Laufzeitumgebung für Docker schafft nebenbei eine Möglichkeit zur Ausführung von serverlosen Funktionen ohne eine dedizierte serverlose Plattform.

Hyperhybridisierung über WASM-Runtimes

Für viele Teams liegt der Schwerpunkt bei WebAssembly auf Functions-as-a-Service (FaaS) im Kern-RZ. Das Team von Cosmonic stellt sich WASM als eine plattformunabhängige Ausführungsumgebung vor, die auch die Edge mit in die Pflicht nimmt. Cosmonic hat seine WASM-Laufzeitumgebung, die wasmCloud, im Jahre 2021 zur CNCF beigetragen. Am 18. April 2023 hat das Unternehmen sein WASM-PaaS als öffentliche Beta freigegeben, die Cosmonic wasmCloud PaaS. Das Unternehmen beabsichtigt, eine umfassende Plattform für die Entwicklung, Bereitstellung und Verwaltung von Anwendungen auf Basis von WebAssembly zu erschaffen.

Cosmonic Connect, eine Erweiterung von wasmCloud, ermöglicht es Entwicklern, Legacy-Systeme und Microservices in ihre WASM-Anwendungen nahtlos zu integrieren, ohne den Code neu schreiben zu müssen. Cosmonic Connect bietet auch Funktionen für das Datenmanagement, das Caching und die Integration von Drittanbieter-APIs.

Benutzer von Kubernetes können Cosmonic Connect verwenden, um die Ressourceneffizienz und Geschwindigkeit von WASM für spezifische Anwendungsfälle zu nutzen, ohne auf die Containerisierung ihrer Arbeitslasten zu verzichten. Cosmonic avisiert hierbei die Erschaffung “hyperhybrider” Umgebungen, in denen verschiedene Teilarbeitslasten auf einem Unterbau aus traditionellen Rechenzentren, Clouds, Edge- und anderen Umgebungen laufen sollen.

(ID:49531771)