World Wide Wasm: Niedrig hängende Früchte

Es scheint, als ob Wasm, oder WebAssembly, wenn Sie so wollen, jeden Tag mehr und mehr seine Präsenz jenseits des Browsers behauptet. Die erste Wasm I/O-Konferenz fand in Barcelona statt, die Cloud Native Computing Foundation widmete ihm einen Tag auf der CloudNativeCon, und Docker hat seine zweite technische Vorschau für die heilige Vereinigung von Containern und Wasm veröffentlicht. Wasm erhielt sogar eine lobende Erwähnung auf der Google I/O. All dies ist allein in der ersten Hälfte dieses Jahres geschehen.

Für diejenigen, die die Entwicklung von Wasm im Auge behalten haben, ist das ein gutes Omen. Einige haben vielleicht begonnen, sich mit dem Gedanken zu beschäftigen, dass Wasm tatsächlich als Teil einer nächsten Welle von Computerparadigmen eingeführt werden könnte. Ich für meinen Teil bin überzeugt, dass Wasm etwas zu bieten hat und dass es erfolgreich sein wird.

Vermeidung von Elster-getriebener Entwicklung

Das ist ja schön und gut, aber ist das wirklich ein Hinweis auf etwas Wesentliches oder unsere begrenzte Aufmerksamkeitsspanne wert? In der Tech-Branche neigen wir dazu, uns blind auf glänzende neue Technologien zu konzentrieren, ohne uns Gedanken über deren Auswirkungen zu machen - zumindest am Anfang. Es liegt also an uns, die vermeintlichen Vorteile, die Wasm bietet, zu erforschen und aufzudecken. Denn wenn Wasm keinen überzeugenden Nutzen bietet, ist es nur eine weitere glänzende Spielerei, die zu einem immer größer werdenden Haufen hinzugefügt wird.

Das ist natürlich leichter gesagt als getan, denn Wasm ist der Knotenpunkt eines sich ausbreitenden Ökosystems. Das Wasm-Ökosystem umfasst die gesamte Bandbreite der Datenverarbeitung, von Client- und Serveranwendungen bis hin zu eingebetteten Geräten und Edge Computing. Genau das ist der Punkt. Wasm versucht wirklich, sich in die Mitte von allem zu stellen - wo es Sinn macht - und das mit Absicht.

Was das Gefühl des Chaos noch verstärkt, ist die Tatsache, dass alles im Fluss ist und nur wenige grundlegende Konstrukte als stabil gelten. Das mag für einige sofort abschreckend wirken, aber selbst in seinem derzeitigen Zustand gibt es Argumente dafür, dass Wasm in bestimmten Szenarien eine praktische Wahl ist. Dies gilt vor allem, wenn man bedenkt, dass die Verwendung von Wasm auf der Serverseite in der Produktion immer seltener deklariert wird.

All das macht es ziemlich entmutigend, es zu erkunden. Mein Ziel ist es, eine Art Führer durch eine wachsende Reihe von Anwendungsfällen zu sein, die Wasm in den Mittelpunkt stellen.

Allerdings ist ein obligatorischer Haftungsausschluss angebracht. Es ist eine ziemliche Untertreibung zu sagen, dass der derzeitige Stand von Wasm (nicht in Bezug auf den Browser) noch nicht ganz ausgereift ist. Der Leser tut gut daran, sich nicht auf die Einzelheiten zu versteifen, sondern sich auf die Elemente von Wasm zu konzentrieren, die als vorteilhaft oder als Lösung für ein Problem dargestellt werden.

Die niedrig hängenden Früchte

Für den Anfang habe ich mich entschieden, einen Blick auf die niedrig hängenden Früchte zu werfen, oder anders gesagt, auf einen Anwendungsfall, bei dem Wasm ein Selbstläufer ist. Natürlich ist der eigentliche Grund für Wasm die Ausführung von Code in einer Browserumgebung. Trotz des relativen Mangels an Aufmerksamkeit hat sich Wasm im Browser jedoch bereits bewährt und ich halte das Thema für ausreichend abgedeckt.

