Networking and eBPF Predictions for 2024 and Beyond

With the new year beginning, it feels like the perfect time to make some predictions. I’ve had a mixed success with predictions over the years. My sporting predictions have been historically dreadful. My technology predictions have fared better although sometimes they took a little longer than I expected to come true (I wrote a Machine Learning for Networks blog post back in 2015 and it’s still pretty relevant).

Here are some of my predictions for 2024 and beyond. These predictions are primarily centered around my interest – eBPF, Cilium, the cloud native world and the broader networking, observability and security spaces. I took some input from several of my esteemed colleagues here at Isovalent but I will shoulder the blame if none of them turns out to be true!

Let’s get started!

eBPF Will Continue Its Exponential Growth

We saw an explosion of eBPF-powered networking and security projects last year. I’ve not kept track of how many were created but the popularity of Liz’s Learning eBPF book, the eBPF labs we host and events like the eBPF summit and of course, the eBPF documentary highlight how popular eBPF is becoming.

I expect that the total of eBPF-based projects will easily exceed triple-digits next year.

There’s an eBPF App for That

You only need to look at all the projects highlighted in ebpf.io to see the eBPF growth – two years ago, there were 9 projects highlighted. At time of writing, there are 41 projects covering a wide range of use cases: CNI of course, high performance load balancing, cloud native runtime security, observability, profiling and even sustainability – eBPF is now able to estimate energy consumption.

Bill often compares eBPF to the equivalent of an App Store for Linux. I love this analogy and I would actually push it further. I anticipate some form of registry where you can not only download and install eBPF programs but verify that these programs won’t clash with each other.

Expect to see the concept of an eBPF Store developing in the coming years.

eBPF Misuse Will Lead To eBPF Fatigue

With the gold rush towards eBPF, it will inevitably cause some misuse. While the eBPF verifier aims to ensure that eBPF programs are safe to run and should prevent dangerous behaviours, the more a technology is used, the more likely some form of vulnerability will be discovered.

This will lead to some backlash around eBPF: after all the excitement around eBPF in the past couple of years, some eBPF fatigue is bound to set in.

As a bonus prediction, I will actually predict a multiplication of eBPF-based applications to control and monitor eBPF-based applications.

eBPF Is Coming to Your Phone

This prediction has already come true, although you may not know it yet. eBPF is already used by millions of Android users every day.

The initial use case of eBPF in Android was to measure network traffic statistics to replace 3,000 lines of out of tree code but now every networking packet entering your phone also runs through eBPF.

eBPF on Android is used for:

• Data use and accounting
• Firewalling/Network restrictions for power saving once you enter battery saver mode
• High speed packet processing like tethering or 464xlat (a method to provide IPv4 connectivity over an IPv6 network) as it’s not natively supported by the Linux kernel.

This video from the IETF 116 meeting in Japan provides a great and brief walkthrough of eBPF on Android.

What I predict is more use cases for eBPF on mobile devices and not just on Android devices.

Don’t be surprised if Cilium is running in your pocket in the coming years.

Kubernetes Users Will Fight Back Against Complexity

We often laugh about the complexity of the cloud native ecosystem by pointing out the ever-growing cloud native landscape. But it’s no joke.

I often see people on social media complaining about the complexity of the stack required to operate a cloud native platform.

The tool sprawl is particularly an object of contempt – there is a lot of fatigue caused by maintaining and operating the multitude of cloud native tools used by most organizations.

What Platform and DevOps engineers want in 2024?

Simplicity.

I expect many Platform and DevOps engineers to invest time in 2024 in simplifying their toolkit.

And as a consequence, expect to see the cloud landscape to start shrinking.

A New Category Emerges: Heterogenous Networking

Interestingly, several of the sessions at CiliumCon – the Cilium-focused event that preceded KubeCon in Chicago – were about life outside Kubernetes. Sessions discussed OpenStack (still alive and kicking, thank you very much) and Nomad and how Cilium can be used in these environments for network connectivity and security.

There’s often the temptation, when a technology takes the world by storm, to forget about everything that preceded it. While Kubernetes is now the accepted underlying container platform, there are at least 85 million virtual machines running on vSphere according to VMware/Broadcom and most likely as many EC2 instances running on AWS. Not to mention, you know, actual physical bare-metal machines.

So in 2024, we will see projects like Cilium Mesh – announced during CiliumCon 2022 in Amsterdam – that will look at plugging the gaps between the Kubernetes world, the VM world, the serverless world, etc… Expect to see networking projects to come out next year will try to connect and secure these heterogenous workloads.

