Här är några bilder för att hjälpa dig komma igång. I korthet handlar det om att skapa en Amazon-användare, registrera sig för tjänsten och sen starta en instans. Inget av stegen kostar (du betalar bara för den tid du har instanserna igång) och du behöver inte vänta på något.

Först, surfa till AWS-sidan och registrera dig.

När du är registrerad så klicka dig vidare i navigeringen till kontrollpanelen “AWS Management Console”.

Sen får du signa upp dig igen, den här gången för att få tillgång till AWS Management Console.

Med det klart så klickar du på länken för att dra igång en instans (alltså en virtuell server)

Det finns många olika att välja emellan, jag väljer en Fedora LAMP-server för jag vet inte bättre. Den består iallafall av Linux, Apache, mySQL och php förkonfigurerat och klart.

En (1) instans tycker jag räcker och jag behöver inte high-CPU-modellen heller.

Någonstans här har jag hoppat över två steg: för att kunna logga in på servern behöver man skapa ett certifikat. Det laddas ner lokalt till datorn och när man sen loggar på med ssh så ska man se till att man står i katalogen där certifikatet ligger (skrivbordet eller Downloads-foldern?). Man ska också konfigurera brandväggsregler och det är också några klick som jag utelämnar. Port 80 och 22 är bra att ha öppna.

Din nya instans startas nu upp någonstans i en virtuell miljö i någon av Amazons datorhallar.

En grön knapp lyser när det är klart! Yes!

Klicka på instansen och upp kommer lite information längst ner på sidan. Det som står bakom “Public DNS:” kan du kopiera in i webbläsaren och sen surfa till din egna instans.

Så här ser min ut, jag har dessutom piffat upp den lite med mitt eget namn. För att kunna göra det måste man logga in och ändra index.php-filen.

Markera instansen och klicka på Connect-knappen ovanför.

En instruktion visas för hur du ansluter och det är bara klipp och klistra en rad in i Terminalen (ssh-klienten) och logga in (som root, lösenordet behövs inte). Glöm inte att ställa dig i katalogen där du har sparat certifikatet.

Nu är du inloggad!

Startsidan ligger i /home/webuser/helloworld/htdocs om du vill ändra….

Det finns mycket mer dokumentation och tutorials hos AWS för att komma igång. Den här är bra och sammanfattar det jag beskrivit mycket tydligare.

Lycka till!

Relaterade länkar:

1. Hur klarar du ett “pull the plug”-test?
2. WP MU tre veckor senare (med några snabba frågor till Henrik)
3. Fix för krånglande VPN (Ipredator till exempel)

Jag söker efter en ny typ av bolag: teknikbolag som arbetar med webbplattformar runt drift och utveckling. Hjälpa till att modernisera plattformar och applikationer genom att använda de möjligheter och erbjudanden som finns på nätet och “i molnet”.

- Äger ingen egen infrastruktur
- Hög kunskapsnivå och nyfikna på vad som väntar runt hörnet
- Få personer som delar mycket kunskap och kan varandras lösningar
- Inte ha ambitioner att växa, utan att bli ännu skarpare och bättre
- Fötterna i open source-myllan
- Hanterar utveckling och drift (av plattformar, inte nödvändigtvis webbutveckling)
- Ingen specifik helpdesk/jour/supportorganisation: vid larm är det direkt någon med rätt kunskap som agerar

Varför då:
- Alldeles för många vet alldeles för lite om vad som är möjligt nuförtiden. Många företag behöver modernisera sig och istället för att lägga pengar på licenser och stora “löser allt”-produkter kan man arbeta med mindre, specialiserade lösningar som man använder som pusselbitar.
- Små snabbfotade konkurrenter/startups/kloka företag arbetar redan så, och gör det med framgång.
- Mindre byråkrati och snabbare kommunikationsvägar behövs. Färre nivåer.
- Ju större företag ju lägre medelnivå på kompetensen.

Med kreditkort kan man idag skaffa sig all tänkbar lagrings och datorkraft. Det är inte längre nödvändigt (eller ens fördelaktigt att äga och serva sin egen hårdvara). De här personerna ska inte byta hårddiskar som kraschar eller sitta och skruva i datorhallar, de ska sitta tillsammans med utvecklare. Att hantera IT-infrastruktur kommer gå samma väg som elkraft: det finns i sladden, du behöver inte bry dig om hur.

Det behövs ett stabilt personberoende; 5-10 personer som delar på några kunder/uppdrag. Inte mer. Full öppenhet och kontakt däremellan, inga mellanhänder. Bra dokumentation som delas mellan bolaget och kunden. Alla ser samma larm- och övervakningssystem (dashboard). Nya kunder endast om det får plats i befintlig organisation, inte genom att växa i antal huvuden.

Bara arbeta med en viss typ av kunder eller uppdrag och vara bäst på det.

Inse att “så har vi alltid gjort tidigare” inte längre fungerar.

I den traditionella värld jag kommer ifrån har vi mycket kvar att lära. Vilka arbetar redan så här?

Relaterade länkar:

1. Om storlek
2. Lite mer Amazon (databaser den här gången)
3. Framtiden: jag är här nu (mobilt, rörligt innehåll och internet)

Google garnered impressive word of mouth among their users for one reason: it worked. Not only did its PageRank algorithms produce delightfully relevant results, but they did it with impressive speed, and the service never showed signs of buckling under the exponential growth it was experiencing.

Page and Brin had their Stanford-era frugality to thank for this robustness. Because the pair had to scrape for every machine they could find to support the early service, they were forced to optimize Google to run over off-the-shelf parts: cheap hard drives, cheap memory chips, and cheap CPUs. Instead of buying heavy mainframe artillery from the likes och IBM or Fujitsu, Brin and Page created a small army of foot soldiers: a massively parallel formation of cheap processing and storage. The beauty of the system was that it scaled: the more computers you threw at it, the more robust it became. And when a component broke down, no problem; you simply swapped it out. The system itself could never fail: there were simply too many individual parts, none of which depended entirely on the others.

Googles tre principer för “scalability“:

Cheap
The key to Google’s competitive strategy is that they have the cheapest compute, network and storage (CNS) in the industry.

Embrace failure
Cheap also means things break. And when you’ve got several million servers, lots of things break every day. Get over it. Google expects failure and builds recovery into the software layer that connects the cheap kit.

Architect for scale
Architecting for scale leverages cheap CNS to give Google the lowest-cost growth as well. Competitors such as Yahoo, who rely more on standard EDC products, can do the same things as Google, but it costs them about 10x in capital expense and several times the operations expense.

Relaterade länkar:

1. Så här gjorde jag Surdegskartan (8hbc:)
2. Den här bloggen är Google Friend Connect-enablad
3. Infrastruktur för realtidswebben

Jag gillar mycket att det är enkelt skruva upp kapaciteten och sen slippa allt vad hårdvara innebär. Bara de två argumenten är tunga.

Relaterade länkar:

1. Bygg backupsajt med Amazon (eller bygg en sajt..)
2. Lite tänk runt drift och framtiden
3. Så enkelt att till och med en IT-chef klarar av det

Idag fick jag mail om att de runt årsskiftet släpper “AWS Content Delivery Service“. Enkelt förklarat ger det möjligheter att med Amazons enorma kapacitet sprida det innehåll man redan har lagrat i deras tjänst S3 (Simple Storage Service), alltså vanlig webbserverleverans.

Genom ett API-anrop så gör man innehållet (i S3) tillgängligt i deras deliverynät som sen kan hämtas av slutanvändarna. Fördelarna är bland annat att de har enorm kapacitet spridd över världen (nåja, tre kontinenter iallafall) och att betalningsmodellen är pay-as-you-go.

Från början är det bara http, på sikt kan man tänka sig olika streaming-lösningar också.

Jag har ofta varit med om kapacitetsbrister på webbplatser och kan se två stora möjligheter: att avlasta vid trafiktoppar eller att hantera en sekundär-/backup-/nödsajt ifall den primära sajten av någon anledning är otillgänglig.

Det Amazon gör är i princip inget nytt (liknande lösningar finns redan hos andra leverantörer) men bit för bit bygger de en arkitektur som finns tillgänglig med ett vanligt kreditkort (utan uppstartskostnader, långa avtalstider eller inlåsningar) och väldokumenterade API:er. Och med enorm kapacitet.

Slutsats: Steget till att bygga en sekundärsajt tillgängligt (genom DNS-ompekning) där man har aktuella kopior av sin sajt speglade håller på att krympa. Speciellt eftersom det är dyrt med sekundärsajter som behöver full (eller mycket) kapacitet men bara används när något smäller.

Metainformation: Jag har ett S3-konto där jag tänkte lagra undan “viktiga filer” som jag än så länge bara lekt med. Men varje månad drar Amazon pengar från mitt betalkort för det utnyttjade utrymmet och trafiken.

Mail från Amazon, kommer en gång per månad. 9 cent för september, ouch…

Så här ser prislistan ut för lagring:

$0.18 per GB-Month of storage used

Data Transfer
$0.100 per GB – all data transfer in

$0.170 per GB – first 10 TB / month data transfer out
$0.130 per GB – next 40 TB / month data transfer out
$0.110 per GB – next 100 TB / month data transfer out
$0.100 per GB – data transfer out / month over 150 TB

Relaterade länkar:

1. Lite mer Amazon (databaser den här gången)
2. Biprodukt
3. Uppkopplade prylar – bygg själv

På pappret ser det bra ut och även efter första synkningen ser det bra ut. Men det finns några brister som förvånar:

Slutbetyg: Bra synkväg, den löser problemet med dator-online-mobil. Men synkning av adressböcker fortsätter tydligen vara svårare än att flyga till månen…

Relaterade länkar:

1. Mail i molnet – check!
2. Buzz kan bli ztort?
3. “The Online Photographer” – Ten New Camera Recommendations

Att få över allting tog ungefär en vecka (brutto). Hade jag haft mailen tillgängliga på en server hade importen kunnat skötas automatiskt, nu hade jag mail lokalt i datorn och fick “dra och släppa” över en mapp i taget. Emellanåt stannade överföringen och det berodde på att jag flyttat på bilagorna (eller raderat dom), konstiga filnamn eller annat oförklarligt.

Ungefär så här går flytten till:

Här är lite plus och minus och kommentarer runt konceptet:

Plus

Minus

Allmänt

Nu kör jag webbmail och har ytterligare ett program mindre att ha igång i datorn (sedan tidigare kalender och todo-lista). Och framförallt: allt tillgängligt om jag är uppkopplad, oavsett hur, var eller med vad.

Relaterade länkar:

1. Och så var kalendern i molnet…
2. Adressboken tillgänglig online (och där den gör bäst nytta)
3. Trådlös anslutning till TV’n (nästan med HD)

Det är mycket enkelt att registrera en Google Apps. Skapa ett konto (domän) och verifiera genom att lägga upp en fil på den aktuella domänens webb. Klicka verifiera och efter ett tag är kontot aktiverat.

Registrera en ny användare eller fortsätt på samma. Gör först en export från iCal av hela kalendern. För mig blev det 1.2 MB som innehöll alla bokningar från september 2002 till nu (och framåt). Klicka dig in i kalendern på Apps och importera.

Klart!

Imponerande att trots att det är en webbtjänst funkar den bättre än iCal: fler kortkommandon, snabbare visning, bättre sök etc. De har inte lyckats helt med AM/PM och hur datum skrivs ut. Trots att man anger det i inställningar så blir det inte rätt överallt (och i mobilgränssnittet är det likadant). Detaljer…

Nu har jag börjat labba lite med import av mail. Det är några hundratusen mail och jag vill helst att det blir rätt första gången.

Relaterade länkar:

1. Mail i molnet – check!
2. Tomt i brevlådan
3. ”Det blir inte bättre än så här!”

Jag vill att tjänsterna ska vara säkra så att informationen förblir privat (om den ska vara det) och att det ska finnas import/export-möjligheter (för att lämna tjänsten och för att kunna ta backup).

Det mest basala är att få ut epost, bokmärken, RSS-feeder, kontakter och kalender i molnet. Sen dokument, vanliga filer och foton etc.

Förutom att få informationen tillgänglig online hanterar man också haverier bättre.

Jag började med något snabbt och enkelt och har laddat upp 1035 bokmärken på del.icio.us/perkovich (de är default privata så det kommer ta ett tag innan jag gallrat och ändrat status). Om du också använder delicious så lägg gärna till mig som kontakt!

Dessutom har jag flyttat över to-do-listorna från iGTD som jag använt i ett halvår till Todoist. Helt webbaserat, enkelt och rent gränssnitt med kortkommandon, finns i mobilversion (inte särskilt snygg, men funkis) och tack vare att det finns ett öppet API så har en Gary King byggt en exportfunktion för backup (dock saknas importfunktion… hm….).

Relaterade länkar:

1. Framtiden: jag är här nu (mobilt, rörligt innehåll och internet)
2. Lite tänk runt drift och framtiden
3. Sverige – mycket mindre, mycket innehållsfattigare

Ett effektivt sätt att testa är ett klassiskt “pull the plug”-test: dra ut kablar som används. När allting är speglat, replikerat, dubblerat, raidat, master/slave:at och redundant ska ingenting hända oavsett vilken kabel som dras ut (el, nätverk, fibre channel etc.).

Det är svårare än det låter.

Testa på din egen dator: låtsas att hårddisken går sönder JUST NU!! Och allt som ligger på den är borta för alltid. Hur gick det?

- Hur lång tid tar det innan du kan arbeta vidare?
- Har någon information gått förlorad? (Kontakter? Epost? Inloggningar? Foton? etc.)
- Har du viktig information tillgänglig någon annanstans?
- När tog du senaste backupen? (Fungerar den? Har du testat att tillbaka något från den någon gång?)

Med tanke på vilket enormt värde man samlar på sig i digital form är det välinvesterad tid och pengar att hantera informationen ordentligt och emellanåt reflektera över riskerna.

* = Min erfarenhet är att det oftare är mjukvara än hårdvara som orsakar problem, men hårdvara kan orsaka långa stopp.

Relaterade länkar:

1. Så enkelt att till och med en IT-chef klarar av det
2. test
3. Är du förberedd på problem?