The Sidecar Pattern

It has been a while since I have written anything here. I need to pick up writing again. I started this blog to keep reminders for me. If others have gained knowledge from it as well, then great. Technology is ever changing. I want to keep my skills up to date. So I wanted to start to incorporate containerization into my arsenal. In doing so, I decided to start where I always have started (after “Hello World” that is), with patterns. There is no use in reinventing the wheel. Also, patterns establish a common vocabulary, allowing you to communicate with others. To get my feet wet again I decided to start with a simple pattern that I have seen, the Sidecar Pattern.

The Sidecar Pattern

The Sidecar Pattern is a pattern that allows you to deploy, in isolation, a component of an application. It also allows applications to be composed of different components regardless of technologies used to create those components. This pattern doesn’t necessarily require containerization, but containerization definitely helps.

Sidecars live and die by the component they are “bolted” to. Some ideal candidates for Sidecars are monitoring, logging, configuration, and networking services. These tasks can be developed in a container and then bolted on to an application. Sidecar allows you to develop this functionality in isolation of the original application; this also removes the need to tightly couple the functionality within the application and allows you to develop reusable components that can deploy bolted onto other applications. This is where containers come in handy. Put the Sidecar functionality into a container and expose properties to configure the functionality and you have a reusable container. When it comes time to deploy your application you can bolt your Sidecar onto your application and deploy them as a container group.

Pros and Cons

Pros:

• Applications and Sidecars may be written in different languages
• Application code should not have to change
• Because of proximity (same container group), latency should be low
• Even if applications don’t provide extensibility, you can add functionality through a Sidecar

Cons:

• Maybe overkill. If your app is small, you may want to bake in the functionality
• If the Sidecar functionality needs to scale differently than or independently from the main applications, you may want to make it a separate hosted service
• When interprocess communication needs to be optimized, you may not want to use the Sidecar Pattern.

Examples

Here I will highlight a couple of real-world examples:

Networking Services

Say you have a web application that uses HTTP to host it and you want to secure it with SSL. You could dig into the application and make the necessary changes; perhaps resources were hardcoded. That may be too much work, or maybe you don’t even have the source code. What can you do then? First, host the web application in a container and expose a local host endpoint (127.0.0.1). Now host the NGINX service in a Sidecar container. Configure NGINX to terminate the SSL connection and forward the requests to the web application. Because the Sidecar is on the same host, it can access the local endpoint. The web application didn’t have to change to support this new functionality.

Configuration Management

Now let’s say that your application reads configuration data from a local store (file system, database, etc.). In the future, you want to hand configuration management from the cloud. You could go back to retrofit your application but that may take too long or may be complicated. One way you can achieve this is by creating a Sidecar with a configuration manager service. This service can talk to the cloud service, download the configuration or any changes, and write them to the local store. The local configuration manager can then signal the application container to perform some action that will trigger the application to fetch the new configuration information from the local store.

Summary

This post was just a quick look at how you can use a simple distributed system pattern to add functionality to an existing application. It also serves as a kick in the pants to keep writing and learning. A good book for these patterns is Designing Distributed Systems (Affiliate Link).