Learning Notes #11 – Sidecar Pattern | Cloud Patterns

26 December 2024 at 17:40

Today, I learnt about Sidecar Pattern. Its seems like offloading the common functionalities (logging, networking, …) aside within a pod to be used by other apps within the pod.

Its just not only about pods, but other deployments aswell. In this blog, i am going to curate the items i have learnt for my future self. Its a pattern, not an strict rule.

What is a Sidecar?

Imagine you’re riding a motorbike, and you attach a little sidecar to carry your friend or groceries. The sidecar isn’t part of the motorbike’s engine or core mechanism, but it helps you achieve your goals—whether it’s carrying more stuff or having a buddy ride along.

In the software world, a sidecar is a similar concept. It’s a separate process or container that runs alongside a primary application. Like the motorbike’s sidecar, it supports the main application by offloading or enhancing certain tasks without interfering with its core functionality.

Why Use a Sidecar?

In traditional applications, all responsibilities (logging, communication, monitoring, etc.) are bundled into the main application. This approach can make the application complex and harder to manage. Sidecars address this by handling auxiliary tasks separately, so the main application can focus on its primary purpose.

Here are some key reasons to use a sidecar

Modularity: Sidecars separate responsibilities, making the system easier to develop, test, and maintain.
Reusability: The same sidecar can be used across multiple services. And its language agnostic.
Scalability: You can scale the sidecar independently from the main application.
Isolation: Sidecars provide a level of isolation, reducing the risk of one part affecting the other.

Real-Life Analogies

To make the concept clearer, here are some real-world analogies:

Coffee Maker with a Milk Frother:
- The coffee maker (main application) brews coffee.
- The milk frother (sidecar) prepares frothed milk for your latte.
- Both work independently but combine their outputs for a better experience.
Movie Subtitles:
- The movie (main application) provides the visuals and sound.
- The subtitles (sidecar) add clarity for those who need them.
- You can watch the movie with or without subtitles—they’re optional but enhance the experience.
A School with a Sports Coach:
- The school (main application) handles education.
- The sports coach (sidecar) focuses on physical training.
- Both have distinct roles but contribute to the overall development of students.

Some Random Sidecar Ideas in Software

Let’s look at how sidecars are used in actual software scenarios

Service Meshes (e.g., Istio, Linkerd):
- A service mesh helps microservices communicate with each other reliably and securely.
- The sidecar (proxy like Envoy) handles tasks like load balancing, encryption, and monitoring, so the main application doesn’t have to.
Logging and Monitoring:
- Instead of the main application generating and managing logs, a sidecar can collect, format, and send logs to a centralized system like Elasticsearch or Splunk.
Authentication and Security:
- A sidecar can act as a gatekeeper, handling user authentication and ensuring that only authorized requests reach the main application.
Data Caching:
- If an application frequently queries a database, a sidecar can serve as a local cache, reducing database load and speeding up responses.
Service Discovery:
- Sidecars can aid in service discovery by automatically registering the main application with a registry service or load balancer, ensuring seamless communication in dynamic environments.

How Sidecars Work

In modern environments like Kubernetes, sidecars are often deployed as separate containers within the same pod as the main application. They share the same network and storage, making communication between the two seamless.

Here’s a simplified workflow

The main application focuses on its core tasks (e.g., serving a web page).
The sidecar handles auxiliary tasks (e.g., compressing and encrypting logs).
The two communicate over local connections within the pod.

Pros and Cons of Sidecars

Pros:

Simplifies the main application.
Encourages reusability and modular design.
Improves scalability and flexibility.
Enhances observability with centralized logging and metrics.
Facilitates experimentation—you can deploy or update sidecars independently.

Cons:

Adds complexity to deployment and orchestration.
Consumes additional resources (CPU, memory).
Requires careful design to avoid tight coupling between the sidecar and the main application.
Latency (You are adding an another hop).

Do we always need to use sidecars

No. Not at all.

a. When there is a latency between the parent application and sidecar, then Reconsider.

b. If your application is small, then reconsider.

c. When you are scaling differently or independently from the parent application, then Reconsider.

Some other examples

1. Adding HTTPS to a Legacy Application

Consider a legacy web service which services requests over unencrypted HTTP. We have a requirement to enhance the same legacy system to service requests with HTTPS in future.

The legacy app is configured to serve request exclusively on localhost, which means that only services that share the local network with the server able to access legacy application. In addition to the main container (legacy app) we can add Nginx Sidecar container which runs in the same network namespace as the main container so that it can access the service running on localhost.

2. For Logging (Image from ByteByteGo)

Sidecars are not just technical solutions; they embody the principle of collaboration and specialization. By dividing responsibilities, they empower the main application to shine while ensuring auxiliary tasks are handled efficiently. Next time you hear about sidecars, you’ll know they’re more than just cool attachments for motorcycle they’re an essential part of scalable, maintainable software systems.

Also, do you feel its closely related to Adapter and Ambassador Pattern ? I Do.

Reading view