Sidecar design pattern analysis in microservices

Sidecar design patterns have become increasingly popular and more widely adopted in the community. Building microservices architectures that are highly scalable, resilient, secure, and observable can be challenging. The evolution of the Service Mesh architecture has changed the game. It reduces the complexity associated with microservices architecture and provides many features such as load balancing, service discovery, traffic management, fusing, telemetry, fault injection, and more.

Read my previous blog to understand the concept of Service Mesh, why cloud native applications need it, and why it’s popular — the rise of Service Grid architectures.

What is Sidecar mode

Dividing the functionality of an application into separate processes can be considered a Sidecar pattern. The Sidecar design pattern allows you to add a lot of functionality to your application without the additional configuration and code of third-party components.

Just as Sidecar is connected to a motorcycle, similarly in software architecture, a Sidecar application is connected to a parent application and extends or enhances its functionality. Sidecar applications are loosely coupled to the main application.

Let me explain with an example. Imagine if you had six microservices communicating with each other to determine the cost of a package.

Each microservice needs to have observability, monitoring, logging, configuration, circuit breakers, and more. All of these functions are implemented in each microservice based on some industry-standard third-party libraries.

But on second thought, isn’t that superfluous? Doesn’t it add to the overall complexity of the application? What happens if your application is written in a different language – how to merge third-party libraries that are specific to.NET, Java, Python, etc.

Advantages of using the Sidecar pattern

• Reduces the complexity of microservice code by abstracting the common infrastructure associated with functionality into a different layer.
• Because you no longer have to write the same third-party component configuration files and code, you can reduce code duplication in the microservices architecture.
• Reduce coupling between application code and the underlying platform.

How does Sidecar mode work

The service grid layer can exist in a Sidecar container that runs with the application. Each application is accompanied by a copy of the same Sidecar.

All incoming and outgoing network traffic from a single service flows through the Sidecar agent. As a result, Sidecar can manage traffic between microservices, collect telemetry data and enforce policies. In a sense, the service does not know the entire network, only the additional Sidecar agents. This is actually the essence of how the Sidecar pattern works — abstracting network dependencies into SidecArs.

In the service grid there are concepts of data plane and control plane:

• The data plane is responsible for handling communication between services within the grid and is responsible for service discovery, load balancing, traffic management, health check and other functions.
• The control plane is responsible for managing and configuring Sidecar agents to enforce policies and collect telemetry.

In the world of Kubernetes and Istio, you can inject Sidecar into pods. Istio uses Sidecar models with an Envoy as proxies.

Envoy from Lyft is the most popular open source agent designed for cloud-native applications. Envoy runs on each service and provides the necessary functionality in a platform-independent way. All service traffic flows through an Envoy proxy.

www.envoyproxy.io

The shift from monolithic services to microservices enables organizations to deploy applications independently and on a large scale. In the Container and Kubernetes world, the Sidecar design pattern is more appropriate. Sidecar abstracts complexity from applications and handles service discovery, traffic management, load balancing, circuit breakers, and more.

Learn more about the Sidecar pattern here:

Docs.microsoft.com/en-us/azure…

This article reprinted from: www.servicemesher.com/blog/sideca…