Amazon EC2 i trubbel - molnet inte så magiskt som vi trott?

[extract]Amazons web service fick under helgen rejäla problem med flera av sina tjänster, bland annat Amazon Elastic Compute Cloud, Amazon Relational Database Service och Amazon Elastic Beanstalk och det ställde till det ordentligt för en del stora aktörer.[/extract]

 

HootSuite, Reddit och Foursquare är några av dom större tjänster som kände av när Amazons molnlösning gick in i väggen och under tre dagar så föll himlen för dom tusentals som satt sitt förtroende till molnlösningen från Amazon. Responsen har inte låtit vänta på sig och webben är fylld av inte helt vänliga tongångar, vilket är förståeligt eftersom Amazon verkar ha brutit mot det löfte man haft gentemot sina kunder. Det löftet var att det inte skulle finnas vad man kallar "single point of failure", dvs en gemensam punkt som kan slå ut hela systemet.

 

Mashable tar tillfället i akt att analysera vad vi kan göra bättre och City Cloud gör detsamma, fast på svenska. Justin skriver också om problemet på ett bra sätt. Det tråkiga i kråksången är att även om problemet med Amazons molntjänst verkar bero på att Amazon har klantat sig, antingen medvetet för att spara pengar eller genom tekniskt fummel av episka mått, så påverkar det hela molnindustrin negativt.

 

En av dom stora fördelarna med molnlösningar är just att det ska vara säkert från serverkrascher och ha en nästan magisk redundans så att ingenting förutom en global katastrof ska kunna påverka innehållet. Det är iallafall hur molnleverantörerna vill att vi ska se på deras produkter. Sanningen är som alltid att det inte finns några garantier och att allting kan kollapsa, oavsett hur gärna vi vill tro annorlunda.

 

Precis som så mycket annat när det gäller molntjänster så brister det när det gäller enkelhet, både när det gäller tekniken och när det gäller utformning av information och kontrollpaneler. Det gör att tröskeln för att skapa bättre redundans är högre än den borde vara och det förlorar branschen på. En idiotsäker plattform är inte bättre än det GUI som användaren ska utnyttja och ju fler variabler som användaren tillåts pilla på, desto tydligare måste användandet utformas.

 

Du kan lägga miljoner på att skapa en utopi av total redundans över dussintals datacenter i olika länder men inte ens då kan du vara 100% säker på allting kommer att finns tillgängligt. Det finns hundratals faktorer som ligger utanför din, och datacentrens, kontroll och någonstans måste du fundera på hur mycket du är villig att lägga på att skydda dig mot just den där katastrofala dagen då allt går åt skogen.

 

Hur mycket är du villig att betala för att undvika en nertid på 1 timme, 6 timmar, 12 timmar, 24 timmar eller tre dagar? Lägg sedan den kostnaden i perspektiv till hur ofta den typen av nertid rimligen kan inträffa per år och då får du ett värde på hur mycket du bör lägga på att försäkra dig att din webbplats eller webbtjänst alltid ligger uppe. I dom allra flesta fallen så kommer det värdet inte ens i närheten av kostnaden för den redundans som krävs kan jag lova.

 

Hur mycket är du villig att betala för att undvika 3 dagars nertid?