Service Meshes: The Next Big Challenge

Now that Kubernetes is on the cusp of mainstream adoption in the enterprise, one of the next big challenges IT organizations will need to contend with is determining what service mesh to embrace.

A service mesh provides functions such as service discovery, load balancing, encryption, authentication and authorization on top of a cluster based on Kubernetes. As the number of services built using containers start to multiply on a Kubernetes cluster, it quickly becomes apparent there is a need for a service mesh to bring some order to the potential communications chaos between different services running on Kubernetes clusters.

At the base layer of any service mesh is a proxy server. The most widely employed proxy server in Kubernetes environments is Envoy, which is being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

There are several service mesh platforms that provide a control plane on top of a proxy server to make it easier to manage, for example, application programming interfaces (APIs). There are four service mesh frameworks that are right now vying for dominance.

The best known is Istio, an open source service mesh developed in collaboration between Lyft, IBM and Google. Written in Go, Istio has now gained additional support, including most notably VMware and Red Hat. By default, Istio deploys on top of Envoy, but it can optionally also be deployed on top of proxy servers from NGINX.

An alternative to Istio is Linkerd, the first service mesh to ever be developed. Originally created by Buoyant, this open source service mesh is written in Scale and is intended to be deployed on multiple types of clusters. Buoyant also developed Conduit, an open source service mesh specifically optimized for Kubernetes environments.

The third major service mesh is Consul. Developed by HashiCorp, Consul relies on an agent-based model where each node in the cluster runs a Consul Client. This client maintains a local cache that gets updated from servers. All service communication APIs respond in microseconds, mainly because they don’t require any external communication.

Finally, a fourth major service mesh comes from Amazon Web Services (AWS). Also based on Envoy, AWS App Mesh is optimized specifically for the AWS public cloud. As the most widely employed public cloud, it’s only a matter of time before AWS App Mesh becomes more widely employed by organizations that have committed to deploying all their workloads on AWS.

It’s too early to say which of these platforms will ultimately become dominant. There’s certainly a lot of momentum behind Istio because of the amount of vendor support behind it. But as the performance and security challenges associated with employing service meshes, HashiCorp CTO Armon Dadgar says many enterprise IT organizations soon will want to consider all their options.

Regardless of the choice made, it’s now become increasingly apparent that beginning this year many more organizations will be wrestling with how to resolve the issues multiple service mesh platforms are designed to address.