devopsy.kinsta.cloud

Tag: NetDevOps

From Operator to Agent Manager: The Real Shift in Network Engineering

I’ve been saying for ten years that network automation was three years away from being the only way to do things. Every year I moved the goalposts, because the data never caught up to the rhetoric. After a decade of scripts, YAML, Ansible, Terraform, and every NetDevOps framework we could throw at the problem, roughly 70% of enterprise networks are still managed by hand.

The industry’s explanation for that has always been some version of “those teams just haven’t gotten with the program.” I don’t think that’s right. I think we built the on-ramp wrong.

The On-Ramp Was Never Going to Work

To automate the network the old way, we asked a 25-year network engineer to also become a proficient software developer: fluent in a programming language, comfortable with source control, capable of writing automation that survives contact with production. We asked them to pick up a second career on top of the one they already had, which was keeping the network so stable that nobody noticed it existed.

The best day a network engineer can have is the day nobody calls them. We built the entire discipline around stability and predictability, then asked the same people to ship production-grade software on the side. The math was never going to work, and blaming the engineers for not doing the math was never fair.

Writing Configs by Hand Is a Solved Problem

What changed isn’t the underlying capability. It’s the interface. When an engineer describes what they want in plain language and an agent handles the translation, the expertise doing the real work is still the engineer’s. Fifteen or twenty years of judgment about how a network should behave doesn’t move to the model. It just stops getting filtered through a programming language the engineer never trained in.

That matters because every hand-typed change is a chance to introduce a human problem that has nothing to do with engineering skill. A fat finger. A missed step. A redundancy pair only half configured because the second command got typed at 2 a.m. and nobody caught it until morning. Automation was always supposed to take that risk out of human hands. We just never made the on-ramp easy enough. We do now.

The Job Isn’t Disappearing. It’s Becoming Management

The next decade of network engineering isn’t about engineers being replaced. It’s about engineers running a fleet. One agent handles documentation. One handles compliance checks. One triages tickets. One sits read-only, gathering the data the others need. The engineer’s job shifts from typing the change to defining the agent, setting its guardrails, watching its work, and deciding when it’s earned more scope.

NVIDIA CEO Jensen Huang described this as IT eventually needing something like an HR department for agents, and I think network engineers are better positioned for that role than almost anyone else in IT. We already troubleshoot in layers. We already design for redundancy. We already operate in environments where a single mistake takes down a business. Managing a fleet of agents is going to feel more familiar to a senior network engineer than it will to most other technical roles.

Trust Has to Be Graduated, Not Granted

Nobody should hand an agent production access on day one, and nobody has to. Start with read-only work: documentation, compliance checks, source-of-truth reconciliation, testing. None of it touches production, and all of it delivers value immediately. If you’ve ever put a new hire’s first two weeks toward updating the network diagrams that never matched reality, you already know this playbook.

Let trust build the same way it would for a person. A quarter of clean documentation and compliance runs might earn the agent the ability to propose a change a human approves. Another quarter of that might earn it the ability to make the change and prove it worked. Eventually, routine tickets close without a human in the loop at all. It’s the same onboarding curve you’d use for a junior engineer, applied to software instead of a person.

Leverage, Not Loss

When Excel arrived, accountants didn’t disappear. The manual reconciliation and line-by-line calculation moved to the spreadsheet, and accountants moved up into work that required judgment. I think the same shift is coming for network engineering, and I think it happens faster than most people expect.

If you’re an engineer who has been waiting for the right moment to get into this, the moment is now, not because you’re behind, but because almost nobody is ahead. Spec-driven development is roughly six months old. MCP is barely a year old. Pick one read-only use case your team has been meaning to get to for years and build an agent that does that one thing. Watch it work. Then build the next one. That’s how the role changes: one agent at a time, not all at once.

August 31, 2026
NetDevOps Isn’t Stalled, it’s Stuck on the Wrong Problem

While it is true that network engineers are taking on NetDevOps roles to advance stalled automation efforts, the barrier to NetDevOps isn’t technical; it’s people.

