Molntjänster välj rätt lösning. Del 2. Plattformar, tjänster och juridik. Sven-Håkan Olsson Styrelsemöte.se / Definitivus AB

Transkript

1 Molntjänster välj rätt lösning Plattformar, tjänster och juridik Del 2 Sven-Håkan Olsson Styrelsemöte.se / Definitivus AB DF_Cloud_kurs_okt16_dag2_v.pptx Sven-Håkan Olsson / Definitivus. Enstaka bilder får återges med angivande av källan.

2 Kursens ungefärliga upplägg Dag 1: Föregångarna Cloud computing, idén Juridik, avtal mm Säkerhet Fem moln-typer Några molnleverantörer Dag 2: Några molnleverantörer forts Appar och molnet Integration/SOA med molnen Praktikfall Molnstrategi Verksamhetsnytta Tekniknytta V e r t i k a l förståelse behövs 2

3 Nytt? Repetition är inlärningens moder 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 vanligen billig kommunikation 3

4 GUIklient Internet Repetition är inlärningens moder Eget OS. Docker IaaS Moln-lev typ 1 Ex: Amazon EC2 Google Comp Eng MS Azure VM Rackspace, IBM ipeer, Ballou Eget Windows... Moln-lev typ 2 Ex: Citrix,TermSrvr AWS Workspaces VDI VMware GNS.SE PaaS? IaaS? ipaas? Kö. Strukturerad lagring, integration. Moln-lev typ 3 Ex: Amazon AWS Google GAE MS Azure SQL-tjänster Dropbox BizTalk PaaS Egenutvecklade kodmoduler. Moln-lev typ 4 Ex: Google GAE MS Azure Heroku Force BizTalk Hel appl. SaaS Moln-lev typ 5 Ex: Salesforce Fortnox Google Apps Exchange Office365 4 Spotify

5 Repetition är inlärningens moder Viktigaste från förra gången: De olika molntyperna är mycket olika De olika molntyperna är komplexa att sätta sig in i, och välja lev för. Särskilt PaaS, myller av detaljer Även för SaaS, men det är å andra sidan alltid komplext att välja standardapplikation IaaS är mer likt vanlig driftning, fast flexiblare och ofta billigare. Integration med intern IT annan traditionell outsourcing och andra moln mycket viktig Inlåsningen kan vara avsevärd Särskilt i PaaS Även i SaaS, men det är å andra sidan alltid fallet vid standardapplikation 5

6 MOBILA APPAR OCH INTEGRATION

7 Mobila appar och integration Integration ofta bra! Kul Integration krävs! Isolerade öar av info: kass. Personlig effektivitet Sociala nätverk Affärsprocesser Molnet passar ofta bra tillsammans med appar: Samma flexibla kultur Lättare integrera Lättare anpassa till last

8 Utmaningen - varför är det så svårt? Ett axplock: Säkerhetsmodeller och multitasking i dagens bästsäljande läsplattor/smarttelefoner är mycket olika ipad/iphone har till exempel varit mycket restriktiv, vilket gör att integrationer kan behöva göras på olika sätt på olika plattformar Om appen bör fungera även vid dålig radiotäckning (3G/WiFi) så blir integrationen klart annorlunda än ren online, behövs offline mode Kvalitetsproblemen tillgänglighet/uptime, svarstider, säkerhet mm Att hantera sammansatta transaktioner, så att inte data kommer bort Framtidssäkring - dagens app-modell kontra traditionell webb kontra genomslag för html5?

9 Multitasking och parallellitet olika! Påverkar integrationsdesignen. Ex: ios (före v7) I stort sett insomnar app när den inte syns, för att spara ström Sju speciella undantag: Background audio - application continues to run in the background as long as it is playing audio or video content Voice over IP - application is suspended when a phone call is not in progress Background location - application is notified of location changes Push notifications (APNS, from 3:rd party servers) Local notifications - application schedules local notifications to be delivered at a predetermined time Task completion - application asks the system for extra time to complete a given task Fast app switching - application does not execute any code and may be removed from memory at any time Android I stort sett insomnar app när den inte syns Samsung etc kan visa flera appar samtidigt Men en app kan ha en service En service får exekvera vidare i bakgrunden Måste vara försiktig så inte bakgrundsjobbet förbrukar mycket radioeffekt, då försämras batteritiden WinRT Kan polla en server (medan ios behöver push från server) Push kan i sig kan vara bra, Android har fått C2DN I stort sett insomnar app när den inte syns Två appar kan synas samtidigt ( snapped ) Men en app kan ha background task Background task får exekvera vidare i bakgrunden. Antingen i appen eller i OS:et. WinRT begränsar resurser i background Kan polla en server (medan ios behöver push från server) Push kan i sig kan vara bra, WinRT har fått WNS (Vanliga Windows 8 kan förstås köra full multitask.)

10 Multitasking och parallellitet olika! Påverkar integrationsdesignen. Ex: ios (från v7, 2013) Ny, mer parallell multitasking, underlättar integrationer Men för att ändå försöka spara ström: Intelligent scheduling ios väcker olika appar olika, baserat på ditt användningsmönster över dagen Opportunistic updates ios väcker andra appar när du ändå har igång apparaten Adapts to network conditions ios väcker appar mer då det är bra radiosignal på 3/4G eller WiFi Coalesced updates ios väcker andra appar när någon app ändå kör radio Push triggers ios väcker appen så ev datahämtning görs direkt efter notifiering Ägare (mest av äldre iphones?) och kanske med olämpligt skrivna appar, rapporterar dock att batteriet håller kortare.

11 Multitasking och parallellitet olika! Påverkar integrationsdesignen. Ex: ios (från v8, 2014) Ny, ytterligare mer parallell multitasking, underlättar integrationer Många av de tidigare integrationsbekymren borta, men om din app behöver stödja tidigare versioner kanske ändå arkitekturen i alla fall måste bli komplex Som med v7, ägare (mest av äldre iphones?) och kanske med olämpligt skrivna appar, rapporterar dock att batteriet håller kortare.

12 App till app? App1 App2 Varje app får av säkerhetsskäl normalt bara leka inom sin egen sandlåda. Teknikdetaljerna för integration är snåriga, och olika i ios, Android och WinRT Dropbox etc För att ta sig runt sandlådan går många via extern molntjänst

13 App till interna system App Direkt integration kan ge mycket hög affärsnytta. Ärenden, order, kundinfo, lagersaldo Säkerhetsutmaningar vid dubbelriktad kommunikation till interna system. Ofta vill man gå via mellanserver i DMZ vilket adderar komplexitet. Ärendesystem, affärssystem etc Brandvägg

14 App till molntjänst till interna system App Ibland är en kombination app molntjänst internt system lämplig. T ex Styrelsemöte.se J Molntjänst Ärendesystem, affärssystem etc Om det passar, utåtriktad kommunikation är mycket säkrare och enklare att införa utan IT-avdelningen Brandvägg

