SDN Should Not Require Programming – Per Se

There has been a lot of controversy about how the network engineering profession will change in the future, thanks to SDN (Software Defined Networking).  Because network decisions will now be controlled by software, many think the network engineering profession will have to learn programming.  While this may be true in some cases, I do not believe it to be true in the majority of the cases.

If you break down the acronym, it will say “Software-Defined” networking.  This means software that has previously been written to accomplish a specific task will be deployed on the network.  Do you need to program an already-programmed system?  Do you need to know programming to use Microsoft Office or Evernote?

What IS programming?

First off, let’s define “programming”.

pro·gram
ˈprōˌɡram/
verb
gerund or present participle: programming
1.
provide (a computer or other machine) with coded instructions for the automatic performance of a particular task.
“it is a simple matter to program the computer to recognize such symbols”
  • write computer programs.
  • input (instructions for the automatic performance of a task) into a computer or other machine.

So, one form of programming is to provide coded instructions to complete a task.  But, it can also be input to complete a task.

You’re probably already a programmer

Technically, network engineers have ALWAYS been programmers.  When you filter an AS-Path, or tweak the default timers of spanning-tree, you ARE programming the network.  Implementing routing protocols is another example.  Need to build a solution to a challenge using GRE or MPLS?  You may not be actually writing the code, but you ARE configuring the code.  And the software that is controlling the network is built-into the hardware OS.  Now, SDN does change where the decisions are being made, and it does give far more flexibility and control over network flows.  But, in the end, we have all been programmers to some extent.

I may be reaching a bit on the definition of programming.  My point of it, is to say that programming is really not much different, only the syntax changes.

I see SDN changing one profession, and creating another.  The first are the network architects.  These are the people who will design how the flow will be processed.  Really, no different than what they are currently doing, except that they will have far more options to choose from, based on the vendor’s controller and applications installed.  Maybe the “architect” is your vendor.  Maybe you hire one. Maybe your engineer is also your architect (very common)

The second is to create a new professional learning path, similar to what we see with Route/Switch, Security, Voice, and Service Provider.  We may now see a new path, learning different controllers and implementing new policies and procedures to the network.  It is these two professions, that should learn programming.  Does that mean everyone else shouldn’t?  Certainly not.  The more you know, the better decisions you can make, and the faster you can resolve problems.

When I talk about “learning programming”, I’m not really talking about any specific language, though, that would be helpful.  I’m talking about procedural steps, logical decisions, conditional statements, variables, etc.  Basically, breaking down the steps and information needed to decide where a flow should go.  Frankly, most of you are probably already more prepared than you think.  Managing Access-Lists, building Filters, and configuring firewalls is already the first steps into this area.  If you have ever scripted a network change, you are more qualified than others.

“But, what will happen to the engineers?”, you ask?  Well, I feel their roles haven’t changed much.  Where they do their work will change.  Instead of a CLI, it may be in a “Diagnostics Mode” or some kind of Web-Interface tool.  We still need deep fundamentals of protocols.  SDN does not do away with spanning tree, MPLS, or routing protocols.  We still need to use IPv4/IPv6 and IPSec.  We need engineers who have detailed knowledge of implemented technologies to identify bugs and know how it “should work”.  SDN merely changes HOW it’s implemented, and maybe WHERE it’s implemented, but not WHAT is implemented.  See my post SDN is a concept, not a technology.

Conclusion

SDN (Software Defined Networking) should not require network engineers to program, but it does help.  The majority of the programming has already been done from the vendor’s product.  You just install and configure it.  However, once SDN becomes more main-stream in networks, I would venture to say that 80% of the work done, would really be in the interface itself.  Point-and-click.  The other 20%, is to give you more control and adversity into what you want to accomplish, that the provider doesn’t have.  It is the 20% that may require programming, as you are extending the system to do more than initially intended.

Okay.  You got me.  Maybe it’s not 80/20.  That’s just a number I threw out there.  But, I do believe the majority of your time spent in configuring the network, will be in a user-interface, and not in coding.  The coding is for the really large networks (the Google’s and Amazon’s of the world).  For everyone else, the vendor’s coding should be sufficient.

Agree?  Disagree?  Leave a comment.

 

Share This Page : Share on TwitterShare on FacebookShare on GooglePlusShare on PinterestShare on Linkedin