Network Designers in the Era of NetDevOps

What NetDevOps Actually Means for Designers

NetDevOps brings the culture and technical methods of DevOps to networking. That definition has been floating around since Cisco first coined it, and it still holds. But most of the conversation focuses on operators automating repetitive tasks. What about designers?

Network designers develop solutions, drive architectural discussions, and define how services get built. We do not traditionally write code or interact with APIs. That is changing. Network services are increasingly software-driven, and the way we design networks has to reflect that.

For me, NetDevOps means using automation and programmability in how I consume data, interact with systems, and manage state in network infrastructure. It is not about replacing design skills with code. It is about augmenting them.

The Core Toolkit

Python

The entry point is a programming language with a rich ecosystem in network engineering. Python remains the dominant choice here, and for good reason. The ecosystem is mature: libraries like Netmiko, NAPALM, Nornir, and pyATS handle the heavy lifting of device interaction. Pydantic handles data validation. Rich and Textual make CLI tooling easy.

If you are a network designer who has not picked up Python yet, you are leaving capability on the table.

Data Serialization

To manage data effectively, you need to be fluent in modern data serialization formats: JSON, YAML, and for more formal data modeling, YANG. The advantage of these formats is that they are both machine-readable and human-readable. They map directly to Python data structures.

Getting the data model right is the single most important decision in any automation project. It drives how you build the datastore, what becomes your single source of truth (SSoT), and how reusable your work actually ends up being. YANG is the formal standard, but in practice a well-structured YAML schema or Pydantic model works for most design automation.

Template Engines

For configuration generation, Jinja2 is the standard. Push complexity into the templates and keep the data clean. This gives you generic, reusable code that requires fewer template variations for design documents or device configurations.

There is a clean separation of concerns here: network engineers design and maintain the templates, while the automation code handles rendering and deployment.

Infrastructure as Code for Network Design

The real shift happens when you combine data models, templates, and version control into an Infrastructure as Code (IaC) approach.

A declarative definition of network state creates reusable blueprints and makes downstream automation not just easier, but possible.

The modern IaC toolchain for networking has matured significantly:

• Source of Truth: NetBox or Nautobot serve as the single source of truth for your network. Devices, IP addressing, VLANs, circuits — everything lives in an API-accessible database that both designers and automation consume.
• Automation Frameworks: Nornir provides a pure Python framework for running tasks against your inventory. Ansible remains popular for its lower barrier to entry.
• Infrastructure Provisioning: Terraform (or OpenTofu) handles cloud networking and increasingly on-prem devices through providers for Cisco, Juniper, Palo Alto, and others.
• Configuration Management: Tools like Hieradata diff intended vs. actual device configs to generate remediation commands.
• CI/CD: GitLab CI, GitHub Actions, or any pipeline tool can validate, test, and deploy network changes automatically.

The pipeline for a network design change looks like this: you define the desired state in code, commit it to Git, the CI pipeline validates syntax and runs tests (possibly against a virtual lab using tools like Containerlab), a peer reviews the merge request, and on approval the change either deploys automatically or generates the config for a controlled push.

Where Designers Fit In

As a designer, you might think this is all operational tooling. It is not. Consider what changes when you adopt this approach:

• Design validation becomes automated. You can write tests that verify a design meets requirements before it ever touches a device.
• Design documents become executable. Instead of a static Visio diagram and a Word document, your design is code that can be rendered, tested, and deployed.
• Reuse becomes real. A well-modeled campus design or data center fabric becomes a parameterized blueprint, not a one-off document.
• Collaboration improves. Git-based workflows mean designers, operators, and developers work in the same system with the same review processes.

Getting Started

The best approach is practical. Read enough to understand the concepts, then start building. Identify small tasks in your day-to-day work and automate them:

• Manipulate IP prefixes using Python’s ipaddress module or netaddr
• Build a configuration templating solution with Jinja2 and YAML data files
• Generate design documents programmatically from structured data
• Create a self-service portal using FastAPI for common design requests
• Model your network in NetBox and pull inventory data for automation scripts

The Network to Code community Slack is where a lot of this gets discussed in the open. The DevNet learning labs are solid for Cisco-specific tooling. And GitHub is full of reference implementations — use them.

The gap between network design and network automation is closing. The designers who bridge it will build better networks. The ones who do not will find their designs increasingly difficult to implement in a world that expects everything to be code.