Editor's note: This piece on the impact of SDN on networking employees is part of a series on evaluating SDN for...
the enterprise. In the first part, we examine why network pros should consider SDN startups in the buying process.
SDN is all about automation and dynamic infrastructure, so the technology will change the role of the networking professional. It's important to consider potential SDN impact on IT staff while evaluating the new technology.
A network engineer accustomed to provisioning the network via a command line interface might need to learn a new way to go about this task. The day-to-day mundane activities of building VLANs, updating firewall policies and provisioning application delivery controllers may suddenly be handled by SDN, while the network engineer focuses instead on the underlying physical network, capacity planning, design, reporting and other types of proactive network management.
The point is that, depending on what specifically is being deployed, SDN is going to impact employees who have been doing things in a particular way for a long time. Those employees will need training and time to adjust to new technology and challenges. While some have prognosticated the decline of the network engineer due to SDN's rise, businesses would be wise to assume just the opposite. SDN promises to make network operations simpler along with extending a network's capabilities into the virtualized era. However, the attributes of SDN do not make the network itself any simpler. Instead, SDN puts a complex layer of abstraction on top of a complex network, the end result being a simpler interface -- but not a simpler network.
To use an analogy, a smartphone is a massively complex device packed with radios, processors, memory, touchscreens, operating systems, applications, etc. Yet my children can use them effectively. That doesn't make my children smartphone engineers; it makes them smartphone consumers. SDN might hope to make network consumption simple, but it can never make network engineering simple. Organizations will need their network engineers to add to their knowledge to keep networks functioning smoothly in an SDN world; not only will network engineers need to understand network theory and design, they will also need to understand how SDN abstraction layers interact with the network so that they can fix that interaction when it (inevitably) breaks.
Any organization evaluating SDN needs to carefully explore the impact that bringing an SDN solution in-house will have on its staff and operations, and include that data in its evaluation process.
About the author:
Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions and technology corporations. Banks has also been a host of the Packet Pushers Podcast, a technical program that covers practical network design as well as cutting-edge topics like virtualization, OpenFlow, software-defined networking and overlay protocols. He is the editor for the independent community of bloggers at PacketPushers.net and can be followed @ecbanks.