Side Car Mode | Young's Blog

SideCar can let you add more feature in your application without third-party configuration and code. This pattern is named Sidecar because it resembles a sidecar attached to a motorcycle. In the pattern, the sidecar is attached to a parent application and provides supporting features for the application. The sidecar also shares the same lifecycle as the parent application, being created and retired alongside the parent. The sidecar pattern is sometimes referred to as the sidekick pattern and is a decomposition pattern.

What is SideCar Mode

Deploy components of an application into a separate process or container to provide isolation and encapsulation.

Why use SideCar Mode

• 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.

How to use SideCar Mode

Using process or container.

When to use SideCar mode

Use this pattern when:

• 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.
• 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
• You need a service that shares the overall lifecycle of your main application, but can be independently updated.
• You need fine-grained control over resource limits for a particular resource or component. For example, you may want to restrict the amount of memory a specific component uses. You can deploy the component as a sidecar and manage memory usage independently of the main application.

This pattern may not be suitable:

• 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.
• For small applications where the resource cost of deploying a sidecar service for each instance is not worth the advantage of isolation.
• 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.

This blog is under a CC BY-NC-SA 3.0 Unported License
Link to this article: https://younggod.netlify.app/2020/05/10/tech/SideCarMode/