eBPF: The future of the service mesh and network innovation

The conversations around eBPF and how this technology will shape the future of the service mesh caused a huge buzz in the last year — yes, bee pun intended. eBPF lets you run sandboxed programs in an operating system kernel. Imagining how eBPF could improve the service mesh brings exciting possibilities, but it also raises security and operational concerns given the current state and limitations of eBPF. In this article, we explore the exciting discussions around this technology and how eBPF could improve the service mesh.

eBPF and a sidecarless data plane?

A year and a half ago, Liz Rice, Isovalent's Chief Open Source Officer, wrote How eBPF Streamlines the Service Mesh, diving into how Cilium, an eBPF CNI implementation, could introduce a sidecarless model of the service mesh.

To briefly summarize the idea, instead of running a sidecar proxy next to each application process, this sidecarless model would instead run a single sidecar proxy for each node, allowing the multiple application processes that run on that node to share that single sidecar. The reasoning behind this new approach would be to address complexity and overhead, two typical concerns when deploying a service mesh.

Shifting towards a sidecar per node approach raises serious security concerns. Linkerd creator and Buoyant CEO William Morgan advocates in favor of the security posture that the sidecar per process approach guarantees, affirming it is better to keep the blast size of a proxy failure to a signle instance of the application, rather than multiple instances. Morgan also responded to the complexity argument by pointing out that it is possible to engineer solutions to minimize the overhead of the sidecar model and that this approach is preferential as it does not compromise security.

Isovalent is not the only one in the service mesh space pushing for a sidecarless future. Last September, Istio announced Ambient Mesh, a new sidecarless data plane mode. Again, security concerns were immediately brought up by the community. Istio defended the new security boundaries of this model in this deep dive, by explaining how ztunnel, a node-shared component, secures workload traffic and has a reduced attack surface.

Clearly, the future of sidecars in the service mesh are up for debate, and it will be interesting to watch as service mesh adoption patterns unfold.

The role eBPF plays in improving the service mesh

Back in December 2021, Isovalent published How eBPF will solve Service Mesh - Goodbye Sidecars furthering the idea of using eBPF to move certain functions to the kernel level and holding this is the continuation of a long history of moving connectivity functionalities into the kernel.

A few months later at IstioCon 2022, Idit Levine and Kohavi Yuval responded to this article. Given where eBPF is today, they believe it will not get rid of sidecars. As for "solving the service mesh", they believe it has great potential for improving the service mesh in two ways: reducing latency and improving observability efforts.

They explain how data travels faster by leveraging eBPF sockets to skip the entire TCP stack journey that data packets typically travel in a kernel. As for observability, in addition to scraping metrics from a proxy to understand the health of a service mesh, Levine and Yuval explain you could understand the health of the entire network by also scraping metrics from an eBPF program running on the same node hosting the proxy and application processes.

In a Buoyant blog post published last June, Morgan shared his latest thoughts on how eBPF will impact the service mesh. In addition to addressing how eBPF could and should not replace the sidecar model, he points out how the two work together: “the CNI is responsible for L3/L4 traffic, and the service mesh for L7” with the footnote “Or possibly L5/L7, or L5-L7… the OSI model, never particularly accurate, now requires footnotes and punctuation gymnastics to approach precision.”

eBPF helps the service mesh where it can, how it can

As service mesh adoption steadily grows, it is exciting to watch the ecosystem collaborate on how to improve the model and push the boundaries of what is possible. While eBPF may not be able to remove the sidecar for most use cases, there are ways for it to work alongside the service mesh to improve the networking stack.

If you are deploying microservices, consider running them on Koyeb and benefit from the service mesh that we built into the platform. 😎