The 44% Problem

The 2025 State of Network Automation Survey from the Network Automation Forum, which gathered responses from 681 network professionals across 58 countries, paints a clearer picture. When asked about barriers to automation, only 10% cited technical challenges. Meanwhile, 44% pointed to people problems: Skills gaps, organizational dysfunction, cultural resistance and yes, sometimes, just personalities that don’t mesh.

Let that sink in: The tools work. Python is mature. Ansible is everywhere. Source-of-truth platforms are production-ready. The tech isn’t the bottleneck — people are — and this aligns with something else the recent NetDevOps article touched on: Nearly half the organizations have no formal measurement of automation success. You can’t fund what you can’t prove, and you can’t prove what you don’t measure.

This is the real challenge in NetDevOps adoption. It’s not about writing better Python. It’s about organizational change management. It’s about communication. It’s about building trust between teams that have historically operated in silos.

You Don’t Need Unicorns — You Need Evolution

Here’s where I want to push back on the industry narrative a bit.

There’s this persistent idea that NetDevOps requires mythical unicorn hires, people who are simultaneously expert network engineers and expert software developers and expert DevOps practitioners. These people exist. I’ve met a few. But building your automation strategy around finding them is a losing game.

Research from theCUBE shows that organizations prioritizing internal upskilling outperform those relying on net-new hires. But I want to amplify this point: You already have the people you need. They just need to evolve.

When I was at Dell EMC, I transitioned from principal network engineer to consultant software developer, because automation became necessary and I kept pulling on that thread. One script at a time. One playbook at a time.

That’s the path for most of us. You don’t wake up one day as a NetDevOps architect. You evolve into one.

The automation survey data backs this up. When asked who builds automation in their organizations, 92% said “network engineers with automation skills.” Not software developers (44%), not DevOps teams (32%) — network engineers who learned new tricks.

So how do you create the conditions for that evolution? Here are a few patterns I’ve seen work:

Permit people to learn on the job. Automation skills don’t come from weekend certification cramming. They come from solving real problems with new tools. That means accepting that the first few automation projects will take longer than doing manual work, and that’s okay.

Pair, don’t silo. When you do have someone with stronger automation skills, don’t make them the automation person. Pair them with network engineers on real projects. Transfer skills through collaboration, not documentation.

Celebrate the small wins. The engineer who writes their first working Python script to pull interface stats has taken a bigger step than it looks. Recognize it. That momentum compounds.

The Data Foundation

Traditional network operations treat documentation as an afterthought, something you update after you make changes (if you remember). NetDevOps flips this. You make changes in the data first, then push those changes to the network through automation.

Intel’s Greg Botts (a Network to Code customer) puts it perfectly: “Start with your data, and everything falls out of that. Network config is a byproduct of the data.”

This is a mindset shift that trips up a lot of organizations.

EMA’s McGillicuddy notes that organizations often spend a year or two just establishing their network source of truth. That sounds like a long time, but it’s foundational work. You’re consolidating information that lives in 10 different silos, cleaning up years of accumulated drift and building the authoritative data layer that makes everything else possible.

Organizations with a clearly defined source of truth are nearly three times more likely to achieve consistent automation outcomes. Yet 56% are still flying without one — and if you’re trying to do NetDevOps without a source of truth, you’re building on sand.

From Documentation to Operations

Here’s where intent-driven methodology changes everything.

Without NetDevOps, without an intent-driven approach, your network data is just documentation. It’s a record of what you did, updated after the fact (if you remember) and its only purpose is to help the next person understand what’s out there. It’s passive. It describes the past.

With an intent-driven approach, data becomes operational. Your source of truth doesn’t just document what the network looks like; it defines what the network should look like. Data becomes the way you operate the network. You change the data, and automation makes reality match.

This flips everything. Documentation stops being a chore you do after the work is done. It becomes a natural byproduct of doing the work itself. You don’t update the spreadsheet after you make a change; you make the change by updating the source of truth. The documentation is the operation.

