You could say that SDN totally changes network hardware, and also be right by saying it conserves every investment in the network you've made.
It's centralized, distributed, neither, and both. It's not only "Mom's apple pie", it's also "Mom" and "apple pie" separately. That's why the media loves SDN so much; it's totally in the eye of the beholder. Look in a mirror and you'll see SDN, at least if you believe the claims.
Real buyers are a bit more circumspect in thorough surveys, however. Right now, 85% of the "SDN installations" we have would not be recognized as SDN at all by the SDN purists. Buyer literacy levels in SDN are about two-thirds what would be needed to sustain a real market. No SDN benefit got even a 40% acceptance rating from enterprises in my fall 2013 survey, and no users reported current or expected total replacement of their current networks with SDN. But on the positive side, well over 80% of enterprises think they will adopt SDN in some form within the next three years, and even more think that their service providers and cloud providers will use it.
What do users really need to know about "SDN?" I think there are four important things, things that the average network user probably doesn't know today.
The first thing is that you are not inevitably going to migrate to SDN. If you have a very large data center and employ virtualization or private cloud technology, you're likely to want to look at some form of SDN within the next couple of years. For the rest, there may never be much of an SDN business case, particularly for SMBs. But even those who "look" at SDN may not find that it brings compelling benefits. Almost everything SDN can do can be done without it, so you're going to want to do a careful business analysis of any SDN benefits before you jump.
The second thing to understand is that there are at least four totally different network product sets that are called "SDN" today, and more may come along. Today's set includes:
1. The "software-switch-router" model, which is a software implementation of current switching/routing and no special SDN features at all.
2. The "overlay-network" or "Nicira" model, where an SDN rides as a new virtual layer on top of current switching/routing.
3. The "distributed" or "API-and-Protocols" model, favored by Cisco, where the goal is adding features to current devices/protocols.
4. The purist OpenFlow model.
If you decide to put out an RFP for an SDN product, you're facing the same kind of challenge that you'd encounter if you said you wanted to buy "a vehicle." Motorcycle, bike, skateboard, automobile, truck, boat, airplane...you get the picture. The moral to this is that you're going to have to do a pretty careful assessment of what "SDN" means before you have any chance of making an SDN buy work for you.
The third point is that this is a very immature space. None of my survey users had a full year's experience with even an SDN pilot. The longest-standing users had gone through several changes in vendors or approach that they deemed to be "significant", and everyone reported that getting skilled SDN professionals was about as easy as finding astronauts in their labor pools. Nearly all said they met other users through SDN events, not through their normal professional circles.
You're going to want to run a very thorough pilot test on anything you decide to try to deploy, and not a short one either. Yes, there are "big companies" using SDN, but most of them are network service providers, IT giants, and the like. Be careful.
Point number four is that most purported SDN benefits don't really come from SDN. Users talk about "greater service agility" or "reduced operations costs" or "lower network service costs", but the problem is that unless you have a complete end-to-end SDN service implementation, these benefits are more likely to come from improved operations practices than from SDN per se. In fact, we don't know what SDN management/operations would really look like, so presuming these benefits is a tad risky.
So what should you do about SDN--what can you assume? Here again we have a list.
First, assume that you'll adopt SDN first in the data center, and in very large data centers at that. SDN can be used to improve application segregation and security, and it can also be used to improve the efficiency of multi-layer switching. The bigger your data center, the more likely it is that you can make use of SDN there. If you can't justify SDN in the data center, then it's very likely you don't have a near-term SDN mission that you can pursue safely. Let the old earth take a couple of whirls so technology and practices mature.
Second, look toward an expanded SDN mission among data centers or across to your branches even before you commit to a data center SDN approach. Most users probably won't see much SDN outside the data center, but SDN solutions are likely to be differentiated by what they can do outside the data center. If you have no such application on the horizon, you have a simple selection and implementation. If there may be an SDN extension in your future, be sure your model of SDN (and your vendor) supports it.
Finally, don't expect SDN to make major changes in the carrier services you consume, at least not in the near term. Carrier SDN is focusing on narrow applications too, mostly in their own cloud. You won't see major changes in service driven by SDN for several years, when management and operations mature.
SDN is going to be important, but just as the choice between concrete and asphalt probably doesn't matter to most drivers, SDN or legacy probably won't matter much to users of applications until we understand just what SDN can do better than we do today.
Follow Tom Nolle on Google+!
Tom Nolle on Google+
