Sidecar Pattern

👋 Introduction

Have you ever played the game CS? 🎮 In CS, there are two teams: Terrorists and Counter-Terrorists, right? Let’s talk about the Terrorists team. In this team, there's a player with the bomb, while the rest of the players support the player with the bomb to plant them. It's like a well-coordinated mission where the main player has their trusted companion who assists them in planting it. 💣💥

Or perhaps you've heard about sidekicks? Yeah! Like the sidekicks of superheroes. 🦸‍♂️ Just as a superhero has their trusted companion who assists them in various tasks and enhances their capabilities, a sidecar is a helper container that runs alongside a main application container in a software environment. It provides additional services, resources, or functionality to the main application, much like a sidekick complements the abilities of a superhero, making it more effective in their mission. 🦸‍♀️🚀

The sidecar pattern is similar to teamwork in action! 🤝 It's a single-node pattern composed of two containers. 🚢 The first container is the application container 📦 – without it, the application wouldn't exist. Alongside the application container, there's a trusty sidecar container 🛠️. The role of the sidecar is to enhance and empower the application container, just like a sidekick bolsters a superhero! 🦸‍♂️💥

These application and sidecar containers work in harmony, scheduled on the same machine, which is referred to as a 'pod.' 🌟 They share a multitude of resources, a hostname, and a network. The general sidecar pattern can be depicted as follows:

📂🚗🏢 An Example Sidecar - Microservices

In many software applications and services, various peripheral functionalities such as monitoring, logging, configuration management, and networking services are required. These functionalities can be implemented as separate components or services.
Historically, developers would often integrate these services directly into the main application codebase, especially if they were written in the same programming language. This approach allowed for efficient code sharing and resource utilization, as these components could run in the same process as the main application. However, this tight integration also meant that these components were not well isolated, and any issues or outages in one component could potentially impact other components or even the entire application. Consequently, there was a high level of interdependence between these components and the core application.

The problem arises when these applications are built using different languages. For instance, Application 1 is built with Python, while the 2nd application is built using Rust. Each application will have its own implementations of caching, authentication, and logging.

One potential solution to this problem is to develop separate API services for these functionalities, as illustrated in the figure.

Does it have any problem?
When the application is decomposed into microservices, it becomes possible to employ different programming languages and technologies for individual services. While this approach provides greater flexibility, it comes with the drawback of each component having its own set of dependencies and the need for language-specific libraries to interact with the underlying platform and shared resources of the parent application. Furthermore, deploying these components as separate services can introduce latency into the application. The management of code and dependencies for these language-specific interfaces can also introduce significant complexity, particularly concerning aspects like hosting, deployment, and overall system management.

💡 Solution

We will use a sidecar pattern.

A sidecar service is not necessarily part of the application, but it is connected to it. It goes where the parent application goes. These are supporting processes or services that are deployed with the primary application. For each instance of the application, an instance of the sidecar is deployed and hosted alongside it.

🌟 Advantages of using a sidecar pattern:

1. The sidecar can access the same resources as the primary application. It can effectively monitor system resources utilized by both itself and parent applications. Resource Access.
2. The sidecar pattern is commonly employed with the containers and is often referred to as a sidecar container.
3. A sidecar can be used to enhance functionality by attaching it as a separate process in the same host.
4. A sidecar operates autonomously from the primary application, both in terms of the runtime environment and programming language, which eliminates the need to develop separate sidecar for each language.

🕐🤔 When can this pattern can be used:

1. When building a PaaS with Sidecars

1. Managing a dynamic configuration
2. When a component or feature must be co-located on the same host as the application.
3. A service that shares the overall lifecycle of your main application, but can be independently updated.
4. A component is owned by a different organization.

🚫❌ But not suitable when:

1. Communication between a parent application and sidecar services includes some overhead. i.e., where inter-process communication is important.
2. For small applications, the cost of deploying a sidecar service for each instance is not worth the isolation.
3. When the service needs to scale differently from the main applications. If so, it's better to deploy the feature as a separate service.

🔗 Further Reading and References

• https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar
• https://www.oreilly.com/library/view/designing-distributed-systems/9781491983638/ch02.html