That’s a profound shift, and that’s why organizations that embrace it see such dramatic improvements. The act of automating forces you to clean up your data, and clean data makes better automation possible. But more than that: Data finally has a real purpose. It’s not busywork. It’s how you run the network.

AI Can Help Today, if You’re Ready

AI can help you today. Natural language queries against network data, configuration analysis, optimization recommendations, and even generating automation code, all of this works right now. The problem isn’t the AI. The problem is that most teams aren’t ready to use it effectively.

Think about how we approach Python in network automation. We don’t just write scripts and push them to production. We have linting. We have a code review. We have testing frameworks and CI/CD pipelines. We build structure around how we use Python so that it’s safe, repeatable and maintainable.

AI needs the same kind of structure. The good news is that the industry is starting to define it — frameworks such as the NIST AI Risk Management Framework and ISO 42001 for AI management systems, plus LLM testing tools such as DeepEval that bring automated validation to AI outputs. However, most organizations haven’t built these guardrails yet.

The automation survey shows that 45% of network professionals have no current plans to use AI/LLM in network operations. Only 3% have actually deployed it. I don’t think that’s because AI doesn’t work; it’s because experienced network engineers are appropriately cautious. They’ve seen what happens when you push untested changes to production. They’re waiting for the guardrails.

The Road to AI Runs Through Automation

Here’s the thing: AI is only as good as the data you feed it. If your network data is scattered across spreadsheets, tribal knowledge and half-updated CMDBs, AI will confidently give you wrong answers.

This is why the road to AI in NetDevOps runs through automation, not around it. Think of it as a flywheel:

First, you build your data foundation. You establish a source of truth and create authoritative records of what your network should look like.

Then, automation starts improving that data. Every automated change gets logged. Every drift gets detected. The act of operating the network through data makes your data better.

Finally, with solid data and mature automation practices, AI has something real to work with. It can query accurate inventory. It can analyze consistent configurations. It can learn from a history of well-documented changes. The foundation you built for automation becomes the foundation AI needs to be useful.

Skip the early steps and you’re asking AI to make sense of chaos. That’s not a technology problem; it’s a sequencing problem.

As Intel’s Botts says, “AI is going to enable us to uplevel our workforce. It’s not going to take these jobs away; it’s going to help us do our jobs better.” But better assumes you’ve done the work to be ready for it.

The Bottom Line

NetDevOps is real. It’s happening — and the organizations that figure it out will operate more efficiently, respond faster and frankly, be better places to work.

But let’s be honest about what figuring it out actually requires. It’s not about finding the perfect hire or buying the perfect tool. It’s about evolving your team, fixing your data and doing the hard organizational work that nobody wants to talk about.

2026 is a turning point. It will be defined by the people who do the work — and most of those people are already on your team. They just need the opportunity to evolve.

May 11, 2026
The Rise of NetDevOps and CI/CD Pipeline Solutions

Over time, as organizations, networks and technologies have changed, the way enterprises think about managing networks has shifted as well. Enterprises are continuing to evolve their networking strategies, specifically with regard to how they expand their efforts to adopt infrastructure-as-code (IaC) practices. Looking ahead, the industry will continue to see the proliferation of solutions that help teams adopt a modern network operating model that delivers an agile, data-driven change management process. In most organizations, the software development team members and the networking team members have operated independently, with separate tools and processes. Developers would leverage pipelines to test and deploy code and then open a ticket for network changes such as VPNs or firewall changes. The network team would implement the changes, and end users could then use the application. The handoff between dev and network could be immediate or, more likely, it could take a few days–delaying the ability of the end users to access the new functionality. NetDevOps is focused on addressing this situation, which has become one of the market’s more critical infrastructure questions: How do you build an organization that can function smoothly across different skill sets, different technologies and different processes? Those same enterprises will be looking to leverage continuous integration/continuous delivery (CI/CD) practices from their software development best practices to help them overcome some of the challenges involved with implementing automation and orchestration into their networks.

CI/CD Accelerates the Automation Process

