It's a fair question. Service meshes are a relatively recent development, and there aren't many papers on them, despite rapid adoption in industry (e.g. many large systems use a service mesh, and AWS App Mesh is in general release as of last year). This is a decent survey paper: https://ieeexplore.ieee.org/document/8705911.
Service meshes are intended to address some of the operational complexity of running microservices. To take Morgan's definition: "A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application."
To answer your question briefly, a service mesh is not a completely brand new thing, the pattern seems a natural improvement to having a set of SDKs (like Twitter's Finagle) and other things tying an SOA together. Consistency in an SOA is pretty valuable, and separating infrastructure logic (like retries, service discovery) from application logic is pretty nice too. Whether the improvement has been significant, I'd recommend searching for "service mesh" and you'll find some talks describing use cases.
What I have found tricky is finding critical analysis of service meshes beyond "do we need this" (i.e. what are service meshes missing, does the pattern give rise to other opportunities), but this should come as more research is done in the area.
Another perspective than what BillFranklin wrote above (which is still a great answer) when compared to an internal load balancer, which is what you’d traditionally have to route internal traffic otherwise:
* typically mTLS is provided and abstracted away for applications (traffic between services is now authenticated and encrypted)
* no single point of failure in the same way
* no traffic bottleneck or needing to scale the LB (e.g. limited to bandwidth of what LB can handle)
* typically integrates natively with your existing service discovery/control plane (kubernetes/consul/nomad)
Comments
What real world problem does this solve that couldn't be as well solved before? Is the improvement significant?
This is a good starting point to your question, from William Morgan who's attributed with coining the term service mesh: https://buoyant.io/service-mesh-manifesto/.
It's a fair question. Service meshes are a relatively recent development, and there aren't many papers on them, despite rapid adoption in industry (e.g. many large systems use a service mesh, and AWS App Mesh is in general release as of last year). This is a decent survey paper: https://ieeexplore.ieee.org/document/8705911.
Service meshes are intended to address some of the operational complexity of running microservices. To take Morgan's definition: "A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application."
To answer your question briefly, a service mesh is not a completely brand new thing, the pattern seems a natural improvement to having a set of SDKs (like Twitter's Finagle) and other things tying an SOA together. Consistency in an SOA is pretty valuable, and separating infrastructure logic (like retries, service discovery) from application logic is pretty nice too. Whether the improvement has been significant, I'd recommend searching for "service mesh" and you'll find some talks describing use cases.
What I have found tricky is finding critical analysis of service meshes beyond "do we need this" (i.e. what are service meshes missing, does the pattern give rise to other opportunities), but this should come as more research is done in the area.
Another perspective than what BillFranklin wrote above (which is still a great answer) when compared to an internal load balancer, which is what you’d traditionally have to route internal traffic otherwise:
* typically mTLS is provided and abstracted away for applications (traffic between services is now authenticated and encrypted)
* no single point of failure in the same way
* no traffic bottleneck or needing to scale the LB (e.g. limited to bandwidth of what LB can handle)
* typically integrates natively with your existing service discovery/control plane (kubernetes/consul/nomad)