Sidecar
An introduction to the Sidecar design pattern in microservice architectures. When and how to use it.
Hi Friends,
Welcome to the 82nd issue of the Polymathic Engineer newsletter.
This week, we discuss a design pattern widely used in microservices architectures: the Sidecar pattern.
The Sidecar pattern is a powerful way to make applications more modular and easy to manage, whether distributed or running on a single node.
In this issue, we will look at its benefits, explain when it's useful, and give examples of how it can be used.
The outline will be as follows:
What is the Sidecar pattern
Benefits of using the Sidecar pattern
Adding capabilities to Legacy Applications
Handling Dynamic Configuration
Creating modular applications with Sidecar
Logging and Monitoring
You may have noticed I used the “Indiana Jones and the Last Crusade " picture. Well, the idea to write this article came into my mind just after having watched the movie with my kids for the first time :)
Complete code reviews in hours, not days, right from Slack
This issue is offered by Pullpo.io, a tool that helps you accelerate your code reviews with AI-powered Slack Channels synchronized in real-time with GitHub (GitLab and Bitbucket too).
Pullpo has many features you can take advantage of:
AI Summaries and reviews
Reply to code review messages, add reviewers, and approve PR right from Slack
Custom reminders and notifications
Engineering metrics and working agreements
Try Pullpo for free and start merging faster!
What is the Sidecar Pattern?
The Sidecar pattern is a design pattern used in microservices architecture where a secondary process or service (the Sidecar) runs alongside the primary application.
This auxiliary service is deployed in the same environment, shares the same lifecycle and resources as the primary application, but operates independently.
Typically, the primary service is responsible for the core business logic. In contrast, the sidecar service provides additional functionalities such as logging, monitoring, configuration, and networking capabilities without altering the main application's codebase.
This approach is particularly beneficial when adding capabilities to an existing application would be complex, risky, or impractical. But it is not only about that.
By isolating the additional tasks into a separate process, the sidecar pattern also improves the modularity, maintainability, and scalability of the applications as a whole.
It should now be clear that this pattern is named Sidecar because it resembles a sidecar attached to a motorcycle.
The primary application is like the motorcycle, containing the core logic without which the application wouldn't exist. The auxiliary service is like the Sidecar, providing supporting features for the application.
Benefits of Using the Sidecar Pattern
The Sidecar pattern offers several key benefits that make it a popular choice in microservices architectures. Here is a summary of the main ones:
Modularity. By isolating auxiliary features in a sidecar, you can keep your main service focused on its primary responsibilities. This simplifies the codebase and makes maintenance easier. Changes to the sidecar can be made without affecting the primary application, reducing the risk of bugs or performance issues.
Scalability. Sidecars can be scaled independently of the primary application. This flexibility allows efficient resource utilization and handling increased load without changing the main application.
Operational Consistency. The sidecar pattern helps to maintain operational consistency across different services. For example, standardized logging can be implemented via sidecars, ensuring uniform practices across the entire application.
Observability. Sidecars can collect and aggregate metrics, logs, and traces, providing better insights into the application's performance and behavior. This enhanced observability aids in troubleshooting and optimizing the system.
Language Agnostic. A sidecar is independent of its primary application in terms of runtime environment and programming language, so you don't need to develop one sidecar per language.
In the following sections, we will check some typical scenarios where the advantages of using the Sidecar patterns are evident.
Adding Capabilities to Legacy Applications
When dealing with legacy systems, adding and integrating new functionalities directly into the existing codebase can be complex and risky. The sidecar pattern is an elegant solution to introduce new features without modifying the legacy code.
Imagine you have a legacy service that only supports HTTP, but you need to secure it with HTTPS. Instead of rewriting the entire service, you can introduce a sidecar proxy that handles all HTTPS communication.
The proxy will sit between the legacy service and its clients, handling SSL/TLS termination and ensuring that all incoming HTTPS requests are decrypted before being forwarded to the legacy service over HTTP.
To implement this solution, you can containerize the legacy application and configure it to serve requests exclusively on localhost, which means that the application can be accessed only by services that share the local network with it.
Then, you can add an Envoy or Nginx sidecar container that runs in the same network namespace as the legacy application container so that it can access the service running on localhost.
The sidecar will terminate HTTPS traffic on the external IP address and delegate that traffic to the legacy application.
Handling Dynamic Configuration
Consider a scenario where your application needs to fetch settings from a centralized configuration service. These settings might include feature flags, testing parameters, connection strings, or other environment-specific parameters that can change frequently.
Instead of embedding the configuration logic within each service, you can use a sidecar to fetch and manage these configurations from a central repository.
To implement this solution, you can introduce a dedicated sidecar service that handles fetching and updating configurations from a centralized source, such as Consul, or etcd.
This sidecar continuously polls the configuration service for updates. When changes are detected, the sidecar can push these updates to the primary application via an API or expose the updated configuration through shared storage or environment variables.
Isolating the configuration management in a sidecar allows the main application to focus only on its core functionality, significantly reducing its complexity.
The sidecar manages all the interactions with the configuration service, enabling the application to adapt to new configurations in real-time without being restarted or redeployed.
Logging and Monitoring
Similarly, you can use the sidecar pattern to implement logging and monitoring for a microservice. Instead of embedding logging logic directly within the microservice, you can deploy a sidecar dedicated to these tasks.
In the case of logging, you could develop a sidecar using a data collector like Fluentd to handle log collection and aggregation. The main application writes logs to a local file system or a shared volume, which the Fluentd sidecar reads and processes.
In the case of monitoring, you could use Prometheus as a monitoring sidecar. The main application exposes metrics through an endpoint that Prometheus scrapes regularly.
These approaches ensure that logging and monitoring are handled consistently and can be updated or scaled independently of the main application.
Job Opportunity
A friend working at Shopify told me they are looking for an External Communications Lead, Engineering & Developer Audiences in her team. The job is remote, and you can apply using the link.
Interesting Reading
Here are some interesting articles I’ve read this week:
Dividing the functionality of an application into separate processes can be considered as the Sidecar pattern. The Sidecar design pattern allows you to add many features to an application without the need for additional configuration and code of third-party components.
Just as a sidecar is attached to a motorcycle, similarly in software architecture, a sidecar application is connected to the parent application to extend or enhance its functionality. The sidecar application is loosely coupled with the main application.
nice introduction, thanks