Nein, stattdessen sollten wir uns Wasm auf dem Server zuwenden, denn das war der Grund für den Aufschwung der letzten Zeit und der Entwicklungsaktivitäten. Das unverzichtbare Äquivalent auf dem Server ist (ironischerweise) das serverlose Computing, insbesondere FaaS.

Was macht es zu einem No-Brainer?

Nun, wenn wir die von den meisten Anbietern angegebenen Best Practices für die Ausführung von serverlosem Code betrachten, läuft es in der Regel auf das Folgende hinaus:

• Verringern Sie die Größe Ihres Bereitstellungspakets
• Reduzieren Sie die Ausführung von unnötigem Code
• Überlegen Sie sorgfältig, welche Abhängigkeiten Sie in Ihr Paket aufnehmen

Die Gründe für die oben genannten Punkte sind bei näherer Betrachtung recht transparent. Diese Punkte sind sowohl für die Plattformanbieter als auch für die Plattformnutzer von Vorteil.

Die Verringerung der Paketgröße und der Menge an unnötigem Code führen beide zum gleichen Vorteil. Ein kleineres Paket (das oft durch harte Grenzen erzwungen wird) ermöglicht einen geringeren betrieblichen Aufwand für die Anbieter. Ebenso bedeutet eine Verringerung der Ausführung von unnötigem Code, dass die Betriebsressourcen effizient genutzt werden und nicht durch die Ausführung von Code gebunden sind, der wenig Nutzen bringt. Dies gilt insbesondere, wenn Sie die Größenordnung berücksichtigen, in der die Anbieter von serverlosen Plattformen in der Regel arbeiten.

Für die Nutzer der Plattform bedeutet ein kleineres Paket eine bessere Erfahrung für den Endbenutzer und Kosteneinsparungen, da ein kleineres Paket weniger Code bedeutet und daher mit einer schnelleren Ausführung korreliert. Das Gleiche gilt für die Ausführung von unnötigem Code. Weniger Zeit für die Ausführung bedeutet ein schnelleres und weniger kostspieliges Ergebnis.

Und schließlich führt die sorgfältige Berücksichtigung von Paketabhängigkeiten auch zu einer Verringerung der Paketgröße und damit zu einer unnötigen Codeausführung. Das ist aber noch nicht alles, denn ein weiterer Aspekt, den es zu berücksichtigen gilt, ist die Sicherheit. Plattformanbieter geben sich oft große Mühe, um sicherzustellen, dass der von den Plattformnutzern bereitgestellte Code in einer streng abgeschotteten Umgebung ausgeführt wird, da andernfalls echte Sicherheitsbedenken für beide Parteien entstehen.

Okay, lassen wir das mit dem Aufbau. Mit dem oben Gesagten im Hinterkopf werfen wir nun einen Blick darauf, was Wasm ist. Wasm lässt sich als ein Low-Level-Codeformat zusammenfassen:

• Schnell
• Sicher
• Kompakt
• Tragbar

Wie ich schon sagte, ein klarer Fall.

Wie sieht Serverless Wasm aus?

Der Plattformanbieter hat mehrere Möglichkeiten, wie er den Code der Verbraucher hosten kann, auf die ich in einem späteren Beitrag eingehen werde. Im Moment scheint die genehmigte Art, eine Einheit von Consumer Wasm Code, ein sogenanntes Modul, zu hosten, die Verwendung von WASI zu sein. WASI ist im Wesentlichen vergleichbar mit den Syscalls, die ein Betriebssystem-Kernel zur Verfügung stellt. Da ein Wasm-Modul jedoch konzeptionell überall laufen kann, müssen solche Aufrufe an das "Betriebssystem", das das Wasm-Modul beherbergt, die Portabilität im Auge behalten. An dieser Stelle kommt das Komponentenmodell ins Spiel. Kurz gesagt, die Entwickler von WASI haben sich dafür entschieden, von der POSIX-Methode der Verwendung von ABIs abzuweichen und stattdessen eine Interface Definition Language (IDL) zu verwenden, um die Schnittstelle zwischen einem Wasm-Modul und seinem Host zu definieren. Sie ist als Wasm Interface Type (WIT) Format bekannt.

