Introduction

A service mesh is an infrastructure layer that controls and secures network traffic between distributed applications. With the explosion of microservices and cloud-native workloads, service meshes have become crucial to run these applications securely and efficiently. A service mesh can offload a lot of the complexities of distributed computing and allow developers to focus on creating valuable business outcomes. Some of these concerns include:

• Service discovery
• End-to-end encryption
• Workload identity
• Load balancing and complex routing
• Observability
• Fault tolerance and resiliency

Istio has become the de facto standard in cloud-native service meshes. Introduced as an open-source project in 2017, Istio has garnered widespread adoption by both large enterprises and high-tech companies. It offloads the encryption, service discovery, observability, and other network functions from application teams, and is supported by a large and active community.

Istio uses a well-known and proven pattern to implement service mesh functionality, known as the sidecar pattern. The sidecar pattern is an effective approach to implementing service mesh, but also brings significant overhead and costs with it. To address these issues, the Istio community has released a new Ambient, or node proxy, solution.

In this post, we will introduce Istio’s new ambient mode, and how it drastically reduces the cost and resources required to run Istio at scale.

Sidecar Pattern vs. Node Proxy

First, let’s take a look at the differences between the original Istio sidecar pattern and the new Ambient mode in Istio.

In a sidecar-based mesh, each workload that is deployed (typically a pod in Kubernetes or a virtual machine) has a proxy process deployed alongside it that intercepts all inbound and outbound traffic. This process, known as a sidecar, can encrypt and decrypt traffic, apply policies, and emit telemetry without the need to modify the original workload. In Istio, this sidecar is an Envoy proxy, and in Kubernetes, this Envoy proxy is automatically injected into a pod as a separate container.

A typical sidecar-based mesh would look something like this:

‍

‍

The sidecar pattern has proven to be an effective approach to service meshes over the years, but it also comes with several downsides:

• Operating sidecars quickly becomes complex in a large-scale environment.
• Availability of workloads becomes dependent on the sidecar. For example, an upgrade to Istio requires each pod to be restarted to get an upgraded Envoy proxy.
• Support for workloads outside of Kubernetes and Linux virtual machines is limited. For example, joining serverless functions to a sidecar mesh is difficult and often requires bespoke solutions.
• Envoy proxy was originally designed to be an OSI Layer 7 reverse proxy. But many service mesh users only need Layer 3/4 capabilities, such as encryption and network telemetry. The overhead of a full Layer 7 solution is overkill in these scenarios.
• Most glaringly, there is a significant infrastructure “tax” for running sidecars in every pod or virtual machine.

Istio’s Ambient mode addresses these issues in two ways: it implements a proxy-per-node model, and it splits Layer 4 and Layer 7 concerns into separate processes. In Ambient, two components make up the service mesh’s data plane: 

• ztunnel, which handles Layer 4 functions such as mTLS encryption, traffic redirection, and network telemetry, and 
• Waypoint, which provides Layer 7 features such as HTTP traffic management and header manipulation.

An Istio service mesh using Ambient mode looks like this:

‍

‍

Istio’s new Ambient architecture addresses many of the concerns with sidecar-based Istio:

• Operations become much simpler, as there is only a proxy per node, not per pod, and little to no configuration is required for ztunnel’s Layer 4 functions.
• Upgrades and patches do not require restarts of the workloads and are done in a zero-downtime fashion.
• Ztunnel runs on many platforms, expanding the reach of a service mesh.
• Splitting Layer 4 and Layer 7 into 2 processes allows users to selectively deploy Waypoints as needed but still get mTLS, authorization, and telemetry across workloads. Ztunnel is designed specifically for Layer 4 concerns.
• The infrastructure required to run a proxy per node is drastically less than a proxy per pod, especially in large, high-density environments.

As you can see, Istio’s Ambient mode aims to address many of the shortcomings of sidecar mode, while still providing the security, control, and observability required of a service mesh.

Savings with Ambient Mesh

Infrastructure Savings

To give an idea of the kind of savings that can be realized for cloud compute costs by migrating to Ambient mode from sidecar-based Istio, let’s look at the infrastructure costs associated with sidecars and with Ambient.

First, the average publicly available price for each vCPU in the major cloud providers’ node instance types is between $22 and $30 a month. For our calculations, let’s be conservative and use $22 per month per vCPU in standard cloud instances.

Let’s assume we have 3 Kubernetes clusters with 15,000 pods that we want to be part of a service mesh. Let’s also assume that these clusters have a total of 200 nodes and 1000 namespaces.

The Istio community has regularly benchmarked Envoy proxy using 0.6 vCPU for 1000 requests per second, so let’s use that figure. For a sidecar-based service mesh, we would use: 9000 vCPUs (15,000 pod proxies x 0.6 vCPU) for proxies, which would cost us $2,376,000 per year ($22 x 12 months x 9000 vCPU) in cloud compute resources.

In contrast, Ambient Mesh’s ztunnel typically uses 0.3 vCPU per node instance. If we deployed a Waypoint to each of our namespaces, our vCPU utilization would be 60 (200 nodes x 0.3 vCPU) for ztunnel and an additional 600 vCPUs (1000 namespaces x 0.6 vCPU) for Waypoints. This means that an equivalent Ambient Mesh would cost us $174,240 per year ($22 x 660 vCPUs x 12 months), a savings of $2,201,760 per year! Even if we deployed Waypoints with 3 replicas for availability, our annual cost would be $491,040, for a savings of $1,884,960 per year.

Cost comparison of Envoy sidecars and Ambient

‍

Using these calculations, real Istio users have created business cases to justify migrating to Ambient Mesh. The following table shows what some organizations have projected in savings.

‍

‍

As you can see, real users are excited about the savings in infrastructure costs that are possible by migrating to Ambient from sidecars. 

Other Areas of Savings

Users switching to Ambient Mesh from sidecars can realize savings across other areas in addition to infrastructure costs:

• The operational burden is drastically reduced. Monitoring and troubleshooting are greatly simplified with the reduction in proxies. This reduces operating costs and the time to recovery when there are issues.
• Responsibilities of configuration can be split across parties. Platform operators can implement encryption, zero-trust configuration, and observability with ztunnel. Developers can implement their specific routing logic with a Waypoint, without the need to touch ztunnel. This reduces the time to resolution for application teams.
• For users who primarily use service mesh for network encryption, observability, and basic authorization, ztunnel can be used as a replacement for the sidecar proxy, without the need for corresponding Waypoint proxies. Ztunnel is lightweight and purpose-built in Rust for Layer 4 processing.
• Ztunnel allows many types of platforms to be joined to a service mesh. For example, ztunnel can be integrated with serverless functions, tightly managed container platforms, and non-Linux virtual machines. This greatly reduces the need for bespoke solutions for these platforms.

These savings also apply to companies that avoided implementing Istio in sidecar mode. This simplified, lighter-weight model drastically reduces the friction to adopt Istio.

Conclusion

As you can see, Istio’s ambient mode greatly improves upon the original sidecar architecture. One of the areas of improvement is the overall cost of using sidecars at scale. Switching to ambient mode can help organizations of all sizes drastically reduce their service mesh footprint and improve overall user experience and customer satisfaction. 

Ambient also reduces the barrier to entry for new service mesh users. Many companies have held off on implementing an Istio-based service mesh because of the cost and complexity of sidecar-based solutions. With Istio ambient mode, many of these concerns are lowered or eliminated.

Istio has long been regarded as the most reliable and complete service mesh solution. With the advent of Ambient Mesh, the Istio community continues to innovate and set itself apart from other solutions, while improving the user experience.

To get an idea of how much you could save with Ambient Mesh, try the new Cost Savings Estimator.

Ready to migrate to Ambient Mesh? Get industry expert enterprise-grade support from the Solo.io team with our new Gloo Istio Subscription and migrate with confidence.