Waarom ik (nog) bij sidecars blijf
Ambient doet veel dingen goed. Voor harde enterprise-eisen blijf ik voorlopig bij de sidecar. De reden daarvoor staat in geen enkele benchmark.
- Datum
- Onderwerp
- Ambient
- Bronnen
- 8
- Leestijd
- 2 min
- Versie
- Vertaling
Dit is een persoonlijke inschatting uit de praktijk, geen oordeel over de volwassenheid van een van beide kanten.
Afbeelding als tekst
Twee kolommen met elk drie argumenten: links sidecar (operationele ervaring, omdat runbooks en debugreflexen het stempel van sidecars dragen; isolatie, omdat een proxy-probleem precies één pod treft, bij een node-laag daarentegen de hele node; functionaliteit, omdat het volledige L7-programma direct bij de workload ligt, zonder waypoint als tussenstap), rechts Ambient (proxy-lifecycle bij het platform, mesh-upgrade zonder app-restart; gedeelde node-laag zonder proxy-overhead per pod; L7 alleen waar het nodig is). Daaronder twee vakken: het 'nog' heeft een houdbaarheidsdatum, er staat alleen nog geen getal op; voor grote vloten met weinig L7-behoefte zijn sidecars waarschijnlijk de duurdere architectuur. Pointe: Architectuur wissel je met een merge request. Operationele ervaring niet.
Ten eerste de operationele ervaring. Sidecars zijn de modus die het langst en het breedst in productie heeft gedraaid. De runbooks en debugreflexen van de teams dragen het stempel van sidecars. Een overstap vervangt daarom meer dan de mesh-laag, hij bouwt de organisatie om die deze laag beheert. Report #10 geldt ook hier.
Ten tweede de isolatie. In het sidecar-model treft een proxy-probleem één enkele pod. Bij een node-laag is de blast radius de node, met alles wat daar draait. Dat is geen fout van Ambient, gedeelde componenten hebben gedeelde foutbeelden. Maar wie harde isolatie-eisen heeft, bijvoorbeeld vanuit compliance-oogpunt, moet rekening houden met deze fysica.
Ten derde de functionaliteit. In het sidecar-model ligt het volledige L7-programma direct bij de workload, zonder waypoint als tussenstap. Op de waypoint staat de Gateway API volgens de feature-statustabel op stabiel, VirtualService staat daar op alfa en EnvoyFilter wordt niet ondersteund. Istio’s migratiegids noemt de overstap naar HTTPRoute daarom verplicht voor stabiel L7. Voor een gegroeid VirtualService-bestand zijn dat twee migraties, en de volgorde is de eigenlijke beslissing: eerst Gateway API, nog in sidecar-modus, dan Ambient.
Voor grote vloten, waarin de meeste workloads vooral mTLS en identiteit nodig hebben, is de beheerbelofte uit report #24 toch reëel. Wie honderden namespaces met weinig L7-behoefte draait, beheert met sidecars waarschijnlijk de duurdere architectuur.
Het “nog” in de titel is serieus bedoeld. Dit antwoord heeft een houdbaarheidsdatum, er staat alleen nog geen getal op. Ik toets het regelmatig opnieuw, en op een gegeven moment slaat het om.
Architectuur wissel je met een merge request. Operationele ervaring niet.
Waar staan jullie vandaag: sidecar, Ambient of allebei naast elkaar? En wat gaf de doorslag?