All dies wird nur erwähnt, um die Neugier zu befriedigen. In Wirklichkeit müssen sich Entwickler, die ihr Wasm-Modul auf einer serverlosen Plattform betreiben möchten, nur um Folgendes kümmern:

1. Besorgen Sie sich die WIT-Dateien für die Zielplattform.
2. Verwenden Sie Tools, um die entsprechenden Bindungen für die unterstützte Programmiersprache Ihrer Wahl zu erzeugen.
3. Fügen Sie die entsprechende Geschäftslogik hinzu.
4. Kompilieren Sie das Modul Wasm.
5. Schieben Sie das Wasm-Modul auf die Zielplattform.

Wenn Sie daran interessiert sind, ein in Rust geschriebenes Arbeitsbeispiel zu sehen, können Sie gerne im folgenden Abschnitt weiterlesen. Wenn Sie das Wesentliche verstanden haben oder vielleicht die Nase voll von Rust haben, können Sie das Arbeitsbeispiel auch überspringen.

Ein Arbeitsbeispiel

1. Besorgen Sie sich die WIT-Dateien für die Zielplattform

Dies ist ein etwas willkürliches Beispiel, aber eine WIT-Datei für eine hypothetische serverlose Plattform könnte etwa wie folgt aussehen:

// ./wit/example-corp-faas-platform.wit

// Package identifier
package example-corp:faas-platform@0.0.1

// A 'world' encloses a particular scope of imports and exports
world example-corp-faas-platform {
  // Import and use a WASI interface type
  // In this case use the WASI `datetime` type
  use wasi:clocks/wall-clock.{datetime}

  // Type aliasing
  type event-version = string
  type response-status = u16

  // Enumerated type representing all possible types of events
  enum event-type {
    object-added,
    object-removed,
    object-updated,
    // any other event types...
  }

  // A struct equivalent type representing a single event record
  record handler-event {
    event-type: event-type,
    event-timestamp: datetime,
    event-version: event-version,
    // any other relevant event attributes...
  }

  // Similar to an enumerated type, but may carry additional data
  variant handler-error {
    timeout,
    unexpected(string),
    unsupported(event-type),
    // any other errors that make sense...
  }

  // Exports refer to items made available to a Wasm module host.
  // In this case it is the function to invoke when an event comes in on the platform.
  export handle: func(event: handler-event) -> result<_, handler-error>
}

Nachdem Sie die WIT-Definitionen erhalten haben, stellen Sie sicher, dass die entsprechenden Abhängigkeits-WITs installiert sind. Geben Sie die folgende deps.toml Datei ein:

# ./wit/deps.toml

clocks = "https://github.com/WebAssembly/wasi-clocks/archive/main.tar.gz"

Installieren Sie die WIT-Abhängigkeiten mit wit-deps-cli:

wit-deps update

2. Generieren Sie Bindungen für die von Ihnen unterstützte Programmiersprache Ihrer Wahl

Das Beispiel wird in Rust geschrieben, da es zum jetzigen Zeitpunkt eine bessere (wenn auch noch instabile und begrenzte) Unterstützung für Wasm bietet. C, C++ und Go sind ebenfalls denkbare Optionen.

Verwenden Sie die erstklassige Rust-Unterstützung von wit-bindgen, um die Bindungen für die in der WIT-Datei definierten Plattformtypen zu erzeugen:

// ./src/lib.rs

// Use a procedural macro to generate bindings for the `world` specified in
// the WIT file (`./wit/example-corp-faas-platform.wit`)
wit_bindgen::generate!("example-corp-faas-platform");

// Code implementing business logic using bindings to follow...

3. Fügen Sie die entsprechende Geschäftslogik hinzu

Als Nächstes implementieren Sie die gewünschte Geschäftslogik nach einigem Boilerplate-Code:

wit_bindgen::generate!("example-corp-faas-platform");

// Define a custom type and implement the generated `ExampleCorpFaasPlatform` trait
// for it, which represents implementing all the necessary exported interfaces
struct Component;

