Kion Mi Lernis ĉe CloudCamp

CloudCamp DaveKvankam malfrua (1 semajno) pro neĝo pasintsemajne, CloudCamp Indianapolis foriris senprobleme ĉi-vespere. Se vi estas ne de Indianapolis - vi devas daŭre legi. CloudCamp estas relative nova kaj okazas en ĉefaj urboj tra la tuta mondo. Danke al la faksperteco kaj industria gvidado de BlueLock, ni okazigis sukcesan eventon ĝuste ĉi tie en Indy.

Se vi scivolas kio estas Cloud Computing, Bluelock provizis iun diskuton pri difino de ĉi tiu sufiĉe nebula termino.

Nuba Komputado en Indianapolis?

Indianapolis atentas nacie kaj internacie pro la malaltaj stabilaj kostoj asociitaj kun potenco kaj nemoveblaĵoj - du grandegaj faktoroj por determini gastigajn kostojn. Aldone nia vetero estas solida kaj ni estas intersekciĝo inter ĉefaj spinoj de la interreto en Nordameriko. Se vi gastigas vian kandidatiĝon en Kalifornia datumstokejo nun - vi eble volas rigardi!

BlueLock estas Gvidanto Internacie en Nuba Komputado

Mi devas esti honesta, ju pli mi aŭdas Pat O'Day paroli, des pli timigita pri kiom multe tiu ulo scias pri nuba komputado, utila komputado, krada komputado, datuma magazeno-administrado, Virtualigo, VMWare ... vi nomas ĝin kaj tiu ulo scias ĝi. Li estas milda, kompleza, kaj havas la strangan kapablon paroli al ni homoj, kiuj ne estas spertuloj pri tiu industrio!

Mi ne rabatas aliajn en la teamo! John Qualls kaj Brian Wolff estas bonegaj amikoj, sed ĉi-vespere Pat estis sub la atento.

Break Break Sessions: Programa Skaleblo

Ed Saipetch pri App Scalability

Unu el la kunsidoj, kiujn mi partoprenis, estis gvidata de Ed Saipetch. Ed laboris ĉe The Indianapolis Star kiam mi faris kaj konstruis grandan parton de la skalebleco kaj aplikaĵoj ĉe la ĵurnalo. Li tiris iom da magio tiam - havis malmultajn rimedojn kaj multajn postulojn krei entreprenajn aplikojn per maldikaj buĝetoj.

Ed dividis multon pri pli novaj iloj uzeblaj por aŭtomata ŝarĝa testado kaj aplika rapido-testado kaj ankaŭ sana diskuto pri arkitekturo kaj kion ĝi signifas kreskante vertikale kaj grimpante horizontale. Mi tre ĝuis la konversacion.

Sharding estas efektive teknika termino?

[Enmetu Beavis kaj Butthead-ridon]

Ni eĉ diskutis dividado, esprimo, kiun mi rezervis nur por banĉambra humuro, kiun mi vidis en filmo unufoje. Sharding efektive estas rimedo por skali vian aplikon, iom barbare, simple per kreado de novaj datumbazaj kopioj kaj pelado de klientoj al malsamaj datumbazoj por mildigi la doloron trafi tutan datumbazon.

Kunfluu Sesion: Cloud ROI

La kostoj asociitaj kun nuba komputado povas varii multe - de preskaŭ nenio al sistemoj tre kontrolataj kaj forte sekurigitaj. La gusto de BlueLock estas Infrastrukturo kiel Servo - kie vi esence povas subkontrakti ĉiujn kapdolorojn de Infrastrukturo al ilia teamo, por ke vi povu koncentriĝi pri deplojo kaj kresko!

Mi eniris la konversacion pri Reveno de Investo pensante, ke ni havos tre intensan lecionon pri analizo de la rimedoj necesaj por tradicia kontraŭ nuba gastigado. Anstataŭe, Robby Slaughter gvidis elstaran diskuton pri la avantaĝoj kaj malavantaĝoj de ambaŭ kaj parolis pri riskomildigo.

Risko estas nombro, sur kiu plej multaj kompanioj povas meti iujn nombrojn ... kiom ĝi kostos, se vi ne povas kreski tuj? Kiom kostos, se vi malsupreniros kaj bezonas rekuperi restarigitan medion? Ĉi tiuj kostoj, aŭ perdita enspezo, povas ombrigi la monerojn kaj monerojn analizitajn en tradicia komparo.

Specialan dankon al BlueLock pro mirinde aranĝita evento (vortludo). Mi ne povis atendi veni hejmen kaj blogi pri sharding.

4 Komentoj

  1. 1

    "Ni eĉ diskutis pri sharding, esprimo, kiun mi rezervis nur por banĉambra humuro, kiun mi vidis en filmo unufoje."

    Mi ridis tiel forte, ke mi iomete ŝarĝis.

    Denove, [Enmetu Beavis kaj Butthead-ridon]

  2. 2

    Dankon pro la ŝtopilo, Doug! Cloudcamp estis bonega evento.

    Mi ne estis en la parolado de Ed pri sharding, sed mi pensis klarigi, ke ĉi tiu aliro ne nepre estas "barbara". Kutime dividado rilatas al disigado de via datumbazo laŭ specifaj fiaskaj linioj. Ekzemple, se datumoj de unu kliento neniam efikas al datumoj de alia kliento, vi povus dividi vian ĉefan datumbazon en du partojn: AL kaj MZ.

    Por stoki ulojn (kiel Ed) ĉi tio estas ia kruda solvo, ĉar ĝi signifas, ke vi devas konservi plurajn datumbazojn, kiuj estas efike strukturitaj same. Sed ĝi estas bonega maniero pliigi rendimenton sen aldoni multe da kosto!

Kion vi pensas?

Ĉi tiu retejo uzas Akismeton por redukti spamon. Lernu, kiel via komento datiĝas.