WebAssembly: Vom Aufstieg eines Browser-Tools

WebAssembly war ursprünglich als hilfreiche Browser-Technologie gestartet. Heute treibt sie ganze Business-Systeme an, zum Beispiel den Streaming-Dienst von Disney an.


Foto: David Peperkamp – shutterstock.com

Mit WebAssembly sollten Webanwendungen ursprünglich an Leistung und Portabilität zulegen. Inzwischen sorgt die Browser-Technologie in diversen Business-Umgebungen für Furore.

WebAssembly – kurz WASM – wurde vom World Wide Web Consortium (W3C) entwickelt und erstmals im Jahr 2018 veröffentlicht. In den Worten von W3C ist WebAssembly ein “Compilation Target”. Das bedeutet: Entwickler können ihren eigenen Code – typischerweise Rust, C++ oder AssemblyScript – mit WebAssembly zu Bytecode kompilieren, um ihn direkt im Webbrowser mit hoher Geschwindigkeit auszuführen.

Um Backend-Anwendungen auf ähnliche Weise ausführen zu können, auf Betriebssystemressourcen zuzugreifen und WebAssembly aus dem Browser herauszulösen, führte Mozilla im Jahr 2019 sein WebAssembly System Interface (WASI) ein. Wie Lin Clark, Senior Principal Engineer bei Fastly, in einem Blogbeitrag beschreibt, inspirierte das viele Entwickler dazu, WebAssembly außerhalb des Browsers als schnelle, skalierbare und sichere Möglichkeit zu nutzen, um denselben Code auf verschiedenen Maschinen auszuführen.

Wie bedeutsam diese “Reichweitenverlagerung” von WebAssembly für das Feld der Datenverarbeitung war, verdeutlicht auch ein Tweet von Docker-Mitbegründer Solomon Hykes aus dem Jahr 2019:

In den Augen seiner glühendsten Verfechter – wie Kevin Hoffman, Schöpfer des CNCF-Sandbox-Projekts WasmCloud – steht WebAssembly kurz davor, die Branche in einem Ausmaß zu verändern, wie es Docker mit seiner Container-Technik im Jahr 2013 getan hat: “Unsere Cloud-Lösungen sollen schlank, schnell, sicher und portabel sein. Als WebAssembly auftauchte, um all das zu verwirklichen, schossen mir sofort tausend Ideen in den Kopf, welche Dinge man im Backend und darumherum entwickeln könnte.”

Damit WebAssembly sein Potenzial auf Unternehmensebene voll entfalten kann, sind laut Gartner-Analyst Fintan Ryan jedoch noch einige wichtige Schritte notwendig: “Ich glaube, dass es sich um eine wirklich revolutionäre Technologie handelt, aber die Entwicklung schreitet noch recht langsam voran.”

Heute ist WebAssembly immer noch eine ziemlich komplexe Technologie, die noch nicht weit verbreitet und vor allem bei spezialisierten Anbietern beliebt ist. Das sind insbesondere Anbieter, die großangelegte Content-Streaming-Plattformen oder Content-Distribution-Networks (CDNs) sowie große Plattformen wie Shopify betreiben, auf denen Entwickler intensive Workloads isoliert voneinander ausführen können.

WebAssemblys Durchbruch in den Mainstream wird derzeit noch durch zwei Faktoren maßgeblich behindert: Einerseits die Langatmigkeit, mit der das W3C die Standards vorantreibt, andererseits ein Mangel an wirklich überzeugenden, entwicklerfreundlichen Packaging Tools. “Wir warten alle gespannt darauf, wie sich der WebAssembly-Standard und WASI weiterentwickeln. Die Technologie verspricht, alle Anforderungen an sichere Netzwerke zu erfüllen. Es ist verlockend, leistungsstarke, netzwerkfähige Workloads in reinem WebAssembly zu schreiben und sich dabei nicht auf proprietäre Laufzeiten verlassen zu müssen”, freut sich Hoffman.

Während das Gros der Branche auf diesen “Docker-Moment” wartet, reizen einige Unternehmen WebAssembly bereits bis an seine Grenzen aus.

