Every app has specific requirements for launch, but they can also require some related functionalities to work seamlessly. These added functionalities can include, but are not limited to, logging, monitoring, networking, and configuration services.  

There are two ways to go about this. They can be tightly integrated into the application (run in the same process), thereby improving efficiency due to the use of shared resources.

‍

However useful this may be, it also means they are not isolated well, and an outage of a single component can affect the entire application. They usually have to be implemented in the same programming language as well, making the app and the component interdependent. 

The sidecar is a separate assisting entity, deployed with the parent application in parallel on the same physical host. It has the same infrastructure, and the parent application and sidecar share the same resources (memory & network). 

‍

More importantly, this allows the devs to enhance performance by avoiding the addition of logic on the main container. It’s not a part of the parent application per se but goes wherever the parent application goes serving as a supporting process deployed within it, much like a sidecar on a motorbike, hence the name. 

5 Key Benefits of  Opting for the Sidecar Pattern

Application logic becomes more maintainable: Doesn’t add extra complexity of additional logic or configuration. 

Reusable app logic:  Common logic from the sidecar is reusable, and can be implemented into similar application containers. 

Security: You can use the sidecar pattern to control access or filter traffic, bolstering security in the process. 

Keep networking configurations separate from the application: Removes the need for external dependencies. 

Implementation abstraction: Because a sidecar is independent of its core application in terms of the runtime environment and programming language, you don't have to create one for each language.

The lifecycle remains the same: Considering it has access to the same resources as the parent app, it can monitor those used by the sidecar itself as well as the parent application. 

Lower latency: Because of its proximity to the parent application, communication between them has no substantial latency.

Extensibility and encapsulation: Even if an application lacks an extensibility mechanism, a sidecar can be used to extend functionality by attaching it as its own process in the same host or sub-container.

Sidecar Pattern: 7 Common Use Cases

Synchronized Infrastructure API Access

Instead of creating a language-specific client library to contact the infrastructure, the infrastructure development team comes up with a service deployed alongside each application. The sidecar service serves as a common layer for infrastructure services such as logging, environment data, configuration store, discovery, health checks, and watchdog services.

Additionally, it monitors the host environment and processes of the parent application and logs the results to a centralized service.

Sidecar Pattern GitOps Integration

The sidecar pattern enables seamless synchronization of application code with its Git repository. It periodically runs the 'git pull' command to keep the application updated. While this approach simplifies the process, it may not be ideal for managing dependencies in larger applications.

Sidecar Pattern for SSL Termination

Sidecar can also be used in place of some ambassador patterns for circuit monitoring, routing, and breaking to handle SSL termination.

Efficient Logging Management

You can also place an NGINX proxy directly in front of a node.js service. This establishes efficient communication of logs to logging servers.

Server Configuration Management

The sidecar pattern streamlines the update process for servers like HAProxy, Apache, or Nginx. It can efficiently download server configurations from a static link and trigger server reloads upon configuration changes. This enables faster and smoother server updates.

Flawless Application Configuration Management

Last but not least, the sidecar pattern is also used to simplify the management of application configuration and related variables. The sidecar container, connected to an external service, can efficiently update volume-mounted environment variables and trigger updates in the application container.

Empowering Kubernetes Service Mesh

The Istio Service Mesh is probably the most famous example of sidecar pattern usage. Here the incoming Istio proxy takes control as a sidecar, manipulating incoming and outgoing requests/responses while overseeing the pod's entire network control.

‍
Sidecar Pattern: When to Use

1. When the module is under the ownership of a remote team or a separate organization aka parent application is programmed using various languages and employs a diverse range of frameworks. 
   

2. When the module or feature has to share the host with the parent app. 
3. When creating a service that has to align with the complete lifespan of your parent application, but can be updated independently.
4. When absolutely need more control over limitations on resources.
   

Sidecar Pattern: When to Avoid

1. In smaller applications, the deployment cost of having a sidecar service for every instance doesn't justify the benefits of isolation.
   

2. Optimized communication between processes is your priority. Communication between the parent app and the sidecar can result in some latency, especially when it comes to calls. 
   

3. When there's a necessity for the service to scale in a manner different from or independently of the parent applications.
   
   

Hopefully, this article was helpful in answering your questions related to the sidecar pattern and its use cases. Thanks for reading!