For most of my career, being good at networking meant being good at the CLI. Knowing your way around IOS, understanding what the show commands were actually telling you, being the person in the room who could read a packet capture. That's still valuable. It's just not enough anymore.
I've spent the last few years working at the intersection of network engineering and DevOps with automation: pushing configs with Ansible, building source-of-truth workflows in NetBox, managing NAC enforcement across hospital sites with Cisco ISE, and writing pipelines that touch firewall policies through AWX. None of that made me stop being a network architect. It made me a more effective one. But it also gave me a clear view of a problem that I don't think either side of the DevOps / networking divide talks about honestly enough.
Why the Network Is Actually Hard
This isn't a complaint. It's an observation. Most of what DevOps has successfully automated, compute, storage, containers, orchestration, is stateless or near-stateless by design. You can destroy and recreate an EC2 instance, a pod, a volume. Infrastructure as code works well here because the target state is discrete and the blast radius of a misconfiguration is bounded.
The network doesn't work like that. Network devices are stateful. A routing table isn't just configuration; it's the accumulated result of protocol convergence across your entire environment. A spanning tree topology isn't a setting you apply; it's an emergent property of how your switches have negotiated roles over time. An ACL that looks correct in isolation can break an application in ways that take hours to trace if you don't understand the order of operations, the implicit deny, and how the traffic is actually flowing.
Vendor heterogeneity compounds this. In a given environment you might have Cisco IOS, NX-OS, Palo Alto, Juniper, FortiGate, and ASA, all with different data models, different hardware, different software, different API maturity, and different failure modes. There's no clean abstraction layer that makes them all behave the same way. Providers and modules help, but they have gaps, and those gaps tend to appear at the worst possible moment.
And the blast radius of a network misconfiguration is not bounded. A bad ACL on a core switch doesn't break one application. It can break everything connected to that segment simultaneously, silently, and in ways that look different depending on where you're standing. That's the environment NetDevOps has to work in. It's genuinely hard, and treating it like a solved problem is how things go wrong.
What DevOps Practices Actually Give Network Engineers
DevOps has produced some of the best operational practices in the industry. Version control for configuration, peer review for infrastructure changes, idempotent automation, automated testing: these aren't soft ideas, they're operational discipline with real payoffs. I use all of them now, and I'm a better network engineer because of them.
The shift that changed things for me wasn't learning to code. It was applying DevOps thinking to network problems. When a network config lives in Git, you have a full audit trail of every change, who made it, and why. When a config push runs through Ansible instead of a terminal window, it's repeatable, reviewable, and testable against a subset of devices before it touches production. When your source of truth is NetBox instead of a spreadsheet, your automation has something reliable to read from.
These aren't DevOps concepts that network engineers need to grudgingly adopt. They're efficiency multipliers for people who already understand the network deeply. The engineer who can write a clean Ansible script, model their intent in NetBox, and push changes through a pipeline with peer review isn't less of a network engineer. They're operating at a different scale with better tooling, and they're solving problems that pure CLI workflows simply can't.
What Network Engineers Get Wrong About DevOps
Equally honest: network engineers have been slow to move, and some of the resistance hasn't aged well.
Version control for network configs gets dismissed as overhead by people who've never had to audit what changed on a device six months ago during an incident. Automation gets treated with suspicion because "if you write the wrong Ansible task, you could push a bad config to 50 devices at once," which is true (but obviously test on a small subset first), and also describes what happens when an engineer makes a mistake in a change window, just slower and with less visibility.
There's also a cultural attachment to the CLI. Deep CLI fluency is a real skill. But if the only way you can manage your network is interactively, one device at a time, you've built a ceiling on what you're capable of doing at scale.
The instinct that "I already understand this, I don't need an abstraction layer" is understandable but leads somewhere bad. The abstraction layer isn't for you to understand the network. You already do. It's for making your knowledge reproducible, auditable, and scalable in a way that individual CLI sessions never will be.
What Working at the Intersection Actually Looks Like
I want to be specific here because most writing about NetDevOps stays at the level of concepts and doesn't show what the work actually is. Your experience may vary depending on the organization.
Source of truth is the foundation. Before you can automate anything reliably, you need a place that represents intent: what devices exist, what their roles are, what VLANs are assigned, what address space is allocated. NetBox fills this role well. It's not perfect, but it's a real data model for network infrastructure, not a spreadsheet or a wiki page someone stopped updating in 2021. When your automation reads from a source of truth, your configs become a function of intent rather than a snapshot of whatever someone typed last.
Ansible handles the translation from intent to device config. This is where domain knowledge matters enormously. Writing a playbook that correctly manages an ACL on a Cisco ASA, handling object-group compaction, CIDR collapse, idempotent adds and removes, requires understanding how ASA processes ACLs, not just knowing how to use the ios_acls module. The module is a tool. The network knowledge is what makes the tool produce correct output.
AWX provides the execution layer: scheduling, credentials management, logging, and a place for non-engineers to run jobs without needing CLI access to the automation host. Git provides the history and the review gate. A change to a network template goes through the same pull request process as any other infrastructure change.
What this doesn't look like is a clean, seamless pipeline where everything works on the first run. Vendor APIs are inconsistent. Some devices don't support the modules you want to use. Idempotency is hard to get right when the device's data model doesn't cleanly map to the module's data model. There are edge cases everywhere. Building this stuff requires both the DevOps discipline to build it correctly and the network knowledge to know when the output is actually right.
Where It Still Breaks Down
I want to be honest about the failures. Vendor API quality is all over the map. Some platforms have well-documented, stable APIs with good module support. Others have APIs that were clearly added as an afterthought, are missing critical functionality, or behave inconsistently between software versions. You can't always automate what you need to automate, and knowing when to push through that friction versus when to work around it is a judgment call that requires domain experience.
Network state modeling in automation tools is still not great. Ansible's network modules have improved significantly since I started using them, but the gap between "what the module thinks the device state is" and "what the device state actually is" can still bite you in complex scenarios. This is less of a problem if you treat your automation as purely declarative and always push full intended state, but that's not always possible in production environments where partial management is a reality.
Organizational structure is often the real bottleneck. The network team is frequently the last team brought into an automation initiative, and by the time they're involved, decisions have already been made that constrain what's possible. That's not a DevOps problem or a networking problem. It's a planning problem, and it's worth fixing early.
The Case for Bringing Both Together
To DevOps engineers: the network is not a dependency you work around. It's load-bearing infrastructure with a domain complexity that deserves the same respect you give to distributed systems or databases. Bring network engineers into your automation pipelines early, not to review changes after the fact, but to help design the models and the tooling from the start. The engineers who understand BGP, RADIUS, spanning tree, and ACL behavior are not obstacles to your automation. They're the people who will keep your automation from doing something that looks correct and isn't.
To network engineers: the tools are learnable, and they will make you more effective at the job you already do well. You don't need to become a software engineer. You need to become fluent enough in Git, Ansible, and your source-of-truth tooling to own your domain in the modern stack. The domain knowledge you've built, the kind that takes years of staring at packet captures and debugging spanning tree convergence and tracing CoA flows through a NAC deployment, does not become less valuable when you add automation to it. It becomes more valuable, because now you can apply it at scale with the discipline and auditability that CLI-only operations never gave you.
The network is still the hardest problem in the room at scale because it requires physical and logical management simultaneously. The way to solve it isn't for one side to figure it out without the other. It's for network engineers to bring their domain expertise into the automation workflow, and for DevOps engineers to make room for that expertise at the table.