It's been said that SDN will conflate the worlds of programming and network engineering. As this happens, engineers will tackle a new job title -- network programmer -- requiring them to build a new set of skills.
Until now, networkers have not had to know deep programming. We are used to dealing with a structured environment when it comes to the operating system on the hardware we control. If I have to build a network for a client, I know that my Cisco, Juniper or HP equipment all have an operating system built into the boxes, and these systems have rules and a structure. In that way, network engineering is much like systems engineering, except that instead of Windows as the OS, we use Cisco's IOS, for example.
But with SDN, we will begin to implement controllers that direct tens of thousands of ports with the ability to provision network virtualization. A new job type is being created by the SDN transition: the network programmer. This is a person who will need to have a wide and deep knowledge of network engineering, as well as a deep knowledge of at least one powerful C-like programming language (C, C++, C#, Java, Objective-C). This role will be responsible for the actual programming of SDN controllers (the interface) and related components.
Understanding the murky world of programming
When it comes to programming, and accessing and accomplishing things using programming paradigms, the world is a different place. In programming, I am ostensibly working within certain systems, and I have the rules whether I am on Windows using PowerShell, Linux with a Bourne Again Shell (BASH), or Python using OS X. The rules of those languages are highly fluid in their application.
The problem for a lot of network folks is that we're used to dealing with variability in many areas of what we do, but not in the OS or commands themselves.
Programming allows you to use the rules and syntax of the language to effect a result, but there are no particular rules that tell you how you have to get to your goal. As one example, take a programming construct called a loop. Let's assume you want to loop using the C programming language. You can use a for loop, a do/while loop, or a while loop, and these can all have different conditions. You can do something while some condition exists, for instance. Which one you use, what conditions you test for and what results you get are highly flexible.
The problem for a lot of network folks is that we're used to dealing with variability in many areas of what we do, but not in the OS or commands themselves. In programming you have much more flexibility to shoot yourself in the foot along the path to wherever you're going. In fact, in programming it's even worse than that: You really are building the path as you go.
The first step to being a network programmer: Basic scripting
So where does a network engineer begin to learn programmability and apply these concepts to the network? The answer to that is highly personal, but I would argue that the first thing you have to learn is the basics of the thought process or logic underpinning all programming languages. The loops I described above exist in some form or another in all programming languages, and they have reasons for all existing at once. You have to learn when and why to use each one.
For most network engineers, it's best to start with some Linux shell (the BASH is the most ubiquitous) and the Microsoft PowerShell scripting. Both have tools and resources available to help you learn, both are very powerful, and both are juggernauts in the IT world as far as the tools and ecosystems supporting, and being supported by, them. Both will also teach you the basics of programming logic, from variable declarations and loops to logical case testing and function control.
Beyond basic scripting: Interpreted languages
Beyond basic scripting, if you want to step into something a bit more powerful, your best friend at this point is probably going to be an interpreted language. Python in particular seems to be the most popular choice on the network side of things, spawning all sorts of projects including one of the most interesting, Pyretic, which is part of the Frenetic Project.
Read more opinion on SDN and network programmability
SDN may … or may not … be the answer to network efficiency
Are you ready for SDN WAN?
Where do network admins fit into an SDN world?
Can we push past the SDN hype?
Interpreted languages tend to be highly portable and fairly easy to use. They're also powerful in their own right, and provide more than enough to network engineers into the foreseeable future in the context of SDN and network programming.
At the end of the day, basic scripting and programming knowledge is a good thing to have no matter where you are now in IT, or where you see yourself in the future. I've always said that any task I have to do more than once is something I'll script, and I see that becoming a trend among many non-programmer IT professionals.
The transition to SDN is not something to run from, or to be scared of. It is an opportunity for growth and learning. For some of us, it's a chance to use dormant skills or branch out into new positions that didn't exist before. Either way, pick a path and explore what programming can do for you. I think you'll be surprised at how useful some extra skills in this area can be, even in the context of non-SDN, traditional network settings.
About the author: Teren Bryson is a lifelong professional network engineer, VMware programmer and Unix geek. He is also whiskey taster; long-time practitioner of the art of beating computer and telecommunications systems into submission; brain hacker; student of everything; cancer survivor; lover of stuff that does stuff and a freelance writer. Read his blog at blog.packetqueue.net and follow him on Twitter @SomeClown.
Dig Deeper on Networking careers and certifications
