Fast jedes Mesh fährt denselben Motor

Istio, Kuma, Consul, App Mesh, Gloo. Fünf Namen, und unter der Haube fünfmal derselbe Proxy: Envoy.

Ende September stellt AWS sein App Mesh endgültig ab. Wer noch darauf läuft, migriert jetzt, freiwillig oder nicht. So eine erzwungene Migration stellt jedem Team dieselbe Frage: Was von dem, was ihr gelernt habt, nehmt ihr mit? Wer nur die Konsole kannte, fängt bei null an. Wer wusste, dass darunter Envoy arbeitet, zieht mit seinem Wissen einfach um.

Der Markt streitet über Meshes, als wären es grundverschiedene Maschinen. Tatsächlich unterscheiden sich die meisten nur in zwei Fragen.

Wo sitzt der Proxy? Als Sidecar neben jedem Pod. Als geteilter Node-Proxy fürs L4, mit Envoy-Waypoints nur dort, wo L7 gebraucht wird (Ambient). Oder gleich im Kernel per eBPF, Envoy übernimmt nur noch L7 (Cilium).

Und wer konfiguriert ihn? Das ist die Control Plane. Sie ist das eigentliche Produkt, das ihr auswählt.

Die eine echte Ausnahme ist Linkerd mit eigenem Rust-Proxy. Dazu gehört eine Wahrheit, die in Feature-Tabellen selten auftaucht: Stabile Builds gibt es seit 2024 nicht mehr als Open-Source-Artefakt, sondern kommerziell vom Hersteller. Die Edge-Releases bleiben offen. Das ist legitim. Aber es ist eine Governance-Entscheidung, keine Proxy-Entscheidung.

Für Entscheider heißt das: Ihr wählt nicht nur Software. Ihr wählt, welches Wissen euer Team in drei Jahren hat und was davon den nächsten Plattformwechsel überlebt. Envoy-Wissen zieht um. Konsolen-Wissen bleibt beim Anbieter.

Meshes kommen und gehen, App Mesh führt es gerade vor. Der Motor bleibt.

Nächste Woche zerlege ich den Motor: vier Envoy-Ressourcen, und das Debugging von fast jedem Mesh wird lesbar. Wer Post 8 gelesen hat, ahnt schon, warum istioctl proxy-config ausgerechnet nach listeners, routes, clusters und endpoints fragt.