Sidecar Concept In 3 Minutes
What is sidecar pattern?
Similar to a sidecar attached to a motorcycle, A sidecar component provides the main service or application with supportive features. It is not part of the code and never share the application’s process or container. However, It share the same lifecycle of its parent (the main app or service).
Logging, monitoring, encrypting and configuration are common features which we need to implement into any service in a distributed system (microservices, cloud native…). It is the best use case of the sidecar!
We may ask: Why not to integrate these functionalities into my code? Well, You can but think about loose coupling and resiliency ! If all the components share the same resources (processes or containers), an outage in one of these components may affect the entire system.
But why not to implement the infrastructure features as standalone microservices? Here you may think about the complexity of deployment especially if multiple teams implement multi-language services where each service has its own dependencies (We don’t need a sidecar for small applications)
Why to use it?
We need a tradeoff between a tightly coupled, efficient solution and a decomposed solution but heterogeneous and less performant (latency). Sidecar pattern is that solution!
It is mainly applied in Kubernetes deployment. However, we can use it in a non-containerized architecture. A sidecar is independent from its primary application in terms of runtime environment and programming language. Nevertheless, It is connected to it. It goes wherever the parent application goes. For each instance of the application, an instance of the sidecar is deployed and hosted alongside it.
Service mesh is a way to control how different parts of an application share data with one another. It providers a configurable infrastructure layer to handle network‑based inter-process communication among services using (APIs). A service mesh is deployed as a service proxy or sidecar in the same K8s pod of an application container. Nginx, Consul and Envoy are some examples of open source service meshes.
K8s documentation is a great start for loggings patterns in distributed system using sidecar.
Sidecars is a deployment pattern where common features like logging and service 2 service communication can be attached to your service without sharing the resources. It ‘s a formal convention of K8s, but they’ve picked up speed as the K8s community experiments and figure out what works. Sidecars are: Modular, Composable and Reusable.