Sidecar Pattern

Applications and services often require related functionality, such as monitoring, logging, configuration, and networking services. These are the task which are independent of the running application and can be implemented in parallel component or service.

If they are tightly integrated into the application, they can run in the same process as the application, making effective use of shared resources. However, this also means they are not isolated and any problem or outage caused to this can affect the entire application.

Also these functionality needs to be written in the same language or technology that the application uses which might not be suitable for these functionalities.

Sidecar Pattern

The sidecar pattern in single node pattern made up of two containers. The first is the application container which has all the logic of running application without which application is of no use and second is the sidecar container.

The role of the sidecar container to add some functionality in most of the cases without application container knowing it they are often or not used in the scenarios defined above.

Sidecar container runs in parallel to main container and can be implemented using pod objects in Kubernetes. As they are running on the same machine they can share resources, space, filesystem, hostname, network etc.

source: Microsoft docs

In the world of microservices there can be needs to add the same kind of sidecar to multiple pods. On a motorcycle, the sidecar is attached to one motorcycle, and each motorcycle can have its own sidecar. In the same way, a sidecar service shares the fate of its parent application. For each instance of the application, an instance of the sidecar is deployed and hosted alongside it.

Implementing Sidecar Pattern

Sidecar is an application container like any other container, having specific things to deal with. Using the fact that a pod can have multiple container in Kubernetes adding it becomes much easier.

As in the example we can see that the container is a list and can take multiple containers as parameter and while creating the pod it Kubernetes will handle things for us.

At first you can have your application container and second can be your sidecar container.

I’ve used it when I had to deal with the network traffic of multiple container. Using sidecar pattern doing it became easier as I didn’t had to touch the running application.

Existing Examples

There are famous examples already in market which solves some problems like service-mesh, network traffic and monitoring using sidecar pattern as internal implementation.

A famous example of it is Istio : An open source service mesh platform that provides a way to control how microservices share data with one another. If we read about the problem statement or the concept of service-mesh the first solution that comes in mind is sidecar-pattern, maybe not directly but in one way or other. Linkerd could be another example similar to Istio.

Want to read more about service mesh — what is service-mesh

Another famous example is Envoy : Open source service proxy designed for cloud native applications.

Advantages

• A sidecar is independent from its primary application in terms of runtime environment and programming language, so you don’t need to develop one sidecar per language.
• The sidecar can access the same resources as the primary application. For example, a sidecar can monitor system resources used by both the sidecar and the primary application.
• Because of its proximity to the primary application, there’s no significant latency when communicating between them.
• Even for applications that don’t provide an extensibility mechanism, you can use a sidecar to extend functionality by attaching it as its own process in the same host or sub-container as the primary application.
• Even if the sidecar goes down application container will work as-is.
• Application container does not needs to worry about the sidecar container.

Consideration before using

• Sidecar container it small enough to not impact the running container.
• Try to see if the deployment technology that you’re using actually support this.
• Try to avoid complex logic in sidecar which may potentially slow down the running container.
• Consider using minimum resources for sidecar to keep your application container running as before.
• Also consider whether the functionality could be implemented as a library or using a traditional extension mechanism. Language-specific libraries may have a deeper level of integration and less network overhead.

When to use sidecar pattern

• The language or technology does not support the feature you want in the sidecar.
• Similar functionality has to be added to multiple pods
• New functionality in sidecar has nothing to do with the application container in terms of feature and sidecar is just interested in some logs or outputs from network or shared resources.
• You need a service that shares the overall lifecycle of your main application, but can be independently updated.
• A component or feature must be co-located on the same host as the application.
• A real example could be logging all network traffic or similar to this.

That’s the end of this article if you’re interested I would highly suggest try it out hands-on and see what could be other possible usecases of the sidecar pattern, or mention any which you’ve already used it for.