The Growing Appreciation for Service Mesh

A Buoyant survey published today finds a third (33%) of respondents have either deployed a service mesh in a production environment or are close to completing deployment. Another 62% say they are still exploring their options, with 63% of respondents using or considering Linkerd or Istio, and 31% considering both open source service meshes. The survey polled 100 attendees of the recent KubeCon + Cloud Native Con Europe conference.

Additionally, the survey also makes it clear that security is the biggest driver of service mesh adoption, at least for the time being. Nearly two-thirds of respondents (65%) identify end-to-end encryption as the biggest driver of adoption. The next-biggest driver of adoption is observability (41%) followed closely by gRPC load balancing (40%), the survey finds.

Among respondents that have yet to implement a service mesh, the most common hindrance to application or business operations was the lack of observability and security. The biggest obstacle to adoption respondents cite is complexity (60%). The top features respondents look for in a service mesh were observability, end-to-end encryption/mutual TLS (security), integration with multiple and external clusters and simplicity/ease of use.

Buoyant CEO William Morgan says the survey results make it clear that most organizations are still in the early stages of adoption. While service meshes provide a layer of abstraction that makes managing multiple application programming interfaces (APIs) simpler, the survey makes it clear that more immediate security concerns are driving initial adoption, he notes.

In general, interest in service meshes is on the rise following what Morgan describes as an initial “bad rap” due to their complexity. As more organizations deploy Kubernetes clusters in production environments, they are starting to appreciate the need for the higher level of abstraction that masks the underlying complexity of a cloud-native application environment from developers, he adds.

It is still not clear which service meshes will ultimately prevail; in some organizations, it’s becoming more common to adopt both Istio and Linkerd. Larger enterprises that have centralized IT teams tend to look favorably on the more feature-rich Istio platform while individual departments might tend to gravitate to the lighter-weight Linkerd option.

Service meshes initially emerged as an alternative to proxy software or an API gateway to manage APIs at scale. More recently, however, IT organizations have started to appreciate the programmable layer of abstraction that a service mesh creates above lower-level networking and security interfaces. At the same time, platform management teams are starting to emerge within IT teams that are squarely focused on simplifying the management of application development and deployment environments.

Regardless of approach, the way security and networking services are managed is about to evolve. In fact, service meshes are likely to play a key role in further integrating network and security operations into DevOps workflows. In fact, while the motivations for deploying a service mesh may vary, it may only be a matter of time before they become much more commonly deployed across distributed computing environments that reach from the cloud to the network edge.

Mike Vizard

Mike Vizard is a seasoned IT journalist with over 25 years of experience. He also contributed to IT Business Edge, Channel Insider, Baseline and a variety of other IT titles. Previously, Vizard was the editorial director for Ziff-Davis Enterprise as well as Editor-in-Chief for CRN and InfoWorld.

Mike Vizard has 1615 posts and counting. See all posts by Mike Vizard