Computerhaus Quickborn

Kann Wasm Container ersetzen?​

loading="lazy" width="400px">Container über Bord?Maxx-Studio | shutterstock.com Seit seiner Einführung hat WebAssembly – kurz Wasm – für Furore gesorgt. In der Webentwicklung hat sich die Assembler-ähnliche Programmiersprache längst etabliert – und auch außerhalb des Browsers steigen die Nutzungsraten der Technologie: Mit seiner Kompaktheit, Geschwindigkeit, Portabilität und Sicherheit kann Wasm Entwickler auch zunehmend im Server- und Client-Umfeld begeistern. Einige sehen in WebAssembly sogar großes Potenzial, Linux-Container künftig zu ersetzen und das heute etablierte Container-Ökosystem zu revolutionieren. Wer sich mit der Diskussion, die um das Thema „Wasm vs. Container“ tobt, schon ein wenig beschäftigt hat, kennt sicher den Tweet von Solomon Hykes, Mitbegründer von Docker, aus dem Jahr 2019: https://twitter.com/solomonstre/status/1111004913222324225 Was Hykes damit eigentlich ausdrücken wollte: Hätte es Wasm damals bereits gegeben, wäre kein akuter Bedarf für Container-Lösungen wie Docker entstanden. Bekanntermaßen ist das nicht geschehen – wir leben in einem Universum, in dem Docker-Container tonangebend sind. Darüber hinaus ist es auch keine triviale Angelegenheit, Linux-basierte Container zu substituieren. Um das transformative Potenzial von WebAssembly besser einschätzen zu können, werfen wir im Folgenden im Gespräch mit Experten einen Blick darauf, in welchen Bereichen Wasm Container übertreffen kann – und in welchen nicht. Wo WebAssembly Container schlägt Edge Computing Seine leichtgewichtige, Sandbox-artige Natur macht WebAssembly für Edge-Computing-Zwecke besonders interessant, wie Michael J. Yuan, Gründer des Wasm-Spezialisten Second State, erklärt: „Am Netzwerkrand benötigen wir isolierte Software, aber Container verbrauchen brauchen dabei viel zu viele Ressourcen. WebAssembly lässt sich auch nutzen, um Software zu isolieren und zu managen – überall dort, wo Container zu schwerfällig sind.“ Das liegt auch an der Größe von Wasm-Modulen, wie Bailey Hayes, CTO beim Plattformanbieter Cosmonic, deutlich macht: „Im Vergleich zu Containern sind .wasm-Dateien deutlich kleiner und Laufzeit-unabhängig. Die Portabilität von WebAssembly ermöglicht es, Workloads in heterogenen Umgebungen auszuführen – etwa in der Cloud, am Netzwerkrand oder sogar auf Devices mit eingeschränkten Ressourcen.“ So eignet sich Wasm für bestimmte Anwendungsfälle, die Einschränkungen aufwerfen – beispielsweise Embedded Devices. Ein IoT-Beispiel aus dem Manufacturing-Bereich: Der Analytics-Spezialist MachineMetrics nutzt wasmCloud in der Fabrikhalle, um Maschinendaten sicherer und effizienter zu managen. Leistungskritische Workloads Auch wenn es um Performance-kritische Workloads wie Serverless-Funktionen oder bestimmte KI-Anwendungen geht, hat Wasm eine klar definierte Rolle eingenommen. Luke Wagner, Distinguished Engineer beim Cloud-Plattformanbieter Fastly, spezifiziert: „Es gibt bestimmte Anwendungen, bei denen Wasm die erste Wahl ist – vor Containern. Im Fall von Serverless-Workloads ergeben sich Kosteneinsparungen sowie Kaltstart-Optimierungen. Wasm ist vor allem für Unternehmen attraktiv, die keinen Wert darauf legen, sich an die aktuellen, proprietären Serverless-Angebote zu binden.“ Im KI-Bereich eignet sich WebAssembly insbesondere für Plattform-übergreifende Inferenz auf heterogenen Devices, wie Yuan weiß: „Container sind sehr schwer und nicht GPU-übergreifend übertragbar. Das trägt dazu bei, dass sie für Anwendungen wie LlamaEdge, einen Wasm-basierten, lokalen Laufzeit- und API-Server für große Sprachmodelle (LLMs), ungeeignet sind.“ Komponenten-basierte Architekturen Einige Experten betrachten den Spezifikations-Vorschlag WebAssembly System Interface (WASI) als Grundlage für ein Ökosystem modularer Komponenten. Darunter auch Cosmonic-Managerin Hayes: „Wir werden miterleben, wie sich neue Arten von Architekturen entwickeln, die sich die Größe und Geschwindigkeit von Wasm-Komponenten zunutze machen werden.“ Darüber hinaus stellten laut der CTO auch die standardmäßigen Sicherheitseinstellungen von WebAssembly einen großen Vorteil gegenüber Containern dar: „Container gelten im Allgemeinen nicht als die richtige Wahl für sicheres Sandboxing und dafür, Benutzercode zu isolieren“. Laut Fastly-Engineer Wagner ist davon auszugehen, dass diverse Workloads künftig von Containern auf WebAssembly migriert werden: „Das gilt insbesondere für Greenfield-Workloads, bei denen das heute bereits geschieht. Die aktuellen Standardisierungsbemühungen rund um das WebAssembly-Komponentenmodell werden dazu führen, dass Unternehmen Wasm zunehmend als Möglichkeit entdecken, um ihre Services zu modularisieren und parallel den Overhead einer traditionellen Microservices-Architektur zu vermeiden.“ Das sieht Matt Butcher, Mitbegründer und CEO des Cloud-Anbieters Fermyon, ähnlich: “Wenn Wasm ausgereift ist, wird es Container vielleicht nicht Funktion für Funktion ersetzen. Aber es besteht durchaus das Potenzial, dass WebAssembly Container in bestimmten Bereichen künftig verdrängen. Einfach deswegen, weil diese keinen Mehrwert für komponentenbasierte Anwendungen bieten.“ Plug-ins für Server-seitige Apps „Plug-ins für bestehende Systeme sind ein weiterer starker Wasm-Use-Case“, meint Yuan. Plug-Ins, die für Server-seitige Applikationen innerhalb von Sandboxes gekapselt sind, wären ein weiterer. Tatsächlich haben sich Entwickler einiger Plug-in-Frameworks bereits für Wasm entschieden. Zum Beispiel: Istio, Shopify und Envoy. Webanwendungen und -Services Browser-basierte Webanwendungen sind für WebAssembly das „tägliche Brot“. Gleichzeitig bleiben Container in diesem Bereich außen vor. Wasm im Browser ist etabliert und bietet guten Support – die Eintrittsbarriere ist also niedrig. Kein Wunder, dass bereits diverse High-Performance-Applikationen WebAssembly als Grundlage nutzen. Zum Beispiel integriert Adobe Wasm (unter anderem) aktiv in die webbasierten Versionen von: Photoshop, Express, Lightroom und Acrobat. Colin Murphy, Senior Software Engineer bei Adobe, erklärt warum: „WebAssembly ist darauf ausgelegt, kurzlebige Programme möglichst schnell, effizient und sicher auszuführen. Mit zunehmender Reife wird es auch in anderen Bereichen wie bei Web Services immer häufiger eingesetzt werden.“ Wo Container Wasm schlagen Umfangreiche Serverprozesse „Für langlaufende Serverprozesse ist WebAssembly nicht ideal“, hält Fermyon-CEO Butcher fest. Er ergänzt: „Container werden hingegen idealerweise dazu eingesetzt, bestehende, langlaufende Server wie Postgres oder WordPress zu verpacken und auszuführen. In diesem Bereich sehe ich Wasm in den nächsten zehn Jahren nicht als Herausforderer.“ Letzteres führt der Manager auf einen Mangel an Threads, schwachen Socket-Support und die Tatsache zurück, dass viele der unterstützten Sprachen nicht für WebAssembly optimiert sind. Fastly-Chefentwickler Wagner ergänzt, dass containerisierte Workloads, die auf die Funktionen eines bestimmten Betriebssystems oder einer bestimmten CPU angewiesen sind, noch nicht von Wasm unterstützt werden. „Eine Substitution durch Wasm ist also nicht so einfach möglich. Dasselbe gilt, wenn der Workload eine Sprache verwendet, die nicht vollständig von WebAssembly unterstützt wird. Ich kann mir jedoch vorstellen, dass sich das mit zunehmender Reife des Wasm-Ökosystems ändert.“ Andere sind sich da nicht so sicher – etwa Butcher: „Das Sicherheitsmodell von Wasm gewährt keinen Zugriff auf viele der Low-Level-Betriebssystem-Primitive, auf die Serveranwendungen zugreifen. Und es gibt keinen Grund zu der Annahme, dass sich das ändern wird. Das Gros der großen Code-Basen lässt sich nicht einfach zu WebAssembly kompilieren. Der Code muss neu geschrieben werden.“ Entsprechend hoch ist die Wahrscheinlichkeit, dass Container auch in Zukunft mit anderen Entwicklungsansätzen koexistieren – und sich mit diesen ergänzen. Linux-basierte, Cloud-native Systeme „Wenn man darüber spricht, Container zu ersetzen, muss man auch darüber sprechen, Linux zu ersetzen “, postuliert Hykes. Er ergänzt erklärend: „Container sind heute ein Kernbestandteil von Linux. Nicht nur der Kernel, sondern auch die Betriebssystemebene, der Standard-Stack darum herum und die Standardmethode, mit der man Linux im Rechenzentrum in der Cloud ausführt. Container werden bleiben. Die Frage ist nur: Kommt eine Ebene darüber hinzu?“ Zwar könnten Container sicherlich Wasm-Komponenten hosten – dennoch hält es der Docker-Mitbegründer für schwer vorstellbar, dass WebAssembly sich zu einer universellen, im Server-Bereich dominanten Plattform entwickelt – so wie es Linux heute ist: „Im Moment sehe ich das nicht, weil es bislang keinen überzeugenden Grund gibt, massenhaft auf diese neue Plattform umzusteigen.“ Das sehen auch andere Experten so – etwa Second-State-Gründer Yuan: „Linux-Container sind für die meisten der heutigen Cloud-nativen Anwendungen die richtigen Tools und sollten nicht ersetzt werden. Wasm ist für neue Anwendungsfälle gedacht, die eine Isolierung erfordern, bei denen Container jedoch nicht eingesetzt werden können.“ Auch in anderen Situationen, in denen die Ausführungszeit minimiert werden muss, ist Wasm keine Option, wie Wagner abschließend ergänzt: „Im Vergleich zu nativem Code entsteht bei WebAssembly ein moderater Laufzeit-Overhead, der im Fall einiger Workloads inakzeptabel sein kann. In diesen Fällen wird Wasm Container nicht ersetzen.“ Die Wasm-Zukunft Einige Experten prophezeien, dass WebAssembly Container-basierte Runtimes bis zum Jahr 2030 ersetzen wird. Die meisten gehen jedoch von einem anderen Szenario aus, in dem Wasm das aktuelle Container-Paradigma ergänzt – statt es zu ersetzen. In diesem Zusammenhang entwickeln beispielsweise die Bytecode Alliance und die Cloud Native Computing Foundation (CNCF) Projekte, die es ermöglichen, Container und Wasm-Module nebeneinander im selben Cluster auszuführen. Andere sehen eine Zukunft, in der Docker Linux-, Windows- und Wasm-Container parallel ausführt. Auch Hykes hält das für realisierbar, räumt allerdings ein: „Die Nachfrage ist eher gering. Das liegt zum Teil auch daran, dass WebAssembly auf dem Server sich bislang noch nicht durchgesetzt hat. Bislang ist das ein Nischen-Use-Case.“ Auf lange Sicht dürften mit Wasm jedoch völlig neue Märkte und Paradigmen entstehen, ist Adobe-Entwickler Murphy überzeugt: „Viele der Silos zwischen Rechenzentrum, Edge Computing, Mobilgeräten und IoT dürften durch die Portabilität und Modularität, die WASI künftig ermöglicht, aufgebrochen werden.“ Dabei dürfte auch eine Rolle spielen, dass WebAssembly branchenübergreifend eingesetzt wird, wie Hayes konstatiert: „WasmCloud wird in einer Vielzahl von Anwendungsfällen im Bankwesen, in der Fertigung, in der Telekommunikation, bei digitalen Diensten, in der Spielebranche und in vielen weiteren Bereichen eingesetzt.“ Es ist davon auszugehen, dass kleinere und schnellere Wasm-Anwendungen Container bei einer wachsenden Zahl von Greenfield-Anwendungen verdrängen werden. Dass WebAssembly jedoch das bestehende Container-Ökosystem vollständig ersetzen kann, scheint etwas weit hergeholt. Wahrscheinlicher ist, dass sowohl Wasm als auch Container die kommenden Jahre im Cloud- und Enterprise-Umfeld prägen werden. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox! 