Bloomberg: Fit für die Zukunft mit WASM

Für die Kunden des Finanzdatenspezialisten Bloomberg ist Performance von größter Bedeutung: Die weltweit führenden Finanzinstitute erwarten laufend aktuelle Daten und die Möglichkeit, diese an ihre individuellen Anforderungen anzupassen. Die populäre Anwendung “Bloomberg Terminal” zeigt Finanzdaten auf mehreren Bildschirmen des Benutzers an und verwendet dazu eine proprietäre, in C++ geschriebene, tabellarische Datenverarbeitungs-Engine, die in ein eingebettetes Chromium-Browser-Frontend verpackt ist, das Tausende von JavaScript-Anwendungen hostet.

“WebAssembly eröffnet uns Möglichkeiten, die Leistung unserer webbasierten Komponenten zu verbessern, indem es uns ermöglicht, einige Berechnungen potenziell schneller durchzuführen”, meint Itay Dafna, ein auf quantitative Analysen spezialisierter Softwareingenieur bei Bloomberg.

Ein Service den Dafnas Team unterhält, ist BQuant, eine Python-Anwendung, die auf Jupyter-Notebooks basiert und in Terminal integriert ist, um Analysten die Möglichkeit zu geben, ihre eigenen Untersuchungen auf Basis von Bloomberg-Daten zu erstellen, zu testen und zu teilen. Dafna und sein Team erkannten das Potenzial von WebAssembly, wenn es darum geht, Nutzern die Möglichkeit zu geben, ihre Ergebnisse außerhalb der Bloomberg-Plattform als unabhängige, einbettbare Webkomponente zu teilen. “Eine typische Architektur solcher Komponenten trennt das Frontend, wo Artefakte gerendert werden, vom Backend, wo die Berechnungen stattfinden. In unserem Fall musste die Komponente in einem hybriden Modus laufen – sowohl in einem Jupyter-Notebook mit einem Python-Kernel als auch eigenständig im Browser”, erklärt der Experte.

“Wenn wir die Datenmodellierungs- und Berechnungslogik in WebAssembly schreiben, können wir sie im Python-Kernel und auch in anderen Umgebungen, wie dem Web, mit identischen Ergebnissen ausführen. Eine Python- und eine JavaScript-Version einer Anwendung mit identischen Ergebnissen auszuführen, war zuvor undenkbar.”

Der Development-Experte räumt jedoch ein, dass es nicht einfach war, das Vorhaben in der Praxis produktiv umzusetzen. Vor allem, weil für Python-Code, der in WebAssembly ausgeführt wird, derzeit kein standardisiertes VM-Format (Virtual Machine) zur Verfügung stehe. “Obwohl WebAssembly heute nahtlos im Browser funktioniert, muss man für alles, was in Python geschrieben ist, seinen eigenen Code entwickeln, und das erfordert eine Menge manuellen Aufwand. Das schränkt das Versprechen von WebAssembly ‘Einmal schreiben, überall ausführen' ein.”

Dennoch bleiben Dafna und Bloomberg WebAssembly treu: “Wir sind begeistert von dieser Technologie und sehen sie als einen wichtigen Teil der Zukunft des Terminal-Ökosystems. Wir suchen nach weiteren Möglichkeiten, WebAssembly dort zu integrieren, wo es Sinn macht und sobald mehr Funktionen über Sprachstandards und Entwicklerwerkzeuge zur Verfügung stehen, wird das wesentlich einfacher werden.”

BBC: Ins Metaverse mit WebAssembly

Wenn wir uns auf eine Welt zubewegen, in der Home-Entertainment nicht mehr nur aus Video- und Audio-Streaming besteht, sondern auch aus reichhaltigen, interaktiven Erlebnissen und sogar VR- oder MR-geschwängerten Experiences innerhalb des Metaverse – wie kann das dann auf den Geräten unterstützt werden, die heute in den Haushalten der Ottonormalverbraucher stehen? Mit dieser Frage beschäftigt sich die Forschungs- und Entwicklungsabteilung der BBC, um die nächste Iteration ihrer äußerst beliebten iPlayer-Videostreaming-Anwendung zu entwerfen, die nach den Worten von Ingenieur Tim Pearce “immersive, interaktive Erlebnisse” bieten soll.

