SDN

In 1876, an internal memo at Western Union is reported to have read: “This ‘telephone’ has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us.” At the time, Western Union was the Microsoft of its day–a behemoth company that touched everyone’s lives. While the veracity of that quote is questionable, the fact remains that after losing a patent lawsuit to Bell Telephone in 1879, the Western Union shifted its focus to money transfers. To put it another way, the entire business model upon which Western Union was predicated, collapsed to a new, disruptive technology that the leaders of the business failed to capitalize on.

While this has important lessons for business leaders today, we often see an almost reflexive reaction to new technologies in the other direction. We get in such a bother trying to divine the “next big thing” that we almost entirely fail to qualify the claims that are being made and end up betting the bank on unproven or half-baked concepts.

I’m certainly not saying that SDN is any of these things, but rather that there are a lot of myths and marketing fogging up the landscape. I actually believe that SDN–in at least some of its purported definitions–will most definitely make it into the networks of tomorrow, and further that several things will change as a result. I don’t, however, buy into a lot of the myths that seem to have developed suddenly, out of the ether, around the technology.

I should also point out that the myths below are some of the more common ones I hear, but taken in totality don’t necessarily represent any one company’s vision of SDN. There are many competing technologies and companies claiming the mantle of SDN which, in many cases, are completely at odds with one another. Is SDN the abstraction of the forwarding plane from the control plane? Is it programmatic access to network devices? Is it automagical definition of policy across abstracted forwarding planes–boxes of dumb pipes manipulated by controllers? The answer is, it depends on who you ask and what they’re selling. Myths abound, no matter from which perspective you look, and we’re going to debunk a few now.

SDN is a Useful Term – I don’t think so, no. I think the term is “marketecture” and is largely meaningless beyond very high-level discussions. There are so many competing visions of not only how to “do” SDN, but of what it even means that largely the catch-all term has lost its usefulness for an engineering-level discussion. Established companies are competing with start-ups, with one another, and in some cases internally to define what SDN is and what it is not. A lot of these ideas will end up in products and technology that will eventually be for sale, while many will fade or become nothing more than slight business differentiators in incrementally improved hardware. As it stands today, SDN as a term is nothing more than the cloud of this year–the thing-du-jour that every company can’t wait to shoe-horn into every marketing slide and product-line they have. It is itself devoid of meaning or usefulness. That’s not to say that the component pieces of any of the amalgamations of definitions aren’t themselves extremely useful–they are–but rather that the term is not useful.

SDN reduces complexity – For those preaching the “less complexity” variant of SDN, I’d say that you need to look at history. Did the advent of virtualization increase or decrease overall complexity in the compute space? It increased it, of course, by several orders of magnitude. The same goes for storage abstraction, and the same will happen with SDN. We may or may not gain efficiencies and flexibility, but we most assuredly will not gain simplicity.

SDN eliminates Network Engineers – This is patently silly on multiple fronts, but let’s just go with the easily picked and obvious nit to begin with: SDN is predicated on having a robust network architecture underpinning it. In other words, you can’t have software-defined anything until you have an infrastructure in place to build on. That infrastructure is going to be complex, highly specialized, and not at all simple to design, build, or maintain. Day-to-day change management will likely be done by less qualified folks, but you’ll still have a place for skilled engineers in the same place where they operate today: design, build-out, and troubleshooting complex environments.

SDN lowers costs – Based on past experience, I don’t think this will ever be true either. People will conflate the downward pressure on pricing and the further commoditization of all aspects of hardware with a lowering of costs directly because of SDN, but this is incorrect. It is incorrect in the same way it would be wrong to say that the abstraction of compute and storage in any way lowered overall costs.

To make sense of this you really have to start looking at 5 and 10 year historical costs (or even 15) to see what has happened. And what that looks like is a similar cost profile as a component of operating profit, but with a large increase in efficiency. I’ll say that another way, you’re not lowering your true IT costs over time… you’re increasing your efficiencies.

Why does increasing efficiency not lower overall costs? Because you rapidly fill the gap with new capabilities. Anyone who has seen a transition from bare-metal servers and storage to virtualized workloads, servers, and SANs has also seen the corollary of server sprawl. How many of us have collapsed thousands of bare-metal servers only to see the total number of VMs increase eventually?

Oh, and now you have a team of storage engineers, and a team of virtualization engineers, and you still have the server, network, DBA, ERP, help-desk, etc. from before you virtualized.

There are a lot of ways to frame or quantify the cost-savings claims in SDN, but I think a better and more accurate description might be that SDN will likely increase efficiencies. You’ll be able to do more with less, but you’ll fill the gap so quickly that any cost savings you think you’ll get will get eaten before one budget cycle is up. Likely you’ll have a large CapEx spend to do a fork-lift upgrade, and that will take 3 years to balance out and come off the books. In the mean time, you’re going to increase OpEx because of training, initial development, network redesign, etc. By the time your feet are firmly planted, you’re comfortable with the new look of things, and you’re ready to start counting the pennies “sprawl” of a new type (development costs most likely) will eat any savings. That’s a 3 to 5-year cycle just there.

SDN mitigates change management risk – This one is only partially a myth. For the bulk of change management, I’d say that this is quite likely completely true. Day-to-day port changes, routing changes, and provisioning (to name a few) are easily screwed up by the less experienced folks likely making those changes today. Having a system that can make the changes with less manual input is going to probably save a lot of the little ticky-tack problems that crop up from someone fat-fingering a configuration command.

Larger changes to a network are likely going to fall outside of the scope of what SDN brings to the table, especially in multi-tenant or highly complex environments. These are the types of changes you still are going to need a highly skilled team to implement, and I don’t see a point coming soon where I’d really feel comfortable trusting large-scale changes to an automagical, largely self-driven system. Even today, how many of us trust the software “wizards” built into any commercially available product? How many of us make wholesale, system-wide network changes using a wizard? Simply changing the name to SDN doesn’t change anything.

SDN is disruptive technology – IT is, almost by definition, filled with people who take a “down in the weeds” view of everything. It has to be. But sometimes this leads to a kind of unique myopia in viewing changes in technology. When Multi-protocol Label Switching (MPLS) was introduced, it was as disruptive to the status quo as anything, but it was adopted slowly, people adapted, nobody lost their jobs and whole industries weren’t eradicated. Why? Because from the business point of view it was just a more efficient way of solving the same old problems. It was better than what it replaced, but it was incrementally better. In other words, it wasn’t the telephone to Western Union’s telegraph.

SDN in all its myriad visions, and as evangelized by all of its newly christened champions, is fascinating, eminently useful on some levels, and maddeningly silly in others. At the end of the day, however, it’s critical that we don’t get so involved in the excitement, promise, and religious fervor of new technology that we lose sight of what is real, what is useful, and what is “marketecture”. Magic beans may have worked for Jack, but I’m not buying any for my network. Yet.