Sidecar pattern: common use cases

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.

Sidecar by name is assisting entity that stays attached with main application and perform some action to extend or improve the parent container like as sidecar of motorbikes. Rather than adding additional logics on main container other than application logics and dependencies, its better to employ sidecar container for better performance, enhance functionality and maintainable.

The pattern may be easy presented on the diagram below:

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.

Advantages of using a sidecar pattern.

1. Keep application logic maintainable. Using sidecar pattern enables to keep parent container with application logic only without adding complexity of additional logic & configuration.
2. Secure or access control application. By using sidecar pattern, configurations can be made to filter traffic or control access to main container keeping it secure.
3. Separate networking configurations from application. For the operation of application, there is need of external dependencies, networking logics can be managed by sidecar container
4. Abstracting implementation. 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.
5. The same lifecycle. 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.
6. Better performance with low latency. Because of its proximity to the primary application, there’s no significant latency when communicating between them.
7. Encapsulation and extensibility. 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.
8. Reusability of application logic. Common logic in sidecar container is reusable across similar application containers rather than adding the functionality of sidecar to application container itself

Common use cases.

1. GitOps. Implementing synchronization application code with the respective git repo. We can use a sidecar container that keeps the application updated at certain interval by running git pull command. This could prevent using a separate pipeline but would not be a good way to manage dependencies and for larger application.
2. Keeping server configuration updated. If we are using Nginx, Apache, HAProxy like servers, they might need to be updated and reload the servers. Using sidecar container for the purpose eases and makes it faster for updating the configs. Sidecar container can be configured to download server config from a static link and reload the server if the config is changed.
3. Infrastructure API. The infrastructure development team creates a service that’s deployed alongside each application, instead of a language-specific client library to access the infrastructure. The service is loaded as a sidecar and provides a common layer for infrastructure services, including logging, environment data, configuration store, discovery, health checks, and watchdog services. The sidecar also monitors the parent application’s host environment and process (or container) and logs the information to a centralized service.
4. Maintaining and sending logs to logging servers. Place an NGINX proxy in front of a node.js service instance, to handle serving static file content for the service.
5. SSL termination. This sounds like ambassador pattern but we can employ sidecar for ambassador services like: circuit breaking, routing, monitoring.
6. Managing application configuration/variables: If we have volume mounted environment variables or any application configuration, sidecar pattern can easily update them. Also, sidecar container with connection to some external service can be configured to trigger application container to do some update.
7. Kubernetes service mesh. Probably the most famous implementation of sidecar pattern. Istio Service Mesh can work as sidecar. The pod’s entire network control is taken over by the incoming istio-proxy as a sidecar and can manipulate incoming and outgoing requests/responses.

Pros and cons.

When to use	When to avoid
Your primary application uses a heterogeneous set of languages and frameworks. A component located in a sidecar service can be consumed by applications written in different languages using different frameworks.	When interprocess communication needs to be optimized. Communication between a parent application and sidecar services includes some overhead, notably latency in the calls. This may not be an acceptable trade-off for chatty interfaces.
A component is owned by a remote team or a different organization.
A component or feature must be co-located on the same host as the application.	For small applications where the resource cost of deploying a sidecar service for each instance is not worth the advantage of isolation.
You need fine-grained control over resource limits for a particular resource or component.
You need a service that shares the overall lifecycle of your main application, but can be independently updated.	When the service needs to scale differently than or independently from the main applications. If so, it may be better to deploy the feature as a separate service.

I hope you like our new architecture patterns seria. For more content please subscribe to our newsletter, follow us on Twitter and LinkedIn.

Save your privacy, bean ethical!