Hvad jeg lærte på CloudCamp

CloudCamp DaveSkønt forsinket (1 uge) på grund af sne sidste uge, CloudCamp Indianapolis gik uden problemer i aften. Hvis du er ikke fra Indianapolis - du skal fortsætte med at læse. CloudCamp er relativt nyt og afholdes i større byer over hele kloden. Takket være fagekspertisen og branchens ledelse af BlueLock, vi afholdt en vellykket begivenhed lige her i Indy.

Hvis du undrer dig hvad Cloud Computing er, Har Bluelock givet nogle diskussioner om at definere dette temmelig tågeudtryk.

Cloud Computing i Indianapolis?

Indianapolis får opmærksomhed nationalt og internationalt på grund af de lave, stabile omkostninger forbundet med strøm og fast ejendom - to store faktorer til bestemmelse af hostingomkostninger. Derudover er vores vejr solidt, og vi er en krydsning på tværs af store rygrad på Internettet i Nordamerika. Hvis du er vært for din ansøgning i et datalager i Californien lige nu - kan du tage et kig!

BlueLock er internationalt førende inden for cloud computing

Jeg skal være ærlig, jo mere jeg hører Pat O'Day tale, jo mere skræmt om hvor meget den fyr ved om cloud computing, utility computing, grid computing, data warehouse management, Virtualization, VMWare ... you name it, og den fyr ved det. Han er blød talt, elskværdig og har den uhyggelige evne til at tale til os folk, der ikke er teknologisk kloge i den branche!

Jeg diskonterer ikke andre på holdet! John Qualls og Brian Wolff er gode venner, men i aften var Pat i rampelyset.

Break Out Sessions: App-skalerbarhed

Ed Saipetch på skalerbarhed af app

En af de sessioner, jeg deltog i, blev ledet af Ed Saipetch. Ed arbejdede hos The Indianapolis Star, da jeg gjorde det og byggede meget ud af skalerbarheden og applikationerne i avisen. Han skabte noget magi dengang - havde få ressourcer og mange krav til at bygge virksomhedsprogrammer på barberknivens tynde budgetter.

Ed delte et ton om nyere værktøjer, der kan bruges til automatiseret belastningstest og applikationshastighedstest samt en sund diskussion af arkitektur og hvad det betyder ved at vokse lodret og skalere vandret. Jeg nød virkelig samtalen.

Sharding er faktisk et teknisk udtryk?

[Indsæt Beavis og Butthead griner]

Vi diskuterede endda sharding, et udtryk, som jeg kun havde reserveret til badeværelseshumor, som jeg så i en film en gang. sharding er faktisk et middel til at skalere din applikation, snarere barbarisk, simpelthen ved at oprette nye databasekopier og skubbe kunder til forskellige databaser for at lindre smerten ved at ramme en enkelt database hele tiden.

Break Out Session: Cloud ROI

Omkostningerne forbundet med cloud computing kan variere meget - fra næsten intet til systemer, der er meget overvåget og stærkt sikret. BlueLocks smag er Infrastructure as a Service - hvor du dybest set kan outsource infrastrukturens hovedpine til deres team, så du kan koncentrere dig om implementering og vækst!

Jeg gik ind i Return on Investment samtalen og tænkte, at vi skulle have en meget intens lektion i analyse af de ressourcer, der var nødvendige for traditionel versus cloud hosting. I stedet, Robby Slaughter førte en fremragende diskussion af fordele og ulemper ved begge og talte om risikoreduktion.

Risiko er et tal, som de fleste virksomheder kan sætte nogle tal på ... hvor meget koster det, hvis du ikke kan vokse øjeblikkeligt? Hvor meget koster det, hvis du går ned og har brug for at bringe et gendannet miljø op igen? Disse omkostninger eller tabte indtægter kan overskygge de nikkel og dimes, der er analyseret i en traditionel sammenligning.

Særlig tak til BlueLock for en vidunderligt vært begivenhed (ordspil beregnet). Jeg kunne ikke vente med at komme hjem og blogge om sharding.

4 Kommentarer

  1. 1

    "Vi diskuterede endda sharding, et udtryk, som jeg kun havde forbeholdt badeværelseshumor, som jeg så i en film en gang."

    Jeg lo så hårdt, jeg splinter lidt.

    Igen, [Indsæt Beavis og Butthead griner]

  2. 2

    Tak for stikket, Doug! Cloudcamp var en stor begivenhed.

    Jeg var ikke i Eds tale om sharding, men jeg troede, jeg ville præcisere, at denne tilgang ikke nødvendigvis er "barbarisk". Sharding refererer normalt til at bryde din database fra hinanden langs applikationsspecifikke fejllinjer. For eksempel, hvis data fra en kunde aldrig påvirker data fra en anden kunde, kan du opdele din hoveddatabase i to dele: AL og MZ.

    For opbevaring af fyre (som Ed) er dette en slags rå løsning, fordi det betyder, at du skal vedligeholde flere databaser, der er effektivt struktureret på samme måde. Men det er en fantastisk måde at øge ydeevnen uden at tilføje store omkostninger!

Hvad mener du?

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.