The classic way of communication
Classic service architectures use a centralized approach. As result, applications interact with well-known end points. But applications do not communicate with each other in direct manner. A frequent used example are web applications. The web browser interacts with a static host name. It is not aware of underlying services. And it also does not know, how many underlying instances exist. The next service call may hit a different instance. On next call the DNS may return a different ip address. Or the target service routes the request to a different worker process. Independent of technology caller talks to other via an exchange. In addition, caller implements no logic for routing.
How service mesh communication works
At service mesh architecture services communicate in direct manner. For this reason the calling service knows address of target service. In addition, the caller knows a list of target services. So caller does routing by choosing and selecting a preferred target service. As result, the calling service has more complex business logic. The connections between services build a mesh.
More complex client in service mesh
As mentioned in last paragraph, calling clients are more complex. First, a client must know a list of applicable target services. Note, during run time number of targets may vary. Second, client must implement a kind of routing strategy to spread load. Bad routing may cause performance issues. All things considered, clients require a service discovery and routing strategy. This is the price for service mesh.
Client side load balancing
On the other side there are some benefits. So calling service has special knowledge to each target service. How long took the last service call? Are there faster and slower services? Does a target permanently fail? All this information may influence routing strategy. In this way intelligent clients use powerful load balancing strategies.
Service mesh and scalability
In centralized routing this special knowledge is not applicable to routing. Here routing is independent of calling client. In service mesh routing strategy may differ from client to client. Decentralized nature of service mesh offers better scalability. In opposite, centralized architecture concentrate traffic to single points. A growing number of clients cause increasing traffic. In this way routing through same network segments may reach bandwidth limits. In service mesh the point-to-point connections use network more efficiently.
Conclusion
If you are already using service mesh, you understand benefits. If you are working on microservices, pay close attention to this topic. And if you are not yet decided yet, check out the recent Gartner and IDC report on micorservices. They say that service mesh will become mandatory for organizations running microservices in production.
Choose appropriate framework to implement a service mesh. For kubernetes based implementations project istio is means of choice. In java world are many cloud native libraries. For example, spring cloud is a great compilation of frameworks. Spring buzzwords are service discovery and ribbon client side load balancing. Spring allows operation in legacy environments as well as in cloud native (e.g. k8s) environments.