The essence of SDN is to create a software model of the current data network business. This quantitative model is based on volumes of data: what ‘bandwidth’ resources do I have (i.e. supply), and how can I give different quantities of this ‘bandwidth’ to different users and uses (i.e. demand)? -via circleid
I’ve been in information technology since the early 1990’s, and it’s always been like this: business tells IT what to do, and IT does it. In other words, we make technology mirror business. Which is a fine formula for success, so long as you think business is the engine of innovation. The problem is innovation doesn’t come from one department or place. In fact, innovation most often comes from the intersection of two or more things. Think about it.
When did cars first start being innovative? When they combined the technology that existed in the latest horse drawn carriages with the latest in industrial technology, including internal combustion engines and assembly line production. All three of these came from someplace else—many people don’t know the idea of interchangeable parts came out of the firearms world, rather than the automotive industry. When did innovation come into the auto industry again? When modern lubricants were combined with transmissions, and then again when electronics were combined with engines, and… No matter where you look, innovation always happens when two other things (often apparently unrelated) collide.
So what does this have to do with the discussion about about SDNs? The fact is that SDNs don’t bring much to the table in terms of real innovation. Centralized control planes? We had them in the SS7 switch we installed at McGuire AFB fifteen years ago, and the Xerox Star we had sitting in the 21st AF building, and the Burrough’s mainframe (really!) and the terminal emulation cards I was stuffing into Z100’s.
The fact is that SDNs might bring in a new way of managing a network and a new way of thinking about control planes, but there’s very little here that’s new, exciting, and unique to SDNs. There’s the interface to the application, sure… But, then again, we’ve not quite worked out the negative side effects of this sort of thing, either. What do the feedback loops look like here? What new complexity are we adding to the overall system? In short: what are the tradeoffs?
Until we think about things this way we’re going to have problems with deciding what, precisely, we do with SDNs. Making our current business models more efficient is a great thing, but it’s not something that’s going to make a huge difference in the wider world. It might sound terrific to turn your network engineers (who are expensive and hard to find) into coders (who appear to be more widely available), but every time you fuss about a bug in your O/S, web browser, or any other application, remember—next time, it’s your entire network that’s going down.
SDNs might be great for some purposes in some places, but let’s not go jump to the other end of the pendulum “just because.” Instead, let’s take a measured approach, and think about how technology and business can interact to make better things, rather than playing the same old game of, “IT is a cost center, I just want it to be cheap.” Should technology mirror business? Rather, technology and business should interact to create new ideas that will drive both into new realms in the future.