For years, one of the cloud’s biggest gifts was that vendors like AWS could take care of the “undifferentiated heavy lifting” of managing infrastructure for you. Need compute? Click a button. Need storage? Click another. Need a database? Let someone else worry about the details. The whole point of managed infrastructure was to save most enterprises from spending their days swimming in low-level systems engineering.

AI is making that abstraction leak.

As I’ve argued, the real enterprise AI challenge is no longer training. It’s inference: applying models continuously to governed enterprise data, under real-world latency, security, and cost constraints. That shift matters because once inference becomes the steady-state workload of the enterprise, infrastructure that once seemed necessary but dull suddenly becomes strategic.

That’s especially true of the network.

The network is… cool?

For decades, networking was prized precisely because it was stable and uneventful. That was the point: No one wants exciting networking. Standards bodies moved slowly and kernel releases moved carefully because predictability was paramount. That conservatism made sense in a world where most enterprise workloads were relatively forgiving and the network’s job was mostly to stay out of the way.

Interestingly, the times when networking became sexy(ish) were times of significant technology upheaval. Think 1999 to 2001, when we had the dot-com bubble/internet infrastructure boom. Then in 2007, we saw broadband and mobile expansion. Later we saw cloud networking consolidation from 2015 to 2022. We’re about to see another big upward shift in networking interest because of AI.

Although observers posting on X still obsess over training runs, model sizes, and huge capital expenditures for data center build-outs to support it all, the real action is arguably elsewhere. For most enterprises, training a model occasionally isn’t the hard part. The harder part is running inference all day, every day, across sensitive data, inside shared environments, with serious performance expectations. Network engineers might prefer to toil away in relative obscurity, but AI makes that impossible. In the AI era, network performance becomes a first-order bottleneck because the application is no longer just waiting on CPU or storage. It’s waiting on the movement of context, tokens, embeddings, model calls, and state across distributed systems.

In other words, AI doesn’t simply increase traffic volume; it changes the nature of what the network does.

A different view of the network

This isn’t the first time we’ve seen a network paradigm shift. As Thomas Graf, CTO at Cisco Security, cofounder of Isovalent, and the creator of Cilium, said in an interview, “The rise of Kubernetes and microservices was the first wave of east-west traffic acceleration. Instead of a single monolith, we broke applications up, and that immediately required security not just at the firewall but east-west inside the infrastructure.”

AI compounds that shift. These workloads aren’t just a few more services talking to one another. They involve synchronized GPU clusters, retrieval pipelines, vector lookups, inference gateways, and, increasingly, agents that continuously exchange state across systems. That’s a different operational world from the one most enterprise networks were built to support. “With AI workloads,” Graf continues, “that’s a hundred times more [data moving around]. Not because things are more broken up, but because AI runs at a scale that is bigger and needs an insane amount of data.”

That “insane amount of data” is why the network matters again and why developers need to think about it again.

In AI environments, the fabric increasingly becomes part of the compute system itself. GPUs exchange gradients, activations, and model state in real time. Packet loss isn’t just an annoyance, as it can stall collective operations and leave expensive hardware idle. Traditional north-south visibility isn’t enough because much of the important traffic never crosses a classic perimeter (e.g., user request to a server). Hence, security policy can’t live only at the edge because the valuable flows are often east-west inside the cluster. And because enterprises are still discovering what their AI demand curves will look like, elasticity matters, too. Networks have to scale incrementally, adapt to mixed workloads, and support evolving architectures without forcing a full redesign every time the AI road map changes.

In other words, AI is making the network less like plumbing and more like part of the application runtime.

Getting serious about Cilium

That’s why eBPF matters. The official eBPF project documentation describes Cilium as a way to safely run sandboxed programs in the kernel, extending kernel capabilities without changing kernel source or loading modules. The technical details are important, but the broader point is simple: eBPF moves observability and enforcement closer to where packets and system calls actually happen. In a world of east-west traffic, ephemeral services, and machine-speed inference, that’s a big deal.

Cilium is one important expression of that shift. It builds on eBPF to provide Kubernetes-native networking, observability, and policy enforcement as fast as the network link itself can carry traffic without becoming a meaningful bottleneck. This is critical to network performance. Unsurprisingly, Cilium has become mainstream table stakes for hyperscalers’ networking stacks. (Google’s GKE Dataplane V2, Microsoft’s Azure CNI Powered by Cilium, and AWS’s EKS Hybrid Nodes all depend on or support Cillium.) Indeed, across the Kubernetes user base, as the 2025 State of Kubernetes Networking Report indicates, a majority use Cilium-based networking.

As important as Cilium is, however, the bigger story is that AI is forcing enterprises to care again about infrastructure details they had happily abstracted away. That doesn’t mean every company should hand-roll its network stack, but it does mean that platform teams can no longer treat networking as an untouchable utility layer. If inference is where enterprise AI becomes real, then latency, telemetry, segmentation, and internal traffic policy are no longer secondary concerns. They’re an essential part of product quality, operational reliability, and developer experience.

More than the network

Nor is this isolated to Cillium, specifically, or networking, generally. AI keeps forcing us to care about things we’d hoped to forget. As I’ve written, it’s fun to fixate on fancy AI demos, but the real work is to make these systems work reliably, securely, and economically in production. Just as important, in our rush to make AI dependable at enterprise scale, we can’t overlook the need to make the whole stack easier to use for developers, easier to govern by IT/ops, and faster under real-world load.

“If an AI-backed service responds faster and behaves more reactively, it will perform better in the market. And the foundation for that is a highly performant, low-latency network without bottlenecks,” notes Graf. “To me, this is very similar to high-frequency trading. Once computers replaced humans, network latency and throughput suddenly became a competitive differentiator.”

That feels right. The winners in enterprise AI won’t simply be the companies with the biggest models. Success comes from making inference reliable, governed, and economical on real data under real load. Some of that battle will be won in models. More of it than many enterprises realize will be won in the supposedly boring layers underneath, like networking.