Kurz gesagt: Ja.
WebAssembly (Wasm) hat sich zu einer führenden Technologie entwickelt, die die Webentwicklung im Sturm erobert hat. Von frühen technischen Demos wie dem beliebten Spiel Doom, das vollständig im Browser läuft, bis hin zu großen Legacy-Anwendungen wie Photoshop, die auf einer gewöhnlichen Webseite ein vollständiges Desktop-ähnliches Erlebnis bieten, ermöglicht WebAssembly völlig neue Erfahrungen in einem vertrauten Programm, das bereits auf jedem PC der Welt installiert ist.
Wasm wurde so konzipiert, dass es von nahezu jeder Programmiersprache unterstützt werden kann – unabhängig davon, über welchen Prozessortyp der Computer des Benutzers verfügt. Zudem bietet es mehrere vorteilhafte Sicherheitseigenschaften, die der Browser nutzt, um unbefugten Zugriff auf die Daten oder Systemressourcen eines Benutzers zu verhindern. Diese Eigenschaften erweisen sich auch außerhalb des Browsers als äußerst nützlich, insbesondere wenn Code isoliert ausgeführt werden oder besonders portabel sein soll.
Die Geschichte von POSIX unter Unix
WebAssembly hat standardmäßig keinen Zugriff auf Ressourcen des Systems, auf dem es ausgeführt wird. Es geht lediglich um die reine Verarbeitung von Nullen und Einsen. Deshalb wurde Wasm bislang hauptsächlich für rechenintensive Aufgaben wie das Dekodieren von Videos oder die Bearbeitung von Bildern eingesetzt und weniger für die Entwicklung vollständiger Anwendungen. Es ist relativ einfach, einer WebAssembly-Sandbox Zugriff auf externe Funktionen zu gewähren, etwa auf Informationen zur aktuellen Uhrzeit oder auf in einer Datei gespeicherte Daten. Welche APIs dabei genau verwendet werden, unterscheidet sich jedoch meist von Anwendung zu Anwendung.
Unix-Systeme erlebten etwas Ähnliches wie das, was derzeit mit WebAssembly außerhalb des Browsers geschieht. Viele Anwendungen benötigten Zugriff auf gängige Systemressourcen wie Netzwerk- und Dateisystemfunktionen, doch jedes Betriebssystem stellte diese auf etwas andere Weise bereit. Aus diesem Grund wurde POSIX als Standard für eine portable Betriebssystemschnittstelle eingeführt. Alle Unix-ähnlichen Systeme konnten diese Schnittstelle übernehmen und so die Kommunikation zwischen Programmen und Betriebssystem vereinheitlichen. Dadurch ließen sich Programme, die für ein Unix-ähnliches System entwickelt worden waren, auch problemlos auf ein anderes portieren.
WASI betritt die Bühne: die WebAssembly-Systemschnittstelle
Um WebAssembly-Programmen eine standardisierte Möglichkeit zur Kommunikation mit einem Betriebssystem zu bieten, wurde WASI, das WebAssembly System Interface, ins Leben gerufen. WASI wurde maßgeblich von einem Projekt namens CloudABI inspiriert, das wiederum auf POSIX zurückgeht. Dadurch eröffneten sich WebAssembly zahlreiche Möglichkeiten, auch außerhalb des Browsers zu glänzen: Nutzer profitierten nun von sämtlichen Sicherheits- und Sandbox-Eigenschaften von WebAssembly sowie von durchdachten APIs für den Zugriff auf gängige Systemressourcen, ohne dabei die Vorteile der Sandbox vollständig aufzugeben. Dabei kommt einem natürlich eine ähnliche Technologie in den Sinn: Container. Keine Diskussion zu diesem Thema wäre vollständig ohne einen Verweis auf einen der eindrücklichsten und meistgeteilten Beiträge über WASI vom Docker-Mitbegründer Solomon Hykes:
Das ist eine gewagte Aussage. WebAssembly bietet eine portable Möglichkeit, Code so zu paketieren, dass er auf jeder Plattform sicher und mit nahezu nativer Geschwindigkeit ausgeführt werden kann. Gegenüber Containern bietet es zudem den Vorteil, dass überhaupt kein Betriebssystem vorhanden sein muss. Die meisten von Entwicklern erstellten Container enthalten eine Form von Linux-Betriebssystem, in dem die Programme ausgeführt werden. Dadurch sind Container oft mehrere Hundert Megabyte oder sogar mehrere Gigabyte groß. WebAssembly-Binärdateien bestehen hingegen ausschließlich aus Code und sind häufig nur wenige Kilobyte oder einstellige Megabyte groß. Die Vorstellung einer Welt, in der Entwickler nicht überall Container, sondern stattdessen WebAssembly bereitstellen, mag verrückt erscheinen. Doch diese Vision wird bereits Realität: Mehrere Projekte, die Wasm auf Kubernetes ausführen sollen, werden aktiv entwickelt.
Serverseitiges WebAssembly im Produktiveinsatz
Eine Reihe von Unternehmen profitiert bereits vom produktiven Einsatz von serverseitigem Wasm. Cloudflare und Fastly verfügen beide über riesige Edge-Computing-Netzwerke, über die Kunden Code weltweit und so nah wie möglich an den Nutzern bereitstellen können. Beide haben sich strategisch für WebAssembly entschieden, um kleine, äußerst portable Binärdateien mit kurzen Startzeiten und zuverlässiger Mandantenfähigkeit zu ermöglichen. Das junge Unternehmen Cosmonic nutzt eine ausgeklügelte Netzwerktechnik, damit WebAssembly-Komponenten unabhängig von ihrem Ausführungsort nahtlos miteinander kommunizieren können – sei es auf einem winzigen Gerät in Ihrer Handfläche oder auf einem Rechner am anderen Ende der Welt. Ein weiteres junges Unternehmen, Fermyon, setzt WebAssembly ein, um die Workload-Dichte auf Servern erheblich zu steigern. Das Ergebnis sind drastisch niedrigere Serverkosten und eine umweltfreundlichere Datenverarbeitung.
Wachstum außerhalb des Browsers
Zusammenfassend lässt sich sagen, dass WebAssembly, obwohl es ursprünglich für Berechnungen im Browser entwickelt wurde, auch außerhalb des Browsers weiterhin großes Potenzial zeigt. Dank seiner Architektur, die verschiedene Programmiersprachen unterstützt und besonderen Wert auf Sicherheit legt, eignet es sich hervorragend, um Code isoliert auszuführen und Portabilität zu gewährleisten. Die Einführung von WASI hat WebAssembly auf Serverseite zum Durchbruch verholfen und ermöglicht es Unternehmen, Wasm zu nutzen, um bessere Produkte deutlich kosteneffizienter bereitzustellen. Das Potenzial von WebAssembly außerhalb des Browsers ist nicht nur eine Idee, sondern wird in der Branche zunehmend Realität.
Weitere Informationen finden Sie in unserem früheren Blogbeitrag „Warum WebAssembly für Sie relevant ist“.
Sehen Sie sich außerdem unseren Podcast „WebAssembly Unleashed“ an oder hören Sie ihn.
Über den Autor
Ähnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.