impl ExampleCorpFaasPlatform for Component {
    fn handle(event: HandlerEvent) -> Result<(), HandlerError> {
        match &event.event_type {
            EventType::ObjectAdded => {
                // Handle `object-added` event
                // ...
                Ok(())
            },
            EventType::ObjectRemoved => {
                // Handle `object-removed` event
                // ...
                Ok(())
            },
            _ => Err(HandlerError::Unsupported(event.event_type)),
        }
    }
}

// Export the custom type for the Wasm module host to hook into
export_example_corp_faas_platform!(Component);

4. Kompilieren Sie das Modul Wasm

Die Kompilierung eines Wasm-Moduls mit Rust ist recht einfach. Der erste Schritt besteht darin, sicherzustellen, dass die wasm32-wasi target toolchain zum Rust-Compiler hinzugefügt wird:

rustup target add wasm32-wasi

Stellen Sie als Nächstes sicher, dass das Rust-Projekt als dynamische Bibliothek kompiliert werden soll, indem Sie Folgendes zum Projekt hinzufügen: Cargo.toml:

# ./Cargo.toml

[lib]
crate-type = ["cdylib"]

Stellen Sie dann sicher, dass wit-bindgen als Abhängigkeit hinzugefügt wurde:

cargo add --git https://github.com/bytecodealliance/wit-bindgen wit-bindgen

All dies ist eine einmalige Konfiguration, und wenn sie einmal vorgenommen wurde, ist die Kompilierung eines mit dem Komponentenmodell kompatiblen Wasm-Moduls so einfach wie die Ausführung der folgenden Befehle für alle nachfolgenden Builds (von denen einer die Installation von wasm-tools erfordert):

cargo build --target wasm32-wasi --release
wasm-tools component new ./target/wasm32-wasi/release/my_project.wasm -o ./my_component.wasm

5. Schieben Sie das Wasm-Modul auf die Zielplattform

Wenn alles gut gegangen ist, dann sollte ein mit dem Komponentenmodell kompatibles Wasm-Modul erstellt worden sein. Im obigen Fall finden Sie es unter ./my_component.wasm zum Hochladen.

Ein paar Bemerkungen

Es lohnt sich, ein paar Dinge darüber zu sagen, wie der Entwicklungsprozess derzeit aussieht.

Erstens muss man wirklich noch einmal erwähnen, dass das Tooling noch nicht fertig ist und dass noch mehr Arbeit geleistet werden kann und sollte. Zum Beispiel bietet wit-bindgen erstklassige Unterstützung für Rust-Projekte, wie in Schritt 2 des Arbeitsbeispiels mit der Verwendung des Makros wit_bindgen::generate! gezeigt wird. Das bedeutet, dass einige Sprachen es besser haben als andere, bis die entsprechenden Gemeinschaften idiomatische Werkzeuge für jede Sprache entwickeln. Bis dahin müssen Sie möglicherweise Tools wie wit-bindgen über die CLI verwenden, um die Bindungen auf eine Out-of-Band Weise zu erzeugen.

Selbst mit besserem Support ist der Prozess selbst nicht ganz reibungslos. Es gibt zu viele Dinge zu konfigurieren, bevor man loslegen kann. Die WIT-Abhängigkeitsverwaltung, die Generierung von Bindungen und die Erstellung von Komponenten (über wasm-tools) sollten idealerweise in einer Toolchain zusammengefasst werden. Aber auch hier ist es noch zu früh. Wenn das derzeitige Tempo der Entwicklung und des Interesses anhält, wird es sich wahrscheinlich verbessern.

Während die Einzelheiten noch im Fluss sind, glaube ich, dass der Gesamtprozess immer noch dem obigen Arbeitsbeispiel ähneln wird. Ich bin auch ziemlich zuversichtlich, dass sich die Werkzeuge und die Unterstützung verbessern werden, um die Reibung zu verringern.

Meiner Meinung nach - und ich bin mir sicher, dass ich damit nicht alleine bin - ist das Komponentenmodell der Eckpfeiler des gesamten Wasm-Unternehmens, da es über seine Wahrnehmung und Akzeptanz entscheiden kann. Im Guten wie im Schlechten wird dieser Ansatz wahrscheinlich die Grundlage für die überwiegende Mehrheit aller potenziellen zukünftigen Wasm-Module bilden. Natürlich werden wir bei der weiteren Entwicklung des Komponentenmodells noch mehr davon sehen.

