21 Punkte von GN⁺ 2025-02-13 | 8 Kommentare | Auf WhatsApp teilen

"WebAssembly ist echtes Write-Once-Run-Anywhere"
"Im Jahr 2030 wird sich niemand mehr an Kubernetes erinnern"

Portabilität

  • Container haben viele Probleme der Softwareentwicklung gelöst und waren benutzerfreundlicher als VMs
  • Heute sind Container jedoch durch komplexe Tools und die starke Kopplung von Programm, Container und Linux umständlich geworden
  • Entwickler wollen sich auf das Schreiben von Code und das Ausrollen von Funktionen konzentrieren, und das Erlernen von Docker wird dabei zum Hindernis
  • WebAssembly (WASM) ersetzt Container in einigen Bereichen bereits und bietet eine "einmal schreiben, überall ausführen"-Erfahrung
  • Mehrere Sprachen lassen sich nach WASM kompilieren, und der Mangel an Systemschnittstellen verhindert zwar noch die breite Akzeptanz, doch das dürfte bald gelöst werden
  • Die wichtigste aktuelle Einschränkung von WASM ist das Fehlen von Systemschnittstellen wie Dateizugriff und Networking, aber das ist ein Problem, das sich mit der Zeit lösen wird

Vergleich mit der JVM

  • WASM bietet ein ähnliches "einmal schreiben, überall ausführen"-Konzept wie die JVM, aber die JVM läuft nicht im Webbrowser
  • Webbrowser sind ein wichtiges Ziel für die Auslieferung von Anwendungen, weshalb viele Entwickler die JVM meiden
  • In letzter Zeit entwickeln sich statische Binär-Compiler wie GraalVM, Kotlin Native und Scala Native als Alternativen zur JVM

Microservices

  • In einer Microservices-Architektur werden Services über HTTP, RPC oder Message Broker miteinander verbunden
  • Die Kosten und Zuverlässigkeitsprobleme der Netzwerkkommunikation sind die größten Nachteile, aber die meisten Unternehmen halten die Vorteile für größer
  • Mit dem Aufkommen serverloser Plattformen wie AWS Lambda können Microservices als einzelne Funktionen bereitgestellt werden
  • Cloudflare Workers laufen innerhalb einer V8-Sandbox und ermöglichen Funktionsaufrufe innerhalb derselben Runtime ohne Netzwerkanfragen
  • Das bietet zugleich die Entwicklungsvorteile von Microservices und die Runtime-Performance einer monolithischen Architektur
  • Auch andere Anbieter wie Wasmer entwickeln WASM-basierte Lösungen

Einführung von WASM

  • WASM ist noch eine junge Technologie, entwickelt sich aber schnell weiter und wird zunehmend unterstützt
  • Derzeit funktioniert sie noch nicht in jeder Umgebung perfekt, aber über Plattformen wie Cloudflare lässt sich die Zukunft schon heute erleben
  • Wer dynamische Sprachen wie Python, Ruby oder PHP nutzt, ist gut beraten, während der weiteren Entwicklung von WASM zusätzlich kompilierte Sprachen wie Go oder Rust zu lernen

8 Kommentare

 
bus710 2025-02-14

K8s ist ein Tool zur Orchestrierung von Containern — wird es wegen wasm an Relevanz verlieren? Bei Docker würde es wohl bis zu einem gewissen Grad verdrängt werden, aber ...

 
colus001 2025-02-14

WASM ist wie ein neuer 3D-Drucker. Alle sagen: „Eine neue Welt kommt“, aber tatsächlich gibt es kaum Leute, die ihn wirklich nutzen ...

 
halfenif 2025-02-14

https://madewithwebassembly.com/

Hier gibt es eine Sammlung von Implementierungsbeispielen.

(Meiner persönlichen Meinung nach) wirken vor allem Bereiche wie CAD oder Bildverarbeitung am plausibelsten.

Das erinnert mich gerade an ein Lösungsteam, das früher darüber nachgedacht hat, wie sich hochauflösende medizinische Bilder im Web umsetzen lassen.

 
halfenif 2025-02-14

