Istio Supercharges Service Mesh With New Ambient Mesh

Istio service mesh was developed to manage microservices and accelerate application development. The new Istio ambient mesh has gone a step further by removing the need for sidecars. Idit Levine, CEO and Founder of Solo.io, discusses the development of Istio ambient mesh, the culmination of over 5 years of experience in the Istio community, along with thousands of production deployments and contributions from nearly 1,000 engineers.

Managing the microservices explosion

The microservices genie has been let out of the bottle and there’s no going back. Microservices provide unparalleled application agility and scalability, enabling organisations to ship more and better features, in order to improve the customer experience at a much faster rate. They’re also suited to distributed architectures and cloud environments, which makes them ideal for modernisation projects. So, it’s easy to understand why they’ve become so widely adopted. Our very own study of IT professionals - spanning developers, VPs, CIO and CTOs - working at medium to large enterprises, revealed that 85% of companies are modernising their apps to a microservices architecture. Another 54% reported that at least half of their apps use a microservices architecture.

However, managing this explosion of microservices has become an operational, security and networking challenge. For instance, an enterprise organisation could have hundreds or even thousands of microservices running in the background. Which is why it’s vital for organisations to have the right tools in place to properly manage and scale their microservices architectures, while also ensuring the integrity of the applications they support.

Understanding service mesh

To address this challenge and unlock the full potential of cloud native application development, organisations are now adopting service mesh and API gateways that run in tandem with container orchestration platforms like Kubernetes.

In brief, a service mesh is a networking framework that adds observability, security and reliability to distributed applications. It provides a vital link between microservices attempting to communicate and share data with each other across a vast and complex environment. A typical application can be made up of any number of microservices, which can make them difficult to manage and even support basic application functions. The service mesh is deployed to ensure those services can communicate reliably, securely, and maintain a high performance.

Service mesh is growing in popularity as an organisational tool. According to our research nearly half of all companies (49%) report using a service mesh at some level, with a further 38% evaluating a service mesh for use. Of those companies already using a service mesh, an overwhelming 89% reported it has had a very positive impact on app reliability, with 44% stating the impact has been ‘transformative.’

A service mesh is made up of a set of lightweight network proxies, typically deployed alongside application code in a ‘sidecar container’, which can effectively manage network services by directing traffic and monitoring the interactions between components. These proxies form the data plane of the service mesh, which is controlled and configured by a control plane. Service mesh simplifies inter-service communication in container-based and microservices architectures. Making it easier to diagnose any communication errors that occur at the infrastructure layer. It also supports security features like authentication, authorisation, and encryption. Ultimately, it accelerates application development, testing, and deployment. But could it be improved upon? That’s the challenge we set ourselves.

Istio: the industry standard service mesh

Stepping back a little, it’s important to mention that Istio is one of the best examples of service mesh. There are alternatives, but Istio offers all the service mesh benefits and it operates in tandem with Kubernetes to deliver smooth running microservices-based containerized environments.

Istio is an open-source project we’ve been committed to since the beginning and we are proud contributors to the ecosystem. That’s why we chose to enhance the Istio service mesh to ensure a process of continuous development that the Istio community and its users would benefit from. The new development is manifested in ‘Istio Ambient Mesh’, which is a sidecar-less data plane option for Istio service mesh that we developed with support from the Google engineering team. We did this to improve the operational experience of adopting, deploying, upgrading and managing Istio as a piece of critical infrastructure.

We also wanted to address some of the drawbacks inherent in the sidecar proxy. To begin with, there are disparities between the sidecar proxy and Kubernetes within an application pod, which can lead to workloads becoming susceptible to container race conditions. The sidecar can also misinterpret Layer 7 (L7) protocols, which can cause errors. Finally, the adoption of Istio features is an ‘all-or-nothing’ proposition. Istio is a powerful service mesh with many capabilities, but the current adoption curve can be very steep without the ability to adopt features incrementally and absorb risk. Overall, the potential issues this causes can make it harder to adopt a service mesh at scale.

