Wherever you look, there are clouds. Across every horizon, in every datacenter, a cloud of a public or private nature is found. The use of Cloud as a marketing term has peaked. As the Cloud hype cycle fades, a new branding and marketing term has arisen: Software Defined Networking or SDN.
Rooted in the academic pursuit of Network Virtualization, SDN is programmatic control over networks. With SDN, a network admin can do more with less. In a world that pulses to the tune of light on glass, this is a powerful thing. The acquisitions of Nicira by VMWare (for north of $1B at a rumored >100x revenues) and other companies are fanning the flames. The big companies want in on that money.
The war for the future of information technology is being fought in the datacenter. SDN may be the latest frontier, but is it all hype? Many products, of frankly questionable technical merit, brand themselves as SDN. Any good marketing term in information technology is subject to similar abuse.
Because information technology is so hard for most people to understand, companies naturally gravitate towards anything that resonates with the prospect of increased utility and ease of use (think cloud). Rather than determine whether or not a particular company is real, we’ll derive more benefit from consideration of our current position in the SDN hype cycle. Companies can call their technology whatever they want. The proof is in the RFP process and customer retention, but let’s not digress too far. Today we’ll consider the SDN Hype Cycle!
The beginning of the Hype
OpenFlow, which started at Stanford, was an attempt to introduce abstraction to network management. Abstraction, from the kernel to the operating system and even to the GUIs we use every day, is central to computing. The theoretical innovation of OpenFlow was to allow abstraction across routers and switches irrespective of manufacturer. Although Google deployed OpenFlow in a rather large network, the use of homogenous equipment prevented validation of the general concept. OpenFlow was trucking along at Stanford when Diane Green (CEO of VMWare) suddenly funded one of the primary OpenFlow researchers. That startup was the previously-mentioned Nicira, just a couple of years before their acquisition by VMWare. The private nature of Nicira prevents detailed knowledge of their technology. It is well to note that some very large companies run it in their data centers to control their networks, ostensibly using software.
Nicira was the beginning of the SDN hype cycle.
What is SDN?
To my mind, SDN has 3 elements:
- Decoupling networks from services
- Providing programmatic control of hardware via software
- Orchestrated management of devices from a GUI (and command line)
Decoupling networks from services allows product managers to think about products instead of networks. This is similar to the way Amazon decoupled hardware from applications using AWS.
Providing programmatic control is an extension of decoupling. Decoupling, by itself, is inadequate. For business at scale, manual control is insufficient. In order to provide scaling accessible controls, an API or other control abstraction must be developed.
Orchestrated management is about making each individual contributor more powerful. Whereas previously many man-hours were required for even the most trivial changes, orchestration makes every admin superman. Instead of having to remote into each router, one command, or one click in a GUI, results in transformative change across the infrastructure: one controlling many.
The punch line is this: SDN is about concealing complexity. SDN hides all of the difficult parts of network management behind a facade of simple GUI goodness.
That sounds awesome! What could possibly be wrong with that?
Well, as is sometimes the case in technology, the truth and the hype may not necessarily line up. There are a lot of companies that pitch solutions as SDN when in reality they’re nothing of the sort. To help you separate the wheat from the chaff, here are three helpful guidelines for deciding if something is an SDN contender or pretender:
- Is it hardware Agnostic?
This is a pretty simple test. SDN is, among other goals, intended to break vendor lock-in. A company pitching vendor lock-in as a part of SDN is clearly pretending.
- Does it have an API or other control mechanism that’s faster than clicking on things?
This test is simple: if you have to use a GUI to control everything it’s not really going to allow for the advanced programmatic control you’ll need as your business grows.
- Does it allow product people to forget about the underlying infrastructure?
This one is a little tricky. If perusing the product specs reveals many network focused items instead of deliverables (itemized server lists versus ‘I need X compute resources here’), chances are your product managers are wrestling with the network when they should be building products.
Again, ending vendor lock-in, accessibility and concealing complexity are the core tenets of SDN-goodness. If you’re missing one or more, chances are you’re not dealing with SDN.
Ok so now that we understand SDN, is it relevant?
If your audience is part of the Fortune 1000, chances are their IT department has a directive to pursue the cloud. At least half of the businesses I’ve worked with personally are looking at SDN. Although lower numbers have directives to pursue SDN, there’s still a groundswell of activity around SDN reminiscent of Cloud from 2010.
We now seem to be at a point of cultural acceptance for SDN. The market will likely press on in this direction for the next three to five years. During that time, marketing teams should position their technology to take advantage of these dynamics. Software Defined Networking is just a better way of managing networks. We’ll all benefit tremendously when true SDN is widely-implemented.
So is SDN all hype? Not from where I’m sitting. Bet on SDN hitting many more data centers in 2014.