15 Offline mode? + Ständigt online ger enkel app och färskt data! MEN 3/4G-täckningen ÄR inte 100% (ibland flyger man, åker i tunnlar, är i glesbygd, utlandet osv). Och 3/4G kostar. + Offline mode ökar användarnyttan MEN ökar också komplexiteten avsevärt! App Annat system Offline mode kräver databas och/eller kö i appen. Teknikval (SqLite..)? Synkning krävs före/efter offline. Synkprotokoll ganska komplexa och har ibland varit buggiga. Egenutveckla vs köpa? I enkla fall synkas hela filer, i andra fall enstaka dataposter (jmfr Evernote och Simplenote).

16 MOLNET KRÄVER INTEGRATION MÖNSTER

17 Diverse externa system... Diverse appar... Diverse interna system... Stort integrationsbehov Hur fixa brandvägg, DMZ, proxys? Eget OS. Eget Windows. Kö. Lagring. Egenutvecklade kodmoduler. Hel appl. Moln-lev typ 1 Moln-lev typ 2 Moln-lev typ 3 Moln-lev typ 4 Moln-lev typ 5 17

18 Data integration Det är information i sig som delas på eller utväxlas Substantiv (t ex kundpost ) Delad databas, filöverföring, kö... mm Ofta enkelt och beprövat Kanske inte tillräckligt bra Väldigt varierande egenskaper Kan vara en del av s k Master Data Management (se Wikipedia etc) 18

19 Functional integration Det är programlogik som delas på Verb (t ex beraekna_raenta för konto ) Ofta ger logiken till resultat ngn datalagring Beräkningsalgoritm, stored procedure, SOA-tjänst, COM-objekt, RMI-anrop... mm Ofta mer komplext Motsvarar högre behov Väldigt varierande egenskaper 19

20 Varje integration: har (minst) tre typer av egenskaper : = Någon faktiskt integration Olika informationsutbytesmönster Olika topologier för informationsutbyte Olika lagringsmönster 20

21 Informationsutbytesmönster Hur initiativ tas till informationsutbyte När i tiden initiativ respektive dataresultatet uppstår (nu, strax, månadsslut ) Vilken part som tar initiativet (den som har datat eller den som behöver datat eller den som ber om lagring/uppdatering). Ex: SOA-anrop Meddelandesändning Resource Oriented Architecture Månadsbatch Event Driven 21

22 Informationsutbytestopologier Vilka parter som kommunicerar Var parterna är Hur parterna relaterar till varann Vilka skikt som finns inom integrationen Vilka ansvarsområden som uppstår Speciella middlewarebehov? Ex: Alla-till-alla Nav Buss Nav tillsammans med nav (en stor org. har ofta flera) 22

23 Lagringsmönster Var information lagras Hur informationen är uppdelad, dubblerad etc Ex: Central lagring Replikerad Cachead Lagring för MDM (Master Data Management) 23

24 Så, varje integration har (minst) fyra helt olika typer av egenskaper : Olika informationsutbytesmönster Olika topologier för informationsutbyte Olika lagringsmönster Dataintegr. Funk.integr. 24

25 Hohpe har skrivit mycket om integrationsmönster. Ex: 25

26 Integrationsförväntningar Applikationer förväntas vara väl integrerade med varann numera (oavsett outsourcing eller moln). Engagemangsbild T ex Engagemangsbild för en kunds alla förhållanden hos leverantören front-end-integrering. Frontendintegr Skr.sytt. syst Leasingkonto Std.syst Fondkonto Std.syst Bankkonto Eller integrerad supply chain management eller att förse bokföringen med info back-end-integrering. Mer och mer köps standardapplikationer som måste integreras med varandra Backendintegr Bokfsyst S k stuprör 26

27 Typiska egenskaper, front-end integration/soa Bredvidläsning Ofta behövs purfärsk info online hela vägen Ibland duger halvfärsk info async/batch/replikering Client/server: svarstid? stabilitet? trådning? Webb: som C/S? frames? portlet/webpart? master? inloggning? Bakomliggande arkitektur SOA/WS: felhantering till UI räcker? EAI/ESB: prestanda, latenstid? overkill, krångligt, dyrt? 27

28 Typiska egenskaper, back-end integration/soa Bredvidläsning Oftast inget behov av purfärsk info async/ batch/ replikering Fil: övervakning? Enkel integr.prod t ex kö? Bakomliggande arkitektur SOA/WS: övervakning? kö? EAI/ESB: stor produkt? formatkonvertering? kontroll? 28

29 Användare/inloggning Väldigt vanligt att varje moln själv vill vara master för användarinfo. SaaS-affärssystem har ofta egna tabeller för detta Iaas och Paas kan ha möjlighet att integrera med AD etc. Annan variant är Single Sign On (SSO) med federering, SAML2 etc SAML2 verkar slå igenom men är tyvärr väldigt komplicerat Inte så bra stöd hos Microsoft on-premise, bättre i Azure... Exempel: Mindre komplex token-utställare baserad på AD Java Web Token (JWT) mycket behändigare än SAML2? Köra AD i molnet? Se t ex / 29

30 Referensarkitektur Referensarkitektur verkar betyda ganska olika saker för olika personer när man söker hittar man ofta varierande metanivåer ;) dvs är det en bild av en arkitektur i sig, eller var en arkitektur passar in och hur den ska förvaltas, mm? Hur skapar man mer tillämpade referensarkitekturer för faktiska projekt? CORA verkar vara en ovanligt fullödig ( icke meta ) referensarkitektur att utgå från: Var uppstår molnfrågor i en sådan modell? 30

31 Andra parter H2A (Human-to-Application) B2B (Business-to-Business) 31

32 Främst SaaS, PaaS, IaaS Andra parter Främst PaaS, IaaS? Främst IaaS, ipaas, +kö Främst PaaS, IaaS Främst SaaS, PaaS, IaaS Här uppstår potentiellt molnkommunikation, måste optimeras Båda dessa områden extra viktiga vid moln! 32

33 Logga! Kommer alltid att behövas för att kunna göra detektivarbete Någon bugg kommer det alltid att vara, du behöver loggen för att försvara dig kunna fördela ansvar vid fel! Varje nod behöver logga både in/ut, särskilt då du kommunicerar med molnet och andra externa parter Två sorters logg behövs vanligen: In/ut-meddelandeinnehåll Kan även ev. vara bas för händelsestyrd arkitektur, krash-restore, uppsättning av testsystem... Logga vad programmet beslutar sig för Verbosity bör gå att styra med konfigurering Loggkomponenter får inte ha komplex arkitektur i sig för då går det inte att logga när det blir fel där, moment-22. Gärna enkla sekvensiellt filer Analys kan ev. göras genom att i efterhand ladda in filerna i SQL-db Loggning kan också ge debiteringsunderlag eller möjlighet att attestera fakturor... 33

