The sidecar design pattern is gaining popularity and wider adoption within the community. Building a Microservice architecture that is highly scalable, resilient, secure and observable is challenging. The evolution of Service Mesh architecture has been a game changer. It shifts the complexity associated with the Microservice architecture to a separate infrastructure layer and provides lot of functionalities like Load Balancing, Service Discovery, Traffic Management, Circuit Breaking, Telemetry, Fault Injection and more.

Read my earlier blog to understand the concept of Service Mesh, why it is needed for your cloud native applications and the reason of its popularity –
The Rise of Service Mesh Architecture

What is a Sidecar Pattern?

Segregating the functionalities of an application into a separate process can be viewed as a Sidecar pattern. The Sidecar design pattern allows you to add a number of capabilities to your application without the need of additional configuration code for 3rd party components.

As a sidecar is attached to a motorcycle, similarly in software architecture a sidecar is attached to a parent application and extends/enhances its functionalities. A Sidecar is loosely coupled with the main application.

Let me explain this with an example. Consider that you have 6 microservices talking with each other in order to determine the cost of a package.

Each microservice needs to have functionalities like observability, monitoring, logging, configuration, circuit breaker and more. All these functionalities are implemented inside each of these microservices using some industry standard 3rd party libraries.

But think again, is this not redundant? Does it not increase the overall complexity of your application? What happens if your applications are written in different languages – how do you incorporate the 3rd party libraries which are generally specific to a language like .Net, Java, Python etc.

Benefits of using a Sidecar Pattern —

• Reduces the complexity in the microservice code by abstracting the common infrastructure related functionalities to a different layer.
• Reduces code duplication in a Microservice architecture since you do not need to write configuration code inside each microservice.
• Provide loose coupling between application code and the underlying platform.

How does the Sidecar Pattern work?

The Service Mesh layer can live in a Sidecar container that runs alongside your application. Multiple copies of the same sidecar are attached alongside each of your applications.

All the incoming and outgoing network traffic from an individual service flows through the sidecar proxy. As a result, the Sidecar manages the traffic flow between microservices, gather telemetry data and enforces policies. In a sense, the service is not aware of the network and knows only about the attached sidecar proxy. This is really the essence of how the Sidecar pattern works – it abstracts away the network dependency to the sidecar.

Inside a service mesh, we have the concept of a Data Plane and Control Plane —

• The Data Plane responsibility is to handle the communication between the services inside the mesh and take care of the functionalities like Service Discovery, Load Balancing, Traffic Management, Health Check etc.
• The Control Plane responsibility is to manage and configure the sidecar proxies to enforce policies and collect telemetry.

In the Kubernetes and Istio world, you can inject the sidecars inside a pod. Istio uses the sidecar model with Envoy as the proxy.

Envoy from Lyft is the most popular open source proxy designed for cloud native applications. Envoy runs along side every service and provides the necessary features in a platform agnostic manner. All traffic to your service flows through the Envoy proxy.
https://www.envoyproxy.io

The shift from Monolith to Microservices has enabled organizations to deploy applications independently and at scale. In a Container and Kubernetes world, the Sidecar design pattern is more compatible. The Sidecars abstract the complexity away from the application and handle the functionalities like Service Discovery, Traffic Management, Load Balancing, Circuit Breaking etc.

Learn more about Sidecar pattern here —
https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar

Categories: Architecture, Istio, Kubernetes, Microservices, Service Mesh