Let’s start with CI/CD. Adoption of network automation and orchestration will accelerate as network operators change the way they think about network updates and configuration management. According to Cisco’s recent white paper on how “Automation is driving network engineer skills transformation,” the reasons we’re seeing an increase in automation adoption is due to organizations relying on continuous connectivity, a greater need for the network to become more dynamic and the increased rate of changes both in the service supply side (applications) as well as in the service demand side (application consumers).

However, some enterprises trying to build their own automation infrastructure struggle with resourcing, skill sets and maintenance effort struggles. To solve this, many of them are looking to incorporate the traditional DevOps practice of building and updating code with traditional continuous integration/continuous delivery (CI/CD) pipelines into their network automation and orchestration initiatives.

Establishing a CI/CD pipeline is a workflow best practice for DevOps teams to follow. Today, organizations rely on CI/CD pipelines to help minimize bottlenecks in the software development and delivery process, while continuous integration optimizes building, integrating and testing code within a development environment.

By integrating both CI/CD with network automation, teams will gain greater velocity and improve delivery. And by integrating network automation with an application CI/CD pipeline, they can reduce the time to perform network changes and enable secure access between the application and an in-house sales database.

Why NetDevOps?

NetDevOps brings the culture, technical methods, strategies and best practices of DevOps to networking.

When DevOps principles are applied to network operations, organizations minimize operator interactions and optimize programmable network processes to configure, deploy and manage the environment, increasing efficiency and ensuring network availability, quality and reliability.

NetDevOps takes those principles and applies them in a networking environment, offering tools to empower teams to collaborate and build an organization that can function across different skill sets and different processes — enabling everyone to participate in network orchestration.

And it’s a movement that’s taking hold. According to Cisco’s Hybrid Cloud Trends report, 55% of those surveyed have created a cross-functional team with technical and business representation and 50% have a centralized CloudOps and NetOps function to help ensure their organization’s hybrid cloud strategy meets business objectives.

Network Management Tools Will Continue to Evolve

In today’s networking environment, where the expectation is to have an “always on” approach, teams are expected to build and release new applications at a faster pace than ever before. And every team has its own processes and methods for doing that which can create delays in the time it takes to execute the application. Incorporating network automation into the pipeline can empower teams to make application changes and deploy them to the network in seconds instead of the multiple days/weeks required for manual network changes. By integrating CI/CD pipelines and NetDevOps principles with network automation and orchestration, organizations can reduce the network change bottleneck even more.

As we face the new year, we expect the way in which teams consume network automation and orchestration services as part of their software pipelines to become more sophisticated, with NetDevOps and CI/CD practices becoming a standard. And as more services become available, the adoption of IAC becomes easier. By abstracting and tweaking to abstract the traditional CI/CD pipeline, organizations of all sizes can accelerate the use of network automation and orchestration.

April 18, 2023
Languages and DevOps: Network

It is fun to discuss the changes in network operations over the last couple decades. We’ve come full circle, and, honestly, ended up in a better place. Network specialists were super command-line wizards who kept us going, with few GUIs in sight. Everyone thought the next iteration would be GUIs, so network operations could be accessible to more than a few command-line specialists. “Everyone” was mostly right; we did head in that direction. It was optional, and many network operations friends pointed out that you could still do more, faster with the command line. Before GUIs had the opportunity to catch up with command lines, though, automation came along. And then DevOps. And finally,* configuration-as-code. Pretty quickly, the ability to do everything through an individual product’s GUI was determined to be a weakness. Network operations personnel were dealing with more vendors to handle the networkification (it is too a word! I just made it up) of common development activities, like some aspects of security. And now, APIs and command lines rule the juncture of DevOps and networking.

*Finally – so far, at least

And that shows in languages. Shell scripting and Python run this show, with little competition from any other language. We could get into a massive discussion about whether shell scripting is programming, but we won’t, because at least in networking, it most definitely is considered to be programming.

