• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Standard Disclaimers
  • Resume/Curriculum Vitae
  • Why Blog?
  • About
  • (Somewhat Recent) Publication List

packetqueue.net

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

Cloud

March 8, 2017 Cloud

Uila: Visions of the Future

Read­ing Time: 5 min­utes

If it’s true that a pic­ture is worth a thou­sand words, then nascent soft­ware com­pa­ny Uila has writ­ten a nov­el with their break­out soft­ware prod­uct for mon­i­tor­ing, and per­form­ing root cause analy­sis on, vir­tu­al­ized and phys­i­cal net­work infra­struc­ture, bridg­ing the gap between both. Rarely does a break­through prod­uct come out of a start­up on first try—usually there is much refining—but Uila may have done just that. The visu­al­iza­tions are noth­ing short of stun­ning, and the back­ing data is attained fast, and is high­ly accu­rate. Add cloud man­age­ment and you real­ly do have the mak­ings of a great prod­uct.

Before we get to the prod­uct, how­ev­er, in this case it is worth talk­ing for a moment about the founders of Uila. Chia-Chee Kuan, Dean Au, and Miles Wu have, col­lec­tive­ly, some 76 years of expe­ri­ence between them in the indus­try they’re try­ing to change; expe­ri­ence that comes in the form of patents, in the found­ing of com­pa­nies like Air­Mag­net and Cin­co Net­works, and in the many years of R&D at com­pa­nies from Cis­co to Fluke. Oh, and let’s not over­look their cre­den­tials in the form of com­put­er sci­ence degrees and master’s degrees from some of the best engi­neer­ing schools across the world. Back­ground and expe­ri­ence do not equal suc­cess, but cer­tain­ly the weight of expe­ri­ence here lends itself to a high lev­el of cred­i­bil­i­ty right out of the gate, and begs at least a sec­ond glance.

What’s the Prob­lem?

As data cen­ters and infra­struc­ture in gen­er­al have become increas­ing­ly com­pli­cat­ed, the risk of one thing break­ing and caus­ing the whole ball of yarn to come undone has increased expo­nen­tial­ly, while the tools to ana­lyze such prob­lems with an eye towards root cause analy­sis and res­o­lu­tion have not matured. Ven­dors are still sell­ing, and users are still using, point prod­ucts designed to trou­bleshoot one par­tic­u­lar aspect of a fail­ure. What we should be doing is not iso­lat­ing fail­ure domains from a trou­ble-tick­et point of view, but rather start­ing with a larg­er domain and shrink­ing from there. It’s a dif­fer­ent method­ol­o­gy, but in today’s data cen­ters it can be chal­leng­ing to go with the tra­di­tion­al bot­tom up tech­niques we’ve all learned to love.

Don’t take that to mean that we should­n’t use good, sol­id meth­ods for iso­la­tion of fail­ures, just that we should be doing so on sub­sets of the larg­er whole, with that larg­er whole firm­ly vis­i­ble and watched as we work. Too often we toss flam­ing bags of shit over the wall to the <insert team here> and hope that they fig­ure out the prob­lem (val­i­dat­ing that the prob­lem was theirs to fix) before toss­ing it back. In this way, each team in suc­ces­sion, goes through the insu­lar trou­bleshoot­ing steps rel­e­vant to only their domain, with no inter­est in, or view of, the big­ger whole. This is inef­fi­cient and slow, and a ter­ri­ble way to solve any prob­lem.

How Does Uila’s Prod­uct Work?

Uila’s prod­uct aims to bridge those inher­ent divides in trou­bleshoot­ing and appli­ca­tion vis­i­bil­i­ty spheres by uti­liz­ing vir­tu­al smart taps (vST) in con­cert with more tra­di­tion­al (SNMP, SMI, SSH) means. Vir­tu­al taps get their infor­ma­tion straight from the dis­trib­uted vir­tu­al switch (DVS) in a vir­tu­al­ized envi­ron­ment, and uti­lize agents to grab the phys­i­cal device data. All of this gets rolled up to the Uila Man­age­ment & Ana­lyt­ic Sys­tem, which is a cloud-based ser­vice han­dling the intel­li­gence and analy­sis behind and of the data–think: Mer­a­ki for appli­ca­tion vis­i­bil­i­ty.

Uila’s prod­uct can per­form deep pack­et inspec­tion (DPI), auto-dis­cov­er over 4000 appli­ca­tions, track appli­ca­tion trans­ac­tions and depen­den­cies, and track net­work and TCP per­for­mance all while remain­ing dis­trib­uted and agent-less. For a lot of sys­tems and net­work oper­a­tors the lat­ter point is a big one. Hav­ing to install agents on a mul­ti­tude of devices, many of which can’t actu­al­ly host agents, can become unwieldy. An agent-less prod­uct like Uila’s allows for a quick­er roll­out over­all, mak­ing for a quick­er time to val­ue for the busi­ness. And because of the var­i­ous inflec­tion points for data into the appli­ca­tion, full stack vis­i­bil­i­ty is more than just lip-ser­vice.

What Else Can It Do? 

One of the chal­lenges of mod­ern soft­ware-defined net­work­ing, sys­tems, cloud, etc., is appli­ca­tion dis­cov­ery map­ping. Assum­ing that one of the pri­ma­ry rea­sons for mov­ing to a new modal­i­ty in net­work fab­rics and automa­tion is agili­ty, under­stand­ing what the hell your appli­ca­tions are doing is of para­mount impor­tance. Under­stand­ing which ports are used by which process­es, which back­end data­bas­es talk to which front-end or mid­dle-ware soft­ware ser­vices, and how all of this can be orches­trat­ed and auto­mat­ed is not as easy as it might appear at first glance. Find­ing this infor­ma­tion can be frus­trat­ing and error-prone, and very often depen­den­cies get missed, lead­ing to down­time, roll-backs, or missed mile­stones.

Uila’s soft­ware, due to it’s full-stack vis­i­bil­i­ty, is actu­al­ly a very good tool for ana­lyz­ing a soft­ware stack, for per­form­ing appli­ca­tion depen­den­cy map­ping at a fast clip and with high accu­ra­cy and con­fi­dence. Hav­ing used a vari­ety of tools to per­form this analy­sis in the recent past, I can say that this tool is one of the best on the mar­ket. The visu­al­iza­tions are a nice touch, as dur­ing these exer­cis­es I have found that many appli­ca­tion teams are sur­prised to learn the com­plete scope of what their stack is doing, rein­forc­ing the fact that a tool like this is key to grab­bing all per­ti­nent infor­ma­tion pos­si­ble.

Con­clu­sions, More Infor­ma­tion, and Next Steps

In watch­ing the pre­sen­ta­tion that led to this arti­cle, research­ing the prod­uct online, using the prod­uct myself, and talk­ing with the founders in per­son, one thing has become abun­dant­ly clear to me: this appli­ca­tion has a lot more capa­bil­i­ties and fea­tures than I can prop­er­ly cap­ture in a sin­gle sit­ting. Stor­age ana­lyt­ics, vir­tu­al machine (VM) cross-talk, laten­cy and jit­ter, and myr­i­ad more options for trou­bleshoot­ing are all cov­ered through this tool, and the uses are lim­it­ed only by the time you have to delve in and push but­tons. I haven’t even brought up the auto­mat­ed root cause analy­sis capa­bil­i­ties, which in and of them­selves war­rant at least an arti­cle, if not a whitepa­per.

 

If you have any inter­est in the prod­uct, I would sug­gest you take a look at Uila’s web­site (http://www.uila.com) and poke around a bit. They have an impres­sive list of cus­tomers already, as well as some whitepa­pers and oth­er infor­ma­tion avail­able. They have a gen­er­ous 30-day free tri­al which is ful­ly fea­tured and includes sup­port and train­ing, which goes a long way to get­ting peo­ple in and using the prod­uct in enough time to actu­al­ly use the demo—something some more estab­lished indus­try play­ers might want to take note of. You can also see some videos of Uila pre­sent­ing their solu­tions to an audi­ence of indus­try folks of vary­ing back­grounds, by going to the Tech Field Day site at: http://techfieldday.com/companies/uila/.

At the end of the day, Uila may have writ­ten a nov­el, but the mar­ket will deter­mine if it’s worth read­ing.

Share

January 3, 2016 Cloud

ZeroStack — Simplified and Automated OpenStack

Read­ing Time: 5 min­utes

“Clut­ter and con­fu­sion are fail­ures of design, not attrib­ut­es of infor­ma­tion.” ~ Edward Tuft

In the ever-so-neat­ly pack­aged and mar­ket­ed buzz­word bin­go world that we know as “cloud,” there are two gen­er­al­ly accept­ed fla­vors: on-premise, or pri­vate, cloud, and pub­lic cloud. Pub­lic clouds of the most well-known vari­ety are Ama­zon Web Ser­vices (AWS,) and Microsoft Azure. On the pri­vate side you have VMware, if you buy a few-bajil­lion dif­fer­ent soft­ware pack­ages, or Open­Stack, itself a fair­ly unwieldy beast of an ecosys­tem. All achieve rough­ly the same goals and end-state, name­ly allow­ing fast and easy cre­ation and con­sump­tion of large­ly tran­sient, vir­tu­al­ized work­loads. The ben­e­fits and draw­backs of each, how­ev­er, exist in dif­fer­ent spheres.

The pub­lic cloud providers offer very easy to con­sume ser­vices, already built in their envi­ron­ments and on their hard­ware, as secure as we can call any­thing these days, all for an osten­si­bly nom­i­nal fee. Your data lives out­side your data cen­ter, how­ev­er, and can suf­fer from what’s known in the indus­try as “noisy neigh­bor” syn­drome, where­by oth­er users’ appli­ca­tions host­ed on the same hard­ware as yours, can con­sume enough resources to starve your appli­ca­tions. Addi­tion­al­ly, as they say in the val­ley, AWS is very cheap if you fail, it’s very expen­sive if you suc­ceed, mean­ing that the cost of pub­lic cloud looks great at first glance, but once you start con­sum­ing a lot of resources, your costs can quick­ly bal­loon to eye-water­ing lev­els.

The pri­vate cloud ecosys­tems aren’t with­out their own blem­ish­es, though, and while offer­ing a much low­er oper­a­tional cost on paper as you don’t have ongo­ing fees to a provider, and you ulti­mate­ly have more secu­ri­ty and con­trol since your data lives in your own data cen­ters, they tend to be very chal­leng­ing to stand up, and even more com­plex to main­tain. Many com­pa­nies have to increase hir­ing of spe­cial­ized staff just to mon­i­tor and main­tain the sys­tem, and often have to pay con­sul­tants to get the envi­ron­ment built and tuned in the first place.

A visu­al exam­ple from a deck they pre­sent­ed on dur­ing a recent Tech Field Day event shows a tra­di­tion­al mod­el of cloud, and the dif­fer­ences at a high lev­el between pub­lic and pri­vate imple­men­ta­tions of the same:

Cloud Before ZeroStack

Cloud Before ZeroStack

From what I can tell, ZeroStack seems to have been found­ed on the premise that OpenStack—one of the most talked about pri­vate cloud sys­tems out there, and by far the one with the most buzz—is an incred­i­ble prod­uct, but need­less­ly com­pli­cat­ed for all but a few folks. Their core mis­sion to sim­pli­fy and reduce Open­Stack to an easy to use plat­form, deploy­able in min­utes rather than weeks, is one that will undoubt­ed­ly res­onate with a sig­nif­i­cant seg­ment of the IT pop­u­la­tion. In doing so, how­ev­er, they run the risk of col­lid­ing head on with some of the big boys of indus­try.

What ZeroStack does is com­modi­tize Open­Stack into a hard­ware and soft­ware plat­form which can be deployed in under 15 min­utes, a claim which I can ver­i­fy first hand. They ship a box—based on mer­chant hardware—to your loca­tion, you plug it in, answer a few ques­tions, it phones home, and with­in min­utes you have a ful­ly func­tion­ing Open­Stack envi­ron­ment. As any­one who has deployed Open­Stack, even in a basic devel­op­ment envi­ron­ment, can attest, it is very time-con­sum­ing and not entire­ly triv­ial to stand up in any kind of func­tion­ing manner—presumably the end goal.

ZeroStack’s hard­ware is cus­tom built from off-the-shelf com­po­nents, and comes in four dif­fer­ent fla­vors depend­ing on your needs. The servers can “stack” in a scale-out mod­el, and use a dis­trib­uted stor­age fab­ric, dis­trib­uted man­age­ment, and dis­trib­uted SDN fab­ric, across all servers. This allows for large build outs, but per­haps more impor­tant­ly, it allows for seam­less host fail­ure recov­ery through a leader elec­tion mech­a­nism. The more inter­est­ing bit is how they han­dle man­age­ment, and is where we begin to see where we can draw a Mer­a­ki com­par­i­son.

What ZeroStack has done that is the most evolutionary—I won’t say rev­o­lu­tion­ary since this is being done already, more on that in a minute—is moved the man­age­ment com­po­nents of Open­Stack into a cloud (how many abstrac­tions of cloud can we han­dle before the whole thing blows up in a cloud of vague­ly con­sul­tant-smelling mar­ke­tec­ture?) They host this on their own plat­form in their own data cen­ter. This allows you to man­age the sys­tem from any­where, much like what Mer­a­ki did for wire­less net­works.

This can be illus­trat­ed again with a slide from the same pre­sen­ta­tion ref­er­enced above:

Cloud After ZeroStack

Cloud After ZeroStack

By sep­a­rat­ing what we could loose­ly call the con­trol plane from the data plane, to bor­row from the net­work­ing world , the entire­ty of the Open­Stack sys­tem and deploy­ment mod­el is made man­i­fest­ly eas­i­er for the aver­age enti­ty to deploy and con­sume. You rack and stack the hard­ware, point it at the ZeroStack cloud man­age­ment por­tal, and it does the rest. You get a cup of cof­fee and when you’re done you have an on-premise cloud. There are obvi­ous­ly some sub­tleties to the deploy­ment, and extra knobs you can tweak if you choose, but this is far quick­er than a tra­di­tion­al deploy­ment, and should appeal to many peo­ple.

The main risk I see from a long term via­bil­i­ty per­spec­tive is that this mod­el of Open­Stack deploy­ment puts ZeroStack square­ly in the path of at least Cis­co and HP Enter­prise, with their Meta­Pod and Helion CloudSys­tem Enter­prise prod­ucts, respec­tive­ly, which per­form almost entire­ly the same func­tion at a high­er cost point. Cisco’s solu­tion, in par­tic­u­lar, can be more accu­rate­ly com­pared to a VCE vBlock than to the ZeroStack plat­form, the for­mer com­ing pre-racked and plug-in-to-pow­er ready with full-blown UCS com­pute, Nexus 9K switch­ing, and ASR rout­ing. Cisco’s solu­tion has the fur­ther ben­e­fit of being ful­ly deployed and man­aged by Cis­co, and so is quite lit­er­al­ly a plug-and-play solu­tion. HP Enterprise’s Hel­lion CloudSys­tem uti­lizes VMware for the cloud plat­form, but func­tion­al­ly accom­plish­es the same goal of dis­till­ing what can be a com­plex deploy­ment down to a sin­gle pur­chase propo­si­tion.

I think where ZeroStack has an advan­tage, and pos­si­bly an unchal­lenged mar­ket space niche, is in the low­er to mid-tier price points. Many (many, many) com­pa­nies who wish to deploy Open­Stack sim­ply won’t be able to afford the Cis­co or HPE solu­tions, but still have a desire and a need for a sim­pli­fied deploy­ment mod­el. If ZeroStack’s prod­ucts can run in a sta­ble man­ner as well as they can deploy, I think they have a fight­ing chance of remain­ing viable for some time to come. Either that or they’ll estab­lish enough of a mar­ket foot­print, and become enough of a chal­lenge the the big-boys inevitable desire to sell down-stream in a like­ly scaled down prod­uct and price point, that they’ll be acquired for a sur­pris­ing­ly large amount of coinage—not at all out of place for the val­ley.

Share

Copyright© 2023 · by Shay Bocks