Sidecar pattern
Table of Contents
Overview
- Sidecars are supporting processes or services that are deployed with the primary application.
- Deploy components of an application into a separate process or container to provide isolation and encapsulation.
- This pattern can enable applications to be composed of heterogeneous components and technologies.
- 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.
- Sometimes referred to as the sidekick pattern.
Objective
- Co-locate a cohesive set of tasks with the primary application, but place them inside their own process or container, providing a homogeneous interface for platform services across languages.
Use-case that I worked on
- All the applications in the domain need to do validation on the incoming HttpServletRequests to make sure that the “cookie token” in the request is valid.
- To do this, spring security is an option.
- But I implemented a stand-alone application to do this.
- This stand-alone application has all the functionality to accept a HttpServletRequest and validate it (using the token key-value pair in the cookie).
- It does this by making a web service call to a backend service that validates the tokens in the request.
- This sidecar application is deployed as a (separate) container along with the actual application.
- This sidecar application can be added as a dependency in multiple other applications and those applications can use this functionality.
- All those applications just need to implement a “Filter” in the MVC context to invoke the functionlity in the jar component. From the Filter class, there will be a method invocation (to the method in the sidecar application).
- If the request validation fails, the method in the sidecar application will throw the appropriate exception (401 or 403 or 400 or 500).
- The application just has to catch the exception thrown by the sidecar component and handle it appropriately (by wrapping it in a custom Exception class and using Controller Advice to convert this custom error into an appropriate json response from the application).
Advantages of using a sidecar pattern include:
- 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.
Reading material
https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar