This week, the Istio project announced the Beta of its new ambient mode functionality in the upcoming v1.22. Since the original announcement of ambient mode in 2022, Solo.io has been leading the development of ambient mode and provided several core innovations. In fact, five of the top 10 contributors to the new ztunnel component are Soloists!
Not sure what ambient mode will mean to you? Read on.
Why Ambient Mode Matters
Ambient mode allows the delivery of the full set of service mesh features—transparent zero-trust security with mTLS, authentication and authorization policy, observability, and traffic management—in a game-changing, innovative way.
Since Istio first introduced the pattern in 2017, service mesh features have been delivered using sidecars: proxy servers that are deployed alongside every pod in a Kubernetes cluster. This pattern comes at a cost, in terms of the resource utilization of the proxy servers (and, in a cloud environment, an actual monetary cost to run them!). It also necessitated the mixing of the Istio infrastructure with your own infrastructure, running each proxy server in your own pods. Among the downsides of this is that you couldn’t deploy or upgrade Istio without restarting every pod in the cluster.
Ambient mode solves both of these problems. By moving the service mesh infrastructure out of your containers and into your cluster, service mesh truly becomes ambient: always there, surrounding your services. You can add workloads to the mesh without changing them or restarting them, and you can safely provide mesh features at a far lower cost.
What Is the Innovation?
With Istio’s ambient mode, we separate the processing of layer 4 traffic (network protocols like TCP) and layer 7 (application protocols like HTTP).
Layer 4 processing can be done on each node, using a custom-designed zero trust tunnel proxy, which we call ‘ztunnel’. Traffic is transparently redirected to the ztunnels, which handle encrypting it and sending it to other pods, via other ztunnels.
In Solo’s experience, users predominantly come to Istio for compliance use cases first. Istio in ambient mode can meet mTLS with only the ztunnel.
For workloads where you need layer 7 functionality, you can deploy an optional ‘waypoint’ proxy. This is the Envoy proxy that Istio has used since the start, but deployed in a “per-namespace” fashion, rather than per-pod. Your waypoint is only processing traffic for the service which it is associated with, so there is no concern about multi-tenancy.
The only thing that changes is how the service is deployed and managed. All the APIs for managing Istio remain the same, and you can switch between the two modes as you wish.
Why Wasn’t It Always Like This?
The sidecar approach replaced other options that existed before, including having to compile libraries into your application (the Google internal and Netflix OSS models) and running a single proxy server running on each node (the Linkerd v1 approach).
Since the success of Istio, other options have been proposed—especially since the rise of eBPF. While eBPF is a useful technology, running a HTTP proxy in the Linux kernel violates the underpinnings of modern operating systems, and is unlikely to be a practical technology for service mesh.
Options that use eBPF to redirect traffic to a proxy server per node bring us back to the model that Linkerd moved away from almost six years ago.
Getting traffic out of the pod and into the ztunnel was a hard problem. Redirecting traffic in a single location per node would often cause conflicts with CNI implementations that expected to do the same thing. Gloo Mesh engineers discovered a novel method for solving this problem and contributed it to the Istio project.
Cost Savings
Not only did each application team have to manage the lifecycle of the sidecar proxies, they had to handle the allocation of resources. Underprovision, and you have poor performance; overprovision, and you have unnecessary extra cost. And remember, if you get it wrong, that means restarting all your workloads!
Our initial research suggested that ambient mode could cost 90% less than sidecar mode. We’re excited to see real world numbers as people start experimenting with ambient mode in Beta.
Enjoying the Ambience
Solo is committed to also ensuring seamless interoperability between ambient mode and existing sidecar-based solutions. Recognizing that many organizations have already invested heavily in sidecar architectures, Solo’s approach emphasizes compatibility and flexibility with Gloo Mesh Core. With support for sidecar interoperability, organizations can seamlessly transition to ambient mode at their own pace, without disrupting existing workflows or compromising on functionality. Whether you’re running sidecar proxies alongside your pods or exploring ambient mode, Solo’s solutions provide the interoperability and versatility you need to successfully navigate cloud native application networking.
As Istio’s ambient mode moves into beta, the possibilities for innovation and cost savings are boundless. We’re excited to see how organizations leverage ambient mode to drive engineering excellence, enhance developer productivity, and achieve increasingly higher operational efficiency.
To learn more about how the ambient revolution can empower your organization, visit us at the Ambient Lounge at KubeCon. And, if you’re hosting on Amazon, you can download our new white paper about unlocking business efficiency with ambient mode and AWS.