Kann Wasm Container ersetzen?​ loading="lazy" width="400px">Container über Bord?Maxx-Studio | shutterstock.com Seit seiner Einführung hat WebAssembly – kurz Wasm – für Furore gesorgt. In der Webentwicklung hat sich die Assembler-ähnliche Programmiersprache längst etabliert – und auch außerhalb des Browsers steigen die Nutzungsraten der Technologie: Mit seiner Kompaktheit, Geschwindigkeit, Portabilität und Sicherheit kann Wasm Entwickler auch zunehmend im Server- und Client-Umfeld begeistern. Einige sehen in WebAssembly sogar großes Potenzial, Linux-Container künftig zu ersetzen und das heute etablierte Container-Ökosystem zu revolutionieren. Wer sich mit der Diskussion, die um das Thema „Wasm vs. Container“ tobt, schon ein wenig beschäftigt hat, kennt sicher den Tweet von Solomon Hykes, Mitbegründer von Docker, aus dem Jahr 2019: https://twitter.com/solomonstre/status/1111004913222324225 Was Hykes damit eigentlich ausdrücken wollte: Hätte es Wasm damals bereits gegeben, wäre kein akuter Bedarf für Container-Lösungen wie Docker entstanden. Bekanntermaßen ist das nicht geschehen – wir leben in einem Universum, in dem Docker-Container tonangebend sind. Darüber hinaus ist es auch keine triviale Angelegenheit, Linux-basierte Container zu substituieren. Um das transformative Potenzial von WebAssembly besser einschätzen zu können, werfen wir im Folgenden im Gespräch mit Experten einen Blick darauf, in welchen Bereichen Wasm Container übertreffen kann – und in welchen nicht. Wo WebAssembly Container schlägt Edge Computing Seine leichtgewichtige, Sandbox-artige Natur macht WebAssembly für Edge-Computing-Zwecke besonders interessant, wie Michael J. Yuan, Gründer des Wasm-Spezialisten Second State, erklärt: „Am Netzwerkrand benötigen wir isolierte Software, aber Container verbrauchen brauchen dabei viel zu viele Ressourcen. WebAssembly lässt sich auch nutzen, um Software zu isolieren und zu managen – überall dort, wo Container zu schwerfällig sind.“ Das liegt auch an der Größe von Wasm-Modulen, wie Bailey Hayes, CTO beim Plattformanbieter Cosmonic, deutlich macht: „Im Vergleich zu Containern sind .wasm-Dateien deutlich kleiner und Laufzeit-unabhängig. Die Portabilität von WebAssembly ermöglicht es, Workloads in heterogenen Umgebungen auszuführen – etwa in der Cloud, am Netzwerkrand oder sogar auf Devices mit eingeschränkten Ressourcen.“ So eignet sich Wasm für bestimmte Anwendungsfälle, die Einschränkungen aufwerfen – beispielsweise Embedded Devices. Ein IoT-Beispiel aus dem Manufacturing-Bereich: Der Analytics-Spezialist MachineMetrics nutzt wasmCloud in der Fabrikhalle, um Maschinendaten sicherer und effizienter zu managen. Leistungskritische Workloads Auch wenn es um Performance-kritische Workloads wie Serverless-Funktionen oder bestimmte KI-Anwendungen geht, hat Wasm eine klar definierte Rolle eingenommen. Luke Wagner, Distinguished Engineer beim Cloud-Plattformanbieter Fastly, spezifiziert: „Es gibt bestimmte Anwendungen, bei denen Wasm die erste Wahl ist – vor Containern. Im Fall von Serverless-Workloads ergeben sich Kosteneinsparungen sowie Kaltstart-Optimierungen. Wasm ist vor allem für Unternehmen attraktiv, die keinen Wert darauf legen, sich an die aktuellen, proprietären Serverless-Angebote zu binden.“ Im KI-Bereich eignet sich WebAssembly insbesondere für Plattform-übergreifende Inferenz auf heterogenen Devices, wie Yuan weiß: „Container sind sehr schwer und nicht GPU-übergreifend übertragbar. Das trägt dazu bei, dass sie für Anwendungen wie LlamaEdge, einen Wasm-basierten, lokalen Laufzeit- und API-Server für große Sprachmodelle (LLMs), ungeeignet sind.“ Komponenten-basierte Architekturen Einige Experten betrachten den Spezifikations-Vorschlag WebAssembly System Interface (WASI) als Grundlage für ein Ökosystem modularer Komponenten. Darunter auch Cosmonic-Managerin Hayes: „Wir werden miterleben, wie sich neue Arten von Architekturen entwickeln, die sich die Größe und Geschwindigkeit von Wasm-Komponenten zunutze machen werden.“ Darüber hinaus stellten laut der CTO auch die standardmäßigen Sicherheitseinstellungen von WebAssembly einen großen Vorteil gegenüber Containern dar: „Container gelten im Allgemeinen nicht als die richtige Wahl für sicheres Sandboxing und dafür, Benutzercode zu isolieren“. Laut Fastly-Engineer Wagner ist davon auszugehen, dass diverse Workloads künftig von Containern auf WebAssembly migriert werden: „Das gilt insbesondere für Greenfield-Workloads, bei denen das heute bereits geschieht. Die aktuellen Standardisierungsbemühungen rund um das WebAssembly-Komponentenmodell werden dazu führen, dass Unternehmen Wasm zunehmend als Möglichkeit entdecken, um ihre Services zu modularisieren und parallel den Overhead einer traditionellen Microservices-Architektur zu vermeiden.“ Das sieht Matt Butcher, Mitbegründer und CEO des Cloud-Anbieters Fermyon, ähnlich: “Wenn Wasm ausgereift ist, wird es Container vielleicht nicht Funktion für Funktion ersetzen. Aber es besteht durchaus das Potenzial, dass WebAssembly Container in bestimmten Bereichen künftig verdrängen. Einfach deswegen, weil diese keinen Mehrwert für komponentenbasierte Anwendungen bieten.“ Plug-ins für Server-seitige Apps „Plug-ins für bestehende Systeme sind ein weiterer starker Wasm-Use-Case“, meint Yuan. Plug-Ins, die für Server-seitige Applikationen innerhalb von Sandboxes gekapselt sind, wären ein weiterer. Tatsächlich haben sich Entwickler einiger Plug-in-Frameworks bereits für Wasm entschieden. Zum Beispiel: Istio, Shopify und Envoy. Webanwendungen und -Services Browser-basierte Webanwendungen sind für WebAssembly das „tägliche Brot“. Gleichzeitig bleiben Container in diesem Bereich außen vor. Wasm im Browser ist etabliert und bietet guten Support – die Eintrittsbarriere ist also niedrig. Kein Wunder, dass bereits diverse High-Performance-Applikationen WebAssembly als Grundlage nutzen. Zum Beispiel integriert Adobe Wasm (unter anderem) aktiv in die webbasierten Versionen von: Photoshop, Express, Lightroom und Acrobat. Colin Murphy, Senior Software Engineer bei Adobe, erklärt warum: „WebAssembly ist darauf ausgelegt, kurzlebige Programme möglichst schnell, effizient und sicher auszuführen. Mit zunehmender Reife wird es auch in anderen Bereichen wie bei Web Services immer häufiger eingesetzt werden.“ Wo Container Wasm schlagen Umfangreiche Serverprozesse „Für langlaufende Serverprozesse ist WebAssembly nicht ideal“, hält Fermyon-CEO Butcher fest. Er ergänzt: „Container werden hingegen idealerweise dazu eingesetzt, bestehende, langlaufende Server wie Postgres oder WordPress zu verpacken und auszuführen. In diesem Bereich sehe ich Wasm in den nächsten zehn Jahren nicht als Herausforderer.“ Letzteres führt der Manager auf einen Mangel an Threads, schwachen Socket-Support und die Tatsache zurück, dass viele der unterstützten Sprachen nicht für WebAssembly optimiert sind. Fastly-Chefentwickler Wagner ergänzt, dass containerisierte Workloads, die auf die Funktionen eines bestimmten Betriebssystems oder einer bestimmten CPU angewiesen sind, noch nicht von Wasm unterstützt werden. „Eine Substitution durch Wasm ist also nicht so einfach möglich. Dasselbe gilt, wenn der Workload eine Sprache verwendet, die nicht vollständig von WebAssembly unterstützt wird. Ich kann mir jedoch vorstellen, dass sich das mit zunehmender Reife des Wasm-Ökosystems ändert.“ Andere sind sich da nicht so sicher – etwa Butcher: „Das Sicherheitsmodell von Wasm gewährt keinen Zugriff auf viele der Low-Level-Betriebssystem-Primitive, auf die Serveranwendungen zugreifen. Und es gibt keinen Grund zu der Annahme, dass sich das ändern wird. Das Gros der großen Code-Basen lässt sich nicht einfach zu WebAssembly kompilieren. Der Code muss neu geschrieben werden.“ Entsprechend hoch ist die Wahrscheinlichkeit, dass Container auch in Zukunft mit anderen Entwicklungsansätzen koexistieren – und sich mit diesen ergänzen. Linux-basierte, Cloud-native Systeme „Wenn man darüber spricht, Container zu ersetzen, muss man auch darüber sprechen, Linux zu ersetzen “, postuliert Hykes. Er ergänzt erklärend: „Container sind heute ein Kernbestandteil von Linux. Nicht nur der Kernel, sondern auch die Betriebssystemebene, der Standard-Stack darum herum und die Standardmethode, mit der man Linux im Rechenzentrum in der Cloud ausführt. Container werden bleiben. Die Frage ist nur: Kommt eine Ebene darüber hinzu?“ Zwar könnten Container sicherlich Wasm-Komponenten hosten – dennoch hält es der Docker-Mitbegründer für schwer vorstellbar, dass WebAssembly sich zu einer universellen, im Server-Bereich dominanten Plattform entwickelt – so wie es Linux heute ist: „Im Moment sehe ich das nicht, weil es bislang keinen überzeugenden Grund gibt, massenhaft auf diese neue Plattform umzusteigen.“ Das sehen auch andere Experten so – etwa Second-State-Gründer Yuan: „Linux-Container sind für die meisten der heutigen Cloud-nativen Anwendungen die richtigen Tools und sollten nicht ersetzt werden. Wasm ist für neue Anwendungsfälle gedacht, die eine Isolierung erfordern, bei denen Container jedoch nicht eingesetzt werden können.“ Auch in anderen Situationen, in denen die Ausführungszeit minimiert werden muss, ist Wasm keine Option, wie Wagner abschließend ergänzt: „Im Vergleich zu nativem Code entsteht bei WebAssembly ein moderater Laufzeit-Overhead, der im Fall einiger Workloads inakzeptabel sein kann. In diesen Fällen wird Wasm Container nicht ersetzen.“ Die Wasm-Zukunft Einige Experten prophezeien, dass WebAssembly Container-basierte Runtimes bis zum Jahr 2030 ersetzen wird. Die meisten gehen jedoch von einem anderen Szenario aus, in dem Wasm das aktuelle Container-Paradigma ergänzt – statt es zu ersetzen. In diesem Zusammenhang entwickeln beispielsweise die Bytecode Alliance und die Cloud Native Computing Foundation (CNCF) Projekte, die es ermöglichen, Container und Wasm-Module nebeneinander im selben Cluster auszuführen. Andere sehen eine Zukunft, in der Docker Linux-, Windows- und Wasm-Container parallel ausführt. Auch Hykes hält das für realisierbar, räumt allerdings ein: „Die Nachfrage ist eher gering. Das liegt zum Teil auch daran, dass WebAssembly auf dem Server sich bislang noch nicht durchgesetzt hat. Bislang ist das ein Nischen-Use-Case.“ Auf lange Sicht dürften mit Wasm jedoch völlig neue Märkte und Paradigmen entstehen, ist Adobe-Entwickler Murphy überzeugt: „Viele der Silos zwischen Rechenzentrum, Edge Computing, Mobilgeräten und IoT dürften durch die Portabilität und Modularität, die WASI künftig ermöglicht, aufgebrochen werden.“ Dabei dürfte auch eine Rolle spielen, dass WebAssembly branchenübergreifend eingesetzt wird, wie Hayes konstatiert: „WasmCloud wird in einer Vielzahl von Anwendungsfällen im Bankwesen, in der Fertigung, in der Telekommunikation, bei digitalen Diensten, in der Spielebranche und in vielen weiteren Bereichen eingesetzt.“ Es ist davon auszugehen, dass kleinere und schnellere Wasm-Anwendungen Container bei einer wachsenden Zahl von Greenfield-Anwendungen verdrängen werden. Dass WebAssembly jedoch das bestehende Container-Ökosystem vollständig ersetzen kann, scheint etwas weit hergeholt. Wahrscheinlicher ist, dass sowohl Wasm als auch Container die kommenden Jahre im Cloud- und Enterprise-Umfeld prägen werden. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!

