The maintainers of the open source Istio service mesh project are preparing a beta release of the lighter-weight Ambient edition of the platform that fulfills a commitment to eliminating the need to rely on container sidecars to deploy it.

Version 1.22 version of Ambient will add support for shared node proxies and optional Layer 7 per-workload proxies that, by eliminating the need for container sidecars, can reduce memory and CPU usage by more than 90% in many instances.

Originally developed by Google and Solo.io, the Ambient edition is an effort to make Istio more accessible to organizations that previously would have shied away from it because of its size and complexity. As part of that effort, Ambient makes use of a proxy developed by Istio maintainers versus the previous iterations of Istio that are based on open source Envoy proxy software. Solo.io is now supporting Ambient in its curated edition of Istio running on the Amazon Elastic Kubernetes Service (Amazon EKS).

The separation between the L4 secure overlay layer and L7 processing layer that Ambient provides allows incremental adoption in contrast to the binary injection of sidecars previously required. IT teams can, for example, start with an layer that only provides cryptographic identity, simple L4 authorization policy and telemetry.

Lin Sun, director of open source for Solo.io, said The Ambient edition is gaining early traction with organizations that are especially interested in applying the mTLS cryptography protocol to authenticate network traffic between services using a lightweight node proxy called the zero-trust tunnel, or ztunnel. Complex L7 functions such as retries, traffic splitting, complex load balancing, and observability collection can be added as needed.

IT teams that still prefer to deploy Ambient using sidecars will still be able to do so, but the forthcoming edition of Ambient will provide a version of the service mesh that is much simpler to manage.

It’s not precisely clear when organizations will require a service mesh as an alternative to using either proxy software or a gateway for managing application programming interfaces (APIs) but the appeal of Istio as a service mesh that can be deployed in Kubernetes environments has thus far been limited to large enterprises. The one thing that is clear is that as IT organizations deploy more microservices at scale, the need for a service mesh becomes more apparent.

There is, of course, no shortage of options when it comes to service meshes, but Solo.io has been using Istio as a foundation for integrating a range of IT services. For example, the company this month added an internal developer portal (IDP) based on the open source Backstage platform originally developed by Spotify.

Previously, Solo.io integrated Istio with Cilium, an open source network virtualization overlay that has been gaining traction within IT organizations deploying distributed applications across multiple Kubernetes clusters.

Ultimately, as networking services become more programmable the historic divide that has existed between DevOps and network operations teams is continuing to narrow. The challenge now is determining which of those teams is best suited to managing those services as the management of IT environments continues to evolve.