Warum ich (noch) bei Sidecars bleibe
Ambient macht vieles richtig. Für harte Enterprise-Anforderungen bleibe ich vorerst beim Sidecar. Der Grund dafür steht in keinem Benchmark.
- Datum
- Thema
- Ambient
- Quellen
- 8
- Lesezeit
- 2 Min.
Das ist eine persönliche Einschätzung aus dem Feld, kein Reifezeugnis für irgendeine Seite.
Abbildung als Text
Zwei Spalten mit je drei Argumenten: links Sidecar (Betriebserfahrung, weil Runbooks und Debugging-Reflexe Sidecar-geprägt sind; Isolation, weil ein Proxy-Problem genau einen Pod trifft, bei einer Node-Schicht dagegen die ganze Node; Funktionsumfang, weil das volle L7-Programm direkt am Workload liegt, ohne Waypoint als Zwischenstufe), rechts Ambient (Proxy-Lifecycle bei der Plattform, Mesh-Upgrade ohne App-Restart; geteilte Node-Schicht ohne Proxy-Overhead pro Pod; L7 nur dort, wo es gebraucht wird). Darunter zwei Kästen: Das 'noch' hat ein Verfallsdatum, es trägt nur keine Zahl; für große Flotten mit wenig L7-Bedarf sind Sidecars vermutlich die teurere Architektur. Pointe: Architektur wechselt man per Merge Request. Betriebserfahrung nicht.
Erstens die Betriebserfahrung. Sidecars sind der Modus, der am längsten und am breitesten in Produktion gelaufen ist. Runbooks und Debugging-Reflexe der Teams sind Sidecar-geprägt. Ein Wechsel tauscht darum mehr als die Mesh-Schicht, er baut die Organisation um, die sie betreibt. Post 10 gilt auch hier.
Zweitens die Isolation. Im Sidecar-Modell trifft ein Proxy-Problem einen einzelnen Pod. Bei einer Node-Schicht ist der Blast-Radius die Node, mit allem, was dort läuft. Das ist kein Fehler von Ambient, geteilte Komponenten haben geteilte Fehlerbilder. Aber wer harte Isolations-Anforderungen hat, etwa aus Compliance-Sicht, muss mit dieser Physik rechnen.
Drittens der Funktionsumfang. Im Sidecar-Modell liegt das volle L7-Programm direkt am Workload, ohne Waypoint als Zwischenstufe. Am Waypoint ist die Gateway API laut Feature-Tabelle stabil, VirtualService steht dort auf Alpha, EnvoyFilter wird nicht unterstützt. Istios Migrationsleitfaden nennt den Umzug auf HTTPRoute darum Pflicht für stabiles L7. Für ein gewachsenes VirtualService-Inventar sind das zwei Migrationen, und die Reihenfolge ist die eigentliche Entscheidung: erst Gateway API, noch im Sidecar-Modell, dann Ambient.
Für große Flotten, in denen die meisten Workloads vor allem mTLS und Identität brauchen, ist das Betriebsversprechen aus Post 24 trotzdem real. Wer hunderte Namespaces mit wenig L7-Bedarf fährt, betreibt mit Sidecars vermutlich die teurere Architektur.
Das „noch“ im Titel ist ernst gemeint. Diese Antwort hat ein Verfallsdatum, es trägt nur noch keine Zahl. Ich prüfe sie regelmäßig neu, und irgendwann kippt sie.
Architektur wechselt man per Merge Request. Betriebserfahrung nicht.
Wo steht ihr heute: Sidecar, Ambient oder beides nebeneinander? Und was hat den Ausschlag gegeben?
