Let’s try to further understand the service interactions and responsibilities which are shown in figure 3.

Business Logic

The service implementation should contain the realization of the business functionalities of a given service. This includes, logic related to it’s business functions, computations, integration with other services/systems(including legacy, proprietary and SaaS) or service compositions, complex routing logics, mapping logic between different message types etc.

Primitive Network Functions

Although we offload most of the network functions to service mesh, a given service must contain the basic high-level network interactions to connect with the service mesh/side-car proxy. Hence, a given service implementation will have to use a given network library(unlike the ESB world, where you just have to use a very simple abstraction)to initiate network calls (to service mesh only). In most cases, microservices development framework embed the required network libraries to be used for these functions.

Application Network Functions

There are application functionalities which tightly coupled to the network, such as circuit breaking, timeouts, service discovery etc. Those are explicitly separated from the service code/business logic, and service mesh facilitate those functionalities out of the box.

Most of the initial microservices implementations simply ignore the gravity of the network functions offered from a central ESB layer, and they implemented all such functionalities from scratch at each microservice level. Now they have started realizing the importance of having a similar shared functionality as a distributed mesh.

Service Mesh Control Plane

All service mesh proxies are centrally managed by a control pane. This is quite useful when supporting service mesh capabilities such as access control, observability, service discovery etc.

Functionalities of a Service Mesh

As we have seen earlier, the service mesh offers a set of application network functions while some (primitive) network functions are still implemented the microservices level itself. There is no hard and fast rule on what functionalities should be offered from a service mesh. These are the most common features offered from a service mesh.

• Resiliency for inter-service communications: Circuit-breaking, retries and timeouts, fault injection, fault handling, load balancing and failover.
• Service Discovery: Discovery of service endpoints through a dedicated service registry.
• Routing: Primitive routing capabilities, but no routing logics related to the business functionality of the service.
• Observability: Metrics, monitoring, distributed logging, distributed tracing.
• Security: Transport level security (TLS) and key management.
• Access Control: Simple blacklist and whitelist based access control.
• Deployment: Native support for containers. Docker and Kubernetes.
• Interservice communication protocols: HTTP1.x, HTTP2, gRPC

Service Mesh Implementations

Linkerd and Istio are two popular open source service mesh implementations. They both follows a similar architecture, but different implementation mechanisms. You can find a very good comparison between these two service mesh implementations at [1].

Service Mesh — Pros and Cons

Let’s have a quick look at the pros and cons of service meshes.

Pros

• Commodity features are implemented outside microservice code and they are reusable.
• Solves most of the problems in Microservices architecture which we used to have ad-hoc solutions: Distributed tracing, logging, security, access control etc.
• More freedom when it comes to selecting a microservices implementation language: You don’t need to worry about whether a given language supports or has libraries to build network application functions.

Cons

• Complexity: Having a service mesh drastically increase the number of runtime instances that you have in a given microservice implementation.
• Adding extra hops: Each service call has to go through an extra hop(through service mesh sidecar proxy).
• Service Meshes address a subset of problems: Service mesh only address a subset of inter-service communication problems, but there are a lot of complex problems such as complex routing, transformation/type mapping, integrating with other services and systems, to be solved at your microservice’s business logic.
• Immature: Service mesh technologies are relatively new to be declared as full production ready for a large scale deployments.

Conclusion

In summary, service mesh addresses some of the key challenges when it comes to the realization of microservice architecture. It gives you more freedom to select diverse set of microservices implementation technologies as well as to focus more on business logic rather investing more time on network functions between services. However, service mesh won’t solve any of the business logic related or service integration/composition related problems.

Update: “Service Mesh vs API Gateway”?

Please check the articles API Gateways vs Service Mesh for more further information on this.