IPv6-only Kubernetes Clusters Become the Norm

I couldn’t make networking predictions without, of course, mentioning IPv6. Three years ago, 31% of Google users were using IPv6. We’re now up to 45% and at the current rate, IPv6 will be the majority protocol seen by Google users worldwide (it’s already over 70% in countries like France and India) by the end of 2024.

But does the momentum behind IPv6 extend to Kubernetes? Partially.

About 15 months ago, I wrote a detailed post on LinkedIn describing some of the progresses and limitations when running Kubernetes on IPv6 clusters. While there have been significant improvements from the managed Kubernetes service providers (AKS, GKE and EKS), IPv6 remains a secondary option, is often less documented and does not seem particularly encouraged. And until recently, many of the essential cloud native tools had several IPv6 shortcomings.

Cilium did introduce native support for NAT46/NAT64 to provide inter-compatibility between IPv6-only clusters and the IPv4 world and I see other positive signs.

GitHub is apparently working on finally providing IPv6 support for its registry and Docker Hub Registry IPv6 Support is now generally available. And there are several other factors that will accelerate IPv6 adoption in Kubernetes.

• Cost: AWS’s recent price increase for public IPv4 addresses will encourage users to move to IPv6
• Operational Simplicity: Segment Routing version 6, (SRv6) a technology primarily used by telcos, is coming to Kubernetes and has the potential to drastically simplify network connectivity and programmability at scale. I’m expecting a lot of interest from Telcos in leveraging Segment Routing in their clusters.

• Performance: introducing high performance networking features like BIG TCP to IPv6 first before IPv4 support will give users more reasons to move to IPv6.

While scale and IP address exhaustion are perfectly valid reasons to adopt IPv6, it will be embraced even faster once it becomes clear it renders the network cheaper and faster.

Platform Engineering Begins an Awkward relationship with Networking

According to Gartner, “platform engineering improves developer experience and productivity by providing self-service capabilities with automated infrastructure operations”.

I am really looking forward to seeing the intersections of platform engineering and networking. I guarantee you that some platform engineers will be absolutely terrified to let developers have self-service networking power.

How do you provide independence and flexibility to developers and other consumers of your IDP (Internal Developer Portal) without them making some terrible networking decisions and endangering the applications they are launching? Organizations will have to find the right balance between autonomy and control.

While building developer portals will remain a focus for many in 2024, I am expecting a lot of growing pains with regards to how much networking independence is afforded.

And before software engineers think I treat them unfairly – just know: you really wouldn’t want to let me anywhere near your code (my coding skills can best be described as mediocre).

Wasm Is Having a Wow Moment

“eBPF is to the kernel what Javascript is to the browser” has often been used to explain what eBPF is. Interestingly, another popular cloud native technology – Web Assembly (Wasm) – has a similar claim. While Javascript was the popular method to run programs in the browser, Wasm provides an abstraction capable of running C/C++, C# and Rust programs within the web browser. 

With containerd adding native support for Wasm, I expect Wasm to take off even further in 2024. Even better – given eBPF’s powers, securing and connecting applications with Cilium will work seamlessly.

Observability Observability Observability

The most popular topic at KubeCon according to this excellent blog post was Observability. 

While many organizations will dedicate time and effort in building their internal development platform (platform engineering will probably be the most popular topic at next year’s KubeCon), I envision that many organizations will be focusing on improving their observability capabilities.

Large organizations are going to need help making sense of the sprawl of clusters and pods in their environment.

Easing the Observability Overhead Burden

The volume of data that comes with observing everything that happens in clusters – and some of the Kubernetes deployments highlighted during KubeCon and CiliumCon involved hundreds of clusters and hundreds of thousands of pods – is the observability overhead.

With so many daemons running in clusters – for logging, monitoring, security – I wouldn’t be surprised if the resources used to monitor clusters doesn’t soon exceed the actual applications running on these clusters.

Yes, it will cost some users more in monitoring applications than running the applications themselves.

With the increased focus on the FinOps framework, I’m expecting that engineers will start looking at the tools that are too resource hungry.

That’s one of the reasons Tetragon’s popularity is soaring – the use of eBPF means monitoring events only comes with a tiny overhead.

Kubernetes Workloads Will Be Contextualized

Context-Aware is not a new concept (I remember pitching context-aware security back when I was working for Cisco over 10 years ago) but it’s something that will see more attention in the coming years.

