.svg){kind=small}
Sep 29, 2022
As the company that coined the service mesh term, we are always keenly interested in understanding where engineers are at in their service mesh adoption. That's why, after surveying KubeCon L.A. attendees last October, we decided to do the same in Valencia. And just as in L.A., we gained some fascinating insights. Here's a snapshot:
Read on for more!
We conducted a survey at KubeCon EU to get a snapshot of what’s driving service mesh deployments, where teams are in their adoption process, and what’s holding them back. Of 100 survey respondents over half (55%) were platform, DevOps, or SRE professionals, 21% were architects, and 9% were developers.
To get a bigger picture of the state of the service mesh, we compare the results from our KubeCon survey with the latest CNCF service mesh micro-survey (published May 2022). We explore where they overlap, where they diverge, and discuss possible reasons.
Among respondents to Buoyant’s KubeCon survey, only 33% said they have deployed a service mesh in production or are on their way to production, with 62% actively exploring options. Among CNCF respondents, though, 60% say that they are already running a service mesh in production! This is a big difference, and worth a closer look.
We believe that the discrepancy is likely due to the two surveys reaching different audiences. The CNCF survey was sent outside of KubeCon, likely to people employed at companies that are more "cloud native mature" and therefore more likely to have already adopted a service mesh. At KubeCon it’s a different story: 65% of the attendees at Valencia were first-timers, so presumably much newer to the cloud-native world. Both surveys are probably accurately reporting on their audience, but they’re not the same audience: a true picture of service mesh adoption is probably somewhere between the two extremes. Overall, this leaves us believing that service mesh adoption is on the rise, but that it still has quite a way to go.
The biggest driver of service mesh adoption for KubeCon respondents is end-to-end encryption (65%). That's up from 58% in our KubeCon NA 2021 survey. The security focus is even more pronounced in the CNCF survey with 79% of respondents naming security as the key driver. This growing emphasis on security is also supported by what we hear over and over again from the community.
Next, 41% of KubeCon and 78% of CNCF respondents listed observability as the second most important driver, followed by 62% traffic management (CNCF) and 40% gRPC load balancing (KubeCon). One interesting point here is that CNCF respondents tended to choose more options as drivers, while KubeCon respondents tended to have a narrower focus on just a few drivers. This may indicate that more mature users understand that a service mesh can deliver multiple kinds of benefits to their organizations, where the less-mature companies tend to focus on immediate pain.
With Linkerd treating all three of security, observability, and reliability as critical features, it’s no surprise that it is a top choice for managing cloud-native infrastructures and application development.
Among KubeCon attendees running a service mesh in production, Linkerd and Istio were the frontrunners: 63% of KubeCon respondents are using or considering each of those service meshes. Here again, we see a difference compared to the CNCF survey which states that 73% of production users use Linkerd with only 34% using Istio.
Two factors likely play a role in these differences. The first, again, could be maturity: perhaps differences in cloud native maturity might affect which service mesh is in use. This is an interesting area that we’ll be digging into in future surveys!
The second is a bit more subtle: the KubeCon survey collapsed “which service meshes are you using” and “which service meshes are you considering” into a single question. We'll separate this into two questions next time, but in the meantime, some respondents may be using one while considering another (31% of respondents selected both Linkerd and Istio). It is worth noting that in our 2021 survey, 28% of respondents reported that they had switched from one service mesh to another as their deployments matured. Of those, 80% switched from Istio to another service mesh.
60% of KubeCon respondents said complexity prevented them from adopting a service mesh. That is up from 25% in our KubeCon NA 2021 survey which stated that complexity and time investment were doing so. The CNCF survey asked participants about their main non-technical challenges which include: a shortage of engineering expertise and experience (47%), architectural and technical complexity (41%), and lack of guidance, blueprints, or best practices (36%).
Note that KubeCon and CNCF respondents were asked slightly different questions. While 60% of KubeCon respondents said that complexity was preventing them from adopting a service mesh, 41% of CNCF respondents stated that complexity was an actual challenge. The implication here is that KubeCon respondents are not yet running a mesh, while the more cloud-mature CNCF respondents are already running a mesh in production — and organizations actually running a mesh are more likely to have realized that a service mesh implementation doesn't have to be complex , even though complexity still remains a concern. Looking further at the CNCF data, we see that of the 60% who are running a service mesh in production, 73% run Linkerd while 34% run Istio — so it may be that fewer production users feel complexity is an issue because more are using Linkerd, a service mesh known for simplicity and reliability.
The fact that some respondents selected both Linkerd and Istio may also indicate that some respondents are in transition from one to the other — and here again, over half (52%) of KubeCon respondents pointed to complexity as the reason for switching. This very much aligns with the perceived challenges mentioned above. Service meshes are often associated with complexity although they don't have to be. By selecting a service mesh that focuses on core service mesh features — security, observability, and reliability — users can avoid adding another complex technology layer on top of an already complex infrastructure. Complexity opens up opportunities for human error, so when it comes to security, simplicity is key. Given that we found that security is the main driver for service mesh adoption, it is no surprise that complexity is also the main reason why users switch.
The top features that KubeCon respondents were looking 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.
For those KubeCon respondents who haven’t implemented a service mesh, the most common hindrance to application or business operations was the lack of observability and security, with a special shoutout to mutual TLS being effectively impossible without a service mesh.
Looking at both of these surveys, we’re able to get a glimpse into the attitudes and motives within the cloud native and Kubernetes communities. It is clear that service meshes are still a relatively new technology, but also that meshes are coming to be widely recognized as providing critical capabilities like security, reliability, and observability to adopters of cloud-native technologies.
At the same time, it is also clear that the biggest single perceived challenge to more widespread adoption of service meshes is complexity. We're not surprised to see that—the service mesh space is notorious for its complexity—and it reinforces Linkerd's laser-like focus on simplicity, which is at the core of Linkerd's design principles and informs every engineering and product decision we make. The results of this survey only further bolster our commitment to delivering world-class security and reliability to Kubernetes applications, without unnecessary complexity and bloat.
A complete guide to everything the modern enterprise architect needs to know about service meshes, including mutual TLS, zero trust security, eBPF, sidecars, and more.
.svg)