WASM am Beispiel lernen
https://de.news.hada.io/topic?id=11891

Ich schaue es mir an und mache es Schritt für Schritt nach.

 
jujumilk3 2025-02-14

Ich glaube, dass k8s auch 2030 noch stark dastehen wird.

 
yangeok 2025-02-14

Heißt das, man muss am Ende sowohl Docker als auch WASM kennen? Haha. Aber da Docker mit zunehmender Reife der Technologie auch leichter zugänglich geworden ist, könnte ich mir vorstellen, dass sich WASM in eine ähnliche Richtung entwickelt und ebenfalls einfacher nutzbar wird.

 
clickin 2025-02-13

Letztlich läuft es wohl darauf hinaus, sich auf die Performance der WASM-Runtime zu stützen – würde V8 damit nicht auf derselben Ebene wie die JVM stehen?
Ich mache mir Sorgen, dass uns eine Zukunft erwartet, in der sich das Verhalten von WASM je nach V8-Version unterscheidet und man genau das dann debuggen muss.

 
GN⁺ 2025-02-13
Hacker-News-Kommentare
  • Das Fehlen von Systemschnittstellen ist der Hauptfaktor, der einer breiteren Akzeptanz im Weg steht. Dateizugriff, Networking usw. werden mit der Zeit integriert werden
    • Wenn jedoch Dateizugriff, Networking usw. hinzugefügt werden, können Sicherheitslücken entstehen. Das ist ein Faktor, der Javas Versprechen „write once, run anywhere“ untergraben hat
    • WASM löst andere Probleme als Container. WASM ist effizient für die Ausführung von Code in einer Sandbox
    • WASM hat gute Chancen, zum Standard zu werden, etwa bei Implementierungen von Functions-as-a-Service
    • Container lösen dieses Problem nicht. Sie taugen nicht als Sicherheitsgrenze, sind schwerer als WASM-Binärdateien und haben höhere Startkosten
    • Container eignen sich dafür, mehrere Prozesse und Threads auszuführen und grundlegende OS-Funktionen zu nutzen
  • WebAssembly bietet eine echte „write once, run anywhere“-Erfahrung
    • Sobald es jedoch mit der Außenwelt interagiert, sieht die Sache anders aus. Jede V8-Runtime hat leicht unterschiedliche Schnittstellen
    • Der Erfolg von Docker lag darin, dass POSIX bereits ein etablierter Standard war
  • PlatformOps (früher DevOps, SRE, Ops) wird durch komplexe Tools und die enge Kopplung von Programmen, Containern und Linux um sein Versprechen gebracht
    • Entwickler wollen Code schreiben und Funktionen deployen
    • PlatformOps kämpft damit, die Probleme zu lösen
  • WASM ist keine Lösung, die Container ersetzt. Container lösen das Problem, verschiedene Versionen von PHP ohne Konflikte auszuführen
    • WASM löst dieses Problem nicht
  • Wann kommt die Zukunft von WASM? Acht Jahre sind vergangen, aber es gibt keine stabile und einfach zu nutzende Toolchain
    • Rust wurde 2012 veröffentlicht und war acht Jahre später stabil
  • WASM läuft nicht auf echter Hardware. Es kann als virtuelle Maschine betrachtet werden
    • Container paketieren Anwendungen, die direkt auf echter Hardware laufen
    • WASM benötigt eine Runtime. Es läuft innerhalb einer Anwendung
    • WASM löst das „Portabilitäts“-Problem, das auch JVM und .NET lösen
    • Container bündeln Anwendungen und Abhängigkeiten
    • Die Technologien können sich ergänzen
  • Zu lernen, wie man Docker benutzt, ist kein Hindernis
    • Man braucht nur ein Dockerfile
    • WASM-Apps brauchen weiterhin Kubernetes
    • WebAssembly wird in den nächsten fünf Jahren nicht stark wachsen
  • WASM ist eine weitere Abstraktionsschicht. Ob es alles ersetzt, hängt von den Abwägungen gegenüber anderen Lösungen ab