Ok, und nun?

Das mag eine ganze Menge gewesen sein oder auch nicht. Im Sinne der Einleitung zu diesem Beitrag sollte man sich die Frage stellen: Was ist hier gewonnen und/oder verloren worden?

Weniger Gepäck

Zunächst einmal ist positiv anzumerken, dass die Ausführungseinheit (Modul) von Wasm im Vergleich zu einem herkömmlichen Container-Image kleiner ist. Dies scheint in der Tat der Fall zu sein. Ein typisches Container-Image kann mehrere zehntausend Megabyte groß sein, während ein Wasm-Modul wesentlich kleiner ist. Zwar kann und sollte man Container so optimieren, dass sie möglichst klein sind, doch wird dies durch einen gewissen Overhead behindert, z.B. durch das Dateisystem. Das gilt selbst dann, wenn Sie eine native ausführbare Datei für einen Scratch-Container kompilieren. Wasm hat diesen Ballast nicht, was für serverlose Anwendungsfälle ein Glücksfall ist.

Der Nachteil ist jedoch, dass Wasm für die Entwickler nicht ganz abstrahiert ist. Ich war versucht, darauf hinzuweisen, dass Entwickler im Vergleich zum einfachen Auslagern einer Anwendung in ein Container-Image und dem Leben in seliger Unwissenheit direkt mit Wasm und verwandten Konzepten konfrontiert werden. Dies gilt jedoch für praktisch alle serverlosen Anwendungen, da sie in der Regel ein Framework oder eine Depenedenz als Einstiegspunkt benötigen, so dass Wasm hier nicht allzu viele Punkte verlieren kann. Dennoch bedeutet dies, dass Sie eine neue Reihe von Technologien und deren Feinheiten erlernen müssen.

Auf zu den Wettkämpfen

Es wird behauptet, dass die Startzeiten von Wasm um eine Größenordnung schneller sind als die von Containern. Der Vergleich liegt in der Größenordnung von Millisekunden gegenüber Sekunden. Dabei sind noch nicht einmal einige der Optimierungen berücksichtigt, die durchgeführt werden könnten. Da Wasm-Module als konzeptionelle virtuelle Maschinen ausgeführt werden, könnten Sie beispielsweise ein Modul "vorbacken", indem Sie es starten, eine Initialisierung durchführen und dann einen Snapshot als Ausgangspunkt für alle künftigen Aufrufe erstellen. Denken Sie an AWS SnapStart für Java, aber mit einem potenziell viel einfacheren Modell und einer geringeren Gesamtgröße des Snapshots. Ehrlich gesagt gibt es wenig Grund, an der Behauptung der schnelleren Startzeiten von Wasm zu zweifeln, und wenn dies zutrifft, wäre es tatsächlich ein Segen für serverlose Anwendungen.

Die Startzeiten scheinen recht flott zu sein, aber diese relative Geschwindigkeit ist teilweise auf das recht einfache Modell von Wasm zurückzuführen. Je nachdem, wen man fragt, ist eine solche Einfachheit eine gute Sache, und ich würde dazu neigen, dem zuzustimmen. Ich befürchte jedoch, dass Wasm mit zunehmender Entwicklung etwas von dieser Einfachheit einbüßt und die damit einhergehenden Leistungssteigerungen zunichte macht. Wasm ist noch nicht ausgereift und wird mit ziemlicher Sicherheit wachsen, hoffentlich nur nicht an Komplexität.

Der kleinste gemeinsame Nenner

Wasm wurde entwickelt, um tragbar zu sein. Das ist eine Aufgabe, die Wasm hervorragend meistert. Vor ein paar Jahren hätte man sich vielleicht nicht so sehr um die Portabilität gekümmert, da man sich auf der Serverseite auf die Containerisierung verlassen konnte. Doch seit einiger Zeit werden ARM-basierte Architekturen immer beliebter und die Containerisierung ist dadurch nicht mehr so einfach. In der Welt von Wasm müssen sich nur die Verwalter der Wasm-Laufzeiten wirklich mit der zugrunde liegenden Architektur befassen. Der durchschnittliche Entwickler, der Wasm einsetzt, ist einmal mehr von dieser Verantwortung befreit.

