Service meshes are the latest, greatest thing in the microservices and containers world. Let’s take a look at what a service mesh is and how they are being used to improve microservices architectures.
If you’re wondering what, exactly, a service mesh is, you’re not alone. The term is relatively new, and there remains some difference of opinion in defining what a service mesh is.
The folks at Buoyant offer what is probably the most popular definition of service mesh. To them, it is “a dedicated infrastructure layer for making service-to-service communication safe, fast and reliable.”
That is exactly the type of solution provided by Linkerd, an open source proxy layer developed by Buoyant as part of the CNCF. In this definition, a service mesh is a specific type of software tool that you add to your stack to handle service communication.
Meanwhile, Istio developers define it as the “network of microservices” that comprise an application. That’s a more generic, broader definition than the Buoyant one. It doesn’t necessarily imply that a service mesh is an external tool or platform that you integrate into your stack. It could be something you implement yourself.
In other cases, service meshes are defined in terms of what they are not: an API gateway or proxy. The idea here is that it is a solution of some kind for service communication that is more sophisticated than the API gateways that traditionally have been used to manage services.
The bottom line: There is not yet total consensus about what a service mesh is or what makes it different from traditional means of facilitating interactions between services.
Service Meshes and the Future of Microservices
There is, however, general agreement that conventional strategies for orchestrating microservices are not working, and that something better is needed.
That something is a service mesh.
Whichever approach you take to thinking about what exactly constitutes a service mesh and how it is implemented, in all cases it allows developers to overcome one of the largest remaining barriers to microservice application deployments: The need for a way to streamline service-to-service communication.
In this sense, they represent the next leap forward for microservices. They will enable more scalability, and make it feasible to break monolithic apps into not just several services, but many dozens, if desired.