molntjänster – välj rätt lösning · – juridik, avtal mm – säkerhet – fem moln-typer...
TRANSCRIPT
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_
Clo
ud_k
urs_
okt1
6_da
g2_v
.ppt
x
© 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
Verksam- hets- nytta
Teknik- nytta
V e r t i k a l
förståelse behövs
3
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 vanligen billig kommunikation
$ $
Repetition är inlärningens moder…
4
”Eget” OS.
Ex: Amazon EC2 Google Comp Eng MS Azure VM Rackspace, IBM iPeer, Ballou
- - - Internet - - -
Moln-lev typ 1 Moln-lev typ 2
”Eget” Win- dows...
GUI- klient
Ex: Citrix,TermSrvr… AWS Workspaces VDI VMware GNS.SE
Moln-lev typ 3
Kö.
Struk- turerad lagring, integration.
Ex: Amazon AWS Google GAE MS Azure SQL-tjänster Dropbox BizTalk
Moln-lev typ 4
Egen- utvecklade kod-moduler.
Ex: Google GAE MS Azure Heroku Force BizTalk
Ex: Salesforce Fortnox Google Apps Exchange Office365 Spotify
Moln-lev typ 5
Hel appl.
IaaS
PaaS? IaaS? iPaas?
PaaS SaaS
Docker
Repetition är inlärningens moder…
5
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
Repetition är inlärningens moder…
MOBILA APPAR OCH INTEGRATION
Kul
Personlig effektivitet
Sociala nätverk
Affärs-processer
Mobila appar och integration
Integration ofta bra!
Affärs-processer
Integration krävs! Isolerade öar av info: kass.
Molnet passar ofta bra tillsammans med appar: • Samma flexibla kultur… • Lättare integrera… • Lättare anpassa till last…
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 ?
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
– Kan polla en server (medan iOS behöver push från server)
– Push kan i sig kan vara bra, Android har fått C2DN
WinRT • 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.)
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.
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.
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…
?
App till interna system
App
Direkt integration kan ge mycket hög affärsnytta. Ärenden, order, kundinfo, lagersaldo…
Ärendesystem, affärssystem
etc
Säkerhetsutmaningar vid dubbelriktad kommunikation till interna system. Ofta vill man gå via mellanserver i ”DMZ” vilket adderar komplexitet.
Brandvägg
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
Ärendesystem, affärssystem
etc
Om det passar, utåtriktad kommunikation är mycket säkrare – och enklare att införa utan IT-avdelningen
Brandvägg
Molntjänst
”Offline mode”?
App
+ 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!
Offline mode kräver ”databas” och/eller kö i appen. Teknikval (SqLite..)?
Annat system
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).
MOLNET KRÄVER INTEGRATION – MÖNSTER
17
”Eget” OS.
Moln-lev typ 1 Moln-lev typ 2
”Eget” Win- dows.
Moln-lev typ 3
Kö. Lagring.
Moln-lev typ 4
Egen- utvecklade kod-moduler.
Moln-lev typ 5
Hel appl.
Diverse interna system... Stort integrations-
behov
Diverse externa system... Diverse appar...
Hur fixa brandvägg,
DMZ, proxys…?
18
Data integration • Det är information i sig som delas på eller utväxlas • Substantiv (t ex kundpost 123456789)
• 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)
19
Functional integration • Det är programlogik som delas på • Verb (t ex beraekna_raenta för konto 987654321) • 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
20
Olika topologier för informationsutbyte
Olika informations-
utbytesmönster
Olika lagrings- mönster
= Någon faktiskt integration Varje integration: har (minst) tre typer av egenskaper :
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
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
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
Olika topologier för informationsutbyte
Olika informations-
utbytesmönster
Olika lagrings- mönster
Så, varje integration har (minst) fyra helt olika typer av egen- skaper :
Dataintegr. Funk.integr.
25 www.eaipatterns.com
Hohpe har skrivit mycket om integrationsmönster. Ex:
26
Integrationsförväntningar
• Applikationer förväntas vara väl integrerade med varann numera (oavsett outsourcing eller moln).
Std.syst Bank- konto
Std.syst Fond- konto
Skr.sytt. syst Leasing- konto
Engagemangsbild
Front-end-
integr
• T ex Engagemangsbild för en kunds alla förhållanden hos leverantören – ”front-end-integrering”.
Bokf- syst
Back-end-
integr
• Eller integrerad supply chain management eller att förse bokföringen med info – ”back-end-integrering”.
• Mer och mer köps standard-applikationer som måste integreras med varandra
S k stup-rör
27
Typiska egenskaper, front-end integration/SOA
• 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?
Bredvidläsning
28
Typiska egenskaper, back-end integration/SOA
• 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?
Bredvidläsning
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 https://forums.aws.amazon.com/servlet/JiveServlet/download/30-38001-150845-2806/amazon%20centalized%20management%20environment.pdf
29
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: http://www.coramodel.com
• Var uppstår ”molnfrågor” i en sådan modell?
30
31 H2A (Human-to-Application)… B2B (Business-to-Business)…
And
ra p
arte
r
And
ra p
arte
r
32
Främst PaaS, IaaS Främst SaaS,
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!
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...
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...
35
Topologier: Nav, hub, ESB (Enterprise Service Bus)
Appl 1
• 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?
Appl 2
Appl 4
Appl 3 = integr-logik, central och inom varje appl.
36
Anropsmässig trelagers-stack
”Ren datakom” TCP/IP dominant idag
”Ren datakom”
Sladd, radio
Kommuni- cerande applikation
Kommuni- cerande applikation
Web Services, MQ etc i enkelt fall
Integrations- teknik
Integrations- teknik
Jämför med den ”mera nertill detaljerade” sjulagers OSI- stacken
Öve
rens
kom
mel
ser /
kon
trakt
37
Definitioner i femlagers-stack
”Ren datakom” TCP/IP dominant idag ”Ren datakom”
XML-schema t ex Syntax- definition
Syntax- definition
Semantik- definition Word-dokument
RDF/OWL?
Semantik- definition
Svårt
Process- definition Visio-fil eller
BPMN, BPEL...
Process- definition
Svårast
Web Services, MQ etc i enkelt fall
Välj integrations- teknik
Välj integrations- teknik
Öve
rens
kom
mel
ser /
kon
trakt
Sladd, radio
Grund- datakomm.
Syntax- definition
Syntax- definition
Semantikdefinition
Process- kontext
Färskhets- behov
Juridisk kontext
Säkerhets- kontext
Grund- datakomm.
Applikation A Applikation B
Service Level
Juridisk kontext
Säkerhets- kontext
Service Level
Kostnad Kostnad
Öve
rens
kom
mel
ser
/ av
tal
/ ko
ntra
kt Zoom in
Formell Konvention
Process- kontext
Färskhets- behov
Semantikdefinition
Formell Konvention
39
Definitioner i femlagers-stack
”Ren datakom” TCP/IP dominant idag ”Ren datakom”
XML-schema t ex Syntax- definition
Syntax- definition
Semantik- definition Word-dokument eller
RDF etc
Semantik- definition
Svårt
Process- definition Visio-fil eller
BPEL etc
Process- definition
Svårast
MQ i enkelt fall t ex Välj integrations- teknik
Välj integrations- teknik
Öve
rens
kom
mel
ser
Sladd, radio
40
SOA–EAI–ESB, min tolkning...
SOA-tyngdpunkt: Anrop av tjänster
SOA
EAI
EAI/ETL/BI- tyngdpunkt: Flöden av data
ESB
ESB-tyngdpunkt: Anrop samt anropsinfrastruktur (samt flöden)
...en hel del överlapp
ETL
BI
EAI: Enterprise Application Integration ETL: Extract-Transform-Load BI: Business Intelligence, data warehouse
41
Web Services
ESB
Web Services vs SOA–EAI–ESB
WS helt centrala för interoperabla
SOA-anrop
Ökande användning av WS för att hälla
in/ut data
WS helt centrala för interoperabla
ESB-anrop
Om ESB (eller modern EAI) används som SOA-infrastruktur sker oftast anrop
med WS
Många gånger duger WS utan
annan infrastruktur för att skapa SOA
SOA EAI
EAI = Enterpr. Application Integr, ESB = Enterpr. Service Bus
Bredvidläsning
ETL
BI
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/buss-lö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
Verksamhets- logikens troliga ägare, domänvist
43
Black box
• 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!
Bredvidläsning
44
Grey box?
• 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 semi-transparent 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
Bredvidläsning
45
Kontrakt, överenskommelse
Process B
Process A
Kontrakt, t ex: - 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
46
Information centric or process centric?
• Stora debatter genom åren...
• 80-talet var starkt information centric • 90-talet starkt process centric (och objektorienterat) • 00-talet – viss balansering (komponenter som bas för
tjänster...)!?
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…
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”, OR-verktyg)
• 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...
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”)!
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
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!
52
Sannolikhet för stabilitet
• 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,9910 = 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
Om alla tjänsterna behövs , synkront...
Tjänst Tjänst Tjänst Tjänst Tjänst …
(Även 0,995^10= 0,95 är kass, och 0,999^10= 0,99 är ganska dåligt)
53
Sannolikhet för stabilitet
• 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...
Om alla tjänsterna behövs , synkront...
Tjänst Tjänst Tjänst Tjänst Tjänst …
Skikt 1
Skikt 2
Skikt 3
Skikt 10
…
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
Optimering kostnad/stabilitet
55
Åstad- kommen stabilitet
Tekniska åtgärder för stabilitet
För liten teknikhjälp till
stabiliteten
Risk för operatörsmiss-grepp pga teknisk
komplexitet eller att samverkan mellan olika teknik blir för komplex
Kostnad
Tekniska åtgärder för stabilitet
Kostnaden ökar kraftigt vid
avancerad teknik som syftar till
stabilitet
Optimalt band m.a.p. alla tre dimensionerna
Högsta stabilitet
Resonemanget utvecklas mer i www.definitivus.se > inlägg trendspaning > När hög tillgänglighet inte blir hög
Bredvidläsning
56
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
Databas- server (ej cluster)
Repetition är inlärningens moder…
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 off-line 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...
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
60
Granularitet för SOA
Rik klient
Server
Pratigt c/s- protokoll kan vara OK
Rik klient?
Server
Mindre pratigt protokoll behövs i SOA-fallet, lösare kopplat etc
Rik klient
Server
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 SOA...
SOA
Anrop från hängrännor o andra apps
Ej SOA . . . . . . . . . . SOA
Bredvidläsning
61
Rätt arkitektur för rätt sak!?
Rik klient
Applikationens server-skikt
SOA-skikt
Anrop från hängrännor o andra apps
Verksh- objekt 1
Verksh- objekt 2
Verksh- objekt n ...
• C/s-stilen • Får vara hårt kopplat • Får vara fingranulärt • ACID • OO ofta • Klen interoperabilitet
• SOA-stilen • Ska vara löst kopplat • Ska vara grovgranulärt • Ej ACID • Ej OO • Stark interoperabilitet Vanlig OO-
återanvändning!
Bredvidläsning
62
I molnet…
Rik klient
Applikationens server-skikt
SOA-skikt
Anrop från hängrännor o andra apps
Verksh- objekt 1
Verksh- objekt 2
Verksh- objekt n ...
• 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 OO-anrop, snarare SOAP eller REST.
• SOA-stilen • Torde gå bra mot molnet!
Om detta nu ligger i molnet…
Bredvidläsning
63
Composite services (komponerade/sammansatta legoklossar)?
Rik klient
SOA-skikt
Anrop från hängrännor o andra apps
Verksh- objekt 1
Verksh- objekt 2
Verksh- objekt n ...
Dettta kan vara OK komponering av sammansatt (composite) tjänst – när man behöver ACID! = OO-återanvändning.
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ärs-transaktioner e dyl = SOA-återanvändning.
Composite service
Bredvidläsning
64
XML och sammansatt data
Rik klient
Server
Pratigt c/s- protokoll 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
Bredvidläsning
65
Fingranulärt vs redundant data vs grovgranulärt
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
Bredvidläsning
66
Fasad och grovgranulärt • Hittat på nätet:
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
Grovgranulärt, SOA, lätthittat
J bra
”skicka_till_Movex” Tunnel-fasad
Liten tjänst Kund
Liten tjänst Fakt_hvd
Liten tjänst Fakt_rad
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)
”skicka_fakt” Komposit-fasad
Anrops-ex: skicka_fakt(”param1,param2,param3)
...betänk ACID-frågan...
Liten tjänst Kund
Liten tjänst Fakt_hvd
Liten tjänst Fakt_rad
Särskilt viktigt om du skapar
publika molntjänster!
Bredvidläsning
67
AJAX-trenden
Webb- server
SOA- servrar
Web vanligen mindre pratigt
Webbläsare • AJAX innebär bl a att
använda omfattande Javascript-kod i webb- lä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) • Riskfyllt ifall denna pratighet fortplantar sig till bakomliggande SOA-skikt
Webb- server
SOA- servrar
AJAX vanligen mer pratigt
Webbläsare & AJAX-kod
?
AJAX = Asynchronous Java script And XML
Bredvidläsning
68
Vad menas nu med löst kopplad? • 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
– ”Löst kopplat i kalendertiden”, smörgåsbordstanken, ”composing an application”, konfigurera den långt efter stora programmerings-jobbet (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
”agreement is expensive”...
Bredvidläsning
69
Andra sorters lös koppling också • 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)
Bredvidläsning
70
ACID – ”tekniska transaktioner” • Atomicity, Consistency, Independency, Durability • Kallas även atomära transaktioner, before-image-journaling eller allt-
eller-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
Egentligen borde man väl alltid sträva mot ACID, men...
Tjänst B
Anropande A sammansatt tjänst
Anropsgränssnitt
Tjänst C
2PC
Kvalitets-mönster ACID
71
...men ACID för integration kan ge problem
• Inkompatibla teknikmiljöer (trots XA-initiativet t ex)
• En del system-integrationsprodukter 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”
Tjänst B
Anropande A
SOA-snitt. Vanligen EJ lämpligt med ACID och 2PC här!
Tjänst C
X
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
• 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”)
– 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!
Tjänst B ACID under ytan
Anropande A
SOA-snitt Ej ACID här
ACID
Tidsmönster Nu
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)
Tjänst B ACID under ytan
Anropande A
SOA-snitt Ej ACID här
Kö Tjänst C Modul för deferred processing
End-to-end async ACID (se nästa sida)
Annan SOA-domän
Tidsmönster
Strax + Nu
74
Olika ACID-exempel för integration (i detta exempel: ”avisering” till annat system)
2PC-variant, synkont
Pgm B Write 1 . . . Write 2
Allt
-elle
r-in
get
Enkel
Pgm A Write 1 . . . Write 2
Allt
-elle
r-in
get
Pgm C Write 1 . . . Write 2
Allt
-elle
r-in
get
Pgm D Read & delete . . . Write
Allt
-elle
r-in
get
Asynk med äkta leveransskydd
Allt
-elle
r-in
get
75
Behövs ofta asynkront returflöde
Pgm C Write 1 . . . Write 2
Allt
-elle
r-in
get
Pgm D Read & delete . . . Write
Allt
-elle
r-in
get
Normalflöde Returflöde
Allt
-elle
r-in
get
Både för tekniska och logiska undantag Och se upp för giftpiller som kan ge ”kraschloop”, finns ofta felkö för detta…
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 http://queue.acm.org/detail.cfm?id=1394128
76
Kvalitets-mönster BASE Tidsmönster
Strax
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
• Alternativ till säker kö kan vara avancerad omsändnings-hantering + dublettkontroll (idempotency)… många REST-förespråkare gillar detta
Sammansatt Tjänst BC ACID mot två köer oftast ok
Anropande A
SOA-snitt Ej ACID här
Köer
Tjänst B Uppdat strax
End-to-end ACID
Tjänst C Uppdat strax
ACID
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!
Sammansatt Tjänst BC ACID mot två köer oftast ok
Anropande A
SOA-snitt Ej ACID här
RSS/Atom
Tjänst B Uppdat strax
End-to-end “ACID”
Tjänst C Uppdat strax
79
Lösning 1c: Vid read-only, sammansätt utan ACID-behov
Tjänst X
SOA-snitt
Tjänst Y
Tjänst Z
Anropare 2
WS
Se upp med sammansatta tjänster (composite services), det ser ju så förledande snyggt ut i Powerpoint fast kan ge problem. Men read-only är OK!
Implem. av X
WS wrap
WS wrap
Implem. av Y
Sammansatt tjänst A
Anropare 1
WS
WS
80
Lösning 1d: ”Fuska”, sammansätt med ACID i en teknik??
Tjänst X
SOA-snitt
Tjänst Y
Tjänst Z
Sammansatt tjänst A
Anropare 1
Anropare 2
WS WS
Funkar endast bra ifall samma programmerings- miljö i A, X, och Y ! Överväg noga – kan ge alltför hård koppling L
OO-anrop m uppdatering
ACID
Implem. av X
WS wrap
WS wrap
Implem. av Y
Samma db eller 2PC L
Ej ACID
OO-anrop går ej bra till molnet…
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.
Avstämning = eng. reconciliation
Sums for reconciliation
= ?
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
!?
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.
Tjänst C (uppdat)
Anropande A
Ej ACID
Tjänst B (uppdat)
instabilare nät+tjänst
t ex till molnet
stabil
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
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
• 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)
Routing slip
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!
Applikation A
Ordrar
Enrich- ment Slå upp, infoga
Applikation B
Ex: Artikelnr men ej
artikelpris
Ex: Prissatta ordrar
Applikationsintegration med ”enrichment” och övervakning
Komplet- teringsdata
Ex: Pris
Ordrar
Verksamhetens transaktionsövervakning
Ev. om- körning av trans!
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…
Summering • Naiv användning av
integrering leder till bort-tappade 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 verksamhets-processerna 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
Balansera/optimera! • Naiv användning av
integrering leder till bort-tappade 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 verksamhets-processerna 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!
90
$ L
$ L
$ L
$ L $ L
91
Tekniken sticker upp sitt fula tryne...
Verksamhet
Teknik
När saker inte GÅR att göra obrytbart eller exakt samtidigt
Verksamhetsmässigt orsakade långa verksamhetstransaktioner
Tekniskt orsakade långa verksamhetstransaktioner
Kräver
Funktionalitet i verksamhetsstödet (kompensation etc)
Kräver
92
Processdefinitions-lagret detaljerat – ta hand om långa verksamhetstransaktioner
”Ren datakom” ”Ren datakom”
HW
Syntax- definition
Syntax- definition
Semantik- definition
Semantik- definition
Process- definition.
Visio-filer eller BPEL etc
Välj integrations- produkt
Välj integrations- produkt
Öve
rens
kom
mel
ser
Workflow, orchestration, business process automation, choreography, arbetsflöden, ärendehantering etc – behandlas här som ungefär samma begrepp
Business workflow - - - - - - - - -
Ta om hand verksamhetsmässigt orsakade långa verksamhetstransaktioner
Business workflow - - - - - - - - - Technical workflow
Technical workflow Ta om hand tekniskt orsakade
långa verksamhetstransaktioner
Bredvidläsning
93
P-flagga!
• 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: 32 768 Vecka 35: 25 432 Vecka 36: 36 443 P
P-flagga
Bredvidläsning
94
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!
Bredvidläsning
95
Kortpraktikfall
• 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)
Även jättegammal appl-kod kan gå att
använda i molnet – om den har bra
egenskaper i övrigt!
96
Egenskaper i detta praktikfall • Löst kopplade • Sessionslösa/stateless – varje
tjänsteanrop oberoende • Ingen ACID 2PC mot Windows-
miljö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!
Bredvidläsning
97
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
Bredvidläsning
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.”
2015-12-10
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.
Tänkbar inkapsling av proprietära API:er, för minskad inlåsning
Exempel: Moln och integration
100
- GAE web. - AWS EC2. - Azure Web Role.
- GAE Backend. - AWS EC2. - Azure Worker Role.
Interna applikationer
- GAE Task Queue. - AWS SQS. - Azure Queue.
Egendef. REST eller SOAP
- GAE Blob-REST. - AWS S3-REST. - Azure-REST.
- GAE Blob el BigTable. - AWS S3 el SimpleDB. - Azure Blob el Table.
- Azure Service Bus. - XMPP. - Mm...
- GAE Blob-REST. - AWS S3-REST. - Azure-REST.
Externa användare
- GAE Blob-REST. - AWS S3-REST. - Azure-REST.
Öppen access- nyckel, tidsbeg- ränsad…
Hemlig access- nyckel…
Hemlig access- nyckel…
Appar, andra applik.
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 track-record (men har ju också stannat någon gång och förlorat data).
• Molnmiljöerna troligen känsliga för ”en fel-konfigurering 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)
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…
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!
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.
§ $ $ § =>
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
Infoklassning…
108
109
Kortpraktikfall: Leverantörskonkurs 1
• En relativt stor molnleverantör har faktiskt gått i drickat hösten 2013, Nirvanix
• Var stor amerikansk moln-lagrare. Priskrig på lagring, Amazon, Google, MS…
• Kunderna fick två veckor att hämta sitt data, vilket nog var omöjligt för vissa kunder pga datamängd
• IBM verkar i sin tur ha haft Nirvanix som underleverantör, visste IBM:s kunder om det?
• Således: Kunder måste ha en exit-strategi!
110
Kortpraktikfall: Leverantörskonkurs 2
• En mindre molnleverantör stoppade också, Coghead gjorde konkurs 18/2 2009 – Mellanting SaaS/PaaS: CRM, projekthantering, bug tracking – SAP (!) har köpt konkursboet, men tjänsten är nerlagd. – Konfigurering/anpassning/scriptning av apps via enkel drag-
drop mm – Kunderna fick efter konkursen på egen hand exportera sitt
data, men kom egentligen inte åt investeringen i affärslogik • “Customers should download their data that is available through
my.coghead.com before 3:00 p.m. Pacific time on April 30th. However, Customers should not attempt to copy, modify, reproduce or reverse engineer any portion of the software that is part of, or used in the delivery of, the service.”
• Möjligen hade inte förbudet mot reverse engineering gällt i EU...
• Således: Ta kreditupplysning, gör due diligence etc!
111
Molnstrategi
Vem gör molnstrategin/taktiken? • Verksamheten/chefer?
– Ökande trend att verksamheten själv fattar beslut om partiell outsourcing, framförallt SaaS.
– Senare kommer integrationskraven till IT-avdelning/EA som känner sig överkörda
• EA-grupp? – Kan logiskt ingå i en EA – Är det en EA-grupp som sitter ihop bra med resten av organisationen eller
har den blivit isolerad?
• IT-avdelningen? – Har kunskapen att tänka ut tydliga krav på partiell outsourcing – Kan behöva ta initiativ för att inte anses vara ”sega” – Vill måna om sin egen driftning? – Ta hybrid-moln-initiativ?
112
Var gör det ont? • Var finns surdegarna? Måste man ruska om en förstenad IT-avdelningar som
själv tycker det fungerar bra men där verksamheten inte tycker det? – Olika sorters outsourcing, både vanlig och traditionell, eller hybrid
• Har man bra IT-avdelning men kanske måste spara kostnader ändå? – Inte givet att outsourcing inkl moln blir billigare – Kalkylera och skriv i strategin vad som i så fall ska läggas ut
• Problem med kompetensförsörjningen? – Outsourcing, inkl moln, kan göra att man slipper ha en mängd driftkompetens – Outsourcingpartnern kan få bättre skalfördelar inom sin kompetensförsörjning – Men skriv i så fall in i strategin att man måste ha ORDENTLIG upphandlingskompetens och
MÅSTE ha rejäl tillgång till kravställande IT-arkitekter.
113
Omgivande ekonomi. Kultur. • Finns er organisation inom ett verksamhetsområde där lite förändras, eller är
det hög ändringstakt? Ska avgöra vilka flexibilitetsmål ni skriver in i strategin!
• Hur är er organisationskultur? Troligen olämpligt att gå på tvärs mot den i strategin (om man inte särskilt vill ruska om). – Vill man ha full koll, veta var allt finns, använda beprövade lösningar
• Mindre andel moln!
– Eller betonar man time-to-market, flexibilitet, fokusera-på-kärnverksamheten? • Större andel moln! • Om man ändå inte vill välja vanliga publika moln, satsa på smart virtualisering (”private cloud”)?
– Många kanske lägger ut ”enkla saker” oavsett detta, t ex Exchange i molnet.
114
Kapitalbindning • Har organisationen problem med för mycket bundet kapital, eller svårt att
expandera för att detta kräver mer kapital? Behöver göra om till löpandeutgifter! – Drifta själv men hyr datorer (och ev licenser)? – Insourca kompetens? – Outsourca traditionellt – Molnet
• Vad händer om det blir lågkonjunktur? – Är löpandeutgifterna ovan ändå ”fasta” pga traditionella drift-avtal? – Molnet är vanligen helt baserat på förbrukning istället
• Börsen älskar rörliga intäkter tillsammans med motsvarande rörliga kostnader • Kanske är olika delar av organisationen olika, skriv olika strategier för dem!
115
Dela upp era applikationer i typer? 1. Applikationer som manifesterar er speciella innovation
– Troligen större förändringstakt, krävs större flexibilitet – Överväg en strategi till molnet – Troligen inte SaaS utan snarare egenutvecklat på IaaS eller PaaS – Ex: Spotify, Hemnet
2. Applikationer som gör er konkurrenskraftiga – Troligen mittemellan-förändringstakt – Överväg molnet, men kanske inte så bråttom – Överväg i så fall SaaS – Ex: Internetbank (detta var typ 1 för femton år sedan)
3. Applikationer för att klara legala och fiskala krav – Låg förändringstakt – Visst kan molnet funka, men lika troligt egendriftning eller traditionell outsourcing – Ex: Ekonomisystem, personalsystem
• Svaret är troligen inte samma i de tre delstrategierna -> ev hybridstrategi!
116 Tankesättet delvis lånat från Gartner…
Några tänkbara rubriker i strategin • Underlag
– Företagets övergripande strategier – Nulägesbeskrivning, var gör det ont, vilken kultur har vi (och vill vi ha), vilken
kapitalbindning ska vi sikta mot, vilka applikationstyper har vi, vilka säkerhetskrav, mm mm?
• Outsourcinginriktning – Baserat på underlaget, lägg ut en strategi
• Hur mycket egendriftning om ett år, om fem år • Hur mycket traditionell outsourcing om ett år, om fem år • Hur mycket molndriftning om ett år, om fem år
– Troligen vill man även välja ett huvud-moln att satsa på
• Integrationsstrategi – De flesta kommer att ha någon slags hybrid, i så fall måste integration ske mellan
applikationer driftade på olika ställen – Peka ut integrationsskategorier som kan vara extra viktiga för er, t ex inloggning/
identifiering eller kund-grunduppgifter – Investera i ett huvud-integrationsnav eller inte? I båda fallen behövs goda riktlinjer för
integrationsprinciper! Kanske måste man få ihop flera nav.
• Utvärderingstidpunkter framåt – följ upp hur det gick!
117
Från cloudsweden.se:
119
Migration
120
Migrera till molnet: Programkod
• EC2 är enkelt, du väljer fritt • GAE och Azure: Vissa apps i Python resp C#/
VB kan tas över direkt till molnet, men modifiering kan behövas
• Ev val av migrerbart språk: Php, Python, Java etc
• För SaaS kan det vara svårt att importera in i deras proprietära kodning/konfigurering
121
Migrera till molnet: Data
• Mycket av integrationsmönstren ovan kan användas för engångsmigrering (och löpande replikering)
• Ifall det är mycket: Skicka hårddisk med bud! • SQL-replikering eller BCP kan ibland
användas • AD-replikering, Exchange-replikering... • Vid migrering till de ”enkla molndatabaserna”
kan om fattande konvertering behövas
122
Migrera från molnet: Programkod
• I genomgången av AWS, GAE, Azure gick vi igenom varierande inlåsning/migrerbarhet
• Eftersom dessa tre plattformar troligen endast finns i EN upplaga, hos dessa leverantörer, kan du behöva förbereda koden för att bli migrerbar: – Inkapsling av moln-API:er – Ev val av migrerbart språk: Php, Python, Java etc – För SaaS kan inlåsningen vara större, kan vara
HELT proprietär kodning/konfigurering
123
Migrera från molnet: Data
• Mycket av integrationsmönstren ovan kan användas för engångsmigrering (och löpande replikering)
• Ifall det är mycket: Skicka hårddisk med bud!? • SQL-replikering eller BCP kan ibland
användas • AD-replikering, Exchange-replikering... • Vid migrering från de ”enkla
molndatabaserna” kan omfattande konvertering behövas
Utläsning • Vid anskaffande av lösning, ställ alltid krav
initialt på hur data ska kunna läsas ut ur lösningen när den ska pensioneras en gång! – Särskilt viktigt vid SaaS-köp – Samt för upphandling av standardapplikationer – Ta exemplet att bokföringsdata måste gå att nå tio år
– Men behövs också om leverantören konkar
124
Kom igen, vad rekommenderar du nu då?
• Vela inte så, Sven-Håkan, rekommenderar du molnet eller inte? • Typiska konsultsvaret: Det beror på! :)
• MÅNGA småfaktorer att sätta sig in i, arbetsamt att besluta om för/emot.
• Många molnlösningar går redan att använda på ett utmärkt sätt – Men det är INTE ett generellt botemedel för allsköns driftproblem
• Molnet kommer att mogna och bara bli en av många outsourcingvarianter
125
126
Trendspaningar, artiklar
• På min enkla sajt www.definitivus.se finns ett artikelarkiv för trendspaningar och annat som successivt fylls på, exempel på ämnen: – Vad är vad uppe bland molnen (mer om molntyper) – Säkerhetskopiering och asynkrona system – Lösa transaktioner och rätt data – REST och sånt… – Facebook eller eID för inloggningen? – Hur den lösa kopplingen ändå blir hård – Till den som sitter med klistret – ESB:n är död – leve ESB:n!
Fler lästips • arstechnica.com • olika nätverk inom linkedin.com • www.cloudcomputingpatterns.org • searchcloudcomputing.techtarget.com • eaipatterns.com • cloudsweden.se • www.iasa.se • www.trendspaning.se • www.definitivus.se • msb.se • Boken om IT-arkitektur 127
128
Sven-Håkan Olsson Definitivus AB 0708 – 84 01 34 sven-hakan.olsson[hos]definitivus.se www.definitivus.se www.styrelsemote.se www.socialjour.se Se även trendspaning.se