Natürlich gibt es nichts umsonst, und Portabilität ist da keine Ausnahme. Um ein hohes Maß an Portabilität zu erreichen, muss man sich in der Regel auf den kleinsten gemeinsamen Nenner beschränken. Das hat zur Folge, dass Wasm sich wahrscheinlich nicht auf jeder Kombination von Architekturen und Stacks genau gleich verhält. Es bleibt abzuwarten, ob dadurch größere Probleme entstehen, aber Wasm kann folglich als eine undichte Abstraktion betrachtet werden. Wie im Fall von Wasm müssen Entwickler darauf achten, dass Wasm irgendwo im Stack verwendet wird, insbesondere auf serverlosen Plattformen, wo es wenig bis keine Kontrolle gibt.

Zugriff verweigert

Und dann ist da noch der Aspekt der Sandbox. Jeder Aufruf eines Wasm-Moduls ist von vornherein isoliert und soll explizit angeben, welche Aktionen es ausführen möchte, um mit der Welt außerhalb des Sandkastens zu interagieren, die so genannten Fähigkeiten. Das bedeutet, dass auf einige der derzeitigen schwerfälligen Methoden des Sandboxing theoretisch verzichtet werden kann. Dies würde die Prozesse im serverlosen Bereich drastisch vereinfachen.

Wie in einer frühen Einführung zu Wasm erwähnt, ist Sandboxing (wenig überraschend) kein Allheilmittel. Wasm-Hosts können durch die Funktionen, die sie exportieren, immer noch Schwachstellen einführen. Außerdem muss Wasm erst noch auf Herz und Nieren geprüft werden, so dass nur die Zeit zeigen wird, ob es wirklich sicher ist. Das soll nicht heißen, dass es als selbstverständlich angesehen wird, denn Wasm-Laufzeiten versuchen oft, die Sicherheit rigoros aufrechtzuerhalten, wo immer es möglich ist.

Natürlich ist das Thema Sicherheit gelinde gesagt ziemlich komplex und es gibt immer mehrere Aspekte zu berücksichtigen. Der größte Teil der Sicherheitsanstrengungen von Wasm befasst sich mit bösartigem Code, der aus den Grenzen der Sandbox ausbricht. Betrachten wir jedoch den Fall, dass der Host kompromittiert wird. Während das gehostete Modul nicht in der Lage ist, über seine Sandbox hinaus zu sehen, kann der Host natürlich in jede Sandbox schauen. Dies liegt sicherlich nicht in der Verantwortung der Plattformnutzer, aber es sollte nicht zu Selbstzufriedenheit führen.

Donde Esta La Bibleoteca

Der obige Punkt, dass Sie möglicherweise einige eher schwerfällige Methoden der Sandboxing loswerden, steht zufällig in Verbindung mit einem weiteren Vorteil von Wasm. Wasm ist polyglott. Das bedeutet, dass Sie nicht nur jede Sprache verwenden können, die Wasm ansprechen kann, was an sich schon eine willkommene Aussicht ist, sondern auch jede Version einer Sprache. Vorbei wären die Zeiten, in denen AWS, Azure und Google Cloud aus scheinbar willkürlichen Gründen eine strenge Liste der unterstützten Versionen von NodeJS, Python, Go usw. führen.

Für die Unterstützung bestimmter Sprachen ist jedoch die breitere Wasm-Gemeinschaft zuständig. Theoretisch können alle Versionen einer Sprache verwendet werden, aber in der Realität müssen alle Nuancen berücksichtigt werden, wenn die Wasm-Grenze überschritten wird. Dies wird höchstwahrscheinlich das Wasm-Komponentenmodell am meisten belasten, da die Generierung von Bindungen für verschiedene Versionen von NodeJS zum Beispiel durchaus unterschiedlich sein kann. Zugegeben, das mag nicht allzu schlimm erscheinen, aber es ist eine weitere Sache, der sich Entwickler bewusst sein müssen.

