From CLI Jockeys to NetOps Engineers

The CLI isn't the enemy. Twenty years of muscle memory in configure terminal built the networks the rest of IT runs on. But the operating model that surrounded the CLI — one operator, one device, one change window — is the constraint we've outgrown.

NetOps isn't "automation." It's the network engineering team adopting the operating model the rest of infrastructure adopted a decade ago: changes go through version control, get reviewed, get tested before they touch production, and stay observable after they ship.

What changes

The job description doesn't change. You still need someone who understands BGP, who can read a fabric topology, who can debug a forwarding plane. What changes is the interface between that engineer and the network.

Today. SSH to the device. Make the change. Hope you didn't typo. Move to the next device. Run the same command many more times. Document somewhere — or don't.

NetOps. Write the change as code. Open a pull request. CI lints it, simulates it, posts the diff against current state. A peer reviews. The pipeline applies it — in stages, with health gates between each — across the fleet. Telemetry confirms the change had the intended effect. The change is now in version control: reviewable, revertable.

The toolchain has consolidated

The pattern is the pattern. The tools to implement it depend on the fabric.

For VXLAN/EVPN leaf-spine fabrics. Vendor-native intent: Apstra (Juniper), CloudVision Studios (Arista), Cisco Nexus Dashboard. All three converged on a similar model — declarative intent + pre-change validation + telemetry.

For multi-vendor or open environments. Ansible / Nornir for change orchestration, Batfish for offline simulation, SuzieQ for state observability, OpenConfig as the configuration model. Heavier integration burden, more flexibility.

For SONiC fabrics. Closer to the cloud-native pattern from day one. SONiC + the SONiC Management Framework + your preferred GitOps stack.

What gets harder

Three things, candidly.

Hiring. The intersection of network engineer and software engineer is a small Venn diagram. Building or buying that talent is the hardest part of the transition. The team you have today probably has two or three people who can do it; the rest need training, rotation, or a different role.

Cultural change. The change-management muscle that built around "I am the only one who knows the running config" doesn't transfer. The team has to learn to trust the pipeline, the simulation, and the rollback. That takes a year of small wins, not a quarter.

The cost of broken automation. When the pipeline ships a bad change to 200 devices, the blast radius is 200 devices. That's the same blast radius any human operator could create — but it happens faster. The discipline of change validation matters more in NetOps, not less.

Where vendors help. Some platforms close the gap themselves. Arista CloudVision, for example, gives operators near-hyperscaler automation without writing code or scripts — making NetOps something the existing team can absorb rather than hire around.

What you get

Three things.

Speed. A reviewed, tested change to 200 devices ships in an hour, not a maintenance window two weeks out.

Audit trail. Every change has an author, a reviewer, a test result, and a deployment record. Compliance teams stop asking for spreadsheets.

Engineering leverage. The team that's stuck in a CLI runbook can't keep up with the AI mandate. The team running NetOps can.

Where to start

Don't try to NetOps the whole network at once. Pick a domain.

The starting domains we see work most often: BGP route-policy, ACL/firewall rules, EVPN intent, and DNS records (because DDI was already there). Each is small enough to scope, big enough to demonstrate value, and stable enough to ship.

Get one domain reviewed-and-tested-before-it-ships. Then the next. Then the next. Inside 18 months, the team is running on a different operating model — not because anyone announced it, but because the work moved.

The CLI didn't die. The runbook around it did.