Many services need ancillary functionalities, such as monitoring, logging, or configuration. One choice is to implement these inside the main application code base, but then there are a few concerns:

• Our single-purpose principle is compromised. Changes will creep into the application for requirements that are not directly related to the responsibility of the service.
• Any bugs/crashes in any of the components will cause outages in the service.
• These components need to be built in the same language/runtime as the the main application. If there are readily available solutions, in different forms, they can't be directly reused.

The Sidecar pattern proposes an alternative—colocate these ancillary tasks with the main service, but host them inside in their own process or container, rather than in-process with the main application. The name comes from the similarity of how the sidecar services are deployed with the main application to how a sidecar is attached to a motorcycle.

The advantages of using a sidecar pattern include the following:

• Independence from its primary application in terms of runtime and programming language, thus enabling reuse
• Locality: Results in reduced communication latency as well as efficient sharing of resources, such as files
• Resiliency: Any sidecar that goes down does not bring down the main application

The sidecar pattern is often employed with container-based deployments, and these are usually referred to as sidecar/sidekick containers.