One time, when we were tracking down a problem that involved all of IT, I was sitting with the serious network geeks and marveling at their ability to make everything they wanted happen from the command line in an instant, and their ability to parse command output. I’m no slouch when it comes to networking, but they easily put me to shame. I got to chatting with a few of them, and the consensus was that they loved computing but hated programming. Networking made sense to them. This explains why networking DevOps people are continuing to use Shell scripting and adopting Python at the same time.

Python and Shell

Shell is a given in networking. There are a lot of extant Shell scripts for doing all sorts of things, and the need to automate to keep up with Agile makes shell scripting a logical choice.

Python enters the picture because it is “common ground.” It is intuitive enough for most networking people to do what they need to get done, and known or knowable to most developers. When it comes to usage, Python has overtaken Shell; (don’t take my word for it, check out the excellent work of the NetDevOps survey on GitHub, or just glance at the graphic below, created by them) in fact, Shell and Python command so much of the network development space that you are probably better off just making sure you’ve got those down, and focusing your free time on other issues like completely different networking commands, or even skills for data center versus cloud. The ROI would be better.

But Wait, There’s More

The key operational changes recently have been around GitOps and reporting back into the DevOps toolchain. People no longer want your appliance or application to have a pretty GUI, they want it to report in to the tools that provide automation and a larger-picture GUI. Many vendors are there already, but many are not yet. That creates a need for tools – products, open source projects, or internally developed – to do that integration while waiting for the vendors to catch up. These, again, are well-served by Python, though other languages that can handle APIs are viable, too.

We’re headed for a world where systems detect anomalies and react to rectify them, but we’re not there yet – not on a strategic scale, at least. And we probably won’t be for some time, as automating massive network changes is a scary proposition and will take time to use these systems for detection, monitoring what they could have done, before organizations are willing to let them “just do it.”

Carry On

Meanwhile, NetDevOps is getting folded into DevOps proper, and in many organizations, using infrastructure-as-code or GitOps, is being deployed and managed like any other part of the life cycle. So we are moving along. For my network peeps, your job will continue to change, but it certainly won’t go away. You’re essential to smooth-running systems, and while the network may become even more virtual, it will still be networking. And under that virtual network will be … a physical network. So keep kicking it, and carving a path from users to apps, while protecting those apps and ensuring they have adequate resources. Oh, and if I spin up another instance at midnight, you’ll hop on and make sure it’s got traffic directed to it, right? RIGHT?!

April 7, 2021
Why DevOps Should Care About SDN

Software-defined networking (SDN) and DevOps are not mutually exclusive. Actually, DevOps wants SDN, whether it knows it yet or not.

Why?

If software is going to eat the world, then SDN is going to eat networking.

Networks are becoming more complex, and one way to manage them more effectively is through SDN. Also, organizations are demanding faster changes, yet networking changes traditionally have been a manual process.

In a profession where network engineers typically work in seclusion and use significant manual processes, it can provide a set of tools to align with DevOps. This is why DevOps needs to care about it.

Software-defined networking leads to infrastructure as code (IaC), which makes network automation possible.

Software-Defined Networking and Infrastructure as Code

SDN, in its simplest form, is controlling networking hardware with software. But there is more to it: Software-defined networking means networking switches and routers no longer need to be controlled with proprietary software. This creates an opening for innovation and is how we now have OpenFlow.

This implies that networking now can culturally align itself with DevOps. The question will become whether it wants to. IaC is where networking will find its home with the DevOps team—it is like SDN for Ops.

Why Does SDN Matter for DevOps?

Software-defined networking will open communication and make automation possible—two ideas that are fundamental to an effective DevOps team.

Open communication between networking can be easier when the mindset and tools are enabling a similar process. For DevOps, the current stack is providing tools to do exactly this. We see this with the Ansible and Red Hat DevOps networking partnership.

What’s more, SDN enables network automation. Automation is an important goal for DevOps, which before SDN was not workable. Network automation can mean a better integration of DevOps and networking, as networking comprises many manual processes and, as such, is a bit isolationist. Aligning goals can provide better communication and collaboration.

The Power of Network Automation

SDN, IaC and DevOps networking are providing a set of tools and ideas that can push widespread adoption of network automation.

