260 likes | 421 Views
Cloud Computing. Sven-Håkan Olsson. 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:
E N D
Cloud Computing Sven-Håkan Olsson 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) • 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.
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
GUI-klient Helappl. ”Eget” Win-dows. Egen-utveckladekod-moduler. Kö. Lagring. Moln-lev typ5 Moln-lev typ4 Moln-lev typ3 Moln-lev typ2 Teknik-ex:SalesforceGoogle AppsExchangeSharepointOffice Live Teknik-ex:Google GAEMS Azure Teknik-ex:Amazon AWS(samt delvislev ur typ 4) Teknik-ex:CitrixVMware - - - Internet - - - ”Eget”OS. Moln-lev typ1 Teknik-ex:Amazon EC2XenVMware
Vad lägger kunden i molnet? Typ 1 Teknik-ex:Amazon EC2XenVMware • 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:CitrixVMware • 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 delvislev 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 GAEMS 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:SalesforceGoogle AppsExchangeSharepointOffice 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 OutsourcingKomplett tjänsteköp, inkl personal Helappl. Moln-lev typ6 Ex:Postens hela löneadminist-ration lades ut, inkl personal
Diverse interna system... Stort integrations- behov Internnät Internet Helappl. ”Eget” Win-dows. ”Eget”OS. Egen-utveckladekod-moduler. Kö. Lagring. Moln-lev typ5 Moln-lev typ4 Moln-lev typ3 Moln-lev typ2 Moln-lev typ1
ETT exempel med moln i kombination med interndrift • 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 Fond-konto Bank-konto Leasing-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
ETT exempel på optimering av färskhet Replikering till lokal db (via kö eller ESB) Engagemangsbild Online (Web Services) Fond-konto Bank-konto Leasing-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
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 Plug-in för att ”externalisera” kund-reg. Dvs online mot huvud-kund-reg. • 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
Allt-eller-inget-uppdatering 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... Bank-konto Leasing-konto
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 OlssonDefinitivus AB 0708 – 84 01 34sven-hakan.olsson[hos]definitivus.sewww.definitivus.se