Sidecar Pattern
Also known as: Sidekick Pattern
1. Overview
The Sidecar pattern is a design pattern used in software architecture, particularly in microservices environments. It involves deploying a secondary component, the “sidecar,” alongside a primary application to provide supporting features. The sidecar shares the same lifecycle as the parent application, being created and retired alongside it. This pattern is also known as the Sidekick pattern and is a decomposition pattern [1]. The name comes from the analogy of a sidecar attached to a motorcycle, where the sidecar is attached to one motorcycle, and each motorcycle can have its own sidecar.
2. Core Principles
The core principles of the Sidecar pattern are:
- Co-location: The sidecar is always deployed and located with the primary application.
- Shared Lifecycle: The sidecar’s lifecycle is tied to the primary application’s lifecycle.
- Isolation: The sidecar runs in its own process or container, providing isolation from the primary application.
- Encapsulation: The sidecar encapsulates a specific set of functionalities, such as monitoring, logging, or security.
3. Key Practices
Applications and services often require related functionality, such as monitoring, logging, configuration, and networking services. When these tasks are tightly integrated into the application, they can run in the same process, but an outage in one of these components can affect the entire application. Also, they usually need to be implemented using the same language as the parent application. If the application is decomposed into services, each service can be built using different languages and technologies, but each component has its own dependencies and requires language-specific libraries to access the underlying platform and any resources shared with the parent application [1].
4. Implementation
The Sidecar pattern provides a solution by co-locating a cohesive set of tasks with the primary application, but placing them inside their own process or container. This provides a homogeneous interface for platform services across languages. The 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, and because of its proximity, there is no significant latency when communicating between them [1].
5. 7 Pillars Assessment
| Pillar | Score (1-5) | Rationale |
|---|---|---|
| Purpose | 3 | Serves a clear technical purpose in system design |
| Governance | 3 | Can be governed through standard engineering practices |
| Culture | 3 | Supports engineering culture of reliability and quality |
| Incentives | 3 | Aligns incentives toward system stability |
| Knowledge | 4 | Well-documented pattern with extensive community knowledge |
| Technology | 4 | Directly applicable to modern technology stacks |
| Resilience | 4 | Contributes to overall system resilience |
| Overall | 3.4 | A valuable technical pattern that supports commons infrastructure |
| Pros | Cons |
|---|---|
| Language Independence: Sidecars can be written in any language, regardless of the main application’s language. | Increased Complexity: The pattern introduces more moving parts, which can increase deployment and management complexity. |
| Isolation: The sidecar isolates auxiliary services from the main application, improving resilience. | Resource Overhead: Running a separate process for the sidecar can consume additional resources. |
| Reusability: A single sidecar implementation can be reused across multiple applications. | Inter-process Communication: Communication between the application and the sidecar can introduce latency. |
6. When to Use
- Service Mesh: In a service mesh architecture, a sidecar proxy is deployed alongside each service instance to handle tasks like traffic management, security, and observability.
- Logging and Monitoring: A sidecar can be used to collect logs and metrics from the main application and forward them to a centralized logging or monitoring system.
- Configuration Management: A sidecar can be used to fetch configuration data from a central configuration server and make it available to the main application.
7. Anti-Patterns & Gotchas
In the cognitive era, the Sidecar pattern can be used to offload AI/ML-related tasks from the main application. For example, a sidecar could be used to:
- Run inference models: A sidecar could host a machine learning model and expose an API for the main application to use for predictions.
- Pre-process data: A sidecar could be used to pre-process data before it is sent to a machine learning model for training or inference.
- Monitor model performance: A sidecar could be used to monitor the performance of a machine learning model and retrain it when necessary.
8. References
- Shared Resource: The Sidecar pattern promotes the creation of reusable components that can be shared across multiple applications.
- Democratic Governance: The pattern allows for decentralized decision-making, as different teams can be responsible for developing and maintaining different sidecars.
- Equitable Access: The pattern can be used to provide common services to all applications in a consistent manner.
- Sustainability: By promoting reusability and reducing duplication of effort, the Sidecar pattern can contribute to the long-term sustainability of a software system.
- Community Benefit: The pattern can benefit the community by enabling the creation of a rich ecosystem of reusable sidecar components.
8. References
[1] Sidecar pattern - Azure Architecture Center [2] Pattern: Sidecar