What are sidecars in microservices?

1. Definition

A sidecar is a separate process or container that runs alongside a microservice in the same host or pod to provide supporting capabilities — without changing the microservice’s code.
It’s called “sidecar” because it’s attached like the sidecar of a motorcycle: it moves with the main service but is separate from it.

---

2. Why Sidecars Exist (Problem They Solve)

• Microservices need cross-cutting features (logging, monitoring, proxying, config, service discovery, security, etc.).
• If every team implements these features inside each service, you get:
  • Code duplication
  • Inconsistent implementations
  • Higher maintenance cost
• You want to add/upgrade these features without touching the service’s core code.

---

3. How Sidecars Solve It

• Put these features in another container that runs in the same environment as the service.
• The sidecar can:
  • Intercept traffic
  • Collect metrics/logs
  • Fetch configs/secrets
  • Handle retries, TLS, service discovery
• Because it’s separate, you can update/configure it without redeploying the main service.

---

4. Common Use Cases

• Service Mesh Proxies
  • e.g., Envoy in Istio or Linkerd: handles mTLS, routing, retries, telemetry.
• Logging Agents
  • e.g., Fluent Bit/Fluentd sidecar shipping logs to ELK/OpenSearch.
• Security Agents
  • Sidecars that fetch & refresh auth tokens, handle encryption.
• Data Sync / Backup
  • Sidecar syncing files or data to a storage service.
• Adapters / Protocol Translators
  • e.g., Translate gRPC calls to REST or vice versa.

---

5. Benefits

• No code changes in the microservice.
• Consistency: same sidecar config applies to all services.
• Can be developed & updated independently.
• Keeps core service lightweight and focused.

---

6. Drawbacks

• More containers → More resource usage.
• Operational complexity: must deploy & monitor both service and sidecar.
• Possible performance overhead if traffic is proxied through it.

---

7. Example: Kubernetes Pod with Sidecar

apiVersion: v1
kind: Pod
metadata:
  name: myservice-pod
spec:
  containers:
  - name: myservice
    image: myservice:1.0
    ports:
      - containerPort: 8080
  - name: envoy-proxy
    image: envoyproxy/envoy:v1.26
    ports:
      - containerPort: 15001

Here:

• myservice = your business logic
• envoy-proxy = sidecar handling traffic routing, retries, TLS

---

✅ In short:
A sidecar is a helper container/process that lives alongside your microservice, taking care of shared infrastructure concerns so your service code can focus on business logic.