For years, networking has operated separately from the rest of IT infrastructure.
While compute, storage, and applications moved toward cloud-first, API-driven models, networking has remained mostly manual and ticket-driven.
That’s no longer sustainable.
In my recent TNOps Podcast conversation with Scott Robohn and Ethan Banks, we explored how networking must evolve — not just by automating tasks, but by delivering network services the same way IT delivers compute and storage. That means embracing a product mindset where networking is no longer a bottleneck. Think about the public cloud — that’s the operating model we can reach. The trick is making the network a fully integrated, API-driven part of IT infrastructure.
Why Networking Is Still Playing Catch-Up
IT teams expect on-demand access to infrastructure. Developers spin up virtual machines, databases, and containers in seconds. But when they need network changes? That still means filing a ticket and waiting days (or even weeks).
As Scott pointed out on the podcast:
Developers are used to bringing up infrastructure instantly in AWS. But when they move to on-prem, they have to submit a ticket and wait two weeks for the network team to provision something. That’s not sustainable.
This is why so many workloads default to the cloud — it’s not that cloud networking is inherently better, it’s that it’s easier to consume. But when dev teams bypass network and use the cloud for everything, they open up more risk and potentially increase tech sprawl.
If we want networking to remain relevant in modern IT, we have to rethink how we’re delivering services to fit the needs of modern business.
The Shift: Bringing Networking to the IT Table
To close the gap, networking must evolve from a collection of manual processes and ad-hoc scripts to a fully automated, API-driven operational model where assets, workflows, and delivery methods are standardized. When network functions can be integrated seamlessly into IT workflows, the network goes from a bottleneck to a catalyst for innovation.
- Networking must be self-service. Just like VMs and storage, network services should be requestable and provisioned on demand via APIs.
- Orchestration must replace fragmented automation. Instead of individual scripts and playbooks, networking should be managed as an end-to-end service.
- Network services should be treated as products. Teams shouldn’t be requesting VLANs or firewall rules — they should be selecting predefined, consumable network services.
This shift will deliver results both for the network side and for network consumers. It’s about aligning networking with the way modern IT operates, bridging those gaps so app devs aren’t waiting around for days for a service — and network teams aren’t left scrambling to fulfill a constantly-growing backlog.
Why Automation Alone Isn’t Enough
Many teams think automation is the solution — but just writing scripts isn’t thinking big enough.
There’s a big difference between automation and orchestration. I’ll paste what I said on the podcast:
Automation is about performing discrete, domain-specific tasks — things like core routing, data center networking, or SD-WAN. Orchestration, on the other hand, is about taking all those separate islands of automation and combining them into a cohesive workflow that delivers an actual service.
In short:
- Automation helps engineers move faster.
- Orchestration helps the entire IT team consume networking as a service.
If we want to bring networking to finally take a seat at the table with the rest of IT, we need orchestration so network and infrastructure functions can be integrated and we can deliver services as productized, end-to-end outcomes.
How to Transform Networking: A Practical Guide
Adopting a product mindset means shifting from one-off automations to building scalable, repeatable network services that the business can consume on demand.
Here’s where to start:
1: Identify the Most Repetitive Requests
What networking tasks slow IT down the most? Start by automating the most common workflows, such as VLAN provisioning, firewall changes, or device onboarding.
2: Expose Network Services via APIs
Developers shouldn’t have to wait weeks for basic network changes. Expose standardized network services via APIs so IT teams can integrate them into their workflows.
3: Integrate Siloed Scripts with Orchestration
Automation alone isn’t enough — network teams must orchestrate workflows that provision, validate, and secure network changes automatically.
4: Make Networking Consumable
Instead of making IT teams request individual network changes, create predefined services that can be deployed on demand — just like compute and storage.
The Bottom Line: Network Teams Must Deliver Services, Not Just Fix Problems
If network teams continue to operate separately from IT, we’ll always be seen as a bottleneck. The future of NetOps isn’t about just automating tasks — it’s about integrating networking into IT infrastructure so it’s as accessible and automated as the rest of the stack.
This shift is already happening. The only question is: will you lead the charge or get left behind?
Want to hear my full conversation with Ethan and Scott for Packet Pushers’ TNOps podcast? Check out the episode here.
Tags: Infrastructure Orchestration Network Automation Network Orchestration Network Transformation Self-Service
Peter Sprygada
Chief Architect ‐ Itential
Peter Sprygada serves as the Chief Architect at Itential after serving as the Chief Technology Officer at Pureport where he was responsible for their multi-cloud network as a service interconnect platform. Prior to Pureport, Sprygada was a Distinguished Engineer for Red Hat, where he played the role of Chief Architect for the Ansible Automation Platform. Sprygada also held senior technical and leadership positions at Arista and Cisco, as well as several networking startups.
