Sidecar Pattern Overview
The sidecar pattern is meant to allow the deployment of components of an application into separate, isolated, and encapsulated processes or containers. This pattern is especially useful when there is a benefit to sharing common components between microservices, as in the case of logging utilities, monitoring utilities, configuration routines, etc.
The Sidecar Pattern name is an analogy indicating the one-seat cars sometimes bolted alongside a motorcycle.
Benefits of Sidecar
Sidecar comes with many benefits:
- Use of multiple languages (polyglot) or technologies for each component. This is especially useful if a language is especially strong in a necessary area (e.g. Python for Machine Learning, or R for statistical work) or if an opensource solution can be leveraged to eliminate in-house specialization (e.g. the use of NGINX for certain network-related functions).
- Separation of what would otherwise be a monolith, and if used properly, fault isolation of associated services.
- Conceptually easy interactions between components similar to those provided by libraries, or service calls between microservices.
- Lower latency than traditional service calls to “other” services as the Sidecar lives in the same processing environment (VM or physical server) – albeit typically in a separate container.
- Similar to the use of libraries, allows for ownership by individual teams and organizational scalability of a larger team.
- Similar to the use of dynamically-loadable libraries, allows for independent release by teams of various shared usage components.
Drawbacks to Sidecar
Regardless of implementation (poly- or mono- glot), Sidecar has some drawbacks compared to the use of libraries:
- Higher inter-process communication latency – Because most implementations are service calls, the loopback interface on a system (127.0.0.1) will increase latency compared to the transition of call flow through memory.
- Size – especially in polyglot implementations but even in monoglot implementations – Containerization leads to multiple copies of similar libraries and increased memory utilization for comparable operations relative to the use of libraries.
- Environments – it is difficult to create any notion of fault isolation with Sidecar without containerization technologies. VM technologies (Sidecar in a VM separate from the host or calling solution) is not an option as it is then a Fan Out or Mesh anti-pattern rather than a local call.
When to Use Sidecar
Sidecar is a compelling alternative to libraries for cases where the increase in latency associated with local service messaging does not impact end-user response times. Examples of these are asynchronous logging, out of band monitoring, and asynchronous messaging capabilities. Circuit breakers (time-based request/response timeouts) are also a good example of a Sidecar implementation.
When to Avoid Sidecar
Never use a Sidecar Pattern for synchronous activities that must complete prior to generating a user response. Doing so will add some delay to end-user response times.
AKF also advises staying away from Sidecar for synchronous communications between services where doing so requires Sidecar to know all endpoints for each service. A specific example we advise against is having every endpoint (instance) of Service A (e.g. add-to-cart) know of every endpoint (instance) of Service B (e.g. decrement-SKU). A graphic of this example is given below:
The above graphic indicates the coordination between just two services and the instances that comprise that service. Imagine a case where all services may communicate to each other (as in the broader Mesh anti-pattern). Attempting to isolate faults becomes nearly impossible.
If Service A sometimes fails while calling Service B, how do you know which component is failing? Is it a failure in Service A, Service A’s Sidecar Proxy or Service B? Easier is to have a fewer number of proxies (albeit at a higher cost of latency given non-local communication) handle the transactions allowing for easier fault identification.