SDN Myths

In 1876, an inter­nal memo at West­ern Union is reported to have read: “This ‘tele­phone’ has too many short­com­ings to be seri­ously con­sid­ered as a means of com­mu­ni­ca­tion. The device is inher­ently of no value to us.” At the time, West­ern Union was the Microsoft of its day–a behe­moth com­pany that touched everyone’s lives. While the verac­ity of that quote is ques­tion­able, the fact remains that after los­ing a patent law­suit to Bell Tele­phone in 1879, the West­ern Union shifted its focus to money trans­fers. To put it another way, the entire busi­ness model upon which West­ern Union was pred­i­cated, col­lapsed to a new, dis­rup­tive tech­nol­ogy that the lead­ers of the busi­ness failed to cap­i­tal­ize on.

While this has impor­tant lessons for busi­ness lead­ers today, we often see an almost reflex­ive reac­tion to new tech­nolo­gies in the other direc­tion. We get in such a bother try­ing to divine the “next big thing” that we almost entirely fail to qual­ify the claims that are being made and end up bet­ting the bank on unproven or half-baked concepts.

I’m cer­tainly not say­ing that SDN is any of these things, but rather that there are a lot of myths and mar­ket­ing fog­ging up the land­scape. I actu­ally believe that SDN–in at least some of its pur­ported definitions–will most def­i­nitely make it into the net­works of tomor­row, and fur­ther that sev­eral things will change as a result. I don’t, how­ever, buy into a lot of the myths that seem to have devel­oped sud­denly, out of the ether, around the technology.

I should also point out that the myths below are some of the more com­mon ones I hear, but taken in total­ity don’t nec­es­sar­ily rep­re­sent any one company’s vision of SDN. There are many com­pet­ing tech­nolo­gies and com­pa­nies claim­ing the man­tle of SDN which, in many cases, are com­pletely at odds with one another. Is SDN the abstrac­tion of the for­ward­ing plane from the con­trol plane? Is it pro­gram­matic access to net­work devices? Is it automag­i­cal def­i­n­i­tion of pol­icy across abstracted for­ward­ing planes–boxes of dumb pipes manip­u­lated by con­trollers? The answer is, it depends on who you ask and what they’re sell­ing. Myths abound, no mat­ter from which per­spec­tive you look, and we’re going to debunk a few now.

SDN is a Use­ful Term — I don’t think so, no. I think the term is “mar­ke­tec­ture” and is largely mean­ing­less beyond very high-level dis­cus­sions. There are so many com­pet­ing visions of not only how to “do” SDN, but of what it even means that largely the catch-all term has lost its use­ful­ness for an engineering-level dis­cus­sion. Estab­lished com­pa­nies are com­pet­ing with start-ups, with one another, and in some cases inter­nally to define what SDN is and what it is not. A lot of these ideas will end up in prod­ucts and tech­nol­ogy that will even­tu­ally be for sale, while many will fade or become noth­ing more than slight busi­ness dif­fer­en­tia­tors in incre­men­tally improved hard­ware. As it stands today, SDN as a term is noth­ing more than the cloud of this year–the thing-du-jour that every com­pany can’t wait to shoe-horn into every mar­ket­ing slide and product-line they have. It is itself devoid of mean­ing or use­ful­ness. That’s not to say that the com­po­nent pieces of any of the amal­ga­ma­tions of def­i­n­i­tions aren’t them­selves extremely useful–they are–but rather that the term is not useful.

SDN reduces com­plex­ity — For those preach­ing the “less com­plex­ity” vari­ant of SDN, I’d say that you need to look at his­tory. Did the advent of vir­tu­al­iza­tion increase or decrease over­all com­plex­ity in the com­pute space? It increased it, of course, by sev­eral orders of mag­ni­tude. The same goes for stor­age abstrac­tion, and the same will hap­pen with SDN. We may or may not gain effi­cien­cies and flex­i­bil­ity, but we most assuredly will not gain simplicity.

SDN elim­i­nates Net­work Engi­neers - This is patently silly on mul­ti­ple fronts, but let’s just go with the eas­ily picked and obvi­ous nit to begin with: SDN is pred­i­cated on hav­ing a robust net­work archi­tec­ture under­pin­ning it. In other words, you can’t have software-defined any­thing until you have an infra­struc­ture in place to build on. That infra­struc­ture is going to be com­plex, highly spe­cial­ized, and not at all sim­ple to design, build, or main­tain. Day-to-day change man­age­ment will likely be done by less qual­i­fied folks, but you’ll still have a place for skilled engi­neers in the same place where they oper­ate today: design, build-out, and trou­bleshoot­ing com­plex environments.

SDN low­ers costs — Based on past expe­ri­ence, I don’t think this will ever be true either. Peo­ple will con­flate the down­ward pres­sure on pric­ing and the fur­ther com­modi­ti­za­tion of all aspects of hard­ware with a low­er­ing of costs directly because of SDN, but this is incor­rect. It is incor­rect in the same way it would be wrong to say that the abstrac­tion of com­pute and stor­age in any way low­ered over­all costs.

To make sense of this you really have to start look­ing at 5 and 10 year his­tor­i­cal costs (or even 15) to see what has hap­pened. And what that looks like is a sim­i­lar cost pro­file as a com­po­nent of oper­at­ing profit, but with a large increase in effi­ciency. I’ll say that another way, you’re not low­er­ing your true IT costs over time… you’re increas­ing your efficiencies.

Why does increas­ing effi­ciency not lower over­all costs? Because you rapidly fill the gap with new capa­bil­i­ties. Any­one who has seen a tran­si­tion from bare-metal servers and stor­age to vir­tu­al­ized work­loads, servers, and SANs has also seen the corol­lary of server sprawl. How many of us have col­lapsed thou­sands of bare-metal servers only to see the total num­ber of VMs increase eventually?

Oh, and now you have a team of stor­age engi­neers, and a team of vir­tu­al­iza­tion engi­neers, and you still have the server, net­work, DBA, ERP, help-desk, etc. from before you virtualized.

There are a lot of ways to frame or quan­tify the cost-savings claims in SDN, but I think a bet­ter and more accu­rate descrip­tion might be that SDN will likely increase effi­cien­cies. You’ll be able to do more with less, but you’ll fill the gap so quickly that any cost sav­ings you think you’ll get will get eaten before one bud­get cycle is up. Likely you’ll have a large CapEx spend to do a fork-lift upgrade, and that will take 3 years to bal­ance out and come off the books. In the mean time, you’re going to increase OpEx because of train­ing, ini­tial devel­op­ment, net­work redesign, etc. By the time your feet are firmly planted, you’re com­fort­able with the new look of things, and you’re ready to start count­ing the pen­nies “sprawl” of a new type (devel­op­ment costs most likely) will eat any sav­ings. That’s a 3 to 5-year cycle just there.

SDN mit­i­gates change man­age­ment risk - This one is only par­tially a myth. For the bulk of change man­age­ment, I’d say that this is quite likely com­pletely true. Day-to-day port changes, rout­ing changes, and pro­vi­sion­ing (to name a few) are eas­ily screwed up by the less expe­ri­enced folks likely mak­ing those changes today. Hav­ing a sys­tem that can make the changes with less man­ual input is going to prob­a­bly save a lot of the lit­tle ticky-tack prob­lems that crop up from some­one fat-fingering a con­fig­u­ra­tion command.

Larger changes to a net­work are likely going to fall out­side of the scope of what SDN brings to the table, espe­cially in multi-tenant or highly com­plex envi­ron­ments. These are the types of changes you still are going to need a highly skilled team to imple­ment, and I don’t see a point com­ing soon where I’d really feel com­fort­able trust­ing large-scale changes to an automag­i­cal, largely self-driven sys­tem. Even today, how many of us trust the soft­ware “wiz­ards” built into any com­mer­cially avail­able prod­uct? How many of us make whole­sale, system-wide net­work changes using a wiz­ard? Sim­ply chang­ing the name to SDN doesn’t change anything.

SDN is dis­rup­tive tech­nol­ogyIT is, almost by def­i­n­i­tion, filled with peo­ple who take a “down in the weeds” view of every­thing. It has to be. But some­times this leads to a kind of unique myopia in view­ing changes in tech­nol­ogy. When Multi-protocol Label Switch­ing (MPLS) was intro­duced, it was as dis­rup­tive to the sta­tus quo as any­thing, but it was adopted slowly, peo­ple adapted, nobody lost their jobs and whole indus­tries weren’t erad­i­cated. Why? Because from the busi­ness point of view it was just a more effi­cient way of solv­ing the same old prob­lems. It was bet­ter than what it replaced, but it was incre­men­tally bet­ter. In other words, it wasn’t the tele­phone to West­ern Union’s telegraph.

SDN in all its myr­iad visions, and as evan­ge­lized by all of its newly chris­tened cham­pi­ons, is fas­ci­nat­ing, emi­nently use­ful on some lev­els, and mad­den­ingly silly in oth­ers. At the end of the day, how­ever, it’s crit­i­cal that we don’t get so involved in the excite­ment, promise, and reli­gious fer­vor of new tech­nol­ogy that we lose sight of what is real, what is use­ful, and what is “mar­ke­tec­ture”. Magic beans may have worked for Jack, but I’m not buy­ing any for my net­work. Yet.