The practical enablers for this are a restructure of the way that development teams work (adopting good CI/CD and GitOps practices, for example) as well as a restructure of the applications they own. But both are easier said than done.

We know that many development teams experience delayed or slowed down application deployments into production. This can be for a variety of reasons, from application networking or security concerns, to complexity caused by the use of containers and Kubernetes.

The increased pressure to ship better features at a higher volume, to improve the customer experience, and do all of this faster requires flexibility, automation, and abstraction.

A key technological development enabling this is the evolution of a microservices approach, and the use of service mesh to manage microservices-heavy environments as the number of services explodes.

Our research shows that 85% of companies are now modernising their applications into a more nimble set of microservices. This is producing results for many microservices adoptees: 56% of organisations with at least half of their apps on microservices architectures have release cycles that are daily or more frequent.

While this is promising, microservices is far from a mature domain - and there are teams that are yet to figure out how to optimise and manage a growing sprawl of services in their environments.

Organisations are adopting service mesh architectures to solve this management problem.

Service mesh, which controls service-to-service communication over a network, offers a solution for managing application reliability, security, and observability along with application traffic monitoring and management.

A large majority of companies building apps on microservices architecture exhibit behaviours that suggest great value in an appropriate and purposeful deployment of a service mesh. Whether it is service-spanning requirements or a general difficulty managing the volume and diversity of services in their microservices architecture, organisations' needs for the capabilities of a service mesh are manifest.

However, as with cloud-native management technologies to emerge before it, service mesh is still in what might be termed a "foggy visibility" stage of its evolution and take-up. While there are some leading organisations that are seeing benefits, the technology still hasn't reached a stage of mass adoption.

In the footsteps

Service mesh is treading a similar take-up and growth trajectory to that once seen with Kubernetes for container orchestration.

Six years ago in Australia, containerisation as we know it today was still nascent, with very few early adopters and no clear choice of containerisation software, let alone software to then manage and orchestrate the containerised workloads.

But six years is a long time in software development. One of the big changes in that time is the emergence and cementing of Kubernetes as the de facto standard for managing containerised environments.

In the early days of Kubernetes, it was more hype than reality. It has moved on from that, and recently "crossed the chasm" into popular use, according to the State of Cloud Native Development Report by CNCF.

Our research shows 64% of companies reporting usage of Kubernetes in production at some level, and a further 31% evaluating Kubernetes. Of those using Kubernetes in production, a majority (53%) now report at least half of their production workloads running on Kubernetes.

Just like Kubernetes and containers, microservices are not a panacea if you don't know what you're doing. Leading organisations are realising the promise of microservices-based architectures in part through an adoption of service mesh.

The rise of service mesh

Most companies that are aware of service mesh use it and agree that a service mesh provides value, but the value is extremely varied among organisations and groups.

Improvements to application reliability and security – the two most-reported benefits – don't even receive top marks from a quarter of organisations.

This is a common story with rapidly evolving technologies organisations are newly deploying. Teams see value in many places, but the value varies by application architecture, organisational experience with underlying technologies, and the different teams within the organisation, each with their own requirements and goals.

Still, as more adopters emerge and start achieving benefits, service mesh adoption is increasing. In the past two years, service mesh adoption has grown from 30% (as reported by CNCF in 2020) to 49% in our study, with a further 38% evaluating a service mesh for adoption.

No service mesh has all the features an organisation needs. For the most part, organisations using either Istio or non-Istio solutions report similar benefits, although leaders prefer an Istio-based service mesh by almost a three to one margin.

In the end, there is no single choice for service mesh. What matters is knowing what you want to achieve with it and considering what you may want it to do for you in the future.