This article is based on a perspective piece originally published on networkworld.com, discussing the evolution of network automation from custom scripting to full automation frameworks.
Why Script-Driven Automation Has Limits
If your network automation strategy still relies entirely on custom scripts, you are likely approaching a ceiling. Scripts can handle discrete tasks well, but they do not provide the modeling, database layer, or orchestration that production-grade service provider and enterprise networks require. The gap between ad-hoc scripting and a production-ready automation framework is significant—and closing that gap has become one of the defining challenges for network engineers moving into a DevOps world.
Network infrastructure has evolved from a passive utility into the critical centerpiece of modern business operations. Service providers need straight-through provisioning—from order intake to live service—with minimal manual intervention. Enterprises, on the other hand, are increasingly driven by compliance, auditability, and change-management rigour. Both use cases demand automation that goes well beyond what a collection of Python scripts or Bash one-liners can reliably deliver at scale.
The Inherent Complexity of Networks
Networks are complex by nature. They consist of many moving parts: multiple vendors, multiple domains, and operational and architectural teams that often work in silos. Each network tends to accumulate what engineers sometimes call “snowflakes”—bespoke configurations that reflect years of one-off decisions. That diversity of implementation makes blanket automation difficult.
A useful mental model for approaching network automation is the ease-versus-impact ratio. Not everything that is easy to automate should be automated without careful thought. Consider operating system upgrades: straightforward to script, but the blast radius of a bug is enormous. VLAN and port provisioning, by contrast, has a low blast radius and a simple, repeatable configuration pattern—making it an ideal first rung on the automation ladder, provided it does not touch live services.
The real complexity surfaces at the topology and service layer, where changes span multiple vendors and multiple domains simultaneously. At that point, a single script—or even a collection of scripts—is rarely sufficient.
A Practitioner’s Journey: From Bash to Python to Frameworks
The following account illustrates a common progression in the field. A network architect working on a large but relatively straightforward enterprise network began automating repetitive tasks in his own time. He started with Bash shell scripting to generate basic device configurations, then graduated to Python to handle more complex workflows—parsing command output, generating device inventories in spreadsheet form, and pushing configurations to multiple nodes.
At the device level, this approach worked well. Libraries for communicating with multi-vendor equipment are readily available in Python, and pulling structured data out of show-command output is achievable with enough effort. He could complete tasks in days that previously took weeks.
The limitations only became apparent when the scope expanded. When asked about those limits, his answer was telling: “A programming language can carry out a lot of tasks—but how far can you go alone?” The issues he encountered are common across the industry:
- No shared model or database: Each script encodes its own assumptions about the network state. There is no single source of truth.
- Poor handover: Scripts written by one person are difficult for another to understand, validate, and safely extend.
- No orchestration layer: Individual scripts handle individual tasks. Coordinating them across a multi-step workflow requires additional glue code that itself becomes a maintenance burden.
- Reinventing the wheel: Every new use case starts from scratch. Compliance checks, audit logging, rollback logic, and integration with Active Directory or LDAP all have to be built—and rebuilt—manually.
What an Ideal Network Automation Framework Looks Like
The conclusion drawn from that practitioner’s experience is that production networks require production-grade tooling. An automation framework designed for network operations should satisfy several core requirements:
- Multi-vendor and multi-domain support out of the box: The framework should communicate with equipment from different vendors without requiring custom adapters for each new device type.
- Abstraction of network complexity: Engineers should be able to express intent in networking language—”provision this L3VPN” or “upgrade the IOS on these devices”—rather than writing low-level API calls.
- Built-in data model and database: A persistent, structured view of the network state is essential for traceability, compliance reporting, and impact analysis before changes are applied.
- Orchestration, not just automation: The framework should coordinate multi-step workflows across devices and domains, not just push a configuration to a single node.
- Integration with enterprise systems: Connections to Active Directory, LDAP, ITSM platforms, and change-management systems should be native capabilities, not afterthoughts.
- Accessible to non-programmers: Network engineers possess deep domain knowledge. The right framework leverages that knowledge without requiring engineers to become full-time software developers.
Frameworks cited in the original discussion as examples in this space include Cisco Network Services Orchestrator (NSO), NetYCE, and Glue Networks. These represent different approaches to the same problem: providing a structured, model-driven environment in which network automation can be built, tested, and operated at scale.
The Future of DevOps for Network Engineers
The DevOps movement brought software engineering practices—version control, continuous integration, automated testing, infrastructure as code—into the operational world. For network engineers, the equivalent shift is moving from reactive, CLI-driven change management to declarative, model-driven automation embedded in structured workflows.
This does not mean every network engineer must become a programmer. Learning to code—particularly Python—remains valuable. Courses such as Ivan Pepelnjak’s Building Network Automation Solutions are well-regarded starting points for understanding what is possible. However, programming skill alone is not a substitute for a proper automation framework on a production network, any more than knowing how to write SQL is a substitute for a proper database management system.
The analogy that holds up well: custom scripts on a production network are like trying to hold sand in your hands. Each grain is manageable on its own, but without a container—a framework—the whole thing slides away. Scripts lack the scalability, compliance controls, documentation, rollback capabilities, and team-level governance that production operations require.
Key Takeaways
- Script-driven automation is a valid starting point, but it hits hard limits at the orchestration, compliance, and multi-domain level.
- The ease-versus-impact ratio should guide which automation use cases to tackle first. Start with low-risk, high-repetition tasks.
- Production networks need production-grade automation frameworks that provide a data model, orchestration, multi-vendor support, and enterprise integration.
- Network engineers do not need to become programmers, but understanding automation concepts and tools is increasingly a core competency.
- Learning to code is worthwhile; relying solely on custom scripts in production is not sustainable.
The question is not whether network automation will become standard practice—it already is in forward-looking organisations. The question is whether your automation approach will scale when the network does.