- Network administrators learning how to program is a benefit to employees and employer, but it shouldn’t be a requirement.
- SDN promises many things including operational simplicity. Programming isn’t operationally simple and your network admins shouldn’t be doing it.
Even if SDN isn’t having an impact on data centers like my colleague Steve Hill thinks, the idea is certainly having a ripple effect within IT departments and among network professionals considering their career path. One common topic the keep recurring is whether network professionals need to become programmers to remain relevant.Kirk Byers thinks programming will be an essential skill for network engineers and points to the number of commercial and open source tools and controllers that have APIs and SDKs that can be used to stitch together various components into an automated and orchestrated network. In principle, I think the more network professionals know about how their systems work and integrate together, the better off they will be career-wise and the greater value they will be to their employers; but I generally disagree with the premise. Besides, if network professionals also have to be developers, then the entire networking industry will have failed to deliver one of the key benefits of SDN – easier operations.
Network equipment vendors, a number of start-ups, and open source projects have started shipping SDN controllers – and the ecosystem that supports them – with the very lofty goal of reducing operational overhead. Tell the controller what you want and let it figure out how to get packets from any point to any other point. Give the controller parameters to meet for quality of service and let it modify the network to meet those demands. Granted, we are a long way from either of those goals, but it’s starting. The operational efficiency of SDN will come from robust SDN controllers and a supporting ecosystem of integrated products. It appears to me that Byers doesn’t think vendors will rise to the challenge, but I am more optimistic.
Enterprises can get many of the benefit of SDN without going to a controller. Byers makes the point that many network engineers already “have been hacking together shell, Perl, and Python scripts for quite a while” but that’s a far cry from the skills required to programmatically automate even moderately simple systems reliably. It takes time to determine what needs to be done and what the final result should be and then write code to glue the two ends together. The more difficult the scenario (i.e., the greater number of requirements or moving parts), the longer it will take. Meanwhile, what will your network engineers be doing while they are programming? (Hint, it’s not administering the network.)
You want your network engineers to administer the network; which includes design, maintenance, management, and troubleshooting. It’s what they are good at and any automated system needs a managerial presence. You want developers to write programs that are reliable, versatile, and maintainable. What you get with both is DevOps—the merging of two IT silos (often more) that collaborate toward the same goal. What you don’t get are staff trying to fulfill two roles, one of which they may not be qualified for or experienced in. Granted, some companies have done away with some IT roles like network engineers and administrators and rely heavily on developers to manage their data center networks, but those same companies will tell you their demands are relatively simple and don’t require the domain expertise of a network engineer. They are the corner case.
If you are a network engineer or you manage them, then yes, a working knowledge of programming will be useful to some degree, but don’t think you can make your engineers into developers. They are people, not widgets.