Network automation is not a new topic, but implementation has been difficult. Technology had to catch up with demand: Before OpenFlow, networking infrastructure ran on proprietary software, which meant manual changes and configurations were commonplace and one-off scripts are the norm.

With SDN and a technological environment conducive to network automation, we can begin to test different network automation strategies. Currently, however, organizations using automation only use it for segmenting their firewalls. We are in the early stages of what network automation can do.

Just as DevOps is still finding ways to use automation in testing and development, networking is on its own discovery path to automation. The only difference is DevOps has a goal to automate and networking still views automation as a “nice to have.”

Using NetDevOps to Bridge the Gap

We have the conversation about SDN, IaC and network automation because networking does not have its functions accurately defined within the DevOps framework. That is why NetDevOps is a topic of discussion.

The fact that SDN is still in its infancy stages and network automation is being discussed as “how to implement” shows there is a need for a cultural shift in networking that aligns with DevOps. This will help DevOps with communication and collaboration.

DevOps wants automation and NetDevOps shares this goal. SDN is what makes this possible, and is exactly why DevOps should care.

September 2, 2016
5 Reasons DevOps Needs NetDevOps
Networking’s role in DevOps is not accurately defined.

Up to this point, networking has been integrated into DevOps through infrastructure as code (IaC), which has been around since the beginning of the DevOps movement. Although important, this does not quite encompass all of what networking needs within DevOps.

A few of the current terms being used for networking in DevOps are:
- Infrastructure as code (IaC)
- DevOps networking
- NetOps
We have not agreed upon a universal, concrete philosophy to determine how to effectively bring networking into the DevOps conversation.

This is why we need NetDevOps.

NetDevOps is a construct of principles that aligns the networking team more closing with DevOps in your organization. It takes what traditionally are manual procedures in network infrastructure and applies the principles of automation and scalability.

Why do you need yet another term or concept? This isn’t a new term; it just needs to be widely adopted.

Therefore, here are five reasons you need NetDevOps.

Networking + DevOps = NetDevOps

DevOps needs networking and networking needs DevOps. The two may not admit this, but the open communication is essential. Networking’s biggest concern is network uptime, while DevOps’ ultimate goal is continuous delivery. The result is DevOps having a high interest in network availability to ensure updates can be delivered.

Adopting a NetDevOps approach promotes networking to apply the same principles as DevOps. The goal of replicating and automating tasks—not automating for the sake of automation, but to take the processes that work effectively on one server and apply them to multiple servers.

Remote Deployment for Cloud Adoption

As cloud adoption increases, the need to deploy updates and changes remotely is essential. Cloud computing provides the necessary environment to implement the NetDevOps approach, which installing a hardware infrastructure allows for code deployment.

In a cloud environment, such as AWS, infrastructure needed to implement this approach is available already. For example, AWS CloudFormation provides the necessary infrastructure for IaC.

Infrastructure as Code

IaC has been fundamental to the DevOps movement, and this is the foundation for NetDevOps: The ability to take network hardware and apply a set of code to the environment. The code allows you to automate an environment, which typically has needed to be updated manually.

Automation is one of the core principles DevOps and NetDevOps share. Automation results in predictable network uptime, which provides an environment to better assist DevOps in achieving continuous delivery.

Software-Defined Networks

Software-defined networks (SDN) are a subset of the IaC discussion. It is the enterprise network version of cloud architecture. NetDevOps works in this environment through the use of white-box switches.

Implementing white-box switches and installing Linux will create an SDN environment, which is conducive to NetDevOps. It is the necessary infrastructure for NetDevOps.

Current Stack is Providing the Tools

Once the above is implemented, a NetDevOps environment is ready to integrate with your current Ops stack. Ansible, Red Hat, Puppet and Chef already are providing the tools necessary to create a NetDevOps environment. Now you and your team need to implement it.

NetDevOps is taking the traditional manual nature of networking and applying a set of DevOps principles. It is an environment of automation that brings networking full circle with DevOps.
June 22, 2016