Why I’m (still) staying with sidecars
Ambient gets a lot right. For hard enterprise requirements, I’m staying with sidecars for now. The reason for that doesn’t show up in any benchmark.
- Date
- Topic
- Ambient
- Sources
- 8
- Reading time
- 2 min
- Version
- Translation
This is a personal assessment from the field, not a maturity rating for either side.
Figure as text
Two columns with three arguments each: on the left, sidecar (operational experience, because runbooks and debugging reflexes are shaped by sidecars; isolation, because a proxy problem hits exactly one pod, whereas with a node layer it hits the whole node; functionality, because the full L7 feature set sits directly at the workload, without a waypoint as an intermediate stage), on the right, Ambient (proxy lifecycle lies with the platform, mesh upgrade without app restart; shared node layer without per-pod proxy overhead; L7 only where it is needed). Below, two boxes: the 'still' has an expiry date, it just doesn't carry a number yet; for large fleets with little need for L7, sidecars are probably the more expensive architecture. Punchline: Architecture changes with a merge request. Operational experience doesn't.
First, operational experience. Sidecars are the mode that has run in production the longest and most widely. Teams’ runbooks and debugging reflexes are shaped by sidecars. So a switch swaps out more than the mesh layer: it restructures the organization that operates it. Report #10 applies here too.
Second, isolation. In the sidecar model, a proxy problem hits a single pod. With a node layer, the blast radius is the node and everything that runs on it. That isn’t a flaw in Ambient: shared components have shared failure modes. But if you have hard isolation requirements, for instance from a compliance perspective, you have to reckon with this physics.
Third, functionality. In the sidecar model, the full L7 feature set sits directly at the workload, without a waypoint as an intermediate stage. At the waypoint, the feature status table lists the Gateway API as Stable, VirtualService is Alpha there, and EnvoyFilter isn’t supported. Istio’s migration guide therefore calls the move to HTTPRoute a requirement for stable L7. For a grown VirtualService estate, that means two migrations, and the order is the real decision: Gateway API first, still in sidecar mode, then Ambient.
For large fleets where most workloads mainly need mTLS and identity, the operations promise from report #24 is real nonetheless. If you run hundreds of namespaces with little need for L7, you’re probably operating the more expensive architecture with sidecars.
The “still” in the title is meant seriously. This answer has an expiry date, it just doesn’t carry a number yet. I re-check it regularly, and at some point it will flip.
Architecture changes with a merge request. Operational experience doesn’t.
Where do you stand today: sidecar, Ambient or both side by side? And what tipped the scales?
