Co jsem se naučil na CloudCamp

CloudCamp DavePřestože byl minulý týden zpožděn (1 týden) kvůli sněhu, CloudCamp Indianapolis odešlo dnes v noci bez problémů. Pokud jsi ne z Indianapolisu - měli byste číst dál. CloudCamp je relativně nový a koná se ve velkých městech po celém světě. Díky odbornosti předmětu a vedoucímu postavení v oboru BlueLock, uspořádali jsme úspěšnou akci právě tady v Indy.

Pokud vás zajímá co je Cloud Computing„Bluelock poskytl určitou diskusi o definování tohoto poměrně mlhavého termínu.

Cloud Computing v Indianapolis?

Indianapolis získává pozornost na národní i mezinárodní úrovni díky nízkým a stabilním nákladům spojeným s energií a nemovitostmi - dvěma obrovskými faktory při určování nákladů na hostování. Naše počasí je navíc solidní a jsme křižovatkou hlavních páteří internetu v Severní Americe. Pokud právě hostujete svou aplikaci v kalifornském datovém skladu - můžete se podívat!

BlueLock je mezinárodním lídrem v oblasti cloud computingu

Musím být upřímný, čím více slyším Pat O'Day mluvit, tím více se bojím toho, kolik toho ten člověk ví o cloud computingu, utilitním počítání, gridovém počítání, správě datového skladu, virtualizaci, VMWare ... pojmenujete to a ten chlap ví to. Je tichý, laskavý a má neuvěřitelnou schopnost mluvit s námi lidmi, kteří v tomto odvětví nejsou technicky zdatní!

Nezlevňuji ostatní v týmu! John Qualls a Brian Wolff jsou skvělí přátelé, ale dnes v noci byla Pat v centru pozornosti.

Break Out Sessions: škálovatelnost aplikací

Ed Saipetch o škálovatelnosti aplikací

Jedno ze zasedání, kterých jsem se zúčastnil, vedl Ed Saipetch. Když jsem pracoval, pracoval Ed v The Indianapolis Star a vytvořil velkou část škálovatelnosti a aplikací v novinách. Tehdy vytáhl nějaké kouzlo - měl málo zdrojů a spoustu požadavků na budování podnikových aplikací na tenkých rozpočtech.

Ed sdílel hromadu novějších nástrojů, které lze použít pro automatické testování zátěže a testování rychlosti aplikací, stejně jako zdravou diskusi o architektuře a o tom, co to znamená, když roste vertikálně a horizontálně se mění měřítko. Moc se mi líbila konverzace.

Sharding je vlastně technický pojem?

[Vložte Beavis a Butthead se smějí]

Dokonce jsme diskutovali sráženíTermín, který jsem si vyhradil pouze pro koupelnový humor a který jsem jednou viděl ve filmu. Stříkání je ve skutečnosti prostředek škálování vaší aplikace, spíše barbarsky, jednoduše vytvářením nových kopií databáze a tlačením zákazníků do různých databází, aby se zmírnila bolest při zasažení jediné databáze po celou dobu.

Break Out Session: Cloud ROI

Náklady spojené s cloud computingem se mohou velmi lišit - od prakticky nic po systémy, které jsou vysoce monitorovány a silně zabezpečeny. BlueLock se chlubí infrastrukturou jako službou - kde můžete v podstatě outsourcovat všechny bolesti hlavy infrastruktury jejich týmu, abyste se mohli soustředit na nasazení a růst!

Šel jsem do konverzace Návratnost investic v domnění, že budeme mít velmi intenzivní lekci v analýze zdrojů potřebných pro tradiční versus cloudový hosting. Namísto, Robby Slaughter vedl vynikající diskusi o výhodách a nevýhodách obou a hovořil o zmírnění rizik.

Riziko je číslo, na které si většina společností může dát nějaká čísla ... kolik to bude stát, když nemůžete okamžitě růst? Kolik to bude stát, když půjdete dolů a potřebujete obnovit obnovené prostředí? Tyto náklady nebo ušlé příjmy mohou zastínit nikly a desetníky analyzované v tradičním srovnání.

Zvláštní poděkování BlueLock za nádherně pořádanou akci (zamýšlená slovní hříčka). Nemohl jsem se dočkat, až se vrátím domů a budu blogovat o shardingu.

4 Komentáře

  1. 1

    "Dokonce jsme diskutovali o střepu, což je termín, který jsem si vyhradil pouze pro humor v koupelně a který jsem jednou viděl ve filmu."

    Smál jsem se tak tvrdě, že jsem se trochu střepil.

    Opět [vložte Beavis a Butthead se smějí]

  2. 2

    Díky za zástrčku, Doug! Cloudcamp byla skvělá událost.

    Nebyl jsem v Edově řeči o střepu, ale myslel jsem si, že objasním, že tento přístup nemusí být nutně „barbarský“. Sharding obvykle znamená rozbití databáze od sebe podél chybových linií specifických pro konkrétní aplikaci. Například pokud data od jednoho zákazníka nikdy neovlivní data od jiného zákazníka, můžete svou hlavní databázi rozdělit na dvě části: AL a MZ.

    Pro lidi z oblasti úložiště (jako Ed) je to trochu hrubé řešení, protože to znamená, že musíte udržovat více databází, které jsou efektivně strukturovány stejným způsobem. Ale je to skvělý způsob, jak zvýšit výkon bez zvýšení nákladů!

Co si myslíte?

Tyto stránky používají Akismet k omezení spamu. Zjistěte, jak jsou vaše údaje komentářů zpracovávány.