This content originally appeared on Bits and Pieces - Medium and was authored by Nishu_Dissanayake
Handling Cross-Cutting Concerns in Microservices: The Sidecar Pattern
How to deal with cross-cutting concerns in Microservice architecture
Microservices have brought a new set of challenges due to their distributed nature. One such challenge is handling cross-cutting concerns such as logging, authentication, authorization &, etc.
In this article, let’s look at how we can use the Sidecar pattern to address these challenges with Microservices.
Sidecar Pattern: An Overview
Sidecar pattern is about separating cross-cutting operations from a Microservice to reduce its internal complexity.
For example, suppose there are several modules that we want to execute for each Microservice like logging, messaging, monitoring, etc. But these operations are far more similar, and repeating the code for handling these operations in each Microservice isn’t worth it.
In such instances, we can use the Sidecar pattern to overcome this. As the name suggests, the Sidecar pattern allows us to execute the components like logging, monitoring separately but still attached to the primary service.
It is just like how a Sidecar is attached to a motorcycle.
The Sidecar provides the supporting features to its parent application and, in turn, reduces the overall complexity.
It is also known as “Decomposition pattern” and “Sidekick pattern.”
When to use the Sidecar Pattern?
There are many instances where we can use the Sidecar pattern in a Microservice architecture. Some of the scenarios are,
- When a different team owns a component and your team expects to use it in your Microservice.
- When a Microservice uses multiple frameworks and languages.
- When you need to control the resource limits of a particular component.
- When you need an optimized way of handling cross-cutting concerns of Microservices with least network overheads.
Different Use Cases of the Sidecar Pattern
Let’s look at some of the use cases where we can use the Sidecar pattern.
- Ambassador Sidecar — The primary application uses an ambassador to handle the connectivity operations like login, routing, etc. The ambassador is executed as a Sidecar. Find more details here.
- Offload Proxy — In a Microservice instance, a Proxy like NGINX is placed for handling static files serving in the service.
- Managing the Proxy Caching — Another Sidecar can monitor the environment and clear the cache when the cache needs to be invalidated.
- Adding HTTPS to a Legacy Service — We can add a Sidecar proxy to receive the HTTPS requests and forward them to a legacy service that uses HTTP.
- Log aggregator -When each Microservice generates any error logs, it might impact its memory and disk volume. In such cases, we can transfer the error logs from the Microservice to a log aggregator, Sidecar.
Besides, there are instances where the Sidecar pattern doesn’t fit well. Let’s look at some of these in detail so that we can avoid these scenarios.
When to avoid using Side Car Pattern?
- Typically for small projects, the cost to deploy a Sidecar is not worth it compared to the benefits.
- Also, if we put synchronous operations in a Sidecar, it can create performance bottlenecks for the parent service.
For these use cases, it’s better to use a library that executes within the same parent process as some functions may perform better within the main application than in a Sidecar.
Benefits of Using the Sidecar Pattern
Implementing the Sidecar pattern is vastly beneficial to the overall efficiency of the Microservice architecture. Let’s see those benefits one by one.
- Reduces the complexity of Services — Sidecar pattern abstracts the modules dealing with cross-cutting concerns into a separate component that can asynchronously carry out its operations. That helps the Microservice to work smoothly according to the flow, where the Sidecar provides the additional features and functions.
- Independent from the environment and language of the parent application — The Sidecar pattern is not dependent on the language or the environment of the Microservice, thus enabling it to work with multiple languages.
- Easy interaction with Microservice— The Sidecar can efficiently communicate with the Microservice by sharing file systems, local networks, and shared memory. Comparatively, the latency is lower as the Sidecar is in the same environment as the Microservice.
- The Sidecar has access to the same resources as the Microservice — Therefore it also allows to track the system resources used by both of these components.
- Different runtime with autonomy — Even when the Microservices faces a downtime, the Sidecar continues to run as its in a different runtime.
- Reduce code repetition and redundancy — The Sidecar contains all the required modules and runs along with the Microservices, preventing the necessity to include the same code again and again in each service.
Limitations of using the Sidecar Pattern
Let’s see the drawbacks of the Sidecar pattern and its limitations.
- One of the current limitations of the Sidecar pattern is that it requires a containerized environment.
- As a result, the resource utilization could go high when there is a large number of Sidecar containers.
However, the benefits of using the Sidecar pattern for cross-cutting concerns have already proven its value. Therefore, if you have the right environment in place, choosing it will save you time and effort in the long run.
Conclusion
I hope you have gained a good understanding of the Sidecar pattern and its usage by reading this article. If you have any questions or suggestions, please use the comment section below.
Thank you for reading!
Build with independent components, for speed and scale
Instead of building monolithic apps, build independent components first and compose them into features and applications. It makes development faster and helps teams build more consistent and scalable applications.
Bit offers a great developer experience for building independent components and composing applications. Many teams start by building their Design Systems or Micro Frontends, through independent components.
Give it a try →
Learn More
- The BFF Pattern (Backend for Frontend): An Introduction
- Using BLoC Pattern with React
- The Observer Pattern in JavaScript — the Key to a Reactive Behavior
Handling Cross Cutting Concerns in Microservices: The Sidecar Pattern was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Nishu_Dissanayake
Nishu_Dissanayake | Sciencx (2021-11-04T15:18:43+00:00) Handling Cross Cutting Concerns in Microservices: The Sidecar Pattern. Retrieved from https://www.scien.cx/2021/11/04/handling-cross-cutting-concerns-in-microservices-the-sidecar-pattern/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.