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.