Kann Wasm Container ersetzen?​

loading=”lazy” width=”400px”>Container über Bord?Maxx-Studio | shutterstock.com Seit seiner Einführung hat WebAssembly – kurz Wasm – für Furore gesorgt. In der Webentwicklung hat sich die Assembler-ähnliche Programmiersprache längst etabliert – und auch außerhalb des Browsers steigen die Nutzungsraten der Technologie: Mit seiner Kompaktheit, Geschwindigkeit, Portabilität und Sicherheit kann Wasm Entwickler auch zunehmend im Server- und Client-Umfeld begeistern. Einige sehen in WebAssembly sogar großes Potenzial, Linux-Container künftig zu ersetzen und das heute etablierte Container-Ökosystem zu revolutionieren. Wer sich mit der Diskussion, die um das Thema „Wasm vs. Container“ tobt, schon ein wenig beschäftigt hat, kennt sicher den Tweet von Solomon Hykes, Mitbegründer von Docker, aus dem Jahr 2019: https://twitter.com/solomonstre/status/1111004913222324225 Was Hykes damit eigentlich ausdrücken wollte: Hätte es Wasm damals bereits gegeben, wäre kein akuter Bedarf für Container-Lösungen wie Docker entstanden. Bekanntermaßen ist das nicht geschehen – wir leben in einem Universum, in dem Docker-Container tonangebend sind. Darüber hinaus ist es auch keine triviale Angelegenheit, Linux-basierte Container zu substituieren. Um das transformative Potenzial von WebAssembly besser einschätzen zu können, werfen wir im Folgenden im Gespräch mit Experten einen Blick darauf, in welchen Bereichen Wasm Container übertreffen kann – und in welchen nicht. Wo WebAssembly Container schlägt Edge Computing Seine leichtgewichtige, Sandbox-artige Natur macht WebAssembly für Edge-Computing-Zwecke besonders interessant, wie Michael J. Yuan, Gründer des Wasm-Spezialisten Second State, erklärt: „Am Netzwerkrand benötigen wir isolierte Software, aber Container verbrauchen brauchen dabei viel zu viele Ressourcen. WebAssembly lässt sich auch nutzen, um Software zu isolieren und zu managen – überall dort, wo Container zu schwerfällig sind.“ Das liegt auch an der Größe von Wasm-Modulen, wie Bailey Hayes, CTO beim Plattformanbieter Cosmonic, deutlich macht: „Im Vergleich zu Containern sind .wasm-Dateien deutlich kleiner und Laufzeit-unabhängig. Die Portabilität von WebAssembly ermöglicht es, Workloads in heterogenen Umgebungen auszuführen – etwa in der Cloud, am Netzwerkrand oder sogar auf Devices mit eingeschränkten Ressourcen.“ So eignet sich Wasm für bestimmte Anwendungsfälle, die Einschränkungen aufwerfen – beispielsweise Embedded Devices. Ein IoT-Beispiel aus dem Manufacturing-Bereich: Der Analytics-Spezialist MachineMetrics nutzt wasmCloud in der Fabrikhalle, um Maschinendaten sicherer und effizienter zu managen. Leistungskritische Workloads Auch wenn es um Performance-kritische Workloads wie Serverless-Funktionen oder bestimmte KI-Anwendungen geht, hat Wasm eine klar definierte Rolle eingenommen. Luke Wagner, Distinguished Engineer beim Cloud-Plattformanbieter Fastly, spezifiziert: „Es gibt bestimmte Anwendungen, bei denen Wasm die erste Wahl ist – vor Containern. Im Fall von Serverless-Workloads ergeben sich Kosteneinsparungen sowie Kaltstart-Optimierungen. Wasm ist vor allem für Unternehmen attraktiv, die keinen Wert darauf legen, sich an die aktuellen, proprietären Serverless-Angebote zu binden.“ Im KI-Bereich eignet sich WebAssembly insbesondere für Plattform-übergreifende Inferenz auf heterogenen Devices, wie Yuan weiß: „Container sind sehr schwer und nicht GPU-übergreifend übertragbar. Das trägt dazu bei, dass sie für Anwendungen wie LlamaEdge, einen Wasm-basierten, lokalen Laufzeit- und API-Server für große Sprachmodelle (LLMs), ungeeignet sind.“ Komponenten-basierte Architekturen Einige Experten betrachten den Spezifikations-Vorschlag WebAssembly System Interface (WASI) als Grundlage für ein Ökosystem modularer Komponenten. Darunter auch Cosmonic-Managerin Hayes: „Wir werden miterleben, wie sich neue Arten von Architekturen entwickeln, die sich die Größe und Geschwindigkeit von Wasm-Komponenten zunutze machen werden.“ Darüber hinaus stellten laut der CTO auch die standardmäßigen Sicherheitseinstellungen von WebAssembly einen großen Vorteil gegenüber Containern dar: „Container gelten im Allgemeinen nicht als die richtige Wahl für sicheres Sandboxing und dafür, Benutzercode zu isolieren“. Laut Fastly-Engineer Wagner ist davon auszugehen, dass diverse Workloads künftig von Containern auf WebAssembly migriert werden: „Das gilt insbesondere für Greenfield-Workloads, bei denen das heute bereits geschieht. Die aktuellen Standardisierungsbemühungen rund um das WebAssembly-Komponentenmodell werden dazu führen, dass Unternehmen Wasm zunehmend als Möglichkeit entdecken, um ihre Services zu modularisieren und parallel den Overhead einer traditionellen Microservices-Architektur zu vermeiden.“ Das sieht Matt Butcher, Mitbegründer und CEO des Cloud-Anbieters Fermyon, ähnlich: “Wenn Wasm ausgereift ist, wird es Container vielleicht nicht Funktion für Funktion ersetzen. Aber es besteht durchaus das Potenzial, dass WebAssembly Container in bestimmten Bereichen künftig verdrängen. Einfach deswegen, weil diese keinen Mehrwert für komponentenbasierte Anwendungen bieten.“ Plug-ins für Server-seitige Apps „Plug-ins für bestehende Systeme sind ein weiterer starker Wasm-Use-Case“, meint Yuan. Plug-Ins, die für Server-seitige Applikationen innerhalb von Sandboxes gekapselt sind, wären ein weiterer. Tatsächlich haben sich Entwickler einiger Plug-in-Frameworks bereits für Wasm entschieden. Zum Beispiel: Istio, Shopify und Envoy. Webanwendungen und -Services Browser-basierte Webanwendungen sind für WebAssembly das „tägliche Brot“. Gleichzeitig bleiben Container in diesem Bereich außen vor. Wasm im Browser ist etabliert und bietet guten Support – die Eintrittsbarriere ist also niedrig. Kein Wunder, dass bereits diverse High-Performance-Applikationen WebAssembly als Grundlage nutzen. Zum Beispiel integriert Adobe Wasm (unter anderem) aktiv in die webbasierten Versionen von: Photoshop, Express, Lightroom und Acrobat. Colin Murphy, Senior Software Engineer bei Adobe, erklärt warum: „WebAssembly ist darauf ausgelegt, kurzlebige Programme möglichst schnell, effizient und sicher auszuführen. Mit zunehmender Reife wird es auch in anderen Bereichen wie bei Web Services immer häufiger eingesetzt werden.“ Wo Container Wasm schlagen Umfangreiche Serverprozesse „Für langlaufende Serverprozesse ist WebAssembly nicht ideal“, hält Fermyon-CEO Butcher fest. Er ergänzt: „Container werden hingegen idealerweise dazu eingesetzt, bestehende, langlaufende Server wie Postgres oder WordPress zu verpacken und auszuführen. In diesem Bereich sehe ich Wasm in den nächsten zehn Jahren nicht als Herausforderer.“ Letzteres führt der Manager auf einen Mangel an Threads, schwachen Socket-Support und die Tatsache zurück, dass viele der unterstützten Sprachen nicht für WebAssembly optimiert sind. Fastly-Chefentwickler Wagner ergänzt, dass containerisierte Workloads, die auf die Funktionen eines bestimmten Betriebssystems oder einer bestimmten CPU angewiesen sind, noch nicht von Wasm unterstützt werden. „Eine Substitution durch Wasm ist also nicht so einfach möglich. Dasselbe gilt, wenn der Workload eine Sprache verwendet, die nicht vollständig von WebAssembly unterstützt wird. Ich kann mir jedoch vorstellen, dass sich das mit zunehmender Reife des Wasm-Ökosystems ändert.“ Andere sind sich da nicht so sicher – etwa Butcher: „Das Sicherheitsmodell von Wasm gewährt keinen Zugriff auf viele der Low-Level-Betriebssystem-Primitive, auf die Serveranwendungen zugreifen. Und es gibt keinen Grund zu der Annahme, dass sich das ändern wird. Das Gros der großen Code-Basen lässt sich nicht einfach zu WebAssembly kompilieren. Der Code muss neu geschrieben werden.“ Entsprechend hoch ist die Wahrscheinlichkeit, dass Container auch in Zukunft mit anderen Entwicklungsansätzen koexistieren – und sich mit diesen ergänzen. Linux-basierte, Cloud-native Systeme „Wenn man darüber spricht, Container zu ersetzen, muss man auch darüber sprechen, Linux zu ersetzen “, postuliert Hykes. Er ergänzt erklärend: „Container sind heute ein Kernbestandteil von Linux. Nicht nur der Kernel, sondern auch die Betriebssystemebene, der Standard-Stack darum herum und die Standardmethode, mit der man Linux im Rechenzentrum in der Cloud ausführt. Container werden bleiben. Die Frage ist nur: Kommt eine Ebene darüber hinzu?“ Zwar könnten Container sicherlich Wasm-Komponenten hosten – dennoch hält es der Docker-Mitbegründer für schwer vorstellbar, dass WebAssembly sich zu einer universellen, im Server-Bereich dominanten Plattform entwickelt – so wie es Linux heute ist: „Im Moment sehe ich das nicht, weil es bislang keinen überzeugenden Grund gibt, massenhaft auf diese neue Plattform umzusteigen.“ Das sehen auch andere Experten so – etwa Second-State-Gründer Yuan: „Linux-Container sind für die meisten der heutigen Cloud-nativen Anwendungen die richtigen Tools und sollten nicht ersetzt werden. Wasm ist für neue Anwendungsfälle gedacht, die eine Isolierung erfordern, bei denen Container jedoch nicht eingesetzt werden können.“ Auch in anderen Situationen, in denen die Ausführungszeit minimiert werden muss, ist Wasm keine Option, wie Wagner abschließend ergänzt: „Im Vergleich zu nativem Code entsteht bei WebAssembly ein moderater Laufzeit-Overhead, der im Fall einiger Workloads inakzeptabel sein kann. In diesen Fällen wird Wasm Container nicht ersetzen.“ Die Wasm-Zukunft Einige Experten prophezeien, dass WebAssembly Container-basierte Runtimes bis zum Jahr 2030 ersetzen wird. Die meisten gehen jedoch von einem anderen Szenario aus, in dem Wasm das aktuelle Container-Paradigma ergänzt – statt es zu ersetzen. In diesem Zusammenhang entwickeln beispielsweise die Bytecode Alliance und die Cloud Native Computing Foundation (CNCF) Projekte, die es ermöglichen, Container und Wasm-Module nebeneinander im selben Cluster auszuführen. Andere sehen eine Zukunft, in der Docker Linux-, Windows- und Wasm-Container parallel ausführt. Auch Hykes hält das für realisierbar, räumt allerdings ein: „Die Nachfrage ist eher gering. Das liegt zum Teil auch daran, dass WebAssembly auf dem Server sich bislang noch nicht durchgesetzt hat. Bislang ist das ein Nischen-Use-Case.“ Auf lange Sicht dürften mit Wasm jedoch völlig neue Märkte und Paradigmen entstehen, ist Adobe-Entwickler Murphy überzeugt: „Viele der Silos zwischen Rechenzentrum, Edge Computing, Mobilgeräten und IoT dürften durch die Portabilität und Modularität, die WASI künftig ermöglicht, aufgebrochen werden.“ Dabei dürfte auch eine Rolle spielen, dass WebAssembly branchenübergreifend eingesetzt wird, wie Hayes konstatiert: „WasmCloud wird in einer Vielzahl von Anwendungsfällen im Bankwesen, in der Fertigung, in der Telekommunikation, bei digitalen Diensten, in der Spielebranche und in vielen weiteren Bereichen eingesetzt.“ Es ist davon auszugehen, dass kleinere und schnellere Wasm-Anwendungen Container bei einer wachsenden Zahl von Greenfield-Anwendungen verdrängen werden. Dass WebAssembly jedoch das bestehende Container-Ökosystem vollständig ersetzen kann, scheint etwas weit hergeholt. Wahrscheinlicher ist, dass sowohl Wasm als auch Container die kommenden Jahre im Cloud- und Enterprise-Umfeld prägen werden. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox! 

Nach oben scrollen