The Istio “ambient mesh” branch was recently merged to main. This marks a major milestone for ambient, and offers new choices for Istio users. In this post, I want to add some clarity to the broader discussion of Istio deployment topologies, and also set out Tetrate’s views on ambient and Istio going forwards.
Ambient mesh is a new deployment model for Istio that splits the duties currently performed by the Envoy sidecar into two separate components: a node-level component for encryption (called “ztunnel”) and an Envoy instance deployed per service for all Layer 7 processing (called the “waypoint”). The ambient mesh deployment model is an attempt to gain some improvements in resource usage. You can read more about the details in Jimmy Song’s excellent blog on how ambient mesh intercepts and routes traffic.
For clarity, let’s agree on some terminology. We like to refer to ambient mode. Ambient is a different topology for Istio’s data plane and, to most users, simply an install option. It’s an implementation detail that gives Istio users more choice and can potentially better fit their needs in specific situations. It’s not a fundamentally different project; it’s all still Istio.
We are excited by the development of ambient mode, the options it opens up for some Istio users and for the dynamism it represents in the Istio community at large. As such, Tetrate will fully support ambient mode for Istio. Our FIPS-verified Istio distribution, Tetrate Istio Distro, consciously doesn’t fork the upstream Istio codebase, to ensure you’ll never get locked-in to us as a vendor. As a result, it will support ambient just like upstream does, as well as bringing the benefits of extended version support and the option to purchase enterprise support through the Tetrate Istio Subscription.
Tetrate Service Bridge, our flagship application connectivity and security platform for large enterprise Istio deployments, will also support ambient mode for the meshes it manages, either provisioned by Tetrate Service Bridge, or when you use our bring-your-own-mesh feature. That support will initially be in alpha, reflecting the realistic state of ambient at the moment. Indeed, there’s some existing functionality that may never be supported in ambient mode because they’re unsolved problems for the alternative topology.
Whether or not you use ambient mode is a choice you should make based on your specific needs. If Istio’s proven sidecar data plane works for you, we’ll support you. If you need ambient mode’s alternative data-plane model, we’ll support you. Either way, we’re here to ensure your successful use of service mesh. We’ll work with you to help make the right choice for your context, and a big part of that is educating folks with the facts to make that choice confidently.
Which Mode Should I Choose?
So what does that choice look like today? We think the broad majority of Istio users will still benefit the most from Istio’s proven sidecar data plane. Ambient mode may offer reduced resource usage in some circumstances (even then it’s nuanced due to kernel cleverness). Any performance gains from using ambient mode must be weighed against its more complex topology, as there are now two types of component making up the mesh’s data plane. Additionally, observability of requests and responses is reduced. And most importantly for most of the users we talk to, the security stance is weakened, often by an unacceptable amount. You can read up on how the two modes compare and a fuller list of consequences, in our previous blog on the topic.
While ambient mode can allow an Istio mesh to run in otherwise impossible resource constraints, we at Tetrate don’t believe it’ll ever replace sidecars for most of our customers. Their strong isolation requirements and need for comprehensive, accurate observability for audit, mean they can’t make the ambient trade. But we’ll leave the choice with our customers, and we’ll be watching the development of ambient, excited to see where it goes in the future.