Spare in der Zeit, so hast du in der Not

In Anbetracht all dessen glaube ich, dass es noch einen weiteren wichtigen Vorteil gibt, der angesprochen werden sollte. Wasm ist umweltfreundlicher. Die Plattformanbieter müssen weniger Energie und Ressourcen aufwenden - vor allem, wenn die Verwendung von ARM weiter zunimmt - und das alles in einer Sandbox, die das Verpacken in Mülltonnen erleichtert. Dies sollte zu einem wesentlich geringeren betrieblichen Aufwand führen.

Wenn wir uns wirklich voll und ganz dafür einsetzen wollten, würden wir natürlich native Binärdateien für weniger leistungshungrige Architekturen wie ARM kompilieren. Wasm ist nicht dazu gedacht, mit der Geschwindigkeit und Größe einer nativen, im Voraus kompilierten Binärdatei (AOT) zu konkurrieren. Dennoch kann Wasm AOT-kompiliert werden, wobei die Sandbox intakt bleibt. Eine solche Kompilierung kann ziemlich verlustreich sein. Es sei darauf hingewiesen, dass das Debugging bei einer undurchsichtigen Anwendung dieser Technik, wie z.B. auf serverlosen Plattformen, ziemlich unangenehm, wenn nicht sogar haarsträubend frustrierend sein würde.

Fazit

Wasm ist eine wirklich gute Lösung für serverlose FaaS-Anwendungsfälle. Es erfüllt alle Voraussetzungen. Wasm ist von Haus aus sandboxed, klein und kann schnell gestartet werden. Außerdem hat es den zusätzlichen Vorteil, dass es portabel und polyglott ist und insgesamt die Auswirkungen auf die Umwelt verbessert.

Das hat allerdings einen gewissen Preis. Wasm ist relativ aufdringlich und muss sich an den kleinsten gemeinsamen Nenner halten. Bislang verdankt Wasm einen Teil seiner Schnelligkeit seinem einfachen Modell, aber es muss noch weiterentwickelt werden und könnte zu einer leistungsmindernden Komplexität führen. Außerdem gibt es die offensichtlichen Nachteile einer unausgereiften Technologie. Es gibt nur begrenzten Support, einen Mangel an Tools und Instabilität.

Sieht man einmal von der Unreife ab (die für einige sicherlich eine große Sache ist), überwiegen die Vorteile die Nachteile bei weitem. Die Vorteile bedeuten für alle Beteiligten greifbare Vorteile, während die Vorbehalte sich in erster Linie auf eine verschlechterte Erfahrung der Entwickler beziehen, die sich höchstwahrscheinlich verbessern wird.

Die einzige Ausnahme ist jedoch die Sicherheit. Es mag den Anschein erwecken, dass die Sandbox der virtuellen Maschine absolut sicher ist, aber nur mit genügend Zeit werden wir in der Lage sein, diese Behauptung gründlich zu überprüfen.

PS

Ich möchte klarstellen, dass Wasm + serverless offensichtlich Sinn macht und (meiner bescheidenen Meinung nach) eher uninteressant ist. Es handelt sich um eine enge Anwendung von Wasm, da es hauptsächlich um die Optimierung für serverlose Umgebungen geht. Das heißt, es geht letztlich darum, die Kosten zu senken. Vieles von dem, was ich gesagt habe, ist bereits an anderer Stelle mehrfach gesagt worden. Wie der Titel des Beitrags andeutet, ist das der Punkt.

Ich hoffe jedoch, dass dieser Beitrag zu einem gewissen Maß an kritischem Denken angeregt hat. Wenn man die erklärten Ziele von Wasm für bare Münze nimmt, dann bin ich mir relativ sicher, dass jeder wirklich engagierte Leser die "glänzende technische" Rüstung durchschaut hätte. Der aufmerksame Leser hätte sich ziemlich interessante Anwendungsfälle ausgedacht, noch bevor er das Ende dieses Beitrags erreicht hat. Ich glaube, dass Wasm, wie andere zweifellos zeigen werden, mehr Potenzial für andere Anwendungen hat, und das ist es, was letztendlich ein größeres Maß an echter Begeisterung hervorruft.