I remember from my early career days working on PBXs that SDN was a Subscriber Directory Number. Later in my career in various consulting gigs, I knew SDN as Secure Data Network. Today is has become more well known as Software Defined Networking.
Facetiously, to many it means Still Don't (K)now or paraphrased from old ISDN jokes, it means Still Does Nothing. In the end, suffice it to say that it's a floating definition, and one that will most certainly evolve over time.
Many people starting out their careers in networking today have great fear of this reused acronym. Many people still in school are actually doubting their career choices already, and haven’t given it a chance! Will it be the new harbinger of doom for the network engineer? (playing ominous music in the background)
The important part about what it means though, has to do with the effect it will have on your current or future career. The unknown breeds fear. Fear leads to paranoia. Or to the Dark Side, whichever you prefer to embrace.
(Yoda: Fear is the path to the Dark Side. Fear leads to anger. Anger leads to hate. Hate leads to suffering. I sense much fear in you.)
The interesting thing about SDN is really two-fold. You have large groups of people who are unsure about what it is really going to do and are trying to analyze the different use-cases of SDN and what it MAY do within their organizations. You also have another large group of people latching onto the marketing aspect of SDN, namely the believers that it will do anything and everything to automate your organization's network!
That generally leaves the existing networking staff someplace in between, blissfully moving through their day normally and simultaneously looking over their shoulder in a paranoid fashion. And some are feverishly updating their resume while looking for that ad for truck driving schools featured in Top Gun.
The reality lies somewhere in there, and as much as it amuses me, I will default back to the standard answer of "It Depends". SDN is a powerful tool that brings automation into networks. But (and all music-related anecdotes aside, it's a big but) not everything within everyone's network either can or should be automated! When people think of their jobs being automated, this is where the fear begins. Will you be automated out of a job? It sounds worse than outsourcing! You can’t really blame someone else for taking your job, you have to blame the equipment and process of the networks which you love! Well, have no fear… here are a few things to consider!
First, let’s run with the idea that SDN can do anything and everything. Congratulations. You believe marketing 100%. There are many professionals out there who will absolutely adore you for that, however, they all want to sell you something. So let’s be a bit more realistic and skeptical! What are the current (read as today’s reality) use-cases for SDN?
They can be summarized into some basic categories:
- Data Center orchestration (this has multiple entries, both for VM networking and for Storage allocation)
- Service Provider Orchestration (this has multiple entries also, for service activation and for mobile network services)
- Traffic Engineering (this includes dynamic changes based on individual application needs or things to balance)
- Dynamic Networking (this could be tunneling, or taps/monitoring for a variety of purposes)
Taking a look at SDN Central, we will see both use-case ideas as well as the place within a network they would seem to fit the best. How many of those apply to either your network or even your organization? Right now, most are within service provider networks, or larger data center operations. Ok, cool. So many of you can now relax! (A few of you just perked up and are now reading more intently!) Yet, in order to understand what is to be automated and where, we need to understand what happens completely in a network path.
(Yoda: You must unlearn what you have learned.)
Second, let’s look at the use-cases where we need to keep in mind the actual working pieces of an SDN network. Believe it or not, a magic wand is NOT one of them. Any process that is going to be automated needs to be analyzed first, and then broken into tasks. Have you even done software programming? Well, SDN is similar. You are creating a list of repeatable tasks and criteria in order to create a predictable list of outcomes. There is much trial and error in doing this (often emphasizing the latter part there!).
There is a lot of equipment as well, and much of it newer. It doesn’t matter what vendor we are working with, although I’ll certainly stick with Cisco here. I would certainly advise taking a look at Cisco’s offerings in this arena, starting with OnePK. The entire Application Centric Infrastructure is a grand idea, and allows for many new areas of expertise to be defined. But it doesn’t replace the basics! (Read this as net new, not throwing out the old!)
Third, and most importantly, keep in mind that even if you were to have every single task on your network automated, the basics of networking don’t change. There are complex things that we do all the time. That doesn’t mean that we can’t embrace automation for HELPING with some things (what I typically think of as the boring things that I don’t want to be doing over and over and over and over and over and …), but that we cannot automate every process in a network. Too many variables. Too many things change location to location.
Have networking vendors ever been able to come up with a startup script or web-GUI setup that works all the time? No. And there are some very smart people who work at (insert networking vendor du jour), but there are too many variables. Our low-end routers have startup scripts that work well. Why? Because those types of devices are put into locations that are more cookie-cutter in design and are easy to repeat. Wait. You mean something we can possibly automate? Yes. NOT the core of the network though.
(Yoda: Try not. Do… or do not. There is no try.)
Last, and perhaps most importantly, keep in mind that all of this grand network design and automation/process design has to be controlled by people. Unless we are implementing Skynet. And we all know how that turns out. (smirk) That being said, if you truly understand networking and how things work, then you may be in a prime position to play with SDN and see how it can be used to make your life easier and save your company money. This actually enhances your marketability, not limits or replaces it!
SDN is a tool, or a set of tools that may help us in certain processes. That being said, we network engineers may need to increase our skills and critical thinking a little bit in order to grasp the business and process/procedure concepts which will allow us to control the automation of particular things. So this should be viewed as an opportunity for improvement rather than any particular reason to run in fear.
As I have been told by a few people, I’m kind of an old guy in the industry. This means that I have seen many things change over the years. And many times there were people claiming that the sky was falling or that everyone would soon be out of a job. Magically, however, we have only seen increases in the need for good network engineers. Yes, things are significantly different than the way we were networking way-back-when (back in the days of Dixie cups and string for long-distance communications!), but many things are still the same and good people are needed, perhaps more than ever.
Know what SDN is and what it can do for you. Know what devices are, or are not, capable of taking advantage of these new features. Embrace the possibilities of the future, but do not get caught up with the view of the sky falling. Perhaps the sky isn’t falling, but the ground is rising!
(Yoda: May the Force be with you.)
Hope this has been helpful!
Note from the Cisco Learning Network with permission to add from Scott Morris:
For more on SDN, join Cisco experts as they review Software Defined Networking topics in live Tech Seminars and archived training videos.
Upcoming Live Sessions Include:
Network Functions Virtualization (NFV) February 27, 2014
eXtensible Network Controller (XNC) 1.5 March 27
SDN Live and Recorded Technical Seminars on the Cisco Learning Network