Sidecar Pattern

Major considerations before containerizing a service

  1. Do not overload the containers with multiple services

  2. If required, use the "Sidecar Pattern".

  3. Take help of dependency injection using external configuration and evaluating it on runtime.

  4. Design the containers for failure and short-life.

So, here in this post, we are going to talk about the Sidecar pattern we follow to break down an application into separate containers on services level.

Basically, the application will have following two things on broader level -

a) Parent service - Core functionality

b) Auxiliary services - Telemetry, Logging, Proxy etc.

Problems in different approaches

Problems if they are kept together -

  1. Single point of failure

  2. Technology/tech-stack dependency

Problems if they are separated -

  1. Latency

  2. Increased complexity (but of course flexibility)


According to the documentation provided by Microsoft, it states that

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.

What is basically means is -

Keep the processes separate, into different containers. But due to the proximity and involvement of share resources - latency issue can be resolved.

Flexibility is also there due to minimal interdependency.

Disclaimer - All the posts on this blog are written to cater the need of quick read. If more insights are required, please refer the official document. Happy learning!

15 views0 comments

Recent Posts

See All