Cloud Computing Sven-Håkan Olsson © Definitivus AB. DataF_Borl_Cloud_v2.ppt © Definitivus AB. Enstaka bild får användas med angivande av källa

Figur lånad från Wikipedia Mindre kända i Sverige: Zoho, ordbehandling mm, Rackspace, hosting

Från servicebyrå till moln... 50-60-talen: De få beräkningsdatorerna delades av forskare, militärer och meteorologer. Delade på kostnaden (eller hade finansiär). 70-talet: ADB-servicebyråer blev populära. Stordatorer med bra möjlighet att skilja olika kunder åt i samma maskin. Betalning per CPU-sekund, minne, lagring etc. 80-talets början: Pendeln svänger tillbaks en del, minidatorn går fint att installera ”hemma” med ökad flexibilitet 80-talets slut: Pendeln svänger tillbaks ytterligare: Mer kapacitet på skrivbordet med PC. Helt och hållet lokalt som fristående PC eller senare LAN-beroende client/server. 90-talets mitt: Flerskiktad c/s tillåter att servrar nås via WAN – lättare att outsourca. 90-talets slut: Webben slår igenom för fullt. Servrar kan definitivt stå på distans, lättare att outsourca. ASP-begreppet myntades. 2000-talets mitt: SOA slår igenom så vi får lättare att dela upp applikationer och använda lego-klossar Vi börjar förstå gångbara affärsmodeller för Internet 2000-talets slut: De föregående erfarenheterna slås ihop till Cloud Computing

Partiell outsourcing (moln mm) IT-arkitekt A5 Partiell outsourcing (eller multisourccing), såsom: Cloud Computing (moln), SaaS (Software as a Service), ASP (Applications Service Provider) Olika sorters “gammal” outsourcing Kräver nästan alltid integration med Interna applikationer och register Andra outsourcade applikationer och register ...för man kan ju inte offra all användarvänlighet på Molnets altare – användarna ska inte behöva hålla ordning på tre separata kundregister till, eller så! Driver integrationsbehov. Många likheter med “vanlig” integration, men också olikheter. © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Nytt? Molnen är ingen ny STOR PRINCIP, det är fortfarande outsourcing, däremot är det några detaljer som skiljer sig jämfört med tidigare – och dessa detaljer får STOR INVERKAN: Dramatiskt mycket flexiblare kapacitetstillgång Flexibel prissättning och mycket lägre priströskel (i vissa fall 0 kr) Förlitande på att Internet duger för kommunikation mellan kund och outsourcingpartner – och Internet är billig kommunikation (För övrigt - om dagens fria Internet stryps, till exempel för mobila enheter som det talats om, så utmanas verkligen molnmöjligheten).

Olika kategorier av moln Molnförvirringen i datapressen och på Nätet är rätt stor! Det har gjorts kategoriseringar av många slag. Jag föreslår här en kategorisering baserad på: Vilken sorts it-resurs eller modul är det du som kund egentligen placerar i molnet? Resonemanget utvecklas mer i www.definitivus.se > inlägg trendspaning > Vad är vad uppe bland molnen

Egen- utvecklade kod-moduler. ”Eget” OS. Moln-lev typ 2 ”Eget” Win- dows. GUI- klient Teknik-ex: Citrix VMware - - - Internet - - - Teknik-ex: Salesforce Google Apps Exchange Sharepoint Office Live Moln-lev typ 5 Hel appl. Moln-lev typ 3 Kö. Lagring. Teknik-ex: Amazon AWS (samt delvis lev ur typ 4) Moln-lev typ 4 Egen- utvecklade kod-moduler. Teknik-ex: Google GAE MS Azure ”Eget” OS. Moln-lev typ 1 Teknik-ex: Amazon EC2 Xen VMware

Vad lägger kunden i molnet? Typ 1 Teknik-ex: Amazon EC2 Xen VMware Ett helt operativsystem På det får kunden själv (efter sina önskemål) anordna applikationsservervrar, databaser, applikationskod med mera Kallas ibland Infrastructure as a Service (IaaS) Ex: Just nu har vi ett projekt, Streamflow, där en demo-server nås på detta billiga sätt. Skarp server installeras däremot på traditionellt sätt i detta fall.

Vad lägger kunden i molnet? Typ 2 Teknik-ex: Citrix VMware En hel windowsapplikation läggs i molnservrarna Inklusive feta klienter som också exekverar ute i molnet Användargränsnsittet nås från lokal persondator (eller tunn klient) via Citrix, Terminal Server etc. Ibland startat ifrån webbsida. Även annat än Windows är förstås tänkbart, men det är ännu dominerande Ex: Har just avslutat outsourcing-upphandling åt ett försäkringsbolag där ena offerenten byggde helt på denna princip

