Sidecar pattern

Overview

  1. Sidecars are supporting processes or services that are deployed with the primary application.
  2. Deploy components of an application into a separate process or container to provide isolation and encapsulation.
  3. This pattern can enable applications to be composed of heterogeneous components and technologies.
  4. 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.
  5. Sometimes referred to as the sidekick pattern.

Objective

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

  1. 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.
  2. To do this, spring security is an option.
  3. But I implemented a stand-alone application to do this.
    1. This stand-alone application has all the functionality to accept a HttpServletRequest and validate it (using the token key-value pair in the cookie).
    2. It does this by making a web service call to a backend service that validates the tokens in the request.
    3. This sidecar application is deployed as a (separate) container along with the actual application.
  4. This sidecar application can be added as a dependency in multiple other applications and those applications can use this functionality.
  5. 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).
  6. If the request validation fails, the method in the sidecar application will throw the appropriate exception (401 or 403 or 400 or 500).
  7. 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:

  1. 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.
  2. 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.
  3. Because of its proximity to the primary application, there’s no significant latency when communicating between them.
  4. 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


Links to this note