This article is based on an interview originally published by SiliconAngle.com, recorded at the Open Source Summit in Los Angeles. Ed Warnicke, Distinguished Consulting Engineer at Cisco Systems Inc., spoke with theCUBE co-hosts John Furrier (@furrier) and Stu Miniman (@stu).
The Network Is Now the Runtime
In software delivery, innovation moves fast — but nothing actually moves unless the network can handle it. For businesses adopting DevOps practices, network agility is no longer a nice-to-have: it is a prerequisite for organizational agility as a whole.
Ed Warnicke, Distinguished Consulting Engineer at Cisco Systems Inc., framed the challenge this way:
“The truth is, there’s a lot of work that goes into making the network invisible and ubiquitous for people. In particular, one of the challenges that we see arising as the world moves more cloud native, as the microservices get smaller, as the shift happens toward serverless, as Kubernetes is coming on with containers, is that the network is really becoming the runtime — and that runtime has the need to scale and perform like it never has before.”
Ed Warnicke, Distinguished Consulting Engineer, Cisco Systems Inc.
In other words, the network is no longer a passive pipe sitting beneath application logic. As workloads decompose into smaller microservices, containers, and serverless functions, the network itself becomes an active part of the execution environment — one that must meet the same reliability, scalability, and automation expectations as any other piece of infrastructure.
DevOps and NetOps: Why They Need Each Other
DevOps teams want the network to be invisible. They need it to be fast, reliable, and easy to consume — but they do not want to manage low-level networking details when their focus is on deploying and iterating software. This is not a criticism of network engineers; it reflects a healthy division of responsibility.
However, invisibility creates a new problem. As Warnicke put it: “The more invisible the network is, the more visibility you need when things go wrong.” When a microservice-to-microservice call fails, or latency spikes unexpectedly inside a Kubernetes cluster, the network team needs tools capable of deep inspection — per-flow tracing, real-time telemetry, and contextual diagnostics — not just ping and traceroute.
This creates a two-way dependency:
- DevOps needs NetOps to provide a network that scales automatically, exposes clean APIs, and stays out of the critical path of software delivery.
- NetOps needs DevOps to communicate what networking primitives and APIs are actually useful, so network engineers can write code and configure systems that serve real application requirements.
Without this dialogue, network tooling risks evolving in isolation — technically sophisticated but poorly matched to how modern applications are built and deployed.
Open-Source Projects Bridging the Gap
FD.io (“Fido”)
One project helping to close the distance between networking and DevOps practices is FD.io (pronounced “Fido”), a Linux Foundation collaborative project. FD.io is a high-performance, extensible I/O services framework designed for data plane workloads.
Key characteristics of FD.io include:
- Plugin-based extensibility: New functionality can be added by dropping plugins into a directory, without rebuilding the entire system. This aligns with DevOps principles of modular, composable infrastructure.
- High throughput at low latency: FD.io is built around VPP (Vector Packet Processing), which processes multiple packets per CPU instruction rather than one at a time, enabling wire-speed performance in software.
- Network visibility: Despite abstracting away complexity for application developers, FD.io provides the deep visibility that network operators need when diagnosing failures in distributed systems.
Beyond FD.io, the broader open-source community has produced tools capable of per-customer, per-flow network tracing — critical capabilities when debugging latency or connectivity issues in environments with thousands of concurrent microservice interactions.
What This Means for DevOps Engineers
For DevOps practitioners, the convergence of networking and DevOps tooling has several practical implications:
- Network-as-Code: Just as infrastructure is managed through code (Terraform, Ansible, Pulumi), network configuration increasingly follows the same pattern. Engaging with NetOps teams to expose network resources through well-designed APIs is a shared responsibility.
- Observability extends to the network: Distributed tracing, service mesh telemetry (e.g., Istio, Linkerd), and eBPF-based tools are making network-layer observability a first-class concern for DevOps teams, not just network engineers.
- Cloud-native networking demands cloud-native operations: Kubernetes CNI plugins, service meshes, and software-defined networking solutions require DevOps teams to understand at least the basics of how network policies, ingress, and east-west traffic function in containerized environments.
- APIs matter: As Warnicke noted, teams must actively work to support existing APIs and take advantage of new features as they become available. Staying current with networking APIs — whether from cloud providers, CNI implementations, or open-source projects — is increasingly part of the DevOps skill set.
Collaboration Is the Path Forward
The key message from Warnicke’s perspective is that neither DevOps nor NetOps can solve the challenges of modern distributed systems in isolation. Network operations teams must proactively engage with development and operations engineers to understand what they need. DevOps teams, in turn, benefit from learning enough networking fundamentals to have productive conversations about performance, reliability, and observability requirements.
Open-source projects like FD.io, along with the broader Linux Foundation networking ecosystem, are providing neutral ground where both communities can contribute, share tooling, and align on common standards — without being locked into any single vendor’s roadmap.
“You have to make sure you’re supporting all the stuff that’s there, and you have to work to take advantage of new features in existing APIs.”
Ed Warnicke, Cisco Systems Inc.
As the network continues its transition from passive infrastructure to active runtime, the organizations that invest in cross-team collaboration and open-source tooling will be the ones best positioned to scale.
Original source: SiliconAngle.com. Interview recorded at the Open Source Summit, Los Angeles. theCUBE is SiliconAngle’s mobile livestreaming studio.