But these potential shifts in responsibility still depend on a capable underlying network. And whatever gets deployed under the SDN/DevOps process will have to co-exist with legacy technology and use it as its foundation for many years.
And the caretaker of that foundational network is the network administrator.
"An enterprise wide SDN network isn't going to happen overnight," says Kindness. "This is going to be 20 year process for many to transition their network and IT mindset. At the very least, companies will still need network administrators to maintain the legacy sections."
While server and application admins are learning the ins and outs of SDN and DevOps, and how to tie it all into VMs and applications, they won't have time to learn about what the network admin already knows about the existing infrastructure. And knowing that will be important if the goal is to tie network behavior, on an individual element level, to the specific requirements of the application.
A deep level understanding of the existing network will be necessary as well when any problems crop up in software defining how it operates. And problems will crop up, especially as the network becomes more policy-based and security-dependent.
Network administrators will be needed to actively monitor and troubleshoot the network to make sure application-driven policies interact seamlessly and don't disrupt network operations. And when this application-driven policy transition takes hold, network security will become paramount: ensuring that application policies don't disrupt security policies will require someone with a deep understanding of both the network infrastructure and security architecture, and any potential impact a new operational model might present.
All this, of course, flies in the face of those who say software defining a network means the server or application specialist can now run the network. These are the same people who say that, just like server virtualization, configuring and operating an SDN won't require a CCIE or another certified specialist.
They demonstrate their point by noting that popular automation tools, like Puppet and Chef, are already allowing server admins to provision network resources on their own. And application developers might use SDN orchestrators to not only document what they need from the network, but also what they need from the storage arrays, server trays, hypervisors, and security and compliance servers, for example.
But again, ensuring the individual network elements behave as instructed by the application policy or SDN controller might come down to the individual who knows the physical network best. Allowing server admins to define, execute and deliver QoS or service-level agreements from an SDN controller sounds great in theory; but if something happens along the way and it happens at the network device level, who are you going to call?
Sign up for CIO Asia eNewsletters.