Vad lägger kunden i molnet? Typ 3 Teknik-ex: Amazon AWS (samt delvis lev ur typ 4) Att kunna lagra data i moln, någon annan garanterar där backup, tillgänglighet etc Att kunna lagra data väg till något moln Applikationskod som driftas någonstans fjärrbeordrar lagringen “Hård koppling” ej bra vid distans-moln-SOA, så man vill gärna kommunicera asynkront. Då krävs kö som finns i vissa molnerbjudanden. Delmängd av det som ibland kallas Platform as a service (PaaS) Ex: Håller på med outsourcing-upphandling av HRM där t.ex. utdata till beslutsstödssystem går via kölösning.

Vad lägger kunden i molnet? Typ 4 Teknik-ex: Google GAE MS Azure Kundens egenutvecklade applikationskod installeras i applikationsserver som köps som tjänst i ett moln Allt från någon enstaka klass till en hel skräddarsydd applikation, kan i teorin läggas i molnet Delmängd av det som ibland kallas Platform as a service (PaaS) Ex: Nästan varenda Azure-demo som görs så visas detta. Google har det i drift sedan länge.

Vad lägger kunden i molnet? Typ 5 Teknik-ex: Salesforce Google Apps Exchange Sharepoint Office Live En färdig applikation som används i molnet utav många kunder samtidigt Inget installeras av kunden, men konfigurations-parametrar, integrationskod, anpassningskod, makron etc ska in Kallas Software as a service (SaaS) eller Application Server Provider (ASP) Ex: HRM-lösning under upphandling. Digital rekrytering. Skolval kör vissa kommuner i Norge.

Jämför med BPO – Business Process Outsourcing Komplett tjänsteköp, inkl personal Hel appl. Moln-lev typ 6 Ex: Postens hela löneadminist- ration lades ut, inkl personal

Stort integrations- behov Diverse interna system... Stort integrations- behov Internnät Internet Hel appl. ”Eget” Win- dows. ”Eget” OS. Egen- utvecklade kod-moduler. Kö. Lagring. Moln-lev typ 5 Moln-lev typ 4 Moln-lev typ 3 Moln-lev typ 2 Moln-lev typ 1

ETT exempel med moln i kombination med interndrift IT-arkitekt ETT exempel med moln i kombination med interndrift A5 I exemplet tar jag inte ”enkla” tjänster som Google maps etc, utan tunga verksamhets-applikationer, ”SOA-domäner” Användarens helhetsupplevelse ligger i engagemangsbilden som i sin tur beror av tre andra komponenter Engagemangsbild Leasing- konto Fond- konto Bank- konto Vanligen helt olika driftsstabilitet hos interna och externa sladdar – inkopplingen till Fondsystemet i exemplet är extern, kanske via Internet! Bokf- syst Övrigt driftas internt Köps t.ex. som moln-tjänst © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

ETT exempel på optimering av färskhet IT-arkitekt A5 Replikering till lokal db (via kö eller ESB) Engagemangsbild Online (Web Services) Leasing- konto Fond- konto Bank- konto Så här tänks tekniklösningarna vara optimerade efter verksamhetsbehov Online bara där det oundgängligen måste vara det Replikering för t.ex. sådana fondkurser som endast uppdateras dagligen Bokföringstransar är rättså tidsokänsliga Batch (ev kö) Bokf- syst © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Om jag nu vill köpa några nya kontosystem/tjänster? Är molntjänsterna du överväger (eller egendriftade applikationer) tillräckligt integrerbara? Har inte vareviga av dem ett eget kundregister t.ex? Har inte vareviga av dem en egen inloggningskatalog? Eller behov av Single SignOn (SSO)? Etc etc Antingen måste det gå att plugga in online-kommunikation till ditt favoriserade kundregister (men online kan ha nackdelar: prestanda/skalbarhet/tillförlitlighet) Eller också måste du kunna replikera data mellan dina olika kundregister (men replikering kan ha nackdelar: icke-färsk info, replikeringskrockar, buggig multimasterreplikering) Viktigt vara medveten och lägga detta i vågskålen vid beslut! Viktigt ställa tydliga krav på sådan integrerbarhet hos system/tjänst! Kolla respektive informationsmodell, är de kompatibla, går det att översätta? Är kund = kund?

