eBPF and Wasm: Emerging Alternatives to Sidecar Proxies in Service Mesh Data Planes

On December 2, 2021, the Cilium project announced a beta testing program for Cilium Service Mesh, extending its eBPF‑based product to handle most sidecar proxy functions such as L7 routing, load balancing, TLS termination, access policies, health checks, logging, tracing, and built‑in Kubernetes ingress.

It frees us from the sidecar model and allows existing proxy technologies to be integrated into the kernel namespace concept, making them part of the container abstraction we use daily.

In short, eBPF promises to solve a major pain point of service meshes—performance loss when many fine‑grained microservices are present—but replacing sidecars with eBPF is a novel and controversial idea.

The data plane of a service mesh manages how traffic is routed to microservice applications, typically using sidecar proxies like Envoy, Linkerd, or MOSN. These sidecars handle routing, load balancing, health checks, authentication, authorization, encryption, logging, tracing, and metrics collection, and may also include SDK‑based frameworks such as Dapr.

Sidecar proxies run in the same pod or container as the microservice, but their resource consumption grows geometrically with the number of services, leading to significant overhead in large deployments. Providers have been improving performance, e.g., Linkerd rewrote its proxy from Go to Rust.

However, not all mesh vendors view eBPF as a panacea. Solo.io, a leading provider of Envoy‑based meshes, published an article titled “eBPF for Service Mesh? Yes, but Envoy Proxy will continue to exist,” arguing that sidecar proxies now perform complex tasks beyond simple traffic management, and that eBPF’s limited programming model and kernel security constraints restrict its applicability.

At Solo.io we see eBPF as a powerful way to optimize service meshes, while Envoy remains the cornerstone of the data plane.

Other developers, such as those at Terate.io, echo similar concerns, noting that while sidecar performance is reasonable and the community is improving it, building application‑specific data‑plane logic on eBPF is challenging due to its Turing‑incomplete nature.

Istio’s architecture is stable and production‑ready, and its ecosystem is maturing.

Many eBPF challenges stem from its nature as a kernel technology, which imposes security restrictions. WebAssembly (Wasm) emerges as a possible solution, offering near‑native performance while safely isolating user‑space code.

Envoy pioneered using Wasm as an extension mechanism for data‑plane programming. Developers can write custom proxy logic in C, C++, Rust, AssemblyScript, Swift, or TinyGo, compile it to Wasm, and run it via the proxy‑Wasm standard on high‑performance runtimes like Wasmtime and WasmEdge. Envoy, Istio Proxy, MOSN, and OpenResty all support proxy‑Wasm.

Wasm can also serve as a universal application container, extending beyond sidecar proxies. The WasmEdge runtime is lightweight, secure, fast, portable, and multi‑language, and can be managed directly by Kubernetes. By December 2021, the community demonstrated that WasmEdge‑based microservices can work with Dapr and Linkerd sidecars, offering a lightweight alternative to traditional Linux containers, consuming only about 1 % of resources and achieving 1 % cold‑start latency.

eBPF and Wasm represent emerging technologies for high‑performance data‑plane implementations in service meshes. While still nascent, they have the potential to become complementary or alternative solutions to existing Linux container‑based microservice ecosystems.