Reading Time: 4 minutes
Software programming is a challenging endeavor. I know, because it’s how I started my career, and it’s still something I do for fun and to keep my network engineering skills sharp. Writing software is also very tedious, which is why I quickly moved on to other things and now haven’t written code professionally for over 18 years or so. It takes a particular kind of person who wants to really learn the syntax and thought process needed to be truly skilled at coding.
It is also a particular type of person who wants to know the level of detail in how a large-scale network operates. Most IT professionals are content to know the basics of networking—enough to do their day jobs—and leave the hard-core network knowledge to that special sort of masochist breed known as network engineers. The hardcore network folks who are obsessed with performance tuning even the smallest details of how packets move around and between datacenters, the intricate differences between routing protocols, tunnels, underlays and overlays, and bit-twiddling for fun and profit.
In the past, those two sides of what I’ll loosely call the IT world have typically been different functions. The software types write the code for the systems, the systems people deliver the services, and the network folks tie it all together. From the outsiders’ point of view looking in, we’re all “computer nerds” and any differences between us are largely semantic at best. But peel back the vale and you’ll see that we’ve all decamped to our respective corners of the playroom and started our own little fiefdoms.
To hear some tell the tale the loose alliances and unsteady truces that have kept us functioning for so long are about to collapse under the weight of a new technology paradigm: Software Defined Networking. While I hope the current crop of shrill screeds about network engineers dying off if they don’t learn to program will slowly start to fade away as the reality of things sets in, I’m not holding my breath. SDN brings changes to the playroom of IT, for sure, but as I’ve written many times before, it is incremental, not wholly disruptive, change that’s coming on the back of SDN.
We only have to look to the changes that have happened in the systems space over the last 8–10 years or so to see what the future looks like. When the first wave of system virtualization started to make inroads, there was a tremendous amount of pushback from all corners of the IT establishment. Vendors refusing to support anything installed on a virtualized OS was the norm, and there were all sorts of opined pieces floating around the trade magazine circuit, bemoaning the death of the systems and applications folks.
In this brave new virtualized world, so went the reasoning, there would be no need for systems administrators. They would all go away in favor of this new specialty. In reality what happened was that the systems people kept right on doing what they’d always done, which was to learn the new technology… incremental change prevailed. Now any self-respecting systems admin knows and understands at least one hypervisor system at a pretty solid level. The tools changed, the paradigm shifted, and the systems administrators changed in parallel.
Did everyone suddenly become software programmers? Nope. They just kept on adapting with the times and instead of using the tools they had been using, or perhaps in addition to those tools, they started using new tools like Microsoft’s PowerShell. Now most big appliances in the systems world are accessible via PowerShell commands and the systems people can do more than ever. In fact, they can do it more quickly and accurately than in years past.
The same thing is going to happen on the network side. Instead of being confined to a pre-built OS, purpose built for one device, we’ll be able to access all of our devices using various new methods. Some of us will use off-the shelf solutions wrapped up as management packages—does anyone doubt that the big-boys of the network world will come out with software for SDN controllers that is pre-built, pre-packaged, and ready to use with no programming knowledge required? Others will use more advanced techniques and script our own tools to do specialized tasks as we need.
Given the changes coming in the next few years, I will say that any network engineers out there who haven’t been exposed to basic programming precepts; things like loops and basic logic flow, algorithms, and generalized problem solving using a programming-like syntax, should probably pick up a book and start playing around a little. PowerShell is a good place to start, as would Unix shell scripting (start with bash), but if you really want to learn a programming language, and you want something that will be useful in the networking world over the next few years, I’d highly recommend starting with Python. It’s easy to learn, easy to use, easy to get things done, and you get some immediate gratification. Also, outside of pure scripting languages, Python really seems to be where everyone seems to be coalescing when it comes to SDN controllers and APIs for network programming. Jennifer Rexford writes about the Frenetic Project and Pyretic in this article at Tech Target and it is well worth a read.
At the end of the day, the IT game is one where the rules are always changing, the skillsets always evolving, and quite honestly if you’re still doing the same thing you learned 5 years ago you’re already behind the curve. SDN may shake up the world of network engineering in a way we haven’t seen in a while, but it is nothing more than the continued march of progress. If you’re not reading at least one whitepaper or book on a new technology at all times, I personally don’t see how you’ve stayed in the game this long. SDN is just more of the same. Adapt or quit now.
Software programming is always going to be a specialized skillset, as is network engineering—at least at the highest levels. That doesn’t mean that you shouldn’t embrace the coming change and learn to play with the kids on the other side of the playroom a bit, though. If you venture over to the other side, you might find that some of the toys they have are the missing pieces from your play set, and that you have more in common with one another than you originally thought.