Während der aktuelle iPlayer über mehrere Client-Anwendungscodes für verschiedene Zielplattformen verfügt – iOS, Android, Smart TVs, Responsive Web und ältere Geräte – hat WebAssembly das Potenzial, in Zukunft eine gemeinsame Übersetzungsschicht für all diese Plattformen zu werden – und mehr: “In unseren Augen ist WebAssembly die perfekte Lösung für die Herausforderungen, vor denen wir stehen”, sagte Pearce auf dem WebAssembly Summit 2021. “WebAssembly ermöglicht es internen und externen Entwicklern, individuelle Erlebnisse in der Sprache und den Werkzeugen ihrer Wahl zu erstellen – etwa eine Spiele-Engine, um eine universelle Binärdatei zu erzeugen, die sowohl performant als auch von anderen Erlebnissen auf der Plattform abgegrenzt ist.”

Das könnte in einer Zukunft von entscheidender Bedeutung sein, in der die BBC interaktive Erlebnisse auf die gleiche Weise in Auftrag gibt, wie sie es heute mit Rundfunkinhalten tut: “WebAssembly ermöglicht es uns, Anwendungscode herunterzuladen und darauf zu vertrauen, dass er andere Anwendungen auf der Plattform nicht beeinträchtigt”, erklärt Pearce. Aus dieser Idee entstand schließlich der Prototyp einer Plattform mit der Bezeichnung Single Service Player (SSP). Sie soll es ermöglichen, Multimedia-Anwendungen auf einer Vielzahl von Zielplattformen mit einer einzigen C++-Codebasis in einer sicheren Sandbox auszuführen.

Die Einführung von WebAssembly bei der BBC brachte jedoch auch Hürden auf: “Die Umstellung von JavaScript auf C++ oder Rust ist für mich und mein Team eine große Herausforderung und es gibt immer noch einige Lücken, die wir schließen müssen, damit WASM seine Versprechen einlösen kann.” So stellten die Entwickler im Fall der SSP beispielsweise fest, dass der Glue-Code, der erforderlich ist, damit die Wasmtime-Laufzeitumgebung dem WebAssembly-Modul Zugriff auf verschiedene Multimedia-Funktionen geben kann, noch nicht vorhanden war. Also bauten sie von Hand eine Importfunktion. Der Aufwand hat sich allerdings gelohnt: Die SSP kann nun mit WebAssembly sowohl Web- als auch native Plattformen ansprechen.

“WebAssembly ist außerhalb des Browsers aus denselben Gründen großartig, wie innerhalb des Browsers: Performance – und zwar in einer sicheren Sandbox. Aber das muss auf einer Laufzeitumgebung basieren, und in der Anfangsphase haben WASI und die Community-Gruppe diesen Standard festgelegt. Im Moment hat sich das nicht so schnell weiterentwickelt.”

Amazon und Disney: WASM für Streaming-Plattformen

Mit 130 Millionen Abonnenten (Stand: Ende 2021) hat der Streaming-Dienst Disney+ seit seinem Start im November 2019 die Nachfrage nach nativen Anwendungen für Mobilgeräte, Set-Top-Boxen, Smart-TVs und Spielkonsolen in die Höhe schnellen lassen.

“Um die wachsende Nachfrage nach unserem Dienst zu befriedigen, der lokal auf Set-Top-Boxen installiert werden kann, musste Disney Streaming eine Software entwickeln, die unseren Partnern eine Basis ermöglicht, mit der sie schnell und effizient auf unsere Inhalte zugreifen können, während wir gleichzeitig die Umgebung kontrollieren und die Qualität des Erlebnisses sicherstellen können, die unsere Kunden erwarten”, schrieb Mike Hanley, Vice President of Software Engineering für Disney Streaming, in einem Blogbeitrag vom September 2021.

