Buoyant Survey Surfaces Service Mesh Shifts
A survey published this week finds more than a quarter (28%) of organizations have already swapped out the service mesh platform they initially adopted. Among those that have switched, 80% had been using open source Istio for Kubernetes now being advanced by Google.
The survey was conducted by Buoyant, the developer of the open source Linkerd service mesh, and polled 100 attendees of the recent KubeCon + Cloud Native Con North America event held last November.
It’s still early days as far as service mesh adoption is concerned. Nearly two-thirds of respondents (63%) say they have yet to deploy a service mesh in a production environment. Another 14% say they have been using one in a production environment for less than six months.
The top reason respondents give for employing a service mesh, however, does not appear to have much to do with managing application programming interfaces (APIs) in a cloud-native environment. Instead, more than half of respondents (58%) cite the need for end-to-end encryption.
Buoyant CEO William Morgan says one of the primary reasons organizations adopt Linkerd is to make it simpler to implement the mutual transport layer security (mTLS) protocol that is now being more widely used to authenticate connections. Linkerd includes a zero-configuration capability for implementing mTLS. IT organizations are adopting mTLS as part of larger zero-trust initiatives, notes Morgan.
Overall, survey respondents identified ease of use and installation (25%), the extent of feature set (20%), simplicity (10%) and resource consumption (10%) as the top criteria they consider for implementing a service mesh.
The technology initially emerged as a way to manage APIs at scale instead of relying on proxy software or an API gateway alone. Most are actually built on top of some type of proxy software. More recently, IT organizations have started to appreciate the programmable layer of abstraction that a service mesh creates above lower-level networking and security interfaces. That layer of abstraction makes those underlying services more accessible to developers.
The debate surrounding which to use revolves around two core issues. Service meshes like Linkerd are considerably lighter-weight than, for example, Istio. That makes them simpler for a developer to implement. Istio’s advocates argue that it’s only a matter of time before organizations will need the richer set of capabilities their preferred service mesh enables. Of course, the more robust the feature set of a service mesh, the more likely it is to require an IT operations team that has been trained to implement and manage it.
The other issue is the degree to which the service mesh needs to be used across both a cloud-native application environment and legacy monolithic applications. Neither Istio nor Linkerd is designed to support legacy applications. As a result, many organizations are evaluating alternative platforms such as Kuma. Both Linkerd and Kuma are being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). There is also a proprietary Consul service mesh from HashiCorp that can be either locally installed or accessed via a cloud service.
Regardless of the approach, it’s clear that service mesh will soon be more widely deployed in production environments.
