onsdag 27 april 2011

Cloudsourcing - hur lyckas man?

Den 17/5 anordnas en heldag om att lyckas med strategier avseende outsourcing. En hel del lärdomar finns att hämta när du tänker molnsatsningar. Jag kommer tillsammans med Johan Kahn att diskutera framgångsfaktorer vid cloudsourcing.

Ämnet känns extra aktuellt i dagsläget. Vi kommer att vara på Näringslivets Hus i Stockholm och anmälan finns här.

Molnkrasch, vandaler och andra fartgupp

Efter en solig påskperiod är molnen i fullt fokus för Cloud Advisor. Två större händelser den senaste perioden är i centrum av blickfånget: Amazons "Molnkrasch" och intrånget i PlayStation Network. Jag ser ett viktigt sammanhang, som är värt att betona på nytt: Hur abstrakt och storslaget molnet än är kullkastas inte faktum att det byggs upp av datacenter, som hanteras av människor! Nu till en genomgång.

Amazons "molnkrasch"

Bokhandlaren från Seattle har en stor mängd datacentra över hela planeten, indelade i regioner: US East (norra Virginia), US West (norra Kalifornien), EU (Irland), Asien (Singapore) och Asien (Tokyo). Varje specifikt datacenter inom en region är uppdelad i så kallade tillgänglighetszoner (availability zones) med målet att skapa flera operativa centra för bättre tillgänglighet. Amazon ger ett SLA med tillgängligheten 99.95% per region och ingen utfästelse per tillgänglighetszon. Arbetsgruppen Infrastruktur inom Cloud Sweden har belyst vikten av att mäta vilken tillgänglighet som är relevant i ett SLA.

Kraschen i fråga drabbade ett antal tillgänglighetszoner inom regionen US East den 21 april. Felet inträffade i tjänsten Elastic Load Balancing och orsakades mest troligt av ett konfigurationsfel. Konsekvensen av felet blev omfattande. Välkända tjänster som Reddit, Quora, Hootsuite, Foursquare, Heroku, Engine Yard och många fler drabbades. Påverkan av ett fel kan således bli enorma och drabba ofattbart många användare. Vilket leder mig in på konsekvensanalyser inför ett strategibeslut kring molnet.

Vill du följa statusen på Amazon Web Services finns den sammanställd på den här sidan.

Att "gå förbi" it-avdelningen-mentalitet duger inte


Jag stöter ofta på situationer hos mina klienter där avdelningen har gått förbi "it-bromsklossen" och sparat si och så mycket tid eller kostnad. Under mina 18 månader i egen regi som Cloud Advisor har jag konstant förespråkat en strategisk approach mot molnet. De kortsiktiga vinsterna för ett kostnadsställe inom en större organisation äts så gott som alltid upp av:


  • Behov att integrera molntjänsten med it-system innanför verksamhetens "väggar"
  • Flera separata avtal med en och samma leverantör
  • Informationsstädning som följer när olika versioner av viktig information återfinns i både interna system och i en/flera molntjänst(er)
Tar vi även riskerna för beroenden till tredjepartssystem utan noggrann mappning av risker, avtal, SLA, säkerhetsnyckeltal, uppföljning och liknande uppstår enorma verksamhetsrisker då en krasch inträffar. Har du ett stort beroende till en PaaS-tjänst (som Heroku i fallet med Amazon) för att leverera applikationer, som i sin tur är beroende av EC2, blir konsekvensen fatal om du inte har en noggrann analys till grund för beslutet. Sannolikt saknar du beredskapen och organisationen för att hantera avbrott på ett kostnadseffektivt och smart sätt. 

Genom att arbeta över gränserna skapas bästa möjliga förutsättningar för att dra nytta av molntjänster, samtidigt som man har beredskapen för att hantera det förutsedda: Det vill säga avbrotten som kommer att uppstå i något led. Här behövs it-experter, säkerhetsfolk, arkitekter, verksamhetsutvecklare, controllers och andra i samverkan.

Jaha, är molnet dött nu?

En strategisk insikt och handling är av vital betydelse och kräver mycket arbete. Molnet är stort och vinstmöjligheterna är många med en lyckad sourcingstrategi. Att det uppstår driftsstörningar är inget underligt och kommer att inträffa mer än en gång till. Att en driftstörning på något vis skulle diskvalificera molnet som möjliggörare tror jag inte på för ett ögonblick. 

PlayStation Network - hur kopplas det till molnet?

Jag har följt skeendet det senaste dygnet och inser att Sony behöver upprätta ett "Security Best Practices Statement" som den molnaktör de är med PlayStation Network:

  • Hur skyddar man informationen som strömmar mellan webbläsare och server?
  • Hur skyddar Sony känsligt data som lagras i deras nätverk?
  • Hur hanterar Sony identitetsuppgifter, betaluppgifter, användarkonton mellan olika tjänster och liknande?
  • Hur skyddar Sony applikationerna?
  • Vilket ansvar tar Sony när skada inträffar?
  • Vad anses vara tidsenlig information?
I det aktuella fallet har Sony brustit på många fronter. Informationen är bristfällig och har kommit alldeles för sent. Det har tagit en vecka för dem att gå ut med information om att deras kunder har drabbats. En vecka är ett par evigheter för angripare som vill skörda baserat på den omfattande information de har fått tillgång till. 


Här är lärdomen för molnköparen följande:

  • Formulera noggranna nyckeltal för säkerhet
  • Definiera vad en incident är för något och enas med leverantören om terminologin
  • Definiera ansvarsområden vid inträffad incident: Vem gör vad?
  • Definiera informationsansvar och tidsaspekter
Vill du ha mera information om säkerhetsaspekter och molntjänster rekommenderas Cloud Swedens säkerhetsgrupps riktlinjer.

tisdag 26 april 2011

Ord om förändring och kaos

There are always two parties,
the party of the Past and
the party of the Future,
The Establishment
and The Movement


-- Ralph Waldo Emerson --

För nyfikna som vill förstå molnlandskapet och skapa en säker väg in finns Cloud Sweden; ett oberoende kompetenscentrum "Powered by Dataföreningen".

fredag 15 april 2011

Molnidentiteter och framtiden efter molnet

Fick förmånen att hålla ett föredrag under Nordic Edge kunddag den 14 april 2011. Flera har efterfrågat min presentation i Powerpointformat och nu kan alla ni som har frågat hämta den hos SlideShare.

Eller titta direkt här hos mig på Cloudadvisor:




Nacka Strand bjöd på en fantastisk solnedgång igår kväll.