packetqueue.net

Musings on computer stuff, and things... and other stuff.

SDN

Cisco

Software Defined, Cisco, and DevNet

It has been said that soft­ware is eat­ing the world. In the world of net­work­ing, how­ev­er, the food has been slow to digest. Net­work engi­neers can be a stodgy bunch, and change is not only slow to come but fast to be blud­geoned angri­ly. If this year’s Cis­co Live con­fer­ence is any indi­ca­tion, how­ev­er, soft­ware, it seems, has start­ed blud­geon­ing back.

Hard­ware has remained king for decades, with the soft­ware oper­at­ing sys­tems tak­ing sec­ond posi­tion in the dance of fea­tures and func­tion­al­i­ty. Pur­chasers of net­work gear would base their deci­sions almost exclu­sive­ly on hard­ware capa­bil­i­ties while accept­ing what­ev­er soft­ware came on the box as just the way things were. Buy speeds and feeds, and you hoped that the soft­ware was up to snuff.

Net­work engi­neers considered–many still consider–that the soft­ware was dif­fi­cult to mas­ter as a badge of hon­or; if you want­ed to call your­self a net­work engi­neer it was not enough to under­stand pro­to­cols and archi­tec­tures, you had to mas­ter painful oper­at­ing sys­tems, arcane syn­tax, and often con­tra­dic­to­ry con­fig­u­ra­tions as well. Indus­tries were born to train and cer­ti­fy engi­neers on net­work oper­at­ing sys­tems, and those engi­neers would then go on with bias­es toward the gear with which they had famil­iar­i­ty. And the cycle of life rolled onward.

With the advent of the hack­neyed soft­ware defined move­ment a few years ago, this all began to slow­ly change. The focus start­ed shift­ing towards the soft­ware as the dri­ver of fea­tures and func­tion­al­i­ty, with the hard­ware increas­ing­ly seen as ful­fill­ing a sup­port­ing role in push­ing data around our insu­lar con­nect­ed worlds. The hard­ware was begin­ning to be seen as good enough so as to not require a par­tic­u­lar badge or pedi­gree. The pur­vey­ors of pedi­greed hard­ware were look­ing at an uncer­tain future.

The soft­ware defined move­ment came from a place of opti­mism, of a legit­i­mate desire to make things bet­ter and to put the world of net­work­ing back on the right tracks that were seen as long ago aban­doned. The way had been lost, and soft­ware defined was going to lead the indus­try out of the dark. Large and estab­lished com­pa­nies, how­ev­er, did not get that way by acci­dent and, though ini­tial­ly slow to react, piv­ot­ed and began to embrace and extend, some would say co-opt, the fledg­ling move­ment. Soon, every­one was lead­ing with soft­ware.

Nowhere was this piv­ot so jar­ring as with Cis­co, a stal­wart, dom­i­nant, mar­ket-lead­ing behe­moth of the net­work­ing equip­ment world. And as with oth­er indus­try shifts before (VoIP, com­put­ing hard­ware), Cis­co quick­ly (or, as quick­ly as they could giv­en their size) adapt­ed them­selves to the new world order. They began rolling out appli­ca­tion pro­gram­ming inter­faces, a kind of inside-base­ball way of mak­ing hard­ware do what you want while bypass­ing the tra­di­tion­al, com­pa­ny-writ­ten, soft­ware oper­at­ing sys­tem. They start­ed open­ing up more and more of their hard­ware, and they began con­tribut­ing to var­i­ous open-source soft­ware projects osten­si­bly designed to mar­gin­al­ize their very same hard­ware.

It is in this cli­mate that Cis­co estab­lished their devel­op­er net­work, DevNet, as a place for code-exchange among soft­ware devel­op­ers. They pub­lished more and more APIs, more doc­u­men­ta­tion, and began to dip a prover­bial toe in the waters of more for­mal­ized train­ing, incul­cat­ing engi­neers into the soft­ware defined men­tal­i­ty as seen through Cisco’s eyes. They start­ed a spe­cial­ized DevNet con­fer­ence called DevNet Cre­ate, and they began bring­ing DevNet wher­ev­er they went. And it grew, and it grew, and it kept grow­ing.

Accord­ing to Cis­co DevNet now has over 500,000 reg­is­tered devel­op­ers, over 38,000 con­tribut­ing com­pa­nies, 72,500 learn­ing labs, and over 60,000 reg­u­lar active users. There are reserv­able sand­box­es for test­ing and devel­op­ment, almost all Cis­co hard­ware as well as Kuber­netes clus­ters, and mul­ti­ple code repos­i­to­ries with code curat­ed exchanges open to any devel­op­ers to use. This entire ecosys­tem is sep­a­rate from Cisco’s exist­ing D-Cloud demo envi­ron­ment, and doesn’t depend on any par­tic­u­lar rela­tion­ship with Cis­co or third-par­ty resellers. Those num­bers are impres­sive by anyone’s stan­dards, espe­cial­ly for some­thing which has only exist­ed for a few short years. It tru­ly is an exam­ple of build it and they will come.

This year at the annu­al Cis­co Live con­fer­ence, held in love­ly sum­mer­time Orlan­do, the DevNet por­tion of the show was the most impres­sive piece of the con­fer­ence. And not just the raw num­bers, which were impres­sive on their own, but in the acreage the DevNet zone con­sumed on the World of Solu­tions show floor as well as the excite­ment and buzz sur­round­ing the thing. The most dif­fi­cult class­es and ses­sions to get into were all with­in the DevNet sphere, and it wouldn’t sur­prise me if next year’s con­fer­ence saw the DevNet ecosys­tem called out with a sep­a­rate fee struc­ture from the rest of the con­fer­ence.

Cisco’s evo­lu­tion is just one example–perhaps the biggest–of the changes occur­ring in the net­work­ing indus­try. New busi­ness­es com­ing out of the Val­ley and oth­er places with new notions of what net­work­ing can and should be is one thing, watch­ing the indus­try giants piv­ot in that same direc­tion brings a lev­el of val­i­da­tion that we would be remiss to over­look or dis­count. Change is not just com­ing, it’s already here, and if you’re look­ing at your career think­ing it’s only a fad, you are run­ning out of time to stay ahead of, or even keep up with, the mon­u­men­tal changes still to come.

Share

SDN

SDN Myths

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 everyone’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 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 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 doesn’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 wasn’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.

Share