34 Exponentiell spaghetti Antalet systemsamband ökar exponentiellt med antalet integrerade applikationer ( Metcalfe's law ) Risk för röra, trögrörlighet och kostnader i applikationsförvaltning och drift! Begreppet Inter-application spaghetti myntades av Gartner på 90-talet SOA/moln-spaghetti är också spaghetti! Men är det alltid ett problem? Vi får se... 34

35 Topologier: Nav, hub, ESB (Enterprise Service Bus) Appl 1 Appl 4 = integr-logik, central och inom varje appl. Appl 2 Appl 3 Topologin för många avancerade integrationsprodukter Minskar risken för inter-application spaghetti Potential för kontrollerad alla-till-alla-kommunikation Risk för duplicerad affärslogik i routing-logiken Riskerar bli single-point-of-failure Viktigt att info-modellera objekt-modell. Läs t ex om OAGIS Erbjuder vanligen info-formatkonvertering Ex: BizTalk, IBM, BEA (Oracle), WebMethods (Software AG)... Men hur passar nav i molnet? ipaas slår igenom? 35

36 Anropsmässig trelagers-stack Kommunicerande applikation Integrationsteknik Överenskommelser / kontrakt Kommunicerande applikation Integrationsteknik Web Services, MQ etc i enkelt fall Jämför med den mera nertill detaljerade sjulagers OSIstacken Ren datakom Sladd, radio Ren datakom TCP/IP dominant idag 36

37 Definitioner i femlagers-stack Processdefinition Processdefinition Visio-fil eller BPMN, BPEL... Svårast Svårt Semantikdefinition Syntaxdefinition Välj integrationsteknik Överenskommelser / kontrakt Semantikdefinition Syntaxdefinition Välj integrationsteknik Word-dokument RDF/OWL? XML-schema t ex Web Services, MQ etc i enkelt fall Ren datakom Ren datakom TCP/IP dominant idag Sladd, radio 37

38 Zoom in Juridisk kontext Säkerhetskontext Processkontext Färskhetsbehov Semantikdefinition Formell Kostnad Service Level Konvention Syntaxdefinition Grunddatakomm. Överenskommelser / avtal / kontrakt Kostnad Juridisk kontext Processkontext Syntaxdefinition Grunddatakomm. Säkerhetskontext Färskhetsbehov Semantikdefinition Formell Konvention Service Level Applikation A Applikation B

39 Definitioner i femlagers-stack Processdefinition Processdefinition Visio-fil eller BPEL etc Svårast Svårt Semantikdefinition Syntaxdefinition Välj integrationsteknik Överenskommelser Semantikdefinition Syntaxdefinition Välj integrationsteknik Word-dokument eller RDF etc XML-schema t ex MQ i enkelt fall t ex Ren datakom Ren datakom TCP/IP dominant idag Sladd, radio 39

40 SOA EAI ESB, min tolkning... SOA-tyngdpunkt: Anrop av tjänster SOA EAI ETL BI EAI/ETL/BItyngdpunkt: Flöden av data ESB...en hel del överlapp EAI: Enterprise Application Integration ETL: Extract-Transform-Load BI: Business Intelligence, data warehouse ESB-tyngdpunkt: Anrop samt anropsinfrastruktur (samt flöden) 40

41 Web Services vs SOA EAI ESB Bredvidläsning WS helt centrala för interoperabla SOA-anrop Många gånger duger WS utan annan infrastruktur för att skapa SOA Om ESB (eller modern EAI) används som SOA-infrastruktur sker oftast anrop med WS SOA EAI ETL BI Ökande användning av WS för att hälla in/ut data WS helt centrala för interoperabla ESB-anrop ESB Web Services EAI = Enterpr. Application Integr, ESB = Enterpr. Service Bus 41

42 Ett antal nav/buss-lösningar har sålts in på: Du får kontroll + Bra att kunna centralisera verksamhetslogik, ge överblick, mäta... - Men VEM ska förvalta all logiken inne i navet/ bussen? - Ibland svårt att delegera konfigurationsrättigheter till de rättmätiga ägarna av verksamhetslogiken - Även om det går att delegera så har alla nav/busslösningar ordentligt höga inlärningströsklar. - Klickar man fel kan hela företaget stanna om man lyckats införa nav/buss brett. Alltså en operatörsmässig single-point-of-failure även om man clustrat och löst maskinmässig fault-tolerance - Man har tyvärr ofta erfarit en propp inom central förvaltning av verksamhetslogik inne i nav/buss, så att verksamhetsförändringar försenats Verksamhetslogikens troliga ägare, domänvist 42

43 Black box Bredvidläsning Inkapsling är en bra princip inom OO Tanken har förstås funnits länge, metaforen gissar jag kommer från elektronikindustrin, t ex en elektronisk tändning sköts av en svart låda med några anslutningar men där ingen ska behöva bry sid om hur innanmätet är konstruerat, bara en spec uppfylls Black box-tänket minskar antalet saker man måste bli överens om, det räcker att speca ytan/gränssnittet/funktionen agreement is expensive En black box ska vara mycket självständig, innebär bl a att alla indata måste valideras strikt SOA (och EAI/ESB) är starkt influerat av black box-principen Svartlådan är förstås anroparens vy, tjänsteleverantören jobbar inuti svartlådan, förhoppningsvis i gott arbetsljus! 43

44 Grey box? Bredvidläsning Black box-idén kanske inte håller helt? Säg att man ska upphandla en black box, sen ska den ju trots allt driftas, personalen måste kunna hantera appservrar som krävs, databaser, middleware, OS Man kanske också vill använda redan betalda licenser för sådan plattforms-mjukvara I praktiken innebär det att man vill speca vissa saker om innehållet i en black box också, därmed uttrycket grey box (borde förstås hetat semitransparent black box...) En annan situation kan vara att man kan vilja inspektera programkoden inne i en black box för att lättare förstå vad den gör i ett udda läge (svårt speca allt hos gränssnittet) Inspektering kan också snabbt behövas ifall t ex ett nytt säkerhetshot uppstått, eller då leverantören som ansvarar för en black box inte hinner med supporten eller har lagt ner 44

45 Kontrakt, överenskommelse Kontrakt, t ex: Process A Process B - Info-innehåll - Driftkontrakt, SLA - Felavhjälpning - Vidareutveckling - Säkerhet - Pris, vite Smörgåsbord av tjänster Black box anroparen ska inte behöva bry sig om innanmätet i boxen, bara vad den uträttar - kontraktet 45

46 Information centric or process centric? Stora debatter genom åren talet var starkt information centric 90-talet starkt process centric (och objektorienterat) 00-talet viss balansering (komponenter som bas för tjänster...)!? 46

47 Information centric Stark betoning på de datatermer som verksamheten hanterar Vikt vid modellering av begrepp, semantik Ofta vill man överbrygga en hel verksamhet med en genomgripande modell + Ordning och reda, alla vet vad som gäller - Centralistiskt, kommer kanske inte i mål. Oflexibelt vid omvälvningar såsom fusioner, dotterbolagsköp etc Zachman, Texas Information Engineering... Nytändning i och med REST-vågen 47

48 Process centric och OO Betoning på processer, use cases Dessa leder till objekt (logik + state) Objekt behöver datalagring (OO-db, SQL med klassisk modell eller köttfärsmodell, ORverktyg) Datalagringen har inget egenvärde + Processvyn är givande. Bra att termer måste motiveras - Processer kommer och går, inneboende data består... OO-metoderna, OR-verktygen... 48

49 Några verksamhets-scenarios En prisfråga mot en leverantör Frågan körs mot en lokal (replikerad) kopia av prisregistret En lagersaldofråga mot en leverantör Frågan körs online mot leverantören En faktura går till en kund Fakturan överförs via en kö på någon timme till kunden Behoven ska styra temporal kvalitet (dvs färskhet )! 49

50 Andra färskhetsbegrepp Det föreslagna datafärskhetsbegreppet är relativt gradvis, men utfaller ofta i de tre färskhetsgraderna som exemplifierades i fg bild Master Data Management-ansatsen (MDM): Master Data (kund, produkt etc lägre förändringstakt) Händelsedata (kundorder, bemanning etc snabbare förändringstakt) Helland & Box: Reference data (read-only) Activity-data & Per-User Data (state) Ett annat vanligt motsatspar ur färskhetshänseende som en del infomodellerare hellre använder: Referensdata Instansdata 50

51 Varför ändå inte alltid köra online/synkront, då är man ju säker på tillräcklig färskhet? Mikrosekund-färskt data överallt är väl trevligt som idé... Men online riskerar ge Sämre stabilitet (se nästa sida) Längre svarstider Sämre skalbarhet Högre kostnader Särskilt via medium som Internet eller stort WAN...och ofta behöver inte allt vara så extremt färskt, 1-10 min fördröjning eller mer kan alltså vara helt OK beroende på verksamhetskraven - således optimera med avseende på färskhetskrav! 51

52 Sannolikhet för stabilitet Om alla tjänsterna behövs, synkront... Tjänst Tjänst Tjänst Tjänst Tjänst En utmaning att få hög uptime för ett sammansatt system med hårda beroenden (och/eller synkron karaktär) Obeveklig matte: 10 bakomliggande system, 99% uptime vardera. Multiplicera sannolikheterna; 0,99*0,99*0,99*0,99*0,99*0,99*0,99*0,99*0,99*0,99 = 0,99 10 = 0,90 endast, om de 10 är oberoende, kass! Två varianter: både m a p oplanerade och planerade avbrott Asynkron grundkaraktär kan möjliggöra att presentation görs allteftersom, jmfr Web Befordrar även upplevd prestanda, anrop kan ofta ske parallellt i tiden Även andra nackdelar med hårda kopplingar. Jmf SOA-trenden med lösare kopplingar (Även 0,995^10= 0,95 är kass, och 0,999^10= 0,99 är ganska dåligt) 52

53 Sannolikhet för stabilitet Om alla tjänsterna behövs, synkront... Tjänst Tjänst Tjänst Tjänst Tjänst Föregående sida exemplifierade ett anropsberoende till flera tjänster Samma stabilitetsproblem uppkommer vid SKIKT-SJUKA, att man har alldeles får många skikt av olika slag, vardera med sin egen uptime-sannolikhet som måste multipliceras... Skikt 1 Skikt 2 Skikt 3 Skikt 10 53

54 Hur höjer man uptime? Om färskhetskraven alltså inte är jättehöga kan data replikeras/cachas nära och onlineberoendena till många system minskas (se bild längre fram) Olika cluster- och failover-lösningar. Komplicerade, dyra. Risk för felkonfigurering så de ändå inte funkar när de ska träda in. Molnleverantören kan ge extra möjligheter till fail-over, men kan också stanna helt Presentation allteftersom Asynkron grundkaraktär kan möjliggöra att presentation görs allteftersom, jmfr Web (bilder, frames) Avancerad fet klient med trådning etc Befordrar även upplevd prestanda, anrop kan ofta ske parallellt i tiden 54

55 Optimering kostnad/stabilitet Bredvidläsning Åstadkommen stabilitet Högsta stabilitet För liten teknikhjälp till stabiliteten Risk för operatörsmissgrepp pga teknisk komplexitet eller att samverkan mellan olika teknik blir för komplex Optimalt band m.a.p. alla tre dimensionerna Tekniska åtgärder för stabilitet Kostnad Resonemanget utvecklas mer i > inlägg trendspaning > När hög tillgänglighet inte blir hög Tekniska åtgärder för stabilitet Kostnaden ökar kraftigt vid avancerad teknik som syftar till stabilitet 55

56 Repetition är inlärningens moder Skalbarhet vid online/sync sämre än async All last fokuseras ofta ner i en central databasserver Allmänt hög last resp dyr server. Dessutom extra risk för låsningar vid hög last Databasservrar är fortfarande svåra o dyra att klustra för lastdelning Vanligt scenario: Webb-server cluster App-server cluster Databasserver (ej cluster) 56

57 Ytterligare sätt att höja prestanda OM det är så att läsningar är det dominerande: Cache, cache, cache Öka databas-cachear RAM-databas? NoSQL? Egenskriven cache i appserver (OBS kostar att programmera/underhålla, jobbig att testa) Använd ev inbyggda appserver- och webserver-cachear (äv separata) Webbsidorna måste ha korrekt http-inställningar så cachning sker i webbläsarna (OBS färskhet kan stå mot prestanda) Om REST används, var noggrann med http-inställningar och URI-design Replikering till lagring i molnwebbservern Molnwebbservrar i varje världsdel? CDN Content Delivery Network Hierarkiskt: Edge Servers i kanten av Internet Akamai, Azure, Amazon Kräver ofta CDN-anpassad html P2P: BitTorrent, Akamai-variant, Spotify-stilen ställer speciella klientkrav 57

58 Kortpraktikfall En bensinmack-kedja för några år sen Kör normalt online mot server-central för kontokorts-kontroll och debitering mm (request/response pseudo-synkront) Ifall centralen ger timeout eller kommunikationen faller går macken över i offline mode: Macken funkar fortfarande Verksamhetsreglerna ändras: Man kan bara tanka för några hundra kr balanserar risken Alla transaktioner köas upp i macken och överförs asynkront snyggt och prydligt när man glider över i on-line mode igen Klart minskade teknikrisker, men å andra sidor kostar det mer att systemutveckla två moder. Ska balanseras mot failover- kommunikation och failover-cluster centralt... 58

59 Lite om granularitet Fine grained fin granularitet finkornigt symaskins-api chatty pratigt API : Många, små anrop Coarse grained grov granularitet grovkornigt chunky : Större, men färre anrop 59

60 Granularitet för SOA Bredvidläsning Ej SOA SOA Anrop från hängrännor o andra apps Rik klient Rik klient? Rik klient SOA Server Server Server Pratigt c/sprotokoll kan vara OK Mindre pratigt protokoll behövs i SOA-fallet, lösare kopplat etc Kanske behöver pratigt c/s-protokoll men ej bra för tjänsteanrop från andra apps! C/s-protokoll må vara WS men då ej 60 SOA...

61 Rätt arkitektur för rätt sak!? Bredvidläsning C/s-stilen Får vara hårt kopplat Får vara fingranulärt ACID OO ofta Klen interoperabilitet Rik klient Anrop från hängrännor o andra apps Vanlig OOåteranvändning! Verkshobjekt 1 SOA-skikt Verkshobjekt 2... Verkshobjekt n Applikationens server-skikt SOA-stilen Ska vara löst kopplat Ska vara grovgranulärt Ej ACID Ej OO Stark interoperabilitet 61

62 Går detta bra? Symaskinsinterface riskfyllda vad gäller latenstid Mycket väldesignad asynkron användning kan gå bra, jmfr Googles successiva svar Kan inte ha OOanrop, snarare SOAP eller REST. Rik klient I molnet Anrop från hängrännor o andra apps Bredvidläsning SOA-skikt SOA-stilen Torde gå bra mot molnet! Om detta nu ligger i molnet Verkshobjekt 1 Verkshobjekt 2... Verkshobjekt n Applikationens server-skikt 62

63 Composite services (komponerade/sammansatta legoklossar)? Anrop från hängrännor o andra apps Bredvidläsning Dettta kan vara OK komponering av sammansatt (composite) tjänst när man behöver ACID! = OO-återanvändning. Rik klient Verkshobjekt 1 SOA-skikt Verkshobjekt 2... Verkshobjekt n Composite service Detta kan vara OK komponering vid: Read-only Eller när det är OK att uppdateringar får gå fel Eller när man tar hand om felen med långa affärstransaktioner e dyl = SOA-återanvändning. 63

64 XML och sammansatt data Bredvidläsning Rik klient Server Pratigt c/sprotokoll kan vara OK Rik klient? Server Mindre pratigt protokoll behövs i SOA-fallet En möjlighet att kunna få större granularitet är att XML lätt lånar sig till att blanda olika sorters data på ett hierarkiskt sätt något som är mycket svårt i ett vanligt resultat-set;. Kund-id. Fakturahuvud. Fakturarad. Fakturarad. Fakturarad 64

65 Fingranulärt vs redundant data vs grovgranulärt Bredvidläsning SQL med en massa småanrop: Läs Kund Läs Fakturahuvud för kund-id:t Läs Fakturarader för faktura-id:t chatty, fingranulärt, problem med latenstider mm SQL med ett anrop och join: Läs Fakturarader med Fakturahuvud med Kund ger kund1data fakturahuvud100data fakturarad1data kund1data fakturahuvud100data fakturarad2data kund1data fakturahuvud100data fakturarad3data kund1data fakturahuvud100data fakturarad4data kund1data fakturahuvud100data fakturarad5data dvs massor av upprepat, redundant data XML för SOA-tjänst: Kund1. Fakturahuvud100. Fakturarad1. Fakturarad2. Fakturarad3. Fakturarad4. Fakturarad5 grovgranulärt, högre nivå, ingen redundans 65

66 Fasad och grovgranulärt Bredvidläsning Särskilt viktigt om du skapar publika Hittat på nätet: molntjänster! Façade: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use Fasad kan tolkas på (minst) två sätt, enligt min åsikt ett bra och ett dåligt... Ej grovgranulärt, ej SOA, ej lätthittat, kontraktet betyder noll L o-bra Anrops-ex: skicka_till_movex( Kund,param1,param2) skicka_till_movex( Fakt_hvd,param3) skicka_till_movex( Fakt_rad,param1) skicka_till_movex( Fakt_rad,param1) Grovgranulärt, SOA, lätthittat J bra Anrops-ex: skicka_fakt( param1,param2,param3) Liten tjänst Kund skicka_till_movex Tunnel-fasad Liten tjänst Fakt_rad Liten tjänst Kund skicka_fakt Komposit-fasad Liten tjänst Fakt_rad...betänk ACIDfrågan... Liten tjänst Fakt_hvd Liten tjänst Fakt_hvd 66

67 AJAX-trenden Bredvidläsning Webbläsare Webbserver Webbläsare & AJAX-kod Webbserver? AJAX innebär bl a att använda omfattande Javascript-kod i webbläsaren för att göra klienten rikare. T ex validering för varje fält ger mycket pratigare protokoll (om än med högre funktionalitet) SOAservrar Web vanligen mindre pratigt SOAservrar AJAX vanligen mer pratigt Riskfyllt ifall denna pratighet fortplantar sig till bakomliggande SOA-skikt AJAX = Asynchronous Java script And XML 67

68 Vad menas nu med löst kopplad? Bredvidläsning Olika oberoende-aspekter: Sessionslöst/stateless *) Varje anrop/ meddelande är självständigt En reaktion mot krånglig distributed object life-cycle management inom DCOM/ Corba/Java Tydligt definierade ansvarsgränser ( kontrakt ) och maskingränssnitt (syntax, semantik, process...) Vanligen inte ha ACID 2PC, skulle ge för hårda kopplingar mm agreement is expensive... Löst kopplat i kalendertiden, smörgåsbordstanken, composing an application, konfigurera den långt efter stora programmeringsjobbet (testbarhet?) Interoperabilitiet färre teknikdetaljer måste vara exakt samma i bägge ändar Ev kunna ha extremely late binding t ex via UDDI dock inte alltid lämpligt. (En del menar att löst kopplat alltid innebär asynkront)...allt detta kan ge större flexibilitet, framtidssäkring och återanvändning! Viktigt i intern SOA, ännu viktigare vid moln! *) Säkerhetskontext må få vara sessionsorienterad 68

