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

Uncategorized

Glue Networks Changes the Automation Game

“Sim­plic­i­ty is the ulti­mate sophis­ti­ca­tion.”

Clare Boothe Luce

Accord­ing to a recent­ly pub­lished sur­vey by Cis­co Sys­tems, Inc., IT orga­ni­za­tions spend 67% of their bud­gets on oper­a­tional expense, and con­sume 80% of their time in the process. That is a stag­ger­ing amount of time and mon­ey spent on sim­ply man­ag­ing the tech­nol­o­gy infra­struc­ture of an enter­prise. It comes as no sur­prise, then, that so many peo­ple are focused on reduc­ing those num­bers, and on increas­ing time-to val­ue of new tech­nol­o­gy in the process.

Glue Net­works is one of the com­pa­nies try­ing to solve this prob­lem by bring­ing automa­tion to the net­work. Jeff Gray, CEO of Glue Net­works, claims that they have built the “first mod­el dri­ven, mul­ti-ven­dor, soft­ware defined net­work, orches­tra­tion plat­form that allows orga­ni­za­tions to con­trol their net­works in a new way.” That’s a lot of words, and a bold claim, to be cer­tain, but there’s many a slip twixt the cup and the lip, and claims are easy to make. Prov­ing them out is more dif­fi­cult.

One of the chal­lenges in today’s net­works, par­tic­u­lar­ly when speak­ing about automa­tion, is the wide vari­ety of prod­ucts, plat­forms, hard­ware, cir­cuits, etc., that exist and need to be con­trolled. If I want to make a change in my QoS pol­i­cy across a spe­cif­ic path in my net­work, for instance, I may have to touch sev­er­al brands of gear, as well as sev­er­al dif­fer­ent mod­els with­in one vendor’s prod­uct line. Automat­ing any kind of task, let alone a com­plex change, has his­tor­i­cal­ly been extreme­ly dif­fi­cult. Even with great script­ing, it’s dif­fi­cult to make changes every­where at once.

Glue has tak­en a unique approach to this prob­lem by cre­at­ing data-dri­ven mod­els based on intent. In oth­er words, their Glue­ware Con­trol plat­form looks at what the intent of the oper­a­tor is in request­ing a change. You’re oper­at­ing at a high­er lev­el of abstrac­tion from the raw gear to be changed, and let­ting the con­trol plat­form fig­ure out how to exe­cute the changes need­ed in order to ful­fil your intent. You tell the sys­tem what hard­ware you have, and it uses its knowl­edge of that hard­ware to exe­cute changes.

When­ev­er you abstract anoth­er lay­er above a hard­ware change, you rely more and more on the accu­ra­cy of your mod­els and for­mu­las to tell the hard­ware what needs to hap­pen. If your automa­tion engine can only talk to three mod­els of switch­es, it is not going to be spec­tac­u­lar­ly use­ful. Cur­rent­ly the Glue­ware Con­trol plat­form comes with mod­els for 13 dif­fer­ent mul­ti-ven­dor pack­ages and oper­at­ing sys­tems, with many more on the way. These are the recipes for how the sys­tem talks to your gear, so more is always bet­ter. The cur­rent goal, accord­ing to Gray, is to release a new ven­dor pack­age every three weeks.

Glue also announced the release of the Glue­ware Com­mu­ni­ty, which is what they’re call­ing their user-dri­ven, online, ecosys­tem for col­lab­o­rat­ing with fel­low users. Here is where a robust com­mu­ni­ty of users exchanges recipes and for­mu­las that they have writ­ten, which may not be some­thing that Glue has released them­selves. In oth­er words, maybe you have a some­what rare device that few peo­ple have, and no one has writ­ten a mod­el for it yet. You wrote a mod­el (there are plen­ty of exam­ples and instruc­tions on the com­mu­ni­ty site) to sup­port your unique device, put it into the com­mu­ni­ty repos­i­to­ry, and now oth­er users can ben­e­fit from your solu­tion. This is quite a good way to both encour­age com­mu­ni­ty par­tic­i­pa­tion, and to rapid­ly increase adop­tion by grow­ing the mod­els and for­mu­las repos­i­to­ry in leaps and bounds.

Respond­ing to cus­tomers, Glue has also tak­en their tra­di­tion­al­ly cloud-based plat­form and extend­ed it into an on-premis­es solu­tion, say­ing that many cus­tomers need­ed a “behind the fire­wall” solu­tion. They have also expand­ed from a pure­ly WAN-based solu­tion, into both LAN and dat­a­cen­ter envi­ron­ments, extend­ing their use­ful­ness across the whole of the enter­prise, rather than sim­ply run­ning as a point solu­tion.