ETT exempel på dubblerade kund-register IT-arkitekt A5 Plug-in för att ”externalisera” kund-reg. Dvs online mot huvud-kund-reg. ETT exempel på dubblerade kund-register Båda lösningarna har sina utmaningar Ambitiös SOA-domän-design kan göra att plug-in-varianten kan underlättas Replikering kan vara snabbt händelseorienterad eller utföras endast periodvis Replikeringar (ev multimaster) av kund-reg t.ex © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Allt-eller-inget-uppdatering IT-arkitekt Allt-eller-inget-uppdatering A5 Skulle behöva commit/ rollback, annars kan pengar verkligen försvinna vid systemnedgång mm! Överföring av pengar från bankkonto till leasingkonto ACID är en mardröm över långa avstånd, med flera parter, i olika teknikmiljöer Såsom tidigare berörts: ACID bryter mot SOA-guidelines som statelessness och loose coupling Vanliga Web Services har inte ACID Den komplexa standarden WS-Transaction är tveksam Det finns ett antal lösningar: Avstämningar, köer med ”end-to-end commit scope”, long-running-transactions, komb m god SOA-design... Leasing- konto Bank- konto © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson

Latensfördröjningar Var står egentligen servern i molnet, det har jag kanske ingen aning om? Australien, Taiwan, USA eller Finland...? Ljushastigheten ställer till problem. Används satelliter för kommunikationskedjan försvinner hela 0,5 s i ljushastighetslatens för fråga/svar. Även problem utan satellit ifall det är på andra sidan jordklotet. Även alla vackra skikt av ESB:er, nav, SQL, fasader, inkapslingar ger klart mätbar latens, ihopadderat. Alltså: Kan inte ha ”pratiga” applikationsprotokoll som vi kan på ett vanligt LAN i en serverhall! ”Coarse granular SOA”...

Enkelt scenario där en molntjänst i sin tur ska nå andra delar Många latens-fördröjningar uppstår! Latens = tidsglapp som går åt innan arbete påbörjas (eng. latency) Resonemanget utvecklas mer i www.definitivus.se > inlägg trendspaning > Tidsglapp hotar Molnet

Säkerhet Att allmänt sett lita på leverantören... men det har vi ju brukat gjort med dagens outsourcingpartners. Fast nu kanske de är på andra sidan jordklotet och jag har aldrig träffat säljaren personligen... Extra backup hemma? Deponering hos tredje part? Hantering av inloggningskatalog. Gärna Single SignOn! Kryptering av kommunikation (tunnel, https)

Molnformalia Får servern stå i vilket land som helst? Amerikanska regler? Kan man bli stämd på en halvmiljard i USA? Sämre lagstiftning för personlig integritet, PUL etc? Vad händer med datat vid ett nytt 11 sept (förhoppningsvis ej)? Vad händer vid beslag av typen Pirate Bay där andra, oskyldiga outsourcingkunder fick servrar konfiskerade flera veckor? Svensk förvaltningslag/EU-rätt? Offentlighetsprincip? Kontraktet är mycket viktigt! Men i vissa fall lovar ingen molnleverantör vissa ansvar. Det hjälper heller inte att kunna kräva skadestånd om jag redan gått i konkurs för att mitt data försvunnit eller applikationen varit nere i en vecka... Kunden måste själv hålla statistik på användning för att kunna attestera moln-fakturorna (GB, antal tick, antal användare, hur många beordrade GHz när etc). Kan ofta lösas i integrationsgränssnitten!

Nu har jag nämnt en del utmaningar – här är en sammanfattning av plusvärdena: Flexibel kapacitet T ex för nystartad webbshop som inte har en aning om belastningen, det kan vara 1 eller 100000 kunder per dag om de blir omskrivna Flexibel prissättning Ibland kan det t o m starta på 0 kr Ofta rörlig prissättning vilket ofta passar näringslivet (men inte offentlig sektor) En naturlig vidareutveckling av de tidigare outsourcingmodellerna (som f ö fortsätter finnas)

Trendspaningar, artiklar Kolla gärna in www.trendspaning.se där jag ungefär månatligen deltar kring tekniktrender etc På min enkla sajt www.definitivus.se finns också ett artikelarkiv på undersidan för trendspaning som successivt fylls på Där kommer det också bl.a. finnas material från mina föredrag på Cloud Symposium i Rotterdam 22-23/10 2009, samt från SOA Symposium i Amsterdam hösten 2008

Tack för mej! Sven-Håkan Olsson Definitivus AB IT-arkitekt A5 Tack för mej! Sven-Håkan Olsson Definitivus AB 0708 – 84 01 34 sven-hakan.olsson[hos]definitivus.se www.definitivus.se © 2009 Dataföreningen Kompetens / Sven-Håkan Olsson