SDN is a Concept, Not a Technology

I was recently posed a question: “How does the networking industry train and build skills for tomorrow’s SDN with today’s engineers?”.

Personally, I think that is the wrong question.  SDN is not a skill that you learn.  SDN is not a class you can take.  SDN is certainly not a training path you can attend.  SDN is a concept, plain and simple.  It’s the software and underlying technologies that you must train, understand, and build upon.  SDN, like Cloud, is born from the limitations of the current technology to keep up with the changes in other technologies and demands.  It is a mix of technologies and software, as it were, all bundled up in a warm and cozy blanket that we call “SDN”, packaged up in a pink bow, and sold to everyone saying “It will fix you, from you!”.

Why has it taken so long for the network paridigm to change?  Because the network just works.  There is very little that goes on from a data path perspective.  A packet in, is a packet out.  Network protocols, algorithms, and equipment only changes in order to keep up with the data speeds that services demands, and to make efficient path decisions.  The *only* reason why it’s changing now, is to keep up on the changes that virtualization and cloud automation brings.  Without those technologies, the network would still be static.

What do you mean, “without virtualization the network would still be static”?  Even if you take virtualization out of the mix, the network still needs to change!

Well, that’s true.  But, what exactly *is* changing, here?  Without Cloud/Virtualization, all the network needs to do is to make data flow more efficient.  What “efficient” means to you can be anything.  That can still be done by throwing in more hardware and building features in it’s firmware.  SDN was created to handle the on-demand needs of virtualization and cloud-services without human intervention.  Of course, like any other concept, once the idea was born, other uses and benefits started to fall into place outside the virtual realm (such as the white-box switch, central controllers, and flow-based decisions).  Need more port density and higher speeds?  Clos networks can do that, and that’s still not SDN.

Really, if you are so apt to define SDN, then look at your network vendor.  If they have an API that you can call from a program to do something, you are using it.  It doesn’t have to be a controller-deciding, flow-tracking, multi-million dollar solution.  And, yes, of course you can have SDN without virtualization.  I am simply saying virtualization is what had to come first before SDN would even be a thought.  Now that it’s out there, people and businesses are coming up with ways to use it every hour.

So, back to the question, “How does the networking industry train and build skills for tomorrow’s SDN?”.  Simply by building training paths of the technologies that are being used.  This really isn’t any different than storage guys learning FCoE or digital voice guys learning VoIP.  The vendor that is selling the SDN offering should be responsible for the training and the skills needed to complete and maintain it.

When talking this over with @netmanchris, he brought up an excellent point that I didn’t consider.  When I asked him “Well, how did we train the storage guys to learn SAN?  How did we train the digital voice guys to learn VoIP?”.  He simply answered, “Most of the time, the network guys took it”.  Nailed it.  I never considered that, but I would imagine that would be true for most.

So, honestly, if the network guys were able to learn SAN and VoIP, then shouldn’t it be reasonable to think that we are flexible enough to learn SDN concepts and technology also?  Is it really a new career path?  Since most network engineers are already learning some kind of programming language (python seems to be the average choice), wouldn’t it make sense that the next logical step in our growth to be a Software Defined Network of some kind?

Personally, I see SDN-type networks to be just another career choice, along with Voice, Route/Switch, and Service Provider.  The running joke early on with VoIP was that voice is just a point-and-click system.  SDN-built networks will probably be similar.

Disclaimer:  I’m no SDN junkie, and simply a network wanna-be.  These are not facts, but simply the ramblings or a network dude who likes to talk.  Personally, I can’t wait to get started on SDN.  I’m all in!

Share This Page : Share on TwitterShare on FacebookShare on GooglePlusShare on PinterestShare on Linkedin
  • http://ca.linkedin.com/in/jasonhurlbut Jason Hurlbut

    Well Said, and I might add that “most network engineers are already learning some kind of programming language” is the point. If the network engineers aren’t learning programming, they will have a hard time creating an “Application Aware” or Smart Network.
    However, have you ever noticed that nobody actually buys technology? They buy what it can do for them and SDN, NFV, ACI and the other acronyms all promise to drastically reduce OpEx & CapEx while enabling agile service delivery.
    Wouldn’t any CIO be happy to bring an actual ROI story to their CFO? (Possibly for the first time!)

    • http://www.myteneo.net Aaron Paxson

      I also think we need to define “programming”. Everyone is worried about making engineer’s “programmers”, but, isn’t that what we’ve been doing all along? Programming network equipment to fulfill a design pattern and flows? The “context” changes, but the ideology stays the same.

      I do agree that it can bring a great ROI. The problem is, it may be harder to build true ROI numbers, since most of it is based on soft-costs.