A world of service mesh without sidecars!
So far there are 2 well known types of service mesh model -
1. Shared library model
In this model, the application implements service mesh features using language-specific libraries. Libraries like Hystrix and Ribbon would be examples of this approach.
This works well for apps that are exclusively written in one language by the teams that run them. The library approach also doesn’t require much cooperation from the underlying infrastructure — Kubernetes doesn’t need to be aware that you’re running a Hystrix enhanced app.
There is some work on multi-language libraries — reimplementations of the same concepts. The challenge here is the complexity and effort involved in replicating the same behaviour over and over again.
2. Sidecar proxy model
In this model, the service mesh-related functionalities are achieved by running a sidecar proxy next to the application. This is the model used by Istio with Envoy.
In the Sidecar deployments, you have one adjacent container deployed for every application container. For a service mesh, the sidecar handles all the network traffic in and out of the application container.
The sidecar proxy model is currently the most commonly used pattern; however over the years practitioners of this pattern have observed many challenges which includes additional cost & resources, performance implications , additional overhead of deployment & maintenance!
What next?
Enters Cilium which brings a “sidecar-less” model to the world of service mesh. It’s based on the concept of eBPF wherein you use eBPF based plugin running in Kernel to tap into the network, security, and observability.
In a follow-up blog, I’ll take you through the why’s & how’s of Cilium!
Update 21/08: I’ve a new blog on eBPF explaining the need that led to the rise of it. Do check out here.
