Amazon är, förutom världens största e-handlare, också världens största leverantör av det som hajpat kallas molntjänster eller Cloud Computing.

När Amazon släppte tjänsten EC2, Elastic Compute Cloud, så var det väldigt nytt att kunna starta och stoppa maskiner på timbasis, och bara betala för användningen (24 timmar = en maskin i ett dygn, eller 24 maskiner i en timme – samma kostnad).

Idag har många, många fler hoppat på det tåget och imiterat EC2 på mer eller mindre lyckade sätt. Nu försöker till och med vanliga svenska webbhotell följa efter, genom att köpa en “Cloud Computing Platform”-tjänst som Enomaly.

Men Amazon släppte EC2 redan 2006, och har sedan dess fortsatt att skapa nya innovativa tjänster som Simple Queue Service, SimpleDB, Elastic Block Store, etc. Allt för att göra det enklare att bygga applikationer helt i Amazons moln.

Nu har de tagit nästa steg, något som är fungerar för någon med Amazons skala men som blir svårt att kopiera för små webbhotell med köpelösningar: Spot Pricing.

I princip är detta auktionssystemet som gjorde Google AdSense så framgångsrikt, applicerat på instanser i Amazons moln. Alla som har ett EC2-konto kan registrera 1) hur många instanser de vill starta och 2) hur mycket de maximalt vill betala för instanserna. Amazon bestämmer utifrån den här informationen ett marknadspris för en instanstimme, och alla vars angivna maxpris ligger över marknadspriset får sina instanser startade.

För att inte kannibalisera på vanliga EC2-instanser (som hyrs för ett fast timpris) och för att möjliggöra snabb anpassning till marknadspriset, så kan en “Spot Instance” stoppas när som helst. När marknadspriset för en instanstimme går över vad du betalar för din “Spot Instance” så stänger Amazon av din instans direkt, utan att vänta till nästa timme.

Det här är självklart ingenting som man kan eller bör använda för att köra en webbserver eller något annat som har krav på tillgänglighet och upptid. Det öppnar snarare möjligheter för en helt annan typ och klass av applikationer att köras så kostnadseffektivt som möjligt. Om du har ett stort konverteringsprojekt, eller en strid ström av tidskrävande operationer som inte nödvändigtvis har en fast deadline, så kan du nu registrera en stående order med Amazon att du vill köpa X antal instanser, att köras så länge priset understiger Y dollar.

Det här är alldeles genialt: Amazon får ett sätt att nå mycket nära 100% kapacitetsutnyttjande hela tiden, och köpare får ett nytt sätt att hålla sina kostnader nere för icke-tidskänsliga applikationer. I tanken liknande “off-peak” och “on-peak”-priser för exv. bandbredd eller elektricitet, men självklart mer komplext.

“If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place” – Eric Schmidt, Google

Eric Schmidt visar på en mycket oroväckande inställning till integritet, och det finns få positioner där en sådan åsikt kan göra mer skada än som Googles CEO.

Apropå det uttalandet påmindes jag om Bruce Schneiers välskrivna The Eternal Value of Privacy från 2006:

For if we are observed in all matters, we are constantly under threat of correction, judgment, criticism, even plagiarism of our own uniqueness. We become children, fettered under watchful eyes, constantly fearful that — either now or in the uncertain future — patterns we leave behind will be brought back to implicate us, by whatever authority has now become focused upon our once-private and innocent acts. We lose our individuality, because everything we do is observable and recordable.

Människors beteende förändras när de är medvetna om att de kan vara övervakade. Oavsett hur otroligt det är att någon skulle vara intresserad av just deras kommunikation, så finns kunskapen om att möjligheten finns undermedvetet kvar. De flesta kanske inte ens märker effekten, men faktum kvarstår: det uppstår en självsanering, en egencensur, av människors kommunikation genom att berätta att de kan vara övervakade.

Vi vet inte vad effekten av det här blir om 10 år, 20 år, 100 år. Och det farliga är att vi aldrig kommer att objektivt kunna bedöma hur vårt beteende har förändrats, eftersom förändringen sker så gradvis att vi inte ser skillnaden.

För att få ut en bloggpost till under 2009 (det gäller att inte sätta upp ouppnåeliga mål…) så kopi^H^H^H^H inspireras jag friskt av en nystartad blogg av en viss Ashish Soni.

I datorsammanhang pratar man ofta om Mean Time Between Failure, MTBF. På enskild komponentnivå är det såklart väldigt intressant att veta MTBF för att veta förväntad livslängd på komponenten ifråga.

Men när man tittar på tjänstenivå så kanske det är mer intressant med Mean Time To Recovery, MTTR. Hur lång tid tar det för tjänsten att återställas till normal drift när väl ett problem inträffar? Kombinerat med ett SLA ger MTTR en klarare bild av vilken typ av nedtid man kan förvänta sig från en tjänst man är beroende av.

Ett SLA-åtagande på upptid på 99.9% på årsbasis säger egentligen inte mycket. Det ger utrymme för nästan 9 timmars nedtid på ett år, men man vet ingenting om hur tiden är uppdelad. Är det ett 10-minutersstopp i veckan, eller ett enda stort avbrott på en hel arbetsdag? Beroende på tjänsten kan man föredra olika modeller, men poängen är att man inte vet hur det ser ut.

Om man däremot också fick se en siffra på MTTR så får man en mycket tydligare bild av det genomsnittliga avbrottet.

Problemen med att planera för framtiden efter historiska resultat utelämnar jag passande nog från detta inlägg.

Med anledning av gårdagens strul hamnade jag på Netnods grafer över Internettrafiken i Sverige.

Jag märkte då något mycket intressant på tvåårsgrafen över trafiknivåerna:

Det stora fallet i våras är ju den omtalade “IPRED-effekten”. Men titta vad som har hänt efter en sommar utan några fällande domar; trafiken är tillbaka på den nivå den var innan IPRED trädde i kraft!

Undrar vad som händer nu när det första och mest uppmärksammade IPRED-fallet har stängts ner av hovrätten som klokt nog förstått att material inte är “tillgängligt för allmänheten” bara för att det finns tillgängligt på en lösenordsskyddad server.

Via irländska Contrasts blogg hittar jag en liknelse som förklarar fördelen med iterativ utveckling på ett synnerligen bra sätt.

När du tillverkar en stor tårta så kan du börja med en tårtbotten, lägga på lager efter lager av fyllning och avsluta med glasyr. Men du kan också börja med en liten muffins, för att sedan gradvis baka större och större bakverk. Fördelen är att du alltid har något att servera, även om du får slut på tid eller pengar halvvägs in i projektet.

Eller det lite mer seriösa citatet som Contrast länkar till:

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” – John Gall, Systemantics