11
Jan 09

Så enkelt att till och med en IT-chef klarar av det

När Amazon/AWS den 9 januari lanserade AWS Management Console blev det så enkelt att börja använda EC2 att alla borde prova det (som på något vis vet vad det handlar om). Alla vi kommer beröras på ett eller annat sätt.

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.


Continue reading →


07
Oct 08

Lite tänk runt drift och framtiden

Inför framtiden (med mer open source, ständigt mer IT-beroende, mer “moln-leverantörer” etc.) kommer IT-folk behöva tänka nytt.

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?


05
Oct 08

The Infrastructure Rules

Apropå tillgänglighet, mjukvara och hårdvara och hur Google bygger sina plattformar (från sidan 129 i The Search):

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.


23
Sep 08

Lite mer Amazon (databaser den här gången)

Nytt mail från Amazon värt att uppmärksamma (det förra skrev jag om för några dagar sen): den här gången mailar de om att EC2 (Elastic Compute Cloud) har stöd och full support för Oracle- och MySQL-databaser. Så det är egentligen bara att ta fram kreditkortet och skapa en användare och sen bygga sin datalagring i molnet. Några fördelar är: hög tillgänglighet, betala för förbrukning, säkerhet, stöd för replikering, failover och backup, stor skalbarhet och alltså full support från leverantörerna. Integrerar också med övriga tjänster från Amazon. Och förhoppningsvis bättre licensvillkor från Oracle?

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.


18
Sep 08

Bygg backupsajt med Amazon (eller bygg en sajt..)

Amazon har börjat outa sina planer innan de har något att visa (alltså pre-beta) för det goda syftet att låta kunder veta vad som är på gång och därmed ge bättre möjligheter att integrera deras tjänster.

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


02
Jun 08

Adressboken tillgänglig online (och där den gör bäst nytta)

Med OS X 10.5.3 (som kom i förra veckan) kan man synka Adressboken med Gmail (och även med Google Apps). Praktiskt – då kan man både behålla adressboken såsom den är men även ha allt innehåll tillgänglig online.

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:

  • Du måste synka något annat för att det ska fungera. Kan vara en telefon, en iPod, iPhone eller .Mac, för annars kan du inte synka mot Gmail heller.
  • I iSyncs logg syns ingen information om Google-synkningen: hur den gått, hur mycket som ändrats, uppdaterats etc.
  • Företagskontakter syns inte. Det tolkas istället som tomt förnamn och efternamn i listan. Så överst i min lista har jag 100-talet poster “tomma”. En otroligt stor brist!
  • Adressboken tillgänglig online

  • Grupper hanteras inte. Inte livsviktigt men hade varit bra att ha.
  • Ändringar syns först när du loggat ut. Och in igen (i Gmail).
  • Continue reading →


    28
    May 08

    Mail i molnet – check!

    Nu har jag flyttat all mail till Google Apps. Tidigare har jag kört POP och haft mail lokalt i bärbara datorn men nu vill jag ha det tillgängligt online.

    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:

  • Regga domänen hos Google Apps.
  • Verifiera den genom att lägga upp googlehostedservice.html på din hemsida.
  • Skapa de konton du vill använda i Apps.
  • Om du vill kan du testskicka både till och från kontona innan domänen är aktiv genom att lägga till test-google-a.com sist i adressen, alltså per@strm.se.test-google-a.com i mitt fall.
  • Skapa taggar/etiketter i Gmail motsvarande de mappar du vill flytta över från ditt mailprogram.
  • Lägg in ditt Gmailkonto i ditt mailprogram (imap.gmail.com och din mailadress).
  • Koppla upp och börja sen kopiera: markera alla mail i en folder och dra och släpp på motsvarande katalog (tagg). Mailen kopieras över. Enkelt!
  • När du flyttat över allt, markera alla mail i Gmail och skapa en ny tagg som heter “Importerat” eller liknande så är vet du varifrån mailen kommer i framtiden.
  • Sen låter du webbhotellet peka om MX-record till Google och efter några timmar trillar mailen in där istället. Du kan också lägga till ett CNAME för att få en snyggare adress till webbgränssnittet, typ mail.dindomän.se.
  • Continue reading →


    15
    May 08

    Och så var kalendern i molnet…

    iCal no more… Nu är kalendern flyttad till Google Apps (under domänen strm.se).

    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.


    13
    May 08

    Nu flyttar jag (innehåll)

    Från midsommar kommer jag vara föräldraledig i sju månader. För att kunna leva vidare som vanligt (uppkopplad, information tillgänglig etcetera) trots en mer mobil tillvaro kommer jag flytta ut innehåll i “molnet“. Det är något jag tänkt göra länge, ständigt skjutit upp och inte genomfört fullt ut.

    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….).


    04
    May 08

    Hur klarar du ett “pull the plug”-test?

    En säker driftsmiljö för till exempel en webbsajt byggs så att den ska fortsätta fungera utan störningar även om någonting går sönder*. Användarna ska inte märka något och i lugn och ro ska felet kunna åtgärdas.

    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.