Service Mesh: How to Manage Common Functionalities in a Microservice Architecture

Each microservice we build requires some component to be built apart from its core functionalities. As said, each service should have authentication & authorization, tracing, observability, retry, circuit breaking, service discovery, and so on. These functionalities are implicit and should be shipped along with the core business logic of the microservice. These components are essential to make the service secured, observable; and resilient.

In a typical microservice architecture, we end up having more than one microservice. That means, we just replicate these common functionalities across all these microservices. The below figure emphasizes what it looks like when we have multiple microservices with these common functionalities.

The above figure provides an overview of common functionalities in one domain. Big organizations address problems across multiple domains. That means these functionalities are replicated across all such services. In polyglot architecture, these functionalities are duplicated in various programming languages and frameworks. This leads us to have multiple flavors of the same aspects. This comes with maintenance overhead. Enhancing these functionalities across all these services requires more effort.

Can we group these functionalities in one place and enable each service to focus on its core business logic? 

This is where service mesh is very useful. Being a low latency and high throughput tool, it allows fast and reliable communication between containerized applications as well as with external applications. It provides support for all common functionalities we are talking about so far.

Service mesh is implemented using a sidecar pattern, providing a proxy for each instance of the service. It handles common functionalities which can be abstracted out from the service. In this pattern, direct communication does not happen between services, instead, the calls go through the sidecar proxy. The sidecar proxy delegates the calls to destinations served. This enables each service to remain unaware of other services and run in isolation.

Along with the sidecar, we should have an instance of front proxy. This front proxy works as an entry point. Sidecar and front proxy together build a reliable and high throughput mesh. Thus it enables each service to focus on its own functionalities. And avoid repetition of efforts and maintenance of common functionalities in polyglot architecture.

In a large and complex infrastructure where we have services across multiple domains, this pattern can be leveraged to have multiple meshes within a large mesh.

This approach enables each service to focus on its core business logic and all other responsibilities like traceability, observability, retry, rate limiting, service discovery; and load balancing is taken care of by the infrastructure layer. This ensures that efforts are not duplicated across multiple services and domains to do the same thing in polyglot architecture. This also reduces maintenance efforts of these common functionalities as these can also evolve independently both technologically and functionality-wise.

Abid H. Khan is part of the Group Architect, Distribution team at AppDirect. AppDirect is hiring! See our open positions.