Bijna elke mesh draait op dezelfde motor

Istio, Kuma, Consul, App Mesh, Gloo. Vijf namen, en onder de motorkap vijf keer dezelfde proxy: Envoy.

Eind september trekt AWS definitief de stekker uit App Mesh. Wie er nog op draait, migreert nu, vrijwillig of niet. Zo’n gedwongen migratie stelt elk team dezelfde vraag: wat nemen jullie mee van alles wat jullie hebben geleerd? Wie alleen de console kende, begint bij nul. Wie wist dat daaronder Envoy werkt, verhuist gewoon met zijn kennis mee.

De markt maakt ruzie over meshes alsof het fundamenteel verschillende machines zijn. In werkelijkheid verschillen de meeste maar in twee vragen.

Waar zit de proxy? Als sidecar naast elke pod. Als gedeelde node-proxy voor L4, met Envoy-waypoints alleen waar L7 nodig is (Ambient). Of meteen in de kernel via eBPF, en Envoy doet alleen nog L7 (Cilium).

En wie configureert hem? Dat is de control plane. Die is het eigenlijke product dat jullie kiezen.

De enige echte uitzondering is Linkerd, met zijn eigen Rust-proxy. Daar hoort een waarheid bij die in feature-tabellen zelden opduikt: stable builds zijn er sinds 2024 niet meer als open-source-artefact, maar commercieel via de leverancier. De edge-releases blijven open. Dat is legitiem. Maar het is een governance-beslissing, geen proxy-beslissing.

Voor beslissers betekent dat: jullie kiezen niet alleen software. Jullie kiezen welke kennis jullie team over drie jaar heeft en wat daarvan de volgende platformwissel overleeft. Envoy-kennis verhuist mee. Console-kennis blijft bij de aanbieder.

Meshes komen en gaan, App Mesh doet het op dit moment voor. De motor blijft.

Volgende week haal ik de motor uit elkaar: vier Envoy-resources, en het debuggen van bijna elke mesh wordt leesbaar. Wie report #8 heeft gelezen, vermoedt al waarom istioctl proxy-config uitgerekend naar listeners, routes, clusters en endpoints vraagt.