Containerization introduces so many layers of abstractions – for the benefits that we know – that context is lost in the process. For example, we know that a pod often includes multiple containers (sometimes dozens of them!), which all share an IP address. Applying a security policy for one container often means we give all the other containers in the pod far more privileges than they required.

I’m expecting a lot of interest in what Thomas presented at KubeCon: integrating Tetragon’s context with Cilium Network Policies – is potentially transformative.

Container Networking Performance Matches Host Networking Performance

The only session I had the chance to watch at KubeCon Chicago was Daniel Borkmann’s “Turning up Performance to 11: Cilium, NetKit Devices, and Going Big with TCP”.

It must be challenging for Daniel to come up with another hit, after having co-created one of the most transformative networking technologies in the past decade (eBPF). Daniel’s now set himself a challenge to push the boundaries of container networking performance to reach a level of parity with host networking.

The Linux networking stack includes so many detours and hops and Daniel and all the developers behind technologies such as XDP (Express Data Path) and BIG TCP had to find ingenious ways to find shortcuts or look at optimizations.

With the recently announced netkit (and the ability to run eBPF programs at the container level), I am predicting that we will be reaching parity in networking performances. And while it may take a little while for these features to be available on a commonly deployed kernel, the feature of networking is exciting.

The Networking Industry Is Bracing for Change

The network industry is going to undergo one of its most significant transformations next year, caused by several events occurring at the same time. 

• Broadcom’s acquisition of VMware will lead some organizations to reconsider their commitment to the VMware technology stack. This, in turn, will have an impact on the adoption of NSX as a virtual network technology.
• Open Source networking has never been as popular. 2023 has seen the first Network Automation and NetDevOps conferences – technology trends supported primarily by open source projects. The popularity of the Awesome Network Automation GitHub repository and of many of the tools highlighted in this repo – I am a big fan of projects such as GoBGP and containerlab – highlight how the network industry has changed in the past decade.
• Open Source networking has never been as powerful. In the past, you could have made a case that open source networking came with a compromise in terms of features and performances compared to proprietary solutions. When you consider some of the performance gains achievable through technologies such as eBPF and XDP, this evidence supporting this argument has become tenuous. The performance improvements in this use case are mind-boggling (who wouldn’t want a 72x improvement in CPU footprint).

Expect the next couple of years to see a radical disruption in the networking industry; perhaps the biggest since the software defined networking movement started.

Cilium Making Its Way to Your Home

We’ve seen adoption of Cilium in edge environments growing in recent years. We know of many organizations in industries such as retail and healthcare deploying cloud native edge compute platforms and using Cilium to bring networking and firewalling closer to the workloads. 

What we explored in a recent eCHO episode is how and most importantly why you might use it in your home labs. Not many of you will need to host a gaming rig on your Raspberry Pis but at least, you know that with Cilium, you can secure your applications with Network Policies and expose them externally with the built-in support for BGP and Gateway API.

I expect Cilium to become really popular in home labs this year.

Will AI Tell Me What Broke My Network?

I couldn’t make a prediction in 2024 without talking about Artificial Intelligence and Machine Learning. Before I talk about how network engineers might leverage natural language processing, let’s talk about how network products might use AI.

This might be an obvious prediction but I can guarantee that networking tools will begin to natively integrate with LLM to provide a chat-like experience to interact with the network.

I’d love to log on to my Grafana dashboard and have a conversation with it. For example – imagine being able to ask why your users complained last night and being told by a chatbot that traffic dropped between 10 and 11PM and that the likely culprit was a misconfigured network policy.

I’d love to give simple instructions to a chatbot about the architecture I want to build and in response, to get a ready-made Terraform configuration.

I’d love to talk to my network and ask it why it’s stuck in a routing loop.

Networkers Turn To LLM for Help – And Some Will Regret It.

Network engineers have already been using ChatGPT to help them troubleshoot network issues and generate networking configuration.

But even if I personally use ChatGPT on a frequent basis and I have been largely impressed by it, I am not quite ready to hand over the keys to it (yet). It is similar to some of the valid concerns around network automation – it might be extremely powerful but you’d better understand the technology used underneath it otherwise, good luck troubleshooting a mistake made in the automation process.

But while there will be inevitable hiccups (I predict the first reported major network outage caused by a network chatbot), AI and LLM will have a transformative impact on networking.

Final Words

I’ve set myself a reminder to revisit these predictions in a year’s time and see how many I got right (if any!). In truth, we had almost 30 predictions but some were so wild that we decided to trim it down.

Agree with any of them? Or do you think I missed the mark with my predictions? Come and find me on LinkedIn and let me know what you think.