What is Sidecar Pattern in Software Architecture?

They say a picture speaks thousands of words. In this case, it really does and there’s no need for a big explanation.

Introducing Sidecars

Also known as Sidekick Pattern. In the pattern, the sidecar is attached to a parent application just like a motorcycle attached to a sidecar providing supporting features to its parent. The sidecar also shares the same life-cycle as the parent application, is created and retired alongside the parent.

A sidecar service is not necessarily part of the application but is connected to it. It goes wherever the parent application goes. Sidecars are supporting processes or services that are deployed with the primary application. 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.

An Example In Software World

This pattern can be used for extending the features of your existing application. For example, making your old non-HTTPS container work with HTTPS.

The legacy web service is configured to serve exclusively on localhost, which means that only services that share the local network with the server will be able to access the service.

[Image]

However, using the sidecar pattern, in addition to the legacy container, we will add a proxy container as sidecar container for example NGINX. This NGINX container lives in the same network as the legacy web application, so it can access the service that is running on localhost. And the sidecar will expose your app to the outside world with HTTPS. This is one of the many uses of the pattern.

The sidecar pattern is often used with containers and referred to as a sidecar container or sidekick container.

The Deeper Explanation

I’m going to get into some bits of information that might be important when you implement this pattern.

Applications and services often require related functionality, such as monitoring, logging, configuration, and networking services. These peripheral tasks can be implemented as separate components or services.

If they are tightly integrated into the application, they can run in the same process as the application, making efficient use of shared resources. However, this also means they are not well isolated, and an outage in one of these components can affect other components or the entire application. Also, they usually need to be implemented using the same language as the parent application. As a result, the component and the application have close interdependence on each other.

[Image 2]

If the application is decomposed into services, then each service can be built using different languages and technologies. While this gives more flexibility, it means that each component has its own dependencies and requires language-specific libraries to access the underlying platform and any resources shared with the parent application. In addition, deploying these features as separate services can add latency to the application. Managing the code and dependencies for these language-specific interfaces can also add considerable complexity, especially for hosting, deployment, and management.

Advantages Of Using Sidecars

• A sidecar is independent of its primary application in terms of the 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 own process in the same host or sub-container as the primary application.

Some Guidelines You Should Follow

• Make sure your application components are packaged when you deploy. Like containerizing it.
• Try to use language, framework-agnostic communication between the sidecar and main service.
• Before going for a sidecar consider the other possibilities such as a traditional daemon or integrating into the same application because language-specific libraries may have a deeper level of integration and less network overhead.

Hope You’ve learned something new today! :D

References

Designing Distributed Systems From Amazon

https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar