SDN Won't Annihilate the Networking Workforce
Network engineers have nothing to fear from SDN, argues guest contributor Michael Bushong.
By Michael Bushong | Posted Jul 2, 2013
Page of | Back to Page 1
Editor's Note: Occasionally, Enterprise Networking Planet is proud to run guest posts from authors in the field. Today, Michael Bushong of Plexxi brings his experience in SDN to bear against the idea that SDN will destroy networking jobs.
The networking industry at large is undergoing a major transition driven by a couple of important technology trends: Software Defined Networking (SDN) and DevOps. One of the basic tenets of both trends is that provisioning and maintaining a network remain exceedingly difficult and needlessly manual. Automation solves both issues. And after tasks become automated, the people who once performed those tasks become expendable. So the theory goes, anyway.
But the prediction of the demise of network engineering is lazy analysis.
The principles driving the technological shift are sound. There really does exist a need to simplify the network. Tasks that are currently hopelessly manual will indeed be replaced by automated tools and processes. The rise of new technologies will absolutely make possible a new class of capabilities.
Two things get glossed over in most of the analysis, though:
- These new technologies depend on the existence of a functional, performant underlying network.
- The commercial viability of any rip-and-replace solution is low. Whatever gets deployed will necessarily live alongside existing technology for years to come.
Nothing about abstractions, APIs, or automated tools will render obsolete the physical network that serves as the foundation for all of these new capabilities. SDN and its complementary technologies build upon and extend the physical infrastructure. With the network as their foundation, they rely more heavily upon a fully functional infrastructure. And that infrastructure remains subject to the same pressures that make network engineers necessary today: the pressures of managing changes to adapt and growth to scale.
SDN's real power lies not in eliminating the need for network specialists, but rather in increasing the interaction of the network with its surrounding IT elements. Taken to its desired end state, SDN allows the network to be treated as a single resource. In concert with servers, storage, and applications, the network orchestrates workloads alongside its infrastructure components.
So who architects this infrastructure and makes all these pieces sing in harmony? DevOps. Chartered with creating the software glue that pulls all these disparate pieces together, the DevOps team simply won't have the time, expertise, or desire to become masters of everything, nor should it. Every moment the team spends working through the details of a supporting element is a moment it doesn't spend weaving it all together.
Some of this work is already happening. Tools like Puppet and Chef shift the point of provisioning from the network to the server side. The server guys specify what they need in terms they know--right now, a mix of networking and non-networking requirements--and those specifications are sent to agents on supporting devices that convert the instructions into device-specific configuration.
With SDN orchestration tools, application teams might document their underlying resource requirements beyond just networking. How many VMs, how much disk, or perhaps latency thresholds. As the model matures, those specifications become more abstract, perhaps involving HIPPA or PCI compliance, for example. Abstract requirements must ultimately be translated into device behavior, however. Who does that?
The DevOps person might own the software glue that deals with delegating requirements to individual IT infrastructure elements. But converting those requirements into specialized behavior that might vary on a device-by-device basis requires a degree of knowledge that comes only with a deep-seated understanding of the supporting technologies. And what if something goes wrong? Who will support all of this infrastructure, and how? A high-level view of inputs does not provide the full view of what's happening at a device level. Troubleshooting will invariably require someone who can plumb the depths of the infrastructure to find out what is actually going on.
In essence, these DevOps personnel will rely on their networking specialists to do their jobs impeccably. It is no more likely that IT will give up its network engineers than it is that IT will kill off the server or storage jobs.
That's not to say that the role of the network engineer won't change, of course. Over time, the growth of the network engineering field will slow from the pace it had achieved over the past couple of decades. Any new growth will likely favor those with programming skills, who can help orchestrate the network alongside applications and other resources. Those who continue to develop their skills along these lines will find themselves in the best position to take advantage of this.
The perfect candidate to lead the charge will be a programmer with a specialist background. And given that the network appears to be Ground Zero in this whole movement, it would appear that network engineers actually have a leg up on their competition.
Michael Bushong is currently the vice president of marketing at Plexxi, where he focuses on using silicon photonics to deliver SDN-based data center options. Prior to joining Plexxi, Mike spent 12 years at Juniper Networks, where he drove Juniper's SDN strategy, including product plans around OpenFlow, path computation element, application-layer traffic optimization and BGP traffic engineering. Prior to Juniper, Mike worked in the ASIC design tools industry.
