The art of Microservices, From Code instrumentation to Sidecar to “Help me” Kernel!
Microservices and distribution come as a package deal, and hence a lot of efforts have been put together to guarantee Microservices resiliency and reliability.
At the very early beginning, Everything was code instrumentation based, where developers have to write - instrument - code within the service implementation to cater for resiliency and reliability requirements.
One step ahead - with the help of containers and Kubernetes - the sidecar pattern becomes more favorable and code instrumentation free, just add a sidecar next to your container where all resiliency and reliability policies can be applied.
Many reasons why sidecar is much more better approach and more superior in all aspects than code instrumentation, But Microservices story didn’t stop here, as we started to see another implementations with neither code nor sidecar instrumentation, Simply leaving all those layers above and go down to host kernel where all those Microservices are running as processes.
eBPF is the keyword, eBPF is a Linux kernel technology, simply allowing you to SAFELY run programs in the kernel space, in another word, securely extending kernel capabilities (writing code within the kernel without modifying it).
BPF was originally designed to to trace and filter network packets, some Linux admins map it directly to a firewall capability - bpfilter e.g., But now thanks for eBPF where functionality was extended beyond network to cover other areas like resource utilization such as CPU, process monitoring where a lot - more than just logs - can be collected for better process observability (see https://github.com/iovisor/bpftrace).
Unlike the sidecar approach where every container has to be instrumented by another small proxy container running next to it within the same pod, eBPF is a host OS kernel level capability that runs once on every host no matter how many containers/pods are scheduled to run it.
Below graph shows both approaches in action
Sidecar vs eBPF, How to compare?
From a cloud native development perspective, It doesn’t really matter as both approaches are transparent to developers and hence need not to deal with them at the development time, then where is the catch!
There is no black and white in this context, both approaches have pros and cons, The catch is to consider the following when comparing between the different offerings:
领英推荐
We will not compare community or enterprise offerings here but above is a very balanced framework for a fair comparison.
Can sidecar and eBPF work together
The short answer is “Yes”, the question now is how to split responsibility between two co-working engines?
eBPF can be a good fit downwards while sidecar can be a better fit upwards, so the more you go down to network level it is most likely that eBPF can provide better experience while moving up towards application layer it is most likely that sidecar can do better.
eBPF in action
Cilium is a good implementation of eBPF, Cilium is an open source project to provide networking, security, and observability for cloud native environments such as Kubernetes clusters and other container orchestration platforms.
For more details
For Cilium hands-on experience