Die Disney-Ingenieure begannen 2019 mit der Entwicklung dieser portablen Laufzeitumgebung – zunächst in C und mit der Client-Anwendung in Rust, die auf WebAssembly ausgerichtet war und auf AWS gehostet wurde. Daraus entwickelte sich schließlich das Disney+ Application Developer Kit (ADK), das externen Entwicklern “eine saubere Abstraktionsschicht” und “ein gut dokumentiertes Programm für unsere Händler, die ihre Hardware und Software am besten kennen, zur Verfügung stellt, um unsere Laufzeit auf ihre Geräte zu portieren.”

Hanley und sein Team kamen zu dem Schluss, nur mit dieser Technologie in der Lage zu sein, die riesige Marktnachfrage zu befriedigen, die Experience zu kontrollieren und gleichzeitig die Kundenzufriedenheit geräteunabhängig sicherzustellen.”

Die Ingenieure bei Amazons Streaming-Dienst Prime Video näherten sich WebAssembly auf ähnliche Art und Weise. Auch sie wollten ihre Anwendung über eine wachsende Anzahl von Geräten und Plattformen hinweg besser aktualisieren können. “Bei Prime Video stellen wir Millionen von Kunden Inhalte auf mehr als 8.000 Gerätetypen wie Spielkonsolen, Fernsehern, Set-Top-Boxen und USB-betriebenen Streaming-Sticks zur Verfügung. Wenn wir ein Update durchführen wollen, benötigt jedes dieser Geräte eine eigene, native Version, was einen schwierigen Kompromiss zwischen Aktualisierbarkeit und Performance darstellt”, beschrieb Alexandru Ene, leitender Softwareentwickler bei Amazon Prime Video, das Ausgangsproblem in einem Blogbeitrag.

Im August 2020 begannen Ene und sein Team zu analysieren, wie WebAssembly Aufgaben erledigen könnte, die bislang von JavaScript-Komponenten ausgeführt wurden. “In diesen Experimenten war Code, der in Rust geschrieben und in WASM kompiliert wurde, rund zehn bis 25 Mal so schnell wie JavaScript. Wir können die Prime Video-Anwendung jedoch nicht einfach in Rust umschreiben und auf einer WASM-VM ausführen, da sie immer noch auf älteren Geräten und Browsern laufen muss, die keine WASM-Unterstützung haben.”

Stattdessen entschied sich das Team, nur ausgewählte Low-Level-Systeme von JavaScript auf WASM umzustellen. Eine Änderung, durch die die durchschnittlichen Bildwiederholraten auf Mittelklasse-Fernsehern von 28 ms auf 18 ms und auf weniger leistungsfähigen Geräten von 40 ms auf 25 ms sanken. “Um unser Ziel einer zuverlässigen Bildgenerierung mit 60 Bildern pro Sekunde zu erreichen und die Eingabe-Latenz zu verbessern, werden wir mehr Systeme auf WASM umstellen”, stellt Ene in Aussicht.

Diese Beispiele zeigen eindrücklich, wie viel Arbeit noch zu leisten ist, bevor WebAssembly eine wirklich brauchbare Unternehmenslösung wird. “Im Moment ist WebAssembly für diejenigen gedacht, die sich mit den Tool-Ketten auseinandersetzen können oder über die Art von Teams verfügen, die diese einrichten können. Sie sollte aber für jedermann zugänglich sein”, meint Gartner-Analyst Ryan.

“Ich denke, WebAssembly wird sich als De-facto-Standard für verteilte Anwendungen durchsetzen, wenn alle wichtigen Sprachcompiler in der Lage sind, grundlegenden Netzwerkcode in etwas zu konvertieren, das mit WebAssembly kompatibel ist”, prophezeit WebAssembly-Fan Hoffman.

Trotz aller bisherigen Fortschritte sehen einige Branchenbeobachter nicht, dass WebAssembly jemals die Art von explosivem Wachstum erreichen wird, die Docker erreicht hat – etwa Gartner-Mann Ryan: “Das liegt nicht unbedingt daran, dass die Technologie weniger nützlich ist, sondern daran, dass keine Marke dahinter steht, die die Bekanntheit treibt. Auf der anderen Seite sind viele immer noch dabei, Use Cases zu identifizieren – die weit weniger klar sind als bei Containern”. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.