packetqueue.net

In 1876, an inter­nal memo at West­ern Union is report­ed to have read: “This ‘tele­phone’ has too many short­com­ings to be seri­ous­ly con­sid­ered as a means of com­mu­ni­ca­tion. The device is inher­ent­ly of no val­ue to us.” At the time, West­ern Union was the Microsoft of its day–a behe­moth com­pa­ny that touched every­one’s lives. While the verac­i­ty 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 shift­ed its focus to mon­ey trans­fers. To put it anoth­er way, the entire busi­ness mod­el upon which West­ern Union was pred­i­cat­ed, col­lapsed to a new, dis­rup­tive tech­nol­o­gy 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 oth­er direc­tion. We get in such a both­er try­ing to divine the “next big thing” that we almost entire­ly fail to qual­i­fy the claims that are being made and end up bet­ting the bank on unproven or half-baked con­cepts.

I’m cer­tain­ly 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­al­ly believe that SDN–in at least some of its pur­port­ed definitions–will most def­i­nite­ly make it into the net­works of tomor­row, and fur­ther that sev­er­al things will change as a result. I don’t, how­ev­er, buy into a lot of the myths that seem to have devel­oped sud­den­ly, out of the ether, around the tech­nol­o­gy.

I should also point out that the myths below are some of the more com­mon ones I hear, but tak­en in total­i­ty don’t nec­es­sar­i­ly rep­re­sent any one com­pa­ny’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 cas­es, are com­plete­ly at odds with one anoth­er. Is SDN the abstrac­tion of the for­ward­ing plane from the con­trol plane? Is it pro­gram­mat­ic access to net­work devices? Is it automag­i­cal def­i­n­i­tion of pol­i­cy across abstract­ed for­ward­ing planes–boxes of dumb pipes manip­u­lat­ed 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 large­ly mean­ing­less beyond very high-lev­el 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 large­ly the catch-all term has lost its use­ful­ness for an engi­neer­ing-lev­el dis­cus­sion. Estab­lished com­pa­nies are com­pet­ing with start-ups, with one anoth­er, and in some cas­es inter­nal­ly to define what SDN is and what it is not. A lot of these ideas will end up in prod­ucts and tech­nol­o­gy that will even­tu­al­ly be for sale, while many will fade or become noth­ing more than slight busi­ness dif­fer­en­tia­tors in incre­men­tal­ly 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­pa­ny can’t wait to shoe-horn into every mar­ket­ing slide and prod­uct-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 extreme­ly useful–they are–but rather that the term is not use­ful.

SDN reduces com­plex­i­ty — For those preach­ing the “less com­plex­i­ty” vari­ant of SDN, I’d say that you need to look at his­to­ry. Did the advent of vir­tu­al­iza­tion increase or decrease over­all com­plex­i­ty in the com­pute space? It increased it, of course, by sev­er­al 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­i­ty, but we most assured­ly will not gain sim­plic­i­ty.

SDN elim­i­nates Net­work Engi­neers - This is patent­ly sil­ly on mul­ti­ple fronts, but let’s just go with the eas­i­ly picked and obvi­ous nit to begin with: SDN is pred­i­cat­ed on hav­ing a robust net­work archi­tec­ture under­pin­ning it. In oth­er words, you can’t have soft­ware-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, high­ly spe­cial­ized, and not at all sim­ple to design, build, or main­tain. Day-to-day change man­age­ment will like­ly 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 envi­ron­ments.

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 direct­ly 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 real­ly 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 prof­it, but with a large increase in effi­cien­cy. I’ll say that anoth­er way, you’re not low­er­ing your true IT costs over time… you’re increas­ing your effi­cien­cies.

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

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 serv­er, net­work, DBA, ERP, help-desk, etc. from before you vir­tu­al­ized.

There are a lot of ways to frame or quan­ti­fy the cost-sav­ings claims in SDN, but I think a bet­ter and more accu­rate descrip­tion might be that SDN will like­ly increase effi­cien­cies. You’ll be able to do more with less, but you’ll fill the gap so quick­ly that any cost sav­ings you think you’ll get will get eat­en before one bud­get cycle is up. Like­ly 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 firm­ly plant­ed, 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 like­ly) 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­tial­ly a myth. For the bulk of change man­age­ment, I’d say that this is quite like­ly com­plete­ly true. Day-to-day port changes, rout­ing changes, and pro­vi­sion­ing (to name a few) are eas­i­ly screwed up by the less expe­ri­enced folks like­ly mak­ing those changes today. Hav­ing a sys­tem that can make the changes with less man­u­al 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-fin­ger­ing a con­fig­u­ra­tion com­mand.

Larg­er changes to a net­work are like­ly going to fall out­side of the scope of what SDN brings to the table, espe­cial­ly in mul­ti-ten­ant or high­ly com­plex envi­ron­ments. These are the types of changes you still are going to need a high­ly skilled team to imple­ment, and I don’t see a point com­ing soon where I’d real­ly feel com­fort­able trust­ing large-scale changes to an automag­i­cal, large­ly self-dri­ven sys­tem. Even today, how many of us trust the soft­ware “wiz­ards” built into any com­mer­cial­ly avail­able prod­uct? How many of us make whole­sale, sys­tem-wide net­work changes using a wiz­ard? Sim­ply chang­ing the name to SDN does­n’t change any­thing.

SDN is dis­rup­tive tech­nol­o­gy — IT 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­o­gy. When Mul­ti-pro­to­col Label Switch­ing (MPLS) was intro­duced, it was as dis­rup­tive to the sta­tus quo as any­thing, but it was adopt­ed slow­ly, peo­ple adapt­ed, nobody lost their jobs and whole indus­tries weren’t erad­i­cat­ed. 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­tal­ly bet­ter. In oth­er words, it was­n’t the tele­phone to West­ern Union’s tele­graph.

SDN in all its myr­i­ad visions, and as evan­ge­lized by all of its new­ly chris­tened cham­pi­ons, is fas­ci­nat­ing, emi­nent­ly use­ful on some lev­els, and mad­den­ing­ly sil­ly in oth­ers. At the end of the day, how­ev­er, 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­o­gy that we lose sight of what is real, what is use­ful, and what is “mar­ke­tec­ture”. Mag­ic beans may have worked for Jack, but I’m not buy­ing any for my net­work. Yet.