Introduction
The sidecar is one of the most commonly used patterns when running a cluster.
Although the pattern can also be applied to processes, it is mostly used with containers. For example with Kubernetes, ECS, EKS, etc.
As the name implies, it is called this because it resembles the sidecar attached to a motorbike. It’s a supporting container that is along for the ride.
Other names include:
- Sidekick pattern
- Decomposition pattern
When to use
The sidecar pattern is used when you want to co-locate containers on the same host. It also allows you to:
- Use a different language for your sidecar.
- Update sidecar independently of main application.
- Give the primary application and sidecar access to the same resources.
- Have minimal latency between sidecar and primary application.
- Share the same life cycle as the primary application.
- Make it easier for a separate team/business to have ownership over the sidecar container.
Considerations
However, watch out for the pot holes! You need to consider if sidecar is the best pattern for your use case:
- Would it be better as a daemon?
- Would it be better as an application feature? Language-specific libraries may have a deeper level of integration and less network overhead.
- If interprocess communication need optimised, sidecars can add unwanted latecy between calls
- If the sidecar need scaled separately, it could be better as it’s own service
Examples
Here are some common use cases for the sidecar pattern:
- Logging and Monitoring
- Security and Authentication
- Caching
- Data Transformation and Proxying
- Asynchronous Processing
- File Synchronisation