Istio ambient mesh addresses the transparency and incremental adoption problem by introducing a sidecar-less data plane and splitting the behaviours of the network into two separate layers, each managing concerns that can be combined to provide all the facets and features of a service mesh. It also delivers cost savings, performance improvements and improved security. And that is on top of maintaining Istio’s core feature set of zero-trust security, resilience, observability, traffic routing, and policy enforcement. It’s leaner and can be deployed as a shared mesh infrastructure across both Istio standard and Istio ambient mesh architectures. Offering a flexible choice of sidecar (standard Istio architecture) or sidecar-less (Istio Ambient Mesh architecture) which can be mixed or matched to be aligned to best suit your application needs.

Realising the impact of Istio ambient mesh

Istio ambient mesh is a game changer for users who are looking to adopt service mesh. Our research indicates 86% of organisations with over half of their production workloads on Kubernetes report delaying or slowing down app deployment into production. Additionally, 74% of organisations say managing the application networking for multiple clusters is time consuming and error prone. Although it’s still a nascent technology, Istio ambient mesh can help organisations to alleviate all these problems and more. The companies already using service mesh agree that it provides value, by dramatically improving application reliability and security. The following section details some of the key features of Istio ambient mesh, in more detail.

Running Applications in Istio ambient mesh

Despite the similarities between the standard mesh sidecar architecture, you will find more advantages to running your applications in Istio ambient mesh. It offers a more transparent experience with much broader application support, simplifying operations and reducing infrastructure costs.

Incremental adoption

Istio ambient mesh facilitates much better incremental adoption. This is because the secure overlay layer is separated via ztunnel and the L7 processing layer via waypoint proxy. It allows users to run ambient mesh using the secure overlay layer, which isn’t possible with a sidecar architecture. The two-layer architecture also enables a more granular transition from no mesh or sidecar to the secure overlay layer to the L7 processing layer.

Transparency

Istio ambient mesh delivers a level of transparency that is non-intrusive to the application, which helps to eliminate any issues you may have had running your applications with a sidecar previously. This includes any start-up or shutdown sequence issues between your application container and sidecars that you may have encountered before. This helps to simplify application onboarding and reduces the time needed to onboard applications to the mesh.

Reduced Infrastructure Costs

There are costs associated with running your applications in service mesh; typically you pay for the control plane, data plane CPU and memory allocation, regardless of the actual usage. Istio ambient mesh reduces infrastructure costs by having the required ztunnel handle the secure overlay layer for all co-located pods and having the optional waypoint proxy deployed outside of the application pod.

Incremental adoption

Adding applications to ambient mesh allows you to secure, connect and observe services incrementally, without any sidecars. We recommend you incrementally adopt Istio ambient mesh to take full advantage of the two-layer data plane architecture. A common adoption strategy is to secure inbound traffic with the Istio ingress gateway first as it is the least intrusive, then gradually add one or more of your services to Istio ambient mesh to leverage L4 mesh capabilities provided by the secure overlay layer.

Securing Inbound Traffic

Securing inbound traffic is the same with sidecar or ambient, using either Istio network resources (e.g., Gateway and VirtualService) or Kubernetes Gateway resources. It ensures a smooth transition from sidecar to Istio ambient mesh without changing any Istio resources. Istio ambient mesh allows you to secure the connection between the Istio ingress gateway and the web-API service without a sidecar by simply including the web-API service to ambient.

Enforce L4 authorisation policies in Istio ambient mesh

Istio ambient mesh retains all the key features of a standard service mesh, including Zero Trust Security, which is crucial to allowing restricted access. Istio has always had Zero-Trust Security built in and enabled by default. We’ve made sure the Istio authorisation policy is the exact same policy for sidecar or sidecar-less architectures. We purposefully designed Istio APIs to remain the same to ensure a smooth transition from sidecar to Istio ambient mesh. This allows you to implement a zero-trust architecture at the network layer granting access to applicable DevOps, CloudOps and SRE teams, as and when required.

Looking forward to an Istio ambient mesh future

We’ve always believed in the future of Istio, which is why we dedicate so many engineering resources to both project contributions and project leadership roles. This contribution is the culmination of nearly a year of engineering effort that began internally before we joined forces with Google, after discovering that we were both working towards similar goals for Istio. My team and I played a significant role in all aspects of the project, with a specific focus on architectural flexibility, security and performance testing. But it doesn’t end there. We’re always interested in future collaborations and receiving feedback from users about how they use Istio and how we can continue to make the project better. This was one of the driving forces behind our decision to develop Istio ambient mesh. Now that the code is out there and available to the Istio community, we’re excited to see how this new architectural option for the Istio data plane evolves.