Anoth­er fea­ture that is extreme­ly promis­ing is the abil­i­ty for the plat­form to dynam­i­cal­ly cre­ate mod­els, based on your gear, in a brown­field envi­ron­ment. You can install this prod­uct, and based on what it knows, it will mod­el your net­work devices and pull them into the sys­tem. This short­ens the time to val­ue equa­tion by allow­ing users to imme­di­ate­ly derive val­ue from the prod­uct, some­thing which helps to pre­vent an expen­sive pur­chase from becom­ing shelf-ware.

All in all, I’d say that Glue has made great strides in this release, and def­i­nite­ly is at the fore­front of ven­dors pro­vid­ing solu­tions to one of the most press­ing issues of the day. While many oth­er prod­ucts and solu­tions pur­port to solve the automa­tion prob­lem, reduc­ing oper­a­tional expens­es and staff uti­liza­tion, far too many require large invest­ments in what are ulti­mate­ly non-ven­dor agnos­tic ecosys­tems. These lat­ter sys­tems tend to move the prob­lem from OPEX to CAPEX, while intro­duc­ing tremen­dous amounts of com­plex­i­ty. Glue offers a solu­tion that is both sim­ple and pow­er­ful, and should def­i­nite­ly be some­thing you take a look at imple­ment­ing.

For more infor­ma­tion on the plat­form, how it works, and what prob­lems it solves, take a look at this pre­sen­ta­tion by Olivi­er Huynh Van, CTO and Co-founder of Glue Net­works:

 

 

Share

Network

Ruminations on Software Programming

Soft­ware pro­gram­ming is a chal­leng­ing endeav­or.  I know, because it’s how I start­ed my career, and it’s still some­thing I do for fun and to keep my net­work engi­neer­ing skills sharp.  Writ­ing soft­ware is also very tedious, which is why I quick­ly moved on to oth­er things and now haven’t writ­ten code pro­fes­sion­al­ly for over 18 years or so.  It takes a par­tic­u­lar kind of per­son who wants to real­ly learn the syn­tax and thought process need­ed to be tru­ly skilled at cod­ing.

It is also a par­tic­u­lar type of per­son who wants to know the lev­el of detail in how a large-scale net­work oper­ates.  Most IT pro­fes­sion­als are con­tent to know the basics of networking—enough to do their day jobs—and leave the hard-core net­work knowl­edge to that spe­cial sort of masochist breed known as net­work engi­neers.  The hard­core net­work folks who are obsessed with per­for­mance tun­ing even the small­est details of how pack­ets move around and between dat­a­cen­ters, the intri­cate dif­fer­ences between rout­ing pro­to­cols, tun­nels, under­lays and over­lays, and bit-twid­dling for fun and prof­it.

In the past, those two sides of what I’ll loose­ly call the IT world have typ­i­cal­ly been dif­fer­ent func­tions.  The soft­ware types write the code for the sys­tems, the sys­tems peo­ple deliv­er the ser­vices, and the net­work folks tie it all togeth­er.  From the out­siders’ point of view look­ing in, we’re all “com­put­er nerds” and any dif­fer­ences between us are large­ly seman­tic at best.  But peel back the vale and you’ll see that we’ve all decamped to our respec­tive cor­ners of the play­room and start­ed our own lit­tle fief­doms.

To hear some tell the tale the loose alliances and unsteady truces that have kept us func­tion­ing for so long are about to col­lapse under the weight of a new tech­nol­o­gy par­a­digm: Soft­ware Defined Net­work­ing.  While I hope the cur­rent crop of shrill screeds about net­work engi­neers dying off if they don’t learn to pro­gram will slow­ly start to fade away as the real­i­ty of things sets in, I’m not hold­ing my breath.  SDN brings changes to the play­room of IT, for sure, but as I’ve writ­ten many times before, it is incre­men­tal, not whol­ly dis­rup­tive, change that’s com­ing on the back of SDN.

We only have to look to the changes that have hap­pened in the sys­tems space over the last 8–10 years or so to see what the future looks like.  When the first wave of sys­tem vir­tu­al­iza­tion start­ed to make inroads, there was a tremen­dous amount of push­back from all cor­ners of the IT estab­lish­ment.  Ven­dors refus­ing to sup­port any­thing installed on a vir­tu­al­ized OS was the norm, and there were all sorts of opined pieces float­ing around the trade mag­a­zine cir­cuit, bemoan­ing the death of the sys­tems and appli­ca­tions folks.

In this brave new vir­tu­al­ized world, so went the rea­son­ing, there would be no need for sys­tems admin­is­tra­tors.  They would all go away in favor of this new spe­cial­ty.  In real­i­ty what hap­pened was that the sys­tems peo­ple kept right on doing what they’d always done, which was to learn the new tech­nol­o­gy… incre­men­tal change pre­vailed.  Now any self-respect­ing sys­tems admin knows and under­stands at least one hyper­vi­sor sys­tem at a pret­ty sol­id lev­el.   The tools changed, the par­a­digm shift­ed, and the sys­tems admin­is­tra­tors changed in par­al­lel.

Did every­one sud­den­ly become soft­ware pro­gram­mers?  Nope.  They just kept on adapt­ing with the times and instead of using the tools they had been using, or per­haps in addi­tion to those tools, they start­ed using new tools like Microsoft’s Pow­er­Shell.  Now most big appli­ances in the sys­tems world are acces­si­ble via Pow­er­Shell com­mands and the sys­tems peo­ple can do more than ever.  In fact, they can do it more quick­ly and accu­rate­ly than in years past.

The same thing is going to hap­pen on the net­work side.  Instead of being con­fined to a pre-built OS, pur­pose built for one device, we’ll be able to access all of our devices using var­i­ous new meth­ods.  Some of us will use off-the shelf solu­tions wrapped up as man­age­ment packages—does any­one doubt that the big-boys of the net­work world will come out with soft­ware for SDN con­trollers that is pre-built, pre-pack­aged, and ready to use with no pro­gram­ming knowl­edge required?  Oth­ers will use more advanced tech­niques and script our own tools to do spe­cial­ized tasks as we need.

Giv­en the changes com­ing in the next few years, I will say that any net­work engi­neers out there who haven’t been exposed to basic pro­gram­ming pre­cepts; things like loops and basic log­ic flow, algo­rithms, and gen­er­al­ized prob­lem solv­ing using a pro­gram­ming-like syn­tax, should prob­a­bly pick up a book and start play­ing around a lit­tle.  Pow­er­Shell is a good place to start, as would Unix shell script­ing (start with bash), but if you real­ly want to learn a pro­gram­ming lan­guage, and you want some­thing that will be use­ful in the net­work­ing world over the next few years, I’d high­ly rec­om­mend start­ing with Python.  It’s easy to learn, easy to use, easy to get things done, and you get some imme­di­ate grat­i­fi­ca­tion.  Also, out­side of pure script­ing lan­guages, Python real­ly seems to be where every­one seems to be coa­lesc­ing when it comes to SDN con­trollers and APIs for net­work pro­gram­ming.  Jen­nifer Rex­ford writes about the Fre­net­ic Project and Pyret­ic in this arti­cle at Tech Tar­get and it is well worth a read.

At the end of the day, the IT game is one where the rules are always chang­ing, the skillsets always evolv­ing, and quite hon­est­ly if you’re still doing the same thing you learned 5 years ago you’re already behind the curve.  SDN may shake up the world of net­work engi­neer­ing in a way we haven’t seen in a while, but it is noth­ing more than the con­tin­ued march of progress.  If you’re not read­ing at least one whitepa­per or book on a new tech­nol­o­gy at all times, I per­son­al­ly don’t see how you’ve stayed in the game this long.  SDN is just more of the same.  Adapt or quit now.

Soft­ware pro­gram­ming is always going to be a spe­cial­ized skillset, as is net­work engineering—at least at the high­est lev­els.  That doesn’t mean that you shouldn’t embrace the com­ing change and learn to play with the kids on the oth­er side of the play­room a bit, though.  If you ven­ture over to the oth­er side, you might find that some of the toys they have are the miss­ing pieces from your play set, and that you have more in com­mon with one anoth­er than you orig­i­nal­ly thought.

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

Uncategorized

SDN in the Enterprise

I recent­ly wrote a mul­ti-part blog series for Cis­co and, as we know, while it may seem like the writ­ing is all of the work, get­ting the word out is at least as hard. So, for those of you who have already seen this, I apol­o­gize. For the rest of you, I have includ­ed a link below.

This first part large­ly sets the stage, while the sec­ond part (com­ing on August 14t) will draw more con­clu­sions. Com­ments are wel­come, as is word-of-mouth adver­tis­ing. 🙂

Thanks, every­one!

SDN in the Enter­prise

Share