69 Andra sorters lös koppling också Bredvidläsning Lös koppling att sent i tiden i ett utvecklingsprojekt kunna ändra baserat på verksamhetskrav (samt ändra fortlöpande) Lös koppling för flexibel driftkonfigurering (inga fysiska adresser angivna, gå via proxy, extremely late binding etc) Lös koppling för stabil och skalbar exekvering (stateless, ingen ACID mm enl föregående bilder) 69

70 ACID tekniska transaktioner Atomicity, Consistency, Independency, Durability Kallas även atomära transaktioner, before-image-journaling eller allteller-ingen-uppdatering. Ibland behövs two-phase-commit (2PC), 3 eller fler parter Uppdateringar garanteras att inte kunna bli halva Självklart för relationsdatabasuppdateringar men inte för systemintegration/soa Utan ACID risk att t ex en försäljning registreras i handelssystemet men tappas bort i ekonomisystemet Anropande A sammansatt tjänst Egentligen borde man väl alltid sträva mot ACID, men... 2PC Anropsgränssnitt Kvalitetsmönster ACID Tjänst B Tjänst C 70

71 ...men ACID för integration kan ge problem Inkompatibla teknikmiljöer (trots XA-initiativet t ex) En del systemintegrationsprodukter stöder inte alls ACID Ger hårda sw-beroenden (versionsbyten, leverantörsinlåsning etc) Risk får dålig uptime Kan bli riktigt långsamt (faktor 10 för 2PC kan vara realistiskt) Dålig skalbarhet för 2PC pga långa databasinterna lås vilket ger deadlock-timeout Alltför hård koppling Anropande A X SOA-snitt. Vanligen EJ lämpligt med ACID och 2PC här! Tjänst B Tjänst C 71

72 Lösning 1: ACID under ytan! Modellera tjänsterna så att inte flera skulle behövt anropas inom en uppdaterande ACID-transaktion (om nu detta är möjligt) Ha gärna ACID under ytan, inom tjänsten Tidsmönster Nu Anropande A Ex 1: Modellera Kontoöverföring (inte Kontotrans och varsitt anrop med plus- och minusbelopp) Ex 2: Modellera fakturahuvud och fakturarader tillsammans i ett anrop Alltså motiv för TVÅ saker: Grov granularitet på tjänstegränssnitt (dvs större-men-färre anrop) Grov granularitet på tjänsterna (dvs stora SOA-domäner ) Tjänst B ACID under ytan SOA-snitt Ej ACID här Men återanvändning etc är istället lättare med liten granularitet Microservices, immutable services etc ger istället små tjänster... så denna fråga måste balanseras och optimeras! ACID 72

73 Lösning 1a: ACID under ytan + async Liknar Lösning 1, fast för att slippa så hård koppling mellan två lagringar görs den andra lagringen via äkta leveransskyddad asynkron kö Kallas ibland deferred processing senarelagd bearbetning B måste ta ansvar även för C Bara ok ifall färskhetskraven är lägre i C Tyvärr behövs vanligen även felflöde tillbaks från C (logiska och tekniska fel) Tidsmönster Strax + Nu Annan SOA-domän Tjänst C Modul för deferred processing Kö Anropande A Tjänst B ACID under ytan SOA-snitt Ej ACID här 73 End-to-end async ACID (se nästa sida)

74 Olika ACID-exempel för integration (i detta exempel: avisering till annat system) Pgm C Allt-eller-inget Pgm A Write 1... Write 2 Allt-eller-inget Pgm B Write 1... Write 2 Allt-eller-inget Allt-eller-inget Write 1... Write 2 Pgm D Read & delete... Write Allt-eller-inget Enkel 2PC-variant, synkont Asynk med äkta leveransskydd 74

75 Behövs ofta asynkront returflöde Pgm C Allt-eller-inget Allt-eller-inget Write 1... Write 2 Pgm D Read & delete... Write Allt-eller-inget Både för tekniska och logiska undantag Och se upp för giftpiller som kan ge kraschloop, finns ofta felkö för detta Normalflöde 75 Returflöde

76 Om ACID finns så borde väl BASE finnas bas/syra J BASE Basically Available - Soft-state - Eventual consistency Teoribygge kring principen att uppdatering kan tillåtas få ske strax istället för nu Föregående bild 1a:s deferred processing är ett exempel på BASE-principen Extra populärt i REST-världen och när man behöver massiv skalbarhet och hög tillgänglighet (ofta förespråkas då RSS etc. eller retry-loopar för stabilitet ) Vanligt i molnlagring med eventual consistency! Se exempelvis Tidsmönster Strax Kvalitetsmönster BASE 76

77 Lösning 1b: BASE i Composite Service En mer generaliserad variant av 1a, där B och C ligger på samma nivå Bara ok ifall färskhetskraven är lägre i både B och C. BASE deferred update Obs, ifall A också har en databas så måste man lösa även den ACID/ BASE-frågan Anropande A Sammansatt Tjänst BC SOA-snitt Ej ACID här ACID mot två köer oftast ok ACID Köer Alternativ till säker kö kan vara avancerad omsändningshantering + dublettkontroll (idempotency) många RESTförespråkare gillar detta 77 End-to-end ACID Tjänst B Uppdat strax Tjänst C Uppdat strax

78 Lösning 1b: BASE i Composite Service Eller RSS/Atom som kö och då kanske endast EN feed för att slippa behov av ACID i skrivningen! Anropande A SOA-snitt Ej ACID här Sammansatt Tjänst BC ACID mot två köer oftast ok RSS/Atom End-to-end ACID Tjänst B Uppdat strax Tjänst C Uppdat strax 78

79 Lösning 1c: Vid read-only, sammansätt utan ACID-behov Anropare 1 Anropare 2 WS WS SOA-snitt Sammansatt tjänst A Se upp med sammansatta tjänster (composite services), det ser ju så förledande snyggt ut i Powerpoint fast kan ge problem. WS Tjänst X WS wrap Implem. av X Tjänst Y WS wrap Implem. av Y Tjänst Z Men read-only är OK! 79

80 Lösning 1d: Fuska, sammansätt med ACID i en teknik?? Anropare 1 Anropare 2 WS WS SOA-snitt Sammansatt tjänst A Ej ACID OO-anrop går ej bra till molnet Funkar endast bra ifall samma programmeringsmiljö i A, X, och Y! ACID OO-anrop m uppdatering Tjänst X WS wrap Implem. av X Tjänst Y WS wrap Implem. av Y Tjänst Z Överväg noga kan ge alltför hård koppling L Samma db eller 2PC L 80

81 Lösning 2: Avstämningar! Välfungerande 60-talslösning Skapa buntsummor, dagssummor e dyl i bägge ändar, skicka dessa en annan kommunikationsväg Manuell koll eller automatiskt larm Korrigera manuellt eller automatiskt Manuell korrigering kan mycket väl vara optimalt! Logga! Behövs för att kunna göra detektivarbete. =? Sums for reconciliation Avstämning = eng. reconciliation 81

82 Lösning 3: Visa upp uppdateringsfelen i användargränsnsittet!? Ifall det är ett användargränssnitt ovanpå tjänsteanropen går det ibland att låta felsituationen och efterföljande åtgärdsbeslut direkt överlämnas till användaren Kräver god felupptäckt Kräver användarvänlig dialogdesign Kräver tillräckligt kunniga användare Funkar inte bra server-till-server Logga! Behövs för att kunna göra detektivarbete, kunna fördela ansvar vid fel! In/ut-meddelandeloggning + logga vad programmet beslutar sig för 82

83 Lösning 4: Optimerad sekvens ( fail early ) + felupptäckt! Optimerad variant av sista utvägen : 1. Anropa uppdaterande tjänst först som har sämst sannolikhet att fungera, B i figuren 2. Ifall det skulle bli fel i B, ha begränsad retry-loop i A eller låt användaren göra retry. Gör ej C-anrop. 3. Tjänst B måste klara dubletteliminering (s k idempotency)! 4. Anropa sedan C och hoppas att den inte kraschar (dock låg sannolikhet) 5. Ifall det ändå blir fel, larma till lång verksamhetstransaktion för kompensering etc. instabilare nät+tjänst t ex till molnet Anropande A Tjänst B (uppdat) Ej ACID Tjänst C (uppdat) stabil 83

84 Lösning 5: Kontrollerad inkonsistens Tillåt kontrollerad inkonsistens Modellera så att relaterade objekt kan få vara inkonsistenta innan de verkligen behövs T.ex. tillåt fakturarader utan fakturahuvud temporärt (ifall separat fakturahuvudskrivning skulle misslyckas) Kräver felupptäckt och rättningsåtgärd innan fakturan kan sändas ut Dyr och komplex undantagshantering Inte ovanlig i praktiska fall, t ex bokföring: Avstämningar före bokslut 84

85 Lösning 6: Saga-mönstret Tillhör den modernare tidens mönster... Ex på sammansatt trans: 1. Hyrbilsbokning 2. Hotellbokning på annan sajt 3. Flygbokning på tredje sajt NEEJ, fanns ingen flight, måste backa de två tidigare bokningarna... Hade varit himla bra med 2PC och commit-rollback, men inte trovärdigt Routing slip Saga-principer, t ex: Steg som är enklast att backa/kompensera läggs först I varje steg som lyckas adderas en anteckning i routing slip I anteckningen skall också stå var/hur kompensationsåtgärd kan nås Om ett steg misslyckas, går man baklänges i kedjan i routing slip och utför alla kompenseringarna Nackdel: Inte alltid lätt att i praktiken kompensera Vem håller rätt på att inte kedjan bryts, routing slip kommer bort...? Kompensering kan vara lättare med s.k. immutable services (kan ej ändras när väl skapade lägg istället till kompenserande, jmfr huvudbok) 85

86 Lösning 7: Långa verksamhetstransaktioner! Klar trend att koppla lösare vid systemintegration Måste därvid tänka att en transaktion kan pågå i timmar, dagar eller veckor innan den är definitiv Eng. Long Running Transaction (ordet transaktion här är alltså inte ett tekniskt begrepp som i SQL) Flera av de tidigare lösningarna är i själva verket varianter av långa verksamhets-transaktioner Behövs compensation schemes, dvs backnings-funktioner insystemerade i applikationerna (radera inte betona spårbarhet jmfr kreditfaktura)! Dessa initieras manuellt eller automatiskt Håll ev ordning på dem med tekniskt workflow / orchestration OBS att modellering, programmering och testning av långa verksamhetstransaktioner är mycket tidskrävande och dyrt! Se alltså dessa som en sista utväg! 86

87 Applikationsintegration med enrichment och övervakning Applikation A Ordrar Ex: Artikelnr men ej artikelpris Verksamhetens transaktionsövervakning Enrichment Slå upp, infoga Kompletteringsdata Ex: Pris Ev. omkörning av trans! Applikation B Ordrar Ex: Prissatta ordrar

88 Andra kvalitetsfrågor Tillgänglighet/uptime Onlinelösningar alltid känsliga, särskilt för dålig 3G-täckning, men även för serverstopp. Varje mellanserver adderar risk för dålig tillgänglighet Synkrona anrop till många parallella tjänster ger dålig uptime Prestanda/svarstider 3G-nätet har långa fördröjningstider, även ifall bandbredden är hög stort problem vid pratig kommunikation Både bandbredd och latens blir sämre vid dålig radiosignal Synkning av stora filer en vanlig prestandabov Säkerhet Stort område; virusskydd, kommunikationskryptering. lagringskryptering, villkor för molntjänster, inloggning, remote wipe mm mm

89 Summering Naiv användning av integrering leder till borttappade uppdateringar, ofärskhet sämre infokvalitet! Ibland tas inte detta på allvar alls. Ibland spelar det ingen roll. Om möjligt, bäst är 1: ACID under ytan Därefter 1a/1b: BASE (men drar mer anropskod + idempotency-kod) De andra lösningarna kan vara nyttiga men de knuffar över undantagshantering till verksamhetsprocesserna och därmed till användarna! Asynk är mer stabilt men leder till mindre färskt data All asynkron felhantering är mycket dyrare att utveckla/testa och riskerar ha fler kvarvarande buggar Alla långa verksamhets-transaktioner är dyra att utveckla/testa, håll nere antalet! 89

90 Balansera/optimera! Naiv användning av integrering leder till borttappade uppdateringar, ofärskhet sämre infokvalitet! Ibland tas inte detta på allvar alls. Ibland spelar det ingen roll. Om möjligt, bäst är 1: ACID under ytan Därefter 1a/1b: BASE (men drar mer anropskod + idempotency-kod) $ L De andra lösningarna kan vara nyttiga men de knuffar över undantagshantering till verksamhetsprocesserna och därmed till användarna! $ L Asynk är mer stabilt men leder till mindre färskt data $ L All asynkron felhantering är mycket dyrare att utveckla/testa och riskerar ha fler kvarvarande buggar Alla långa verksamhets-transaktioner är dyra att utveckla/testa, håll nere antalet! $ L 90 $ L

91 Tekniken sticker upp sitt fula tryne... När saker inte GÅR att göra obrytbart eller exakt samtidigt Verksamhetsmässigt orsakade långa verksamhetstransaktioner Kräver Kräver Funktionalitet i verksamhetsstödet (kompensation etc) Verksamhet Teknik Tekniskt orsakade långa verksamhetstransaktioner 91

92 Processdefinitions-lagret detaljerat ta hand om långa verksamhetstransaktioner Bredvidläsning Ta om hand verksamhetsmässigt orsakade långa verksamhetstransaktioner Ta om hand tekniskt orsakade långa verksamhetstransaktioner Business workflow Technical workflow Business workflow Technical workflow Processdefinition. Visio-filer eller BPEL etc Workflow, orchestration, business process automation, choreography, arbetsflöden, ärendehantering etc behandlas här som ungefär samma begrepp Semantikdefinition Syntaxdefinition Välj integrationsprodukt Ren datakom Överenskommelser Semantikdefinition Syntaxdefinition Välj integrationsprodukt Ren datakom HW 92

93 P-flagga! Bredvidläsning När vi ökar användningen av SOA och moln är det alltså mycket troligt att antalet tekniskt orsakade långa verksamhetstransaktioner ökar Vi måste ge användarna en chans att se att visst data endast är preliminärt! Användargränssnitten borde avspegla detta, förslag: Skriv ut ett P vid siffror som endast är preliminära Saldobild Namn: Sven Svensson Vecka 34: Vecka 35: Vecka 36: P P-flagga 93

94 Bredvidläsning Funktionell modellering vs teknik Krocken funktionella krav tekniska krav vid tidiga projektskeden: Har funnits en risk att man glömt bort att överväga färskhetsbehov då man tar fram datamodell, bör-process, funktionella krav etc. Detta borde tillhöra samma modelleringsfas! På samma sätt har man ofta glömt tänka ut funktioner för compensation de måste ju finnas i applikationen, tekniken löser inte detta automatiskt! 94

95 Kortpraktikfall Även jättegammal appl-kod kan gå att använda i molnet om den har bra egenskaper i övrigt! Ett företag inom bank/finans/försäkring 1994 SOA/moln som mönster är ju egentligen inget nytt! Mångkanal-stöd skulle skapas Det fanns en gammal Cobol-applikation i stordator som SaaS (fast det namnet inte fanns då) Cobol-koden försågs med överrockar så att det gick att anropa dem online/synkront ifrån Gupta och VB Tjänsterna var på ganska hög nivå och innehöll mycket affärslogik bakom Skryt: Teknikrörläggningen har bytts flera gånger men själva tjänste-definitionerna (syntax/semantik) överlevde i stort sett oändrade i många år (för utökat antal kanaler) 95

96 Egenskaper i detta praktikfall Bredvidläsning Löst kopplade Sessionslösa/stateless varje tjänsteanrop oberoende Ingen ACID 2PC mot Windowsmiljön (däremot pålitlig ACID bakom tjänsten) Ingen speciell säkerhets-lösning två datahallar ihopkopplade med säkrade sladdar Noga uttänkt felhantering Modelleringen av tjänsterna viktig det möjligas konst (vad finns i stordatorn, vad behövs i användar-gränssnittet) Vi diskuterade att skapa självbeskrivande info för anropen (såsom idag XML är) men hade inte tid att enas om det. Vi höll på att modellera Överföring genom två separata insättning/uttag. L Istället gjorde vi en mer grovgranulär tjänst Överföring. Slapp ACID-problemet! 96

97 Bredvidläsning Meddelandemodelleringen i praktikfallet CRUD Create, Read, Update, Delete; 4 varianter för många av tjänsterna Samma datastruktur både för begäran och svar, men med olika fältifyllnad Strukturerad returkod Information, Varning, Fel, Fatalt. Uppdelning hos anroparen i förväntad/ ickeförväntad returkod. Flerförekomst möjlig Själva modellerings-arbetet var mycket nyttigt för att överbrygga kulturskillnader. Deltagare: Applikations-kompetens från stordator, från windows, samt moderator som kunde båda teknikerna Tydlig ansvarsuppdelning med black box -tänkande och med modellen som kontrakt Korsreferens stordator-fältnamn windows-fältnamn behövde i alla fall skapas för lättare samarbete Korsreferens datatyper (comp-3 integer etc) skapades 97

98 Kortpraktikfall private cloud I dagsläget körs någonstans mellan 350 och 400 virtuella maskiner i det privata molnet. Det körs i två datahallar i Stockholmstrakten, med två serverrack med sju noder i varje. Lösningen kommer från Oracle och heter PCA, Private Compute Appliance. 98

99 Inlåsning, forts? I flera fall är API:erna inom molntjänsterna proprietära och kan heller ofta inte exekvera utanför molnet. I andra fall kanske API:erna är öppna, men inte relevanta om du skulle ta hem driften till en egen server. Särskilt viktigt för PaaS då du ju troligen skriver egen programkod som ska exekvera i molnleverantörents appserver. Eller har egen programkod utanför molnet som ska ropa på lagring inne i en PaaS-tjänst. KAPSLA IN! Gör klasser som innesluter de proprietära API:erna så att du kan byta lättare om du tröttnat på en molnleverantör. Ex: Storage i Amazon, Google och MS Azure har olika API:er, men ändå relativt liknande. Om du inte behöver utnyttja väldigt speciella finesser kan du skriva klasser som kan klara av alla tre alternativen. Azure-queue kanske kan kapslas in så du kan byta till MSMQ om du skall flytta hem driften. Liknande med Azure Service Bus. 99

100 Exempel: Moln och integration Tänkbar inkapsling av proprietära API:er, för minskad inlåsning Externa användare - GAE Blob-REST. - AWS S3-REST. - Azure-REST. Appar, andra applik. - GAE Blob-REST. - AWS S3-REST. - Azure-REST. Egendef. REST eller SOAP Interna applikationer - Azure Service Bus. - XMPP. - Mm... Öppen accessnyckel, tidsbegränsad Hemlig accessnyckel - GAE web. - AWS EC2. - Azure Web Role. Hemlig accessnyckel - GAE Task Queue. - AWS SQS. - Azure Queue. - GAE Blob el BigTable. - AWS S3 el SimpleDB. - Azure Blob el Table. - GAE Blob-REST. - AWS S3-REST. - Azure-REST. - GAE Backend. - AWS EC2. - Azure Worker Role. 100

101 GOVERNANCE, SLA KOSTNADER

102 Stabilitet Leverantörerna lägger oerhörda pengar på att skapa stabila molnplattformar. Google, Amazon, Azure t.ex. har totalt sett bra trackrecord (men har ju också stannat någon gång och förlorat data). Molnmiljöerna troligen känsliga för en felkonfigurering kan slå ut alla serverinstanser (eftersom de måste kunna konfigureras centraliserat och effektivt så kan en felkonfigurering också sprida sig snabbt) På liknande sätt med buggar i plattformarna Beroende av stabiliteten hos Internet (där det inga garantier finns) 102

103 Uppgradering av tjänsteplattformen För PaaS och SaaS, undersök hur versionsuppgradering görs Skönt slippa hantera det hemma Men troligen måste du acceptera uppgradering samtidigt med alla andra kunder Hur gör du ifall den nya versionen råkar bli sämre just för dej? Du kan behöva en reservplan. Kan det finnas risk för bristande bakåtkompatibilitet? Vad får du för förvarning? Verkar ofta finnas rolling upgrade, serverinstanserna byter automatiskt allteftersom För IaaS är det mindre skillnad mot interndriftning Dock OS-versioner etc... Kolla även managed solutions 103

104 Backup Någon slags backup/dataredundans brukar ingå men ofta endast spegling Extra backup hemma (med längre tillfällen emellan)? Deponering hos tredje part? OBS att backup ska skydda mot många saker: Diskkrasch Operatörsmissgrepp (delete * hoppsan, konfigfel) Användarmissgrepp (felaktigt borttag av kundpost) Återställning efter applikationsbuggar Naturkatastrof, terrordåd etc Mm Dvs endast spegling duger inte alls! 104

105 SLA (Service Level Agreement) % => $ Vanligen definitioner av: Servicetid (när ska lösningen garanteras vara igång, servicefönster, best effort annars ) Teknisk tillgänglighet (typ 99.95% av Servicetid) Prestanda (hur mäta? vem mäter båda helst!) Vad är straffet om SLA inte följs? Flera molnleverantörer har financially backed SLA:s, läs det finstilta. Och ofta låga straffbelopp. Endast 10% av fakturan (Amazon)? Hårda viten?

106 Ansvar => $ $ I vissa fall lovar ingen molnleverantör ansvar (förutom kanske lite för uptime). 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... Det finns ibland en övertro på vad ett kontrakt eller ett vite kan göra. 106

107 Du har redan en massa moln? Personalen är så vana nu vid bring-your-own att de inte bara tar med sin privata Mac eller smartphone, de tar också med sin Dropbox, Google+, OneDrive, gmail, hotmail, tidigare konto på Projektplatsen, dialoger på LinkedIn & FaceBook osv i en salig blandning Avvägning: Hur hårt bör du styra genom policies? Till och med filtrera i brandvägg? Å andra sidan är man ofta mobilt uppkopplade. MDM (Mobile Device Management)? Vara mer proaktiv och erbjuda flexibla och behändiga alternativ till ovanstående tjänster, men säkerhetsmässigt välhanterat? 107