Befehle für gestapelte VMs Was ist Wasm?

Anbieter zum Thema

Dell GmbH

DataCore Software GmbH

Schwarz IT KG

WebAssembly-Anwendungen dringen in Cloud- und Edge-Bereitstellungen vor und wollen das Rechenzentrum erobern. Die flinke, Container-lose Docker-Alternative trumpft mit einer beinahe nativen Performance und Sandbox-geschirmter Sicherheit. Die zweite Version der Spezifikation bekommt gerade noch den letzten Schliff.

WebAssembly (kurz: Wasm) ist ein binäres Befehlsformat für eine stapelbasierte virtuelle Maschine (VM). Dabei handelt es sich um eine Turing-vollständige VM, welche kurzlebige temporäre Werte auf einen Stapel schiebt und davon wieder abzieht. Der Ansatz reduziert die erforderliche Anzahl von Prozessorregistern und kommt der Performance zugute.

Wasm ist als ein portables Kompilierungsziel für eine Vielzahl von Programmiersprachen konzipiert. Wasm kann zusätzlich zu HTML und CSS unter anderem JavaScript, C++ und Rust integrieren. Der für den Interpreter einer VM kompilierte Bytecode wird in systemeigenen Maschinencode übersetzt und dann direkt auf der CPU mit nahezu nativer Performance ausgeführt.

WebAssembly beschreibt hierzu eine speichersichere Sandbox-Ausführungsumgebung. Sie stützt sich auf explizite Importe, um die Kommunikation mit dem Host zu ermöglichen, und macht sich Techniken der Fehlerisolierung zu Nutze.

Sicherer Code

Das Design von WebAssembly fördert sicheren Code. Unsichere Sprachkonstrukte sind aus der Ausführungssemantik verbannt. Erweiterte Sicherheitsfeatures wie geschützte Aufrufstapel (englisch: protected call stacks) und Typüberprüfung zur Laufzeit (englisch: runtime type checking) sollen die Auswirkungen von Bugs eindämmen.

Liam Randall, CEO bei Cosmonic, vergleicht WebAssembly mit einer virtuellen CPU, die einem einzelnen Prozess zugewiesen ist. In Kombination mit einem Framework wie „WasmCloud“ lassen sich die benötigten Bibliotheken auch gleich mit virtualisieren; so wird Wasm-Code portabler.

Simplizität, Portabilität, Sicherheit

WebAssembly benötigt keine Garbage-Collection, kein Betriebssystem und keine Container. Damit lassen sich Wasm-Anwendungen direkt auf der CPU auf jeder Edge-Umgebung und auf jeder nativen Cloud-Plattform ausführen – einschließlich Service-Mesh- und Edge-Kubernetes-Bereitstellungen.

WebAssembly kommt damit als ein robuster, sicherer Ersatz für Docker ins Gespräch. Solomon Hykes, der Gründer von Docker, hat im März 2019 auf Twitter verkündet: „Hätte es Wasm+Wasi im Jahr 2008 gegeben, hätten wir Docker nicht erst noch erschaffen müssen“.

Eines der Hauptprobleme im Zusammenhang mit Docker ist die Gefahr von CVE-Verwundbarkeiten, die Container-Images einschleusen können (CVE steht für Common Vulnerabilities and Exposures und bedeutet so viel wie allgemein bekannte Schwachstellen und Gefahren). Im Gegensatz zu einem Docker-Container, welches neben dem auszuführenden Code auch eine Vielzahl von Abhängigkeiten mitbringt, handelt es sich bei einer WebAssembly-Anwendung schlicht und ergreifend um eine Binärdatei.

On the fly

Im Gegensatz zu Docker kommt ein WebAssembly-Modul nicht gleich mit einem vorgefertigten Dateisystem oder anderen Low-Level-Betriebssystemprimitiven daher. Stattdessen lassen sich die benötigten Dateien, Verzeichnisse, Umgebungsvariablen, Systemtaktgeber und andere Systemressourcen während des Starts direkt mit dem WebAssembly-Modul verbinden.

Die auf WebAssembly basierenden Anwendungen sind im Allgemeinen nicht größer als 1 MB, während ein Docker-Image 100 oder 200 MB in Anspruch nehmen kann. Als Resultat daraus ist WebAssembly beim Kaltstart rund 100 Mal schneller als Docker und auch zur Laufzeit 10 Prozent bis 50 Prozent schneller. Wasm nutzt gängige Hardware-Funktionen, um eine nahezu native Leistung auf einer Vielzahl von Plattformen zu erreichen.

WebAssembly wurde im Jahre 2017 vom World Wide Web Consortium (W3C) veröffentlicht. Rund zwei Jahre später führte das W3C-Mitglied Mozilla mit WASI eine WebAssembly-Systemschnittstelle ein (ähnlich wie JNI in Java). Dank dieser Schnittstelle können WebAssembly-Anwendungen den Zugriff auf Betriebssystemressourcen erlangen, um aus der Eingrenzung im Browser herauszubrechen.

Wasm bei der CNCF

WebAssembly hat sich in Edge-Bereitstellungen bewährt. Einige Befürworter der Technologie avisieren Anwendungsszenarien in der Cloud wie im Rechenzentrum.

So hat die Cloud Native Computing Foundation (CNCF) im Laufe von 2021 eine Reihe von WebAssembly-Projekten aufgenommen, die auf Server-Workloads abzielen, darunter „WasmCloud“, „WasmEdge“ und „Krustlet“. Jedes dieser Projekte geht seinen eigenen Weg zur Vereinheitlichung der Verwaltung von weit verteilten Anwendungen in Clouds, Edge-Computing-Standorten sowie auf IoT- und Mobilgeräten.

Zahlreiche Implementierungen von Metaverse-Anwendungen machen sich bereits Wasm im großen Stil zu Nutze. Die Technologie ermöglicht es internen wie auch externen Entwicklern, individuelle Erlebnisse in der Sprache und mit den Werkzeugen ihrer Wahl zu erstellen und als eine hochperformante universelle Binärdatei auszugeben. Wasm-Anwendungen sind – dank der Sandbox-Abschottung – geschützt von anderen Erlebnissen auf der Plattform.

Wasm in der Cloud und an der Edge

Wasm hält unter anderem das Versprechen, die Softwareversorgungskette zu straffen und den Ballast verschachtelter Abhängigkeiten abzuwerfen. Shopify zum Beispiel nutzt Wasm-basierte Tools, um die benutzerdefinierten Anwendungen von Partnern in seiner Cloud zu hosten und gleichzeitig die Sicherheit und Skalierbarkeit seiner eigenen Plattform zu wahren.

CDN-Anbieter wie Cloudflare haben Wasm für serverloses Edge-Computing entdeckt. CloudFlare unterstützt die Ausführung kleiner WebAssembly-Module wahlweise im Rahmen von skriptbasierter oder modulbasierter Worker. Diese Methode der Bereitstellung ermöglicht es den Kunden von CloudFlare, ressourcenintensive Anwendungen an der Netzwerkkante direkt in der Nähe ihrer Verbraucher auszuführen, ohne auf die zugrundeliegende Infrastruktur zuzugreifen oder sie verwalten zu müssen. Tools wie Denoflare machen es möglich.

WASM glänzt bei der Ausführung ressourcenintensiver, Mathematik-lastiger Berechnungen, die in sich geschlossen ablaufen, wie etwa die Änderung der Bildgröße oder Verarbeitung eines Audio-Stream. Wasm als eine statisch typisierte kompilierte Sprache mit expliziter Typ-Zuweisung hat einen Leistungsvorsprung gegenüber einer Javascript-Implementierung. Die WASM-Implementierung von Cloudflare macht sich die „Javascript Service Worker API“ zu Nutze.

CDN und Wasi

Der CDN-Anbieter Fastly setzt auf Wasi. Fastly hat die unternehmenseigene Implementierung eines WebAssembly-Compilers und eier Laufzeitumgebung mit der Bezeichnung „Lucet“ im Jahre 2019 unter einer quelloffenen Lizenz veröffentlicht, verlagerte dann aber den Schwerpunkt auf „Wasmtime“, ein Projekt der Bytecode Alliance.

Die Bytecode Alliance entstand Ende 2019 aus der Initiative von Mozilla, Fastly, Intel und Red Hat und setzte sich zum Ziel, die Sicherheit von Wasm zu verbessern. Die Allianz hat unter anderem „Wasi Common“ geschaffen, eine wiederverwendbare Bibliothek von Wasi-Funktionen (der so genannten Hostcalls), welche die Nutzung von Wasi in Wasm-Projekten standardisieren sollte.

WasmEdge, ein Sandbox-Projekt der CNCF, positioniert Wasm und das WebAssembly System Interface (Wasi) als potenziellen Ersatz für Linux-Container. WasmEdge hält das Versprechen einer besseren Performance und einer effizienteren Ressourcennutzung.

Es geht schneller

Um eine JavaScript- oder Node.js-Anwendung in Kubernetes-Umgebungen auszuführen, erläutert Michael Yuan, CEO des WasmEdge-Anbieters Second State, müsse man zuerst Docker initiieren, Docker würde ein Gast-Linux starten, dieses dann Node.js, Node.js wiederum Java V8… erst danach ließe sich das eigentliche JavaScript ausführen.

„Das JavaScript-Programm besteht vielleicht aus nur 20 Codezeilen, aber Sie müssen all dies[e Komponenten] starten, um jede einzelne Zeile auszuführen“, beobachtet er. Mit WebAssembly würde sich die Anwendung zu Bytecode kompilieren, in Millisekunden ausführen und sauber beenden.

Wasm würde Linux-Container niemals vollständig ersetzen, so Yuan, aber es könnte die Auswahlmöglichkeiten der Entwickler für die Anwendungsbereitstellung in bestimmten Branchen erweitern. Er sieht das größte Potenzial in der Fertigung und in autonomen Fahrzeugen, denn dort würden die Rechenressourcen auf absehbare Zeit arg begrenzt bleiben. Einige Rechenzentrumsanwendungen wie Datenbanken könnten ebenfalls von einfacheren Möglichkeiten profitieren, die Berechnungen näher an die einzelnen Datensätze zu verlagern, so Yuan.

Bei Datenbanken sei das Konzept der gespeicherten Prozeduren weit verbreitet. Sie übernehmen die Ausführung von Berechnungen und benutzerdefinierten Funktionen innerhalb der betreffenden Datenbank. Dies mache typischerweise eine domänenspezifische Sprache erforderlich, so Yuan. Mit WebAssembly ließen sich normale Programmiersprachen verwenden, um diese Funktionen zu implementieren.

Einigen Befürwortern zufolge habe WebAssembly auch das Zeug dazu, die Portabilität von Anwendungen zwischen Edge-, Mobil- und IoT-Geräten sowie zwischen Clouds und herkömmlichen Rechenzentren zu verbessern. Dazu Liam Randall, CEO von Cosmonic: „WebAssembly ist ein Internet-Standard, der bereits überall unterstützt wird, vom Webbrowser, über Edge-Geräte, Edge-Netzwerke bis hin zu Cloud-Servern.“ Das Unternehmen vertreibt eine kommerzielle Version von WasmCloud.

Die Entwickler von Cosmonic und WasmCloud betrachten WebAssembly als eine neue Abstraktionsebene für die Datenverarbeitung, welche für Anwendungen und die ihnen zugrunde liegenden Softwarebibliotheken etwas Vergleichbares leisten könne, was die Servervirtualisierung für Betriebssysteme und die ihnen zu Grunde liegende Server-Hardware, oder was Container für Anwendungen und die ihnen zugrunde liegenden Betriebssysteme, oder Kubernetes für Microservices und die ihnen zugrunde liegenden Cloud-APIs geleistet hätten.

Das WasmCloud-Framework ermöglicht es den Betreibern von IT-Infrastrukturen, die in WebAssembly-Modulen kompilierte Geschäftslogik mit verschiedenen Softwarebibliotheken für unterschiedliche Betriebssysteme, Prozessortypen, Kubernetes-Distributionen und Cloud-APIs kreuz und quer miteinander zu mischen und gemeinsam zu verwenden. Entscheidungen darüber, wo und wie die resultierenden Anwendungen bereitzustellen sind, ließen sich einfach zur Laufzeit treffen, ohne dass die Entwickler Softwarebibliotheken erst noch importieren und ihre Anwendungen separat in jede Umgebung integrieren müssten.

Service-Mesh-Architekturen

Einige der Vorreiter von Service-Mesh-Architekturen nutzen WebAssembly für die Erstellung und Bereitstellung von Anpassungsmodulen. Die serverseitige Unterstützung von WebAssembly fand im Laufe von mehreren Releases ihren Weg in den „Envoy“-Proxy. Im Gegensatz zu der zuvor verwendeten Skript-Sprache Lua, bei der Entwickler ihre eigenen Envoy-Erweiterungen erstellten und pflegen mussten, lassen sich mit WebAssembly Anpassungen aus mehr als 30 Programmiersprachen in eine standardisierte und gemeinsam nutzbare Sammlung von Modulen kompilieren.

Ab „Istio“-Version 1.9 kann das Service-Mesh Wasm-Filter auf Envoy-Proxys über die Istio-Kontrollebene systematisch anwenden. Der Istio-Anbieter Solo.io hat eine Reihe dieser Module in einem Portal unter der Bezeichnung WebAssembly Hub veröffentlicht. Ein anderes Open-Source-Projekt, Proxy-Wasm, hat eine ABI-Spezifikation (Application Binary Interface) entwickelt, die sich mit beliebigen Proxy-Projekten verwenden lässt, um WebAssembly-Module zu kompilieren.

Istio erweitert Kubernetes, um ein programmierbares, anwendungsspezifisches Netzwerk mit dem leistungsstarken Envoy-Service-Proxy einzurichten. Istio funktioniert sowohl mit Kubernetes als auch mit herkömmlichen Workloads und bringt ein standardisiertes universelles Netzwerkmanagement, Telemetrie und Sicherheit in komplexe Bereitstellungen.

Krustlet, ein Sandbox-Projekt der CNCF, verbindet Wasm mit dem Container-Orchestrierer. Krustlet ist eine in Rust geschriebene Version des Knoten-Agenten von Kubernetes, Kubelet, mit der sich sowohl WebAssembly-Workloads als auch Linux-Container im selben Cluster ausführen lassen. Krustlet wartet im Event-Stream auf neue Pods basierend auf bestimmten Kubernetes-Toleranzen. Wie viele andere Wasm-Tools ist auch Krustlet noch experimentell.

* Das Autorenduo Anna Kobylinska und Filipe Pereia Martins arbeitet für McKinley Denali Inc. (USA).

(ID:48455929)