Service Mesh Is Super Hot. Why?
One of the hottest technologies of the year is service mesh. But what even is it?
Part of the challenge is that the specific boundaries of what defines a service mesh are still being worked out. We’re still at the very early stages of the technology where a lot of things are in flux, which makes it tricky to wrap your brain around.
You can think of a service mesh as the network infrastructure of microservices. It’s software that enables all the microservices that make up an application to talk to each other. Just like physical networks, a service mesh has a data plane that moves all the data around, and a control plane that enables you to configure and monitor the service mesh.
Why have a service mesh? Without one, microservices applications need to handle a lot of common tasks themselves: how to find service endpoints, where the service is currently running, how to authenticate services, deciding who has access to what services encryption key management, etc. It’s a lot of work when you have a lot of microservices.
“The way to solve this is to write a library for every language that you then have to build into every application, or you try to shift as much as possible into an infrastructure component,” said Matt Klein, Envoy maintainer and ‘plumber and loaf balancer’ at Lyft.
With a service mesh, all these tasks can be delegated to infrastructure that takes care of it for you, which makes writing applications easier. It also provides a layer of abstraction and indirection that provides flexibility; if a service is moved to a different place in the mesh (say onto a different server in the cluster) you don’t have to rewrite or recompile your application. The service mesh takes care of the repetitive, boring work for you.
However, there’s still a lot of complexity involved in service mesh approaches to problems, mostly in the control plane, which is why we’re seeing so many competing approaches to service mesh at the moment. There’s Istio (backed by Google, IBM, and Lyft), Hashicorp’s Consul Connect, linkerd, nginMesh from NGINX, and a plethora of other options. In the data plane, a majority of services are based on the open source Envoy.
“Envoy has become incredibly popular,” said Klein, “Almost everyone is converging on using Envoy as a data plane.” Envoy has a reputation for stability and performance, and it has a configuration API that provides a relatively clean separation of data plane from control plane. This makes it ideal for building upon to handle the more complex control plane logic, which is the approach taken by Istio, Consul Connect, and nginMesh.
“It’s very hard to build a control plane that rules them all,” says Klein. “There’s no way to unlink the control plane from how people deploy their software.” Different people find different benefits from how they choose to deploy software, which creates a need for variety in control planes. Unless a broad consensus develops around how software deployment should be done, consolidation of service mesh control planes will be minimal.
I recommend reading Klein’s 2017 article on service mesh control planes and data planes to get a better idea of the principles at work here.
There’s also complexity in where the boundary of a service mesh is. The consensus so far seems to be that a service mesh is for so-called east-west traffic within a cluster, while north-south traffic coming into and out of a cluster is seen as a separate component, usually called an API gateway or ingress proxy. However this view is changing as more functionality is built into service meshes, with some working to include both east-west and north-south traffic within their capabilities.
Service mesh is a fast-moving part of the already fast-paced cloud native world. For the majority of organisations it’s something to be aware of, but unless you’re investing heavily in cloud-native microservices style development, it’s not something you need to know much more about… yet.
For those who enjoy staying up-to-date with what’s happening at the bleeding edge, service mesh is something to keep an eye on in the year ahead.
This article first appeared in Forbes.com here.
HashiCorp Adds Support For VMware vCloud Air
If you’ve been watching the developer/enterprise overlap that is in full swing, you may well have heard of Vagrant, and its eponymous vagrant up command. What you may not know (as I did not until this week) is that the company behind Vagrant is called HashiCorp, and they have a lot of other tools they want you to use.
HashiCorp Completes Portfolio of DevOps Tools with Otto and Nomad
HashiCorp today announced the availability of the final two parts of their suite of DevOps workflow tools, Otto and Nomad, completing a multi-year journey to provide a set of tools for developers and operators of the modern datacenter.