What is network automation?
Network automation has the simplest definition of all the terms we've covered in our lexicon, yet somehow it creates the most confusion about what "doing automation" actually means in practice.
Network automation: the simple definition
Network automation means using software to perform network tasks that would otherwise be done manually.
Red Hat defines it as using "programmable logic to manage network resources and services." The Network Automation Forum describes it as "offloading network operations to software tools."
Straightforward enough.
Yet when you talk to network engineers and automation specialists about what network automation means, the conversation starts to get complicated.
What does "doing automation" actually mean?
The confusion isn't about the definition but about the enormous spectrum of activities that network automation can encompass.
"There’s really no definition of network automation," says network and automation consultant Claudia de Luna:
"Is it, 'I can generate my configurations automatically'? Is it, 'I can push them to a switch'? Is it that I can check for these settings on all my switches? There's just this whole gamut. And we've never really come to a decision."
Ethan Banks, co-founder of Packet Pushers, describes the range this way:
"We still, in 2025, have people that are like, 'My version of network automation is I'm using Python with some libraries like Netmiko and whatever that help me talk to devices.' And that's it. They gather some reports or maybe, if they're feeling crazy, they push a config change. And then you've got people that are sitting on a platform that's very robust and does all kinds of things for them and exposes APIs and makes it very easy for them to structure a workflow, which is a very different place to be."
Banks adds: "Network automation seems to be the general term we're rallying around. It's like we all know what we mean by that, even though if we talk about strict definitions, I don't think it's broad enough."
The term seems to work precisely because it's flexible enough to include everything from basic Python scripts to self-healing, AI-driven networks.
The reality of network automation in practice
To understand why network automation means such different things to different practitioners, de Luna offers a perfect analogy: the Apollo moon program.
The Apollo program to land astronauts on the moon started with smaller projects. First came the Mercury mission: Can we get someone into space and will they survive it? Then came the Gemini program: Can we change orbit, can we rendezvous and dock, and can we nail the re-entry? Finally, the Apollo mission was to land on the moon.
"NetDevOps, GitOps, I consider more in the Apollo level," says de Luna. "But almost everyone's still trying to see if they can just get out of Earth's atmosphere and survive it."
This spectrum is reflected in how vendors describe network automation maturity. Cisco outlines five levels:
- Manual device configuration: CLI or SNMP, device-by-device
- Basic configuration automation: Some templating and basic provisioning
- Controller-based per-domain automation: Automation in specific network domains
- Controller-based, network-wide automation: Policy-based automation across the network with orchestration
- Self-organized, self-diagnosing network: Advanced AI/ML-driven automation with AIOps
Most organizations are somewhere between level 1 (which is actually no automation at all) and level 3. This explains why "network automation" encompasses such a wide range: Practitioners at different maturity levels are describing fundamentally different implementations.
Cisco also breaks down automation across the network lifecycle:
- Day 0: Zero-touch network device deployment, security certificates, VM deployment
- Day 1: Network configuration using templates, segmentation based on analytics
- Day 2: Configuration updates, vulnerability fixes with AI/ML, capacity planning, lifecycle management
Again, an organization doing Day 0 automation with basic templating is in a very different place than one doing Day 2 AI-driven optimization, but both are practicing what can legitimately be called network automation.
Where does network automation fit in framework conversations?
There's debate about whether network automation is a practice within other frameworks or the umbrella that contains them.
Network automation engineer Eric Chou sees automation as a component of NetDevOps:
“DevOps is the big bubble. NetDevOps is a smaller bubble. And automation is yet another smaller bubble within NetDevOps. DevOps focuses on the mindset and culture, automation focuses on operational processes.”
Network automation architect Christopher Fauveau sees it the opposite way:
"NetDevOps is a subset of network automation. Network automation is a broader umbrella covering all automation skills for network architects and engineers. NetDevOps specifically focuses on DevOps practices applied to networks, like things like CI/CD and version control, but network automation includes much more. It covers areas like source of truth management, automation orchestration platforms, interaction with network observability platforms, and the architecture of all these different modules to provide end-to-end automation through the entire lifecycle."
Datapath.io takes yet another view, positioning automation as an outcome:
"Network automation is the result of the NetDevOps approach."
Unlike the definitional chaos around NetDevOps, GitOps, and Network as Code, the disagreement here isn't about what automation is. It's about whether it's a practice within other frameworks or the umbrella containing them. Either way, everyone agrees automation is fundamental to modern network operations.
How network automation became the dominant term
In the early 2010s, as software-defined networking (SDN) and network functions virtualization (NFV) concepts gained traction and DevOps tools like Ansible, Puppet, and Chef matured, a small community of network engineers began experimenting with programmatic approaches to network configuration.
The phrase "network automation" began appearing in blog posts, conference talks, and community discussions. As 2014 rolled into 2015, key projects and conversations were emerging:
- Kirk Byers began developing Netmiko, an open-source Python library for managing network devices via SSH—one of the first tools specifically designed for network automation workflows.
- Ivan Pepelnjak's Software Gone Wild podcast featured discussions about network automation tools and practices, helping spread awareness across the networking community.
- David Barroso and collaborators released NAPALM, a Python library that helps automation practitioners work with different vendor operating systems.
- Consulting and training companies sprouted up to help organizations implement network automation.
In 2016, the first industry survey was launched to understand how engineers were implementing automation. Variously called the Network Automation Survey or the NetDevOps Survey, it reflected the label confusion of the time: Was the community practicing NetDevOps or network automation? The survey ran again in 2019 and 2020 (led by Damien Garros and colleagues), continuing to focus on automation adoption even as it carried the NetDevOps name.
Between 2016 and 2018, network automation moved from niche experimentation to mainstream conversation. Conferences added dedicated network automation tracks, vendors incorporated automation into their roadmaps, and training programs proliferated.
In 2023, when Scott Robohn and Chris Grundemann launched a new industry organization and conference series, they called it the Network Automation Forum—not the NetDevOps Forum or the Network as Code Forum. Their conferences have quickly become defining industry events, further cementing network automation as the unifying term engineers are rallying around.
Search data backs this up. Google Trends shows that, starting around April 2025, searches for “network automation” have far eclipsed related terms, hitting a score of 100—peak search interest—in August. Comparatively NetDevOps sat at 1, GitOps at 34, Network as Code at 23, and Infrastructure as Code at 29.
Network automation TL;DR
Network automation means using software to perform network tasks instead of doing them manually. It’s a small definition that encompasses an enormous spectrum of activity.
In practice, “network automation” can refer to everything from basic Python scripts to AI-driven self-healing networks. Most organizations are still in the early stages of automation maturity, which explains why the term can mean vastly different things to different people.
Unlike NetDevOps, GitOps, or Network as Code—all terms that have struggled with contested definitions or failed to gain traction—network automation has succeeded precisely because of its flexibility.
It's broad enough to include everyone's work regardless of maturity level, and it emerged organically from community work rather than vendor evangelism or standards bodies. Network automation is the term the industry has rallied around.
What is network orchestration?
If network automation is about eliminating manual work for individual tasks, network orchestration is about coordinating those tasks into complete, end-to-end services.
ManageEngine defines it as "the automated coordination, management, and provisioning of network infrastructure to achieve streamlined operations and optimized performance."
IBM describes orchestration more broadly as "the automated end-to-end coordination and management of computing resources, applications, services and workflows across an organization's technology stack."
The relationship between network automation and network orchestration
Ethan Banks describes the distinction this way:
"There's the automation, the doing of the thing in a programmatic way, and then there's orchestration, the workflow, the pipeline, the process, the canvas, however you want to talk about it, that kicks off all of the automation steps to deliver some kind of a service."
Network automation architect Roger Perkin puts it even more simply: "Automation is a building block. Orchestration is the entire system that coordinates those blocks."
For example, automation might handle the individual steps of upgrading firmware across a fleet of devices: running pre-checks, verifying the target image, executing the upgrade, performing error checking, running post-checks.
But orchestration ensures all those automated steps execute in the correct sequence, with proper error handling, validation, and rollback capabilities if something fails.
The birth of network orchestration
The term "network orchestration" first appeared around 2012, and solidified in 2013 as part of the NFV white paper from the European Telecommunications Standards Institute (ETSI). The ETSI NFV architectural framework defined MANO (Management and Orchestration) as one of three core building blocks for virtualizing network functions.
While the term originated in the telco world, orchestration quickly spread across industries as infrastructure everywhere continued to grow in size and complexity, and performance demands increased through the 2010s.
By the time network automation became part of the mainstream conversation, orchestration was increasingly recognized as the next evolution of that, helping organizations move from automating individual tasks to coordinating complete services.
Network orchestration TL;DR
Network orchestration is the coordination of multiple automated tasks into a complete, end-to-end service workflow.
Momentum around the term solidified in 2013 with ETSI’s publication of its NFV white paper, and the concept has become increasingly important as networks continue to scale.
Orchestration is acknowledged as the next evolution beyond task-level automation. Automation and orchestration work together, with orchestration providing the coordination layer that transforms isolated automated tasks into complete services.
The term is well-understood by practitioners working at scale, even if it hasn't achieved the universal recognition of "network automation" itself.