Why eBPF Hasn't Taken Over IT Operations — Yet
Despite its potential to revolutionize observability and security, eBPF faces adoption challenges due to coding complexity, kernel dependencies, lack of Windows support, and competition from established tools.
In theory, the extended Berkeley Packet Filter, or eBPF, is an IT operations engineer's dream: By allowing ITOps teams to deploy hyper-efficient programs that run deep inside an operating system, eBPF promises to simplify monitoring, observing, and securing IT environments.
This begs the question: If eBPF is so great, why isn't it running everywhere? After all, eBPF technology has existed for years and has received plenty of attention in the IT community (including from this website). Why are IT pros still doing things the old way rather than turning to eBPF?
The answer, I think, involves multiple factors.
What Can You Do with eBPF?
Before exploring the reasons why eBPF has achieved limited adoption, let's briefly go over what eBPF is and what it can be used for.
eBPF is a framework built into the Linux kernel that makes it possible to write and execute custom programs. The programs can collect virtually any type of data from the system on which they're running. This makes eBPF a powerful way to collect information for security monitoring, system monitoring, and performance management purposes.
In addition, because eBPF programs run in a sandboxed environment, they're more secure and stable than traditional methods of kernel-level code execution (like inserting kernel modules). You also don't need to modify any kernel code or recompile your kernel to run eBPF programs; you can load and execute them into a running system on the fly, which makes eBPF very flexible.
eBPF originated in the mid-2010s as an improvement upon the Berkeley Packet Filter, a decades-old technology for network packet capturing and filtering on Unix-like systems.
eBPF's Limited Adoption
Since its emergence about a decade ago, eBPF has certainly seen some adoption. For example, the Cilium open source project uses eBPF for observability and security in cloud-native environments. Some commercial monitoring and observability tools also now support eBPF to collect data.
On the whole, however, eBPF seems not to have taken off as rapidly as one might have expected, given the potentially revolutionary nature of the technology. For example, in the realm of observability, OpenTelemetry — a framework that doesn't use eBPF natively — remains a hot topic. (An eBPF collector is available for OpenTelemetry that makes it possible to use the two frameworks in concert, but the collector hasn't seen much development activity over the past year.) In security, too, eBPF has yet to transform the landscape.
Explaining the State of eBPF
A number of factors explain why eBPF hasn't proven as revolutionary as it once appeared.
1. The complexity of eBPF code
Writing eBPF programs requires specific expertise. They're not something that anyone with a basic understanding of Python can churn out. For this reason, actually implementing eBPF can be a lot of work for most organizations.
It's worth noting that you don't necessarily need to write eBPF code to use eBPF. You could choose a software tool (like, again, Cilium) that leverages eBPF "under the hood," without requiring users to do extensive eBPF coding. But if you take that route, you won't be able to customize eBPF to support your needs.
Unless eBPF coding becomes easier or more people learn to write eBPF programs, I see the complexity of these programs as a major barrier to further eBPF adoption.
2. Kernel-specific dependencies in eBPF
Virtually every Linux kernel release brings with it a new version of the eBPF framework. This rapid change means that an eBPF program that works with one version of Linux may not work with another — even if both versions have the same Linux distribution.
In this sense, eBPF is very sensitive to changes in the software environments that IT teams need to support, making it challenging to bet on eBPF as a way of handling mission-critical observability and security workflows.
3. Lack of Windows support
For now, at least, eBPF only works on Linux. A Windows eBPF variant is theoretically in the works, but it has been under development now for years, and it's unclear when, if ever, it might become available for real-world use.
This limitation means that eBPF can't be a platform-agnostic solution, making it less attractive to businesses that run workloads outside of Linux environments.
4. eBPF has mature competitors
A final factor behind limited eBPF adoption is that great tools already exist that don't leverage eBPF. In this sense, eBPF offers a new means to the same end — and given that the traditional means worked well enough for many organizations, few likely see a reason to switch to eBPF.
To be sure, eBPF offers advantages like greater efficiency, which can translate to lower infrastructure costs because eBPF programs are likely to consume fewer CPU and memory resources than traditional tools. But given the hesitancy of most folks to fix what is not broken, you can't blame IT teams for not wanting to adopt eBPF if their existing, non-eBPF solutions already work for them.
Conclusion: The Future of eBPF
Over time, I expect that eBPF adoption will continue to grow. But it will be slow because the chief user base for eBPF is relatively small. It consists of IT teams that work solely with Linux, that are comfortable with the complex task of writing eBPF programs, and that see enough value in the advantages of eBPF to want to use it in place of their traditional tools.
Everyone else will stick with what they've already been using for the foreseeable future, regardless of how amazing eBPF may be.
About the Author
You May Also Like
