This article is based on coverage originally published on infoq.com. The discussion below expands on the core concepts for a DevOps engineering audience.
The Convergence of DevOps and Networking
For years, networking was treated as a discipline apart from software development and systems operations. Network changes were manual, infrequent, and governed by change-management processes that stood in sharp contrast to the rapid iteration cycles championed by DevOps teams. That gap is closing. Practices from the DevOps world — automation, version control, continuous delivery, and observability — are being systematically adopted into the management of networking services, driven by better tooling, more programmable hardware, and the rise of software-defined networking.
Key DevOps Practices Being Adopted in Networking
Several DevOps disciplines translate directly into networking contexts:
- Networks-as-Code — Declaring desired network topology and behavior in version-controlled configuration files, then applying that state programmatically to physical or virtual devices.
- CI/CD Pipeline Integration — Treating network configuration changes as deployable artifacts, validated and promoted through automated pipelines before reaching production.
- Container-scale Network Functions — Decomposing network services into smaller, independently deployable units that can run in containers rather than on dedicated appliances.
- Chaos Engineering for Networks — Deliberately injecting network faults to validate resilience and expose hidden dependencies before they cause unplanned outages.
- Unified Monitoring and Observability — Extending the same monitoring stacks used for applications and infrastructure to cover network-specific metrics and events.
Networks-as-Code: Declaring Intent, Not Commands
The infrastructure-as-code (IaC) pattern — where the desired state of infrastructure is expressed in declarative files and enforced by automation tools — maps naturally to networking. With networks-as-code, engineers describe how a network should look and behave: which VLANs exist, how routing tables should be configured, what firewall rules apply. An automation tool then reconciles the live network against that declared state.
Historically, network device configuration has been standardized through protocols such as NETCONF (Network Configuration Protocol, RFC 6241), but adoption in automation toolchains was slow. That changed as mainstream DevOps tools added native networking support:
- Ansible introduced dedicated modules for networking device automation, covering hardware from multiple vendors including Cisco, Juniper, Arista, and others. These modules allow network configuration tasks to be expressed as Ansible playbooks alongside server and cloud automation.
- SaltStack provides similar networking modules, enabling event-driven and scheduled configuration management of network devices.
- NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) is an open-source library that provides a vendor-neutral Python API for interacting with network devices. It integrates with both Ansible and Salt, allowing engineers to write automation that works across different vendors’ hardware without rewriting logic per platform.
Virtual Network Functions and Containers as Experimentation Platforms
One barrier to adopting automation in networking has been the risk of experimenting directly on production hardware. Virtual Network Functions (VNFs) — network capabilities such as firewalls, load balancers, or routers running as software on virtual machines rather than on dedicated physical appliances — lower that barrier considerably. Teams can test automation workflows against virtual instances before applying them to production hardware.
VNF adoption has been particularly pronounced in the telecommunications industry, where operators are under pressure to provision and reconfigure network services rapidly. Beyond virtual machines, some network functions are being containerized, enabling faster startup times and denser packing on commodity hardware. Not all network functions are well-suited to containerization — those with high throughput requirements or tight hardware integration may still require VMs or dedicated appliances — but the trend toward containerized network functions is growing.
Software-Defined Networking as an Automation Enabler
Software-Defined Networking (SDN) separates the control plane (decisions about where traffic goes) from the data plane (the actual forwarding of packets). By exposing the control plane through APIs and programmable interfaces, SDN makes network devices far more amenable to scripted and automated configuration. As more networking services are delivered through SDN architectures, the surface area available for DevOps-style automation expands correspondingly.
Chaos Engineering Applied to Network Reliability
Chaos engineering — the practice of deliberately introducing failures into a system to uncover weaknesses — is well established for application and infrastructure layers. Its application to networking is less mature. Network chaos experiments might include simulating link failures, injecting packet loss or latency, or partitioning network segments to observe how applications and failover mechanisms respond.
At the time of the original reporting, chaos engineering in the networking domain was still in early stages. The principles are sound: if you do not proactively test how your network behaves under failure conditions, you will discover those behaviors during an incident instead.
Monitoring and Observability for Networks
Networks are increasingly monitored using the same tooling that observes the rest of the stack — time-series databases, dashboards, alerting systems, and distributed tracing platforms. Some of these tools include network-specific extensions or integrations, such as SNMP polling, flow data collection (NetFlow, sFlow, IPFIX), and BGP/routing state monitoring. Unifying network observability with application and infrastructure observability gives teams a single plane of glass for diagnosing cross-layer issues, rather than requiring separate NOC and operations workflows.
The Human Factor
Automation does not eliminate the human element in network reliability — it changes it. Studies on network reliability have identified human error as a leading cause of outages, which motivates investment in automation to reduce manual, error-prone steps. At the same time, effective automation requires skilled engineers who understand both the networking domain and the software engineering practices needed to build and maintain reliable automation pipelines. Bridging this skill gap is one of the central challenges in the NetDevOps or Network Reliability Engineering space.
Summary
The application of DevOps principles to networking is not a distant aspiration — it is actively happening, driven by programmable hardware, open-source tooling like Ansible, SaltStack, and NAPALM, and architectural shifts toward SDN and VNFs. Teams looking to move in this direction can start by treating network configuration as code, integrating network change validation into CI/CD pipelines, and extending existing monitoring practices to cover the network layer.