Welcome to our second edition of our annual predictions! After last year’s 17 projections, I am once again tasked with forecasting the future of networking, security, and cloud native technologies.
Once more, my premonitions are unabashedly biased and greatly influenced by, not only my current interests, but also by some of my Isovalent colleagues who joined me for a looking-ahead show at the end of last year.
But before we start predicting the future, let’s first check in on my previous prophetic performance.
2024 Predictions Review
Overall, last year’s predictions were a hit and miss.
My assumption that IPv6 would become the norm for Kubernetes clusters was incorrect. My omen that eBPF fatigue would set in couldn’t have been more incorrect.
But I correctly foresaw the disruption that came in with the Broadcom acquisition of VMware. I was right about container networking performance achieving parity with the host. It wasn’t premature to claim that AI agents would help us interface with our networks (John Capobianco, an expert in AI for networking, proves it in this video on AI agents).
And I have seen plenty of evidence that platform engineering and networking are like a couple struggling to reconcile their differences.
Food for Thought: Savoring a Feast of Networking Predictions
For a more neutral review of my predictions, I'd highly recommend the renowned industry analyst Brad Casemore's take on my predictions.
Start Reading
Let’s now start with this year’s predictions.
eBPF Will Finally Come to Windows
There are evident signs that eBPF is maturing. It’s not common that kernel subsystems become IETF standards but with projects implementing BPF programs through device offload, it became essential to standardize the BPF instruction set. The RFC 9669 now provides a standard outside of the in-kernel implementation, which is timely given the upcoming release of eBPF for Windows.
2025 is indeed when eBPF might finally reach “General Availability” status for Windows. In May 2021, Microsoft announced they were working on a project – aptly named ebpf-for-windows – to make eBPF work on Windows 10 and Windows Server 2016. While you still need to switch Windows to a special development mode in order to run eBPF, it’s never been closer to reality.
Frankly, I’d argue it’s surprising it took so little time to bring a Linux API standard to Windows.
The good news is that the eBPF runtime is expected to be backwards-compatible all the way to Windows Server 2019, meaning you won’t need the latest version of Windows to benefit from it.
The most immediate use case for it? Security. While Cilium‘s port to Windows will benefit anyone running Windows containers on Kubernetes, eBPF-based tools such as Tetragon will immediately bring an entirely new level of threat mitigation capabilities, helping users deal with the tedious and everlasting task of system patching.
AI and eBPF’s Security Revolution Will Arrive but You Should Remain Cautious
Expect to see a flood of new products, projects and tools around security with eBPF baked in. In the same way we’ve seen the entire observability space overtaken by eBPF (with even the popular OpenTelemetry framework joining in the eBPF love), eBPF is coming for security next.
Combining eBPF’s real-time data collection with pattern matching across global threat databases could enable instant detection of vulnerabilities, automatic CVE correlation, and AI-generated plain-language explanations of security events – making complex security insights accessible to all team members.
Or at least, that’s what we hope will happen.
As zealous as you might be about eBPF and AI, remain cautious about the effectiveness of AI-generated policies. As I discuss further below, hallucinations are inevitable, and implementing an incorrect network policy could create more problems than it solves.
Funding of eBPF Startups Will Soar
Prior to the eBPF and Cilium (eCHO) predictions episode (embedded earlier in this post), Liz asked her LinkedIn network for their opinion on what would have the most impact on eBPF and cloud native. You can see that I voted for VC funding for eBPF startups: I believe that we will see over $100M invested into eBPF-centric start-ups over the course of 2025.
$100M is probably on the lower-end: after all, 2024 saw Upwind, Qpoint, Odigos and others achieving funding rounds that exceeded that total.
The market for eBPF developers has never been more buoyant.
Will AI Become Our Next 10x eBPF Developer?
Could ChatGPT create the next Cilium? Creating a basic CNI from scratch is easy enough. Writing a simple one with Ollama is achievable (as demonstrated during this entertaining KubeCon session by Doug Smith). But building a powerful eBPF-based networking tool is a significant undertaking, especially given that kernel and eBPF knowledge remain scarce. Will AI help?
If AI can somehow analyse the output of the eBPF verifier, a critical component of the BPF subsystem, it could remove one of the biggest hurdles for many developers without assembly and low-level kernel knowledge (the output of the verifier can be so cryptic the eBPF community is looking at crowd-sourcing eBPF verifier errors).
Daniel Borkmann, the co-creator of eBPF and Cilium who featured heavily in the eBPF documentary, even asked ChatGPT to write a L4 load-balancer in eBPF. The result was better than anticipated but still – the output code was a poorly-performing UDP-only load balancer (ChatGPT just decided TCP support would be too much effort).
Daniel’s job is safe – but for how long?
(I am being facetious: Daniel is, of course, irreplaceable)
AI Hallucinations Will Have Repercussions on Our Networks
Have you heard the story of the Los Angeles man who nearly missed his flight after his self-driving vehicle wouldn’t stop making circles in a parking lot?
If Waymos get stuck in a literal routing loop, don’t you think that the same will happen to self-driving IP packets? While we feed AI models mountainous volumes of data, it still remains very often prone to hallucinations.
I expect that AI-generated incorrect network configuration will cause many to regret having blindly trusted the response from the prompts.
Netkit Will See a Quasi-Immediate Widespread Adoption
Last year, I predicted that container networking performance would match host network performance. With netkit – the successor to the virtual ethernet device – we have now reached performance parity. What I am predicting this year is a swift adoption of netkit.
Even though netkit requires a recent Linux kernel, we have already seen a surprisingly quick rollout: in fact, if you watch any videos on Instagram or TikTok, you’re already benefitting from netkit’s performance gains.
ByteDance – the company behind Tiktok – shared at the recent eBPF Summit how they’re embracing netkit across a million servers and how it led to a 10% improvement in throughput.
Another social media giant will talk about the performance gains – and challenges – they faced when rolling out netkit across millions of containers at Meta at the upcoming FOSDEM.
Disruptive technologies are often rolled out first by content providers unafraid of cutting-edge technologies but I expect netkit to start being deployed in productions in other industries (financial institutions and service providers) where aiming for optimal performance is the standard.
Kubernetes Becomes the Operating Model for Virtual Machines
In last year’s predictions, I mentioned that the Broadcom acquisition of VMware would have an impact on the networking industry. I underestimated the potential ramifications of the acquisition as they spread beyond just networking.
Users have turned to Kubernetes to run virtual machines – and often leveraged Cilium to secure and connect virtual machines as efficiently as it’s been used for containers. KubeVirt has existed for 8 years but last year was the year it took off, to the extent that we created labs, wrote blog posts and ran webinars on how to connect and secure KubeVirt-based virtual machines.
Expect 2025 for KubeVirt to continue its exponential growth and for the broader Kubernetes community to innovate at pace to provide an alternative for VMware administrators.
Connecting and Securing VMs with Cilium
With KubeVirt and Cilium, you can achieve Zero-Trust security for your Kubernetes-based Virtual Machines.
START LAB
As users start using Kubernetes to run virtual machines, they will start a gigantic wishlist for security, networking, load balancing needs that now need to be fulfilled.
Kubernetes had not been designed to run VMs. Despite the broad similarities in the virtualization and containerization form factors, they have drastically different storage and networking demands. Of course, we see eBPF as the obvious candidate to fill those gaps.
eBPF Rejuvenates the Networking Industry
As a hardened networking veteran, I have observed how our industry is constantly re-inventing itself (or recycling if you’re more of a cynic).
Software-Defined Networking (SDN) like VMware NSX mirrors physical networking concepts. Cilium itself is a form of SDN for Kubernetes.
In fact, the entire networking model oscillates between the centralized and distributed networking model (as Andreessen Horowitz General Partner Peter Levine described in his 2017 “The End of Cloud Computing” talk).
We constantly see networking ideas being re-introduced as user needs change and as new technologies empower networking innovators to offer a fresh take on an existing concept.
In 2025, we will see eBPF used to reinvigorate networking. eBPF will be used for the notoriously difficult challenge of “adaptive routing” (forward data onto a different route for a given destination if adverse conditions are observed). eBPF will soon bring Quality of Service to Cilium – enabling users to prioritize network traffic of specific workloads over others) to Cilium.
But of all networking technologies, we see load-balancing as the ripest area for disruption. Innovation in the broader ADC (Application Delivery Controller) market has stalled but Cilium’s Maglev support for Google’s own ultra-fast load balancer shows that load balancing remains a market category where innovation is possible. Users will aspire to a high-performant and cost-effective load balancer that is API-driven, Kubernetes-aware and with VM/Multi-Cloud support.
Kubernetes Scheduling Will Finally Become Networking-Sentient
One of the first blog posts I wrote for Isovalent was on a lesser-known feature called “Bandwidth Manager”. At the time, I talked about how Kubernetes was a scheduler aware of compute demands but with little understanding of the networking demands required by a pod. What I hope we’ll get to see in the coming years is an improvement of how Kubernetes places workloads. Presumably, the vast networking telemetry we collect and the intelligence and automation we can derive from it should help us make networking-aware schedule decisions.
I hope that the Kubernetes scheduler finally becomes networking-aware. I expect it will be able to place workloads closer to each other if they frequently communicate together or place pods onto different nodes if they hog too much networking capacity.
That’s not the only scheduler undergoing change: the eBPF-based scheduler got merged into the Linux kernel last year. This might also soon impact Kubernetes: expect to see developers writing custom process schedulers to accelerate network workloads.
It’s not the only disruption to Kubernetes networking I anticipate.
Kubernetes Networking Adjust To AI Workloads
I recently wrote in the New Stack about Kubernetes’ evolution as it begins its second decade. I will expand on one of the predictions I made in the article: Kubernetes networking will evolve to cater for AI workloads. I previously wrote about the pressure AI workloads are placing on Kubernetes – the need for a scalable, high-performance and secure cloud native networking layer has never been more vital.
It’s a turbulent time, which is not helped by the industry vacillating between Ethernet and Infiniband as the method for remote direct memory access (RDMA) transport (RDMA provides AI workloads access to remote GPUs).
One of the Kubernetes projects to follow in this space is Google’s dranet. Based on Kubernetes’ Dynamic Resource Allocation, it aims at delivering high-performance networking for demanding applications in Kubernetes.
Deeper in the kernel, keep an eye on another project looking at accelerating AI traffic: Device Memory TCP (a.k.a “Devmem TCP”) aims at transferring data to and from device memory efficiently; greatly accelerating GPU throughput.
As current models continue to grow to trillions of parameters and beyond, expect cloud providers to follow in Google’s footsteps: GKE, which runs on Cilium, now supports up to 65,000 nodes to support large language models training.
Final Words
What did you think? Which predictions do you agree with? Come and find me on LinkedIn and let me know what you think.
Prior to joining Isovalent, Nico worked in many different roles—operations and support, design and architecture, and technical pre-sales—at companies such as HashiCorp, VMware, and Cisco.
In his current role, Nico focuses primarily on creating content to make networking a more approachable field and regularly speaks at events like KubeCon, VMworld, and Cisco Live.
