SlideShare une entreprise Scribd logo
1  sur  26
Télécharger pour lire hors ligne
Fra Silo til Micro Services; 3 + 8 + 3
Tormod Varhaugvik, SKD, SW 2016
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 2
Forbehold og historikk
Presentasjonen kategoriserer tema etter 3 + 8 + 3, uten
at det nødvendigvis er en helt rett eller eneste gode
kategorisering.
Utgangspunkt i designvalg fra 2010 og det jeg oppfatter
som varig gode mønstre, selv om det har kommet nye
produkter og 3-bokstavs-forkortelser i mellomtiden.
(PS. ditt målbilde må bestå av gode varige mønstre)
Micro services er ikke nødvendigvis «micro» i
forretningslogikk eller informasjonsmodell
Min DnD historikk:
DnD 2010 «ut av Siloene» - Systemarkitektur for migrering inn i skyen
SW 2012 – Forenkling og framtidsretting hos Skatteetaten
SW 2012 – Massivt skalerbar skatteberegning
Ark2012 – Kinderegget; enklere, billigere og mye raskere
SW 2013 – Revolusjon kamerater!
SW 2014 – Forretningsutvikling igjennom sky-prototyping
Ark 2014 – Hemmeligheten bak SkatteInfo
SW 2015 – 5 år med forenkling og framtidsretting
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 3
Agenda
•Strategien
•3 basis teknologier
•8 designmønstre
•3 komponenter
•Egenskapene
Strategien
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 4
Erkjennelse i 2010
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 5
•Dagens systemer er ikke i stand til å håndtere fremtidens krav
•Forretningsbehov
•Teknisk
•Merkantilt
•Forretningsbehov
•Part i sentrum; helhet, selvbetjening og risikohåndtering
•Hendelsesdrevet; datakvalitet og å være med på det som skjer
•Teknisk
•Endringsevne; forståelige, skalerbare og testbare systemer
•Standardisert; implementere og bruke slik «alle» er vant til
•Merkantilt
•Markedstilgang; tilgjengelig kompetanse og produkter
•Portabilitet; sikre investering ved å kunne flytte
•=> Grunnleggende modernisering av kjerneapplikasjoner
Hvordan?
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 6
Hvordan kan de klassiske kompliserte fagsystemene
(Siloene) flyttes over på en plattform med helt andre
premisser (Sky), slik at endringsevnen økes og
forvaltningskosten til systemene senkes eller begrenses?
Dette er ett paradigmeskifte i software design og
implementasjon. Spesielt skalering og robusthet løses helt
annerledes, og utfordrer vesentlig hvordan informasjon
struktureres.
3 Teknologier
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 7
Java
•Standardisering
•Isolerer funksjonalitet fra infrastruktur
•Tilgjengelighet på ressurser
•Fleksibilitet i valg av kjøremiljø
(fra «lett» i utvikling / test, til «kjempe» i produksjon)
•Skalerbar
•Sikkerhet
•Infrastruktur
•Integrasjon
•Standardløsninger har Java API
•Livsløp
•Ikke så mye språket som plattformen
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 8
XML
•Standardisering
•XML Schema Definition
•Ferdige komponenter
•Isolerer funksjonalitet fra infrastruktur
•Selvbærende skjema + forekomst (modell og data)
•Kontroll på egen informasjon
•Fleksibelt og robust
•Integrasjon
•Standardløsninger har XML
•Livsløp (det vi begynner på nå, skal vare i mange 10-år)
•Ikke så mye XML i seg selv, men kan ha egnet
implementasjon (JSON)
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 9
HTML
•Standardisering
•Universell utforming
•Tilgjengelighet på ressurser
•Fleksibilitet i valg av kjøremiljø
•Skalerbar
•Sikkerhet
•Infrastruktur
•Integrasjon mellom skjermbilder
•Standardløsninger har web-grensesnitt
•Lavere brukerterskel -> Alle er vant til å bruke det
•Sees i sammenheng med CSS, JavaScript, HTTP og
REST
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 10
8 Designmønstre
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 11
Domain Driven Design
•Dette er ikke ett mønster, men snarere en bibel
•Designmønstre for å lage og forvalte store systemer
•Ikke lærd over natten, man må leve med den
•Legg spesiell vekt på disse delene:
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 12
Viktig område Årsak
Ubiquitous language Entydig språk som alle i organisasjonen bruker
Bounded Context Respekter at det finnes mange ulike «områder» med
ulik forretningslogikk og informasjonsbruk
Layered Architecture Skille mellom tilstandsløs forretningslogikk og
tilstandsfulle prosesser
Modules Systemer består av uavhengige moduler, disse tilbyr
tjenester (aka. Micro Services)
Aggregate Design Informasjonsmodell avgrenset av bruksmønster (og
tjeneste (informasjon entydig til en Micro Service)
CQRS
•Command Query Resource Segregation
•Det må skilles mellom det å lage ett konsistent sett med
data, og det å hente det fram igjen
•Vi ser dette skille i mange andre sammenhenger slike
som
•Kamera – Album
•Trykkeri – Bibliotek
•Lage værmelding – Se værmeldingen
•Poenget er å kunne ha kontroll på en gyldig
forretningsmessig tilstand og sikre skalering uavhengig
på produsent-siden og konsument-siden
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 13
BASE
•“Basic Availabile, Soft-state, Eventual consistency”
•Ordspill mot ACID...
•Design for å håndtere CAP teoremet
•Consistency (all nodes see the same data at the same time)
•Availability (a guarantee that every request receives a response
about whether it succeeded or failed)
•Partition tolerance (the system continues to operate despite
arbitrary partitioning due to network failures)
•Det finnes mange implementasjoner av dette både for
datalagring og for dataprosessering
•Dette spiller også sammen med de andre mønstrene
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 14
Tuple Space
•Teoretisk fundament for «distribuert in-memory parallell
prosessering»
•Se Space-Based Architectures, som igjen har relasjoner
til Cloud Native Architectures
•Ikke bokstavelig som i «JavaSpaces»
•Micro Services er ikke bare uavhengige tjenester, men
informasjonsmengden må også være uavhengige
•Twist er at det ikke er Java Objects, med Domain Driven
Design «Aggregates»
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 15
Event Sourcing
•Komponenter må fortelle om endringer i det de er
ansvarlige for
•Hendelser relevante i forretningsmessige beslutninger
•Viktig å modellere riktig; slik at de danner en fornuftig
forretningsmessig protokoll og god datagranularitet
•Når katta er ute av sekken vil andre systemer reagere på
hendelsen. Viktig å respektere at det har en effekt å gjøre
om på hendelser
•Passer godt i typiske saksbehandlingsapplikasjoner
•Ikke en «undo»-strategi i GUI
•Vurder løsning ut fra lese og skrive hyppighet
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 16
Dokumentbasert lagring
•Lagre informasjon i avgrensede informasjonsmengder
•Bruk «Aggregate Design» for å modellere disse
•En ny versjon er i praksis en ny forretningsbeslutning, og
kan knyttes til «Event Sourcing»
•Skalerer utmerket horisontalt for ytelse
•Skalerer utmerket forvaltningsmessig (av systemet)
•Utstyr dokumentet med Metadata
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 17
Operational Data Store
•Egentlig bare ideen om å lagre alle operasjonelle data i en
lagringsarkitektur
•Viktig twist er metadata om de forskjellige informasjonsmengdene og
som «immutable time-series» dokumenter
•ODS støtter implementasjon av strategien på flere områder:
•Masterdata, ett sted for konsumenter å henvende seg
•Migrering, fordi data fra gamle siloer lagres her (og også skjermer soliene
for uhåndterbare krav til oppetid og sikkerhet)
•Kundefokus
•Risikobasert behandling
•Langtidslagring
•Det er ikke det å integrere de forskjellige typene som er viktig
•Integreringen skjer hos konsumenten!
•«Canonical» eller Universell modell er ett anti-pattern
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 18
REST
•«Representational state transfer»
•Den åpenbare kandidaten gitt internett sin utbredelse
•Bygger på HTTP (som kanskje burde vært en av
teknologiene nevnt ovenfor)
•Inneholder også feeds som er en implementasjon for events
•Vi er ikke tvingende for WS eller REST
•REST’ viktigste bidrag som protokoll er at den er tydelig
på tilstandsovergang i et distribuert miljø med varierende
latency
(RPC og WS skjuler denne kompleksiteten)
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 19
3 Komponenter
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 20
SkatteInfo
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 21
• Dokumentlager (SkatteInfo)
• Tar forvaltningsloven på kornet
• Felles arkivnøkkel
• Arkivert og versjonert
• Uavhengige «områder»
• Skalerbar for ytelse
• Enkel for 24/7 bruk
• Søkemotor – «Skattefinn»
• Felles tilgangskontroll og sporing
• Prosesslag (Micro Services)
• Årvisse uavhengige komponenter
• Hendelsesstyrt gjennomløp
• Løpende forretningsmessige vedtak og tilrettelegging
• En komponent inneholder forretningslogikk og støtte for
saksbehandling for ett «område»
Saksmappe
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 22
•Metadata og referanser til saksinnholdet
•Hvert vedtak lagres som
en ny versjon (xml-dokument)
•Fokuser på Sakens innhold
og tilstand, ikke prosessen
•Rettssikkerhet
•Saksbehandlers tilgang
styres av Saken, som igjen
gir tilgangs til dokumenttyper definert av sakstypen
•En Sakstype har en applikasjon med reglene for denne saken
•Konsistens sikres ved at saksmappe-dokumentet må være
nyere enn alle relevante dokumenter
•Forvaltningsloven (NOARK-5) i kjernen av fagsystemet
Attributbasert tilgangsstyring (ABAC / PBAC)
•Referansearkitektur for tilgangsstyring
•Policy Enforcement Point
•Policy Decision Point
•En policy er bygd opp av følgende attributter
•Subject er den som ber om aksess
•Action er handlingen som ønskes utført
•Resource er informasjonsobjektet som handlingen ønskes utført på
•Environment identifiserer i hvilken kontekst objektet blir forespurt på
Saksbehandler for en sakstype skal ha tilgang til informasjon som
angår saker av denne typen
•Versjonerte Saksmappe og SkatteInfo-dokumenter - sammen med
metadata - gir en elegant og håndterbar måte av avgjøre «Resource»
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 23
Egenskaper
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 24
Egenskaper (til Micro Services)
ved at moduler lar
seg teste hver for
seg i en tydelig
verdikjede
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 25
Skalerbar
Testbar
Enkel
ved at regler, informasjon og
prosess er tettest mulig opp
mot forretningsbegrep
ved at volum og svartider lar seg
løse ved kjøp av mer hardware,
og ikke igjennom å skrive om
regler, informasjon eller prosess
Takk for meg
Alle mine presentasjoner ligger på http://slideshare.net/tormodv
Blogg: http://tormodv.blogspot.no/
Twitter: @tormodvar
LinkedIn: https://no.linkedin.com/in/tormod-varhaugvik-b6170a
12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 26

Contenu connexe

En vedette

Smidig i MAG og skatteetaten
Smidig i MAG og skatteetatenSmidig i MAG og skatteetaten
Smidig i MAG og skatteetatenSmidigkonferansen
 
"Vi har for mange systemer" sier du. Er du sikker?
"Vi har for mange systemer" sier du. Er du sikker?"Vi har for mange systemer" sier du. Er du sikker?
"Vi har for mange systemer" sier du. Er du sikker?christingorman
 
Making Enterprise Architecture Succeed at Tax Norway
Making Enterprise Architecture Succeed at Tax NorwayMaking Enterprise Architecture Succeed at Tax Norway
Making Enterprise Architecture Succeed at Tax NorwayTormod Varhaugvik
 
Computer History Museum slideshare 101910
Computer History Museum slideshare 101910Computer History Museum slideshare 101910
Computer History Museum slideshare 101910Tormod Askildsen
 
Hemmeligheten bak Skatteetatens nye saksbehandlingskjerne
Hemmeligheten bak Skatteetatens nye saksbehandlingskjerneHemmeligheten bak Skatteetatens nye saksbehandlingskjerne
Hemmeligheten bak Skatteetatens nye saksbehandlingskjerneTormod Varhaugvik
 
Mvp, jada. Men det er mvc som virkelig rocker
Mvp, jada. Men det er mvc som virkelig rockerMvp, jada. Men det er mvc som virkelig rocker
Mvp, jada. Men det er mvc som virkelig rockerSmidigkonferansen
 
Statoil nobel fredspris - presentasjon
Statoil   nobel fredspris - presentasjonStatoil   nobel fredspris - presentasjon
Statoil nobel fredspris - presentasjonIBM Sverige
 

En vedette (7)

Smidig i MAG og skatteetaten
Smidig i MAG og skatteetatenSmidig i MAG og skatteetaten
Smidig i MAG og skatteetaten
 
"Vi har for mange systemer" sier du. Er du sikker?
"Vi har for mange systemer" sier du. Er du sikker?"Vi har for mange systemer" sier du. Er du sikker?
"Vi har for mange systemer" sier du. Er du sikker?
 
Making Enterprise Architecture Succeed at Tax Norway
Making Enterprise Architecture Succeed at Tax NorwayMaking Enterprise Architecture Succeed at Tax Norway
Making Enterprise Architecture Succeed at Tax Norway
 
Computer History Museum slideshare 101910
Computer History Museum slideshare 101910Computer History Museum slideshare 101910
Computer History Museum slideshare 101910
 
Hemmeligheten bak Skatteetatens nye saksbehandlingskjerne
Hemmeligheten bak Skatteetatens nye saksbehandlingskjerneHemmeligheten bak Skatteetatens nye saksbehandlingskjerne
Hemmeligheten bak Skatteetatens nye saksbehandlingskjerne
 
Mvp, jada. Men det er mvc som virkelig rocker
Mvp, jada. Men det er mvc som virkelig rockerMvp, jada. Men det er mvc som virkelig rocker
Mvp, jada. Men det er mvc som virkelig rocker
 
Statoil nobel fredspris - presentasjon
Statoil   nobel fredspris - presentasjonStatoil   nobel fredspris - presentasjon
Statoil nobel fredspris - presentasjon
 

Similaire à Fra silo til micro services

Mellomvare og integrasjon en innføring i bruk av biz talk hos ikt agder iks
Mellomvare og integrasjon    en innføring i bruk av biz talk hos ikt agder iksMellomvare og integrasjon    en innføring i bruk av biz talk hos ikt agder iks
Mellomvare og integrasjon en innføring i bruk av biz talk hos ikt agder iksAtle Frydenlund
 
Kinderegget; enklere, billigere og mye raskere
Kinderegget; enklere, billigere og mye raskereKinderegget; enklere, billigere og mye raskere
Kinderegget; enklere, billigere og mye raskereTormod Varhaugvik
 
BrilliantOffice
BrilliantOfficeBrilliantOffice
BrilliantOfficeSolv AS
 
Et datadrevet nav uninettdagene 20191112
Et datadrevet nav   uninettdagene 20191112Et datadrevet nav   uninettdagene 20191112
Et datadrevet nav uninettdagene 20191112Tommy Jocumsen
 
Monolitter og byggeklosser jon erik solheim - stacc
Monolitter og byggeklosser   jon erik solheim - staccMonolitter og byggeklosser   jon erik solheim - stacc
Monolitter og byggeklosser jon erik solheim - staccJon Solheim
 
Inngåelse og oppfølging av it kontrakter
Inngåelse og oppfølging av it kontrakterInngåelse og oppfølging av it kontrakter
Inngåelse og oppfølging av it kontrakterKjell Steffner
 
Hva må jeg ha klar for å bruke skyen- v/Bjørn Tore Johannessen og Øystein Her...
Hva må jeg ha klar for å bruke skyen- v/Bjørn Tore Johannessen og Øystein Her...Hva må jeg ha klar for å bruke skyen- v/Bjørn Tore Johannessen og Øystein Her...
Hva må jeg ha klar for å bruke skyen- v/Bjørn Tore Johannessen og Øystein Her...IKT-Norge
 
Cloud Computing – hva betyr dette for IT-avdelingen og utviklerne?
Cloud Computing – hva betyr dette for IT-avdelingen og utviklerne?Cloud Computing – hva betyr dette for IT-avdelingen og utviklerne?
Cloud Computing – hva betyr dette for IT-avdelingen og utviklerne?Morten Tørmoen
 
Splitt og hersk: Fleksibel arkitektur med mikrotjenester!
Splitt og hersk: Fleksibel arkitektur med mikrotjenester!Splitt og hersk: Fleksibel arkitektur med mikrotjenester!
Splitt og hersk: Fleksibel arkitektur med mikrotjenester!Henrik Schwarz
 
Integrasjonsdagene 2014 - Lenkede data - automagisk integrasjon?
Integrasjonsdagene 2014 - Lenkede data - automagisk integrasjon?Integrasjonsdagene 2014 - Lenkede data - automagisk integrasjon?
Integrasjonsdagene 2014 - Lenkede data - automagisk integrasjon?Steinar Skagemo
 
Inngåelse og oppfølging av it-kontrakter
Inngåelse og oppfølging av it-kontrakterInngåelse og oppfølging av it-kontrakter
Inngåelse og oppfølging av it-kontrakterLYNX advokatfirma DA
 
Inngåelse og oppfølging av it kontrakter
Inngåelse og oppfølging av it kontrakterInngåelse og oppfølging av it kontrakter
Inngåelse og oppfølging av it kontrakterKjell Steffner
 
Hvordan Lykkes Med Overvåkning
Hvordan Lykkes Med OvervåkningHvordan Lykkes Med Overvåkning
Hvordan Lykkes Med OvervåkningOdd Inge Bjørdal
 

Similaire à Fra silo til micro services (20)

Mellomvare og integrasjon en innføring i bruk av biz talk hos ikt agder iks
Mellomvare og integrasjon    en innføring i bruk av biz talk hos ikt agder iksMellomvare og integrasjon    en innføring i bruk av biz talk hos ikt agder iks
Mellomvare og integrasjon en innføring i bruk av biz talk hos ikt agder iks
 
Kinderegget; enklere, billigere og mye raskere
Kinderegget; enklere, billigere og mye raskereKinderegget; enklere, billigere og mye raskere
Kinderegget; enklere, billigere og mye raskere
 
Skalerbare systemer
Skalerbare systemerSkalerbare systemer
Skalerbare systemer
 
BrilliantOffice
BrilliantOfficeBrilliantOffice
BrilliantOffice
 
Et datadrevet nav uninettdagene 20191112
Et datadrevet nav   uninettdagene 20191112Et datadrevet nav   uninettdagene 20191112
Et datadrevet nav uninettdagene 20191112
 
Monolitter og byggeklosser jon erik solheim - stacc
Monolitter og byggeklosser   jon erik solheim - staccMonolitter og byggeklosser   jon erik solheim - stacc
Monolitter og byggeklosser jon erik solheim - stacc
 
Semantisk integrasjon
Semantisk integrasjonSemantisk integrasjon
Semantisk integrasjon
 
Inngåelse og oppfølging av it kontrakter
Inngåelse og oppfølging av it kontrakterInngåelse og oppfølging av it kontrakter
Inngåelse og oppfølging av it kontrakter
 
Hva må jeg ha klar for å bruke skyen- v/Bjørn Tore Johannessen og Øystein Her...
Hva må jeg ha klar for å bruke skyen- v/Bjørn Tore Johannessen og Øystein Her...Hva må jeg ha klar for å bruke skyen- v/Bjørn Tore Johannessen og Øystein Her...
Hva må jeg ha klar for å bruke skyen- v/Bjørn Tore Johannessen og Øystein Her...
 
Ta styringen!
Ta styringen!Ta styringen!
Ta styringen!
 
Aws på kartet - 2
Aws på kartet - 2Aws på kartet - 2
Aws på kartet - 2
 
Cloud Computing – hva betyr dette for IT-avdelingen og utviklerne?
Cloud Computing – hva betyr dette for IT-avdelingen og utviklerne?Cloud Computing – hva betyr dette for IT-avdelingen og utviklerne?
Cloud Computing – hva betyr dette for IT-avdelingen og utviklerne?
 
Splitt og hersk: Fleksibel arkitektur med mikrotjenester!
Splitt og hersk: Fleksibel arkitektur med mikrotjenester!Splitt og hersk: Fleksibel arkitektur med mikrotjenester!
Splitt og hersk: Fleksibel arkitektur med mikrotjenester!
 
Integrasjonsdagene 2014 - Lenkede data - automagisk integrasjon?
Integrasjonsdagene 2014 - Lenkede data - automagisk integrasjon?Integrasjonsdagene 2014 - Lenkede data - automagisk integrasjon?
Integrasjonsdagene 2014 - Lenkede data - automagisk integrasjon?
 
Medlemsnytt_3_2015_side4_5
Medlemsnytt_3_2015_side4_5Medlemsnytt_3_2015_side4_5
Medlemsnytt_3_2015_side4_5
 
Soa Runtime
Soa RuntimeSoa Runtime
Soa Runtime
 
Migrering uten migrene
Migrering uten migreneMigrering uten migrene
Migrering uten migrene
 
Inngåelse og oppfølging av it-kontrakter
Inngåelse og oppfølging av it-kontrakterInngåelse og oppfølging av it-kontrakter
Inngåelse og oppfølging av it-kontrakter
 
Inngåelse og oppfølging av it kontrakter
Inngåelse og oppfølging av it kontrakterInngåelse og oppfølging av it kontrakter
Inngåelse og oppfølging av it kontrakter
 
Hvordan Lykkes Med Overvåkning
Hvordan Lykkes Med OvervåkningHvordan Lykkes Med Overvåkning
Hvordan Lykkes Med Overvåkning
 

Fra silo til micro services

  • 1. Fra Silo til Micro Services; 3 + 8 + 3 Tormod Varhaugvik, SKD, SW 2016
  • 2. 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 2 Forbehold og historikk Presentasjonen kategoriserer tema etter 3 + 8 + 3, uten at det nødvendigvis er en helt rett eller eneste gode kategorisering. Utgangspunkt i designvalg fra 2010 og det jeg oppfatter som varig gode mønstre, selv om det har kommet nye produkter og 3-bokstavs-forkortelser i mellomtiden. (PS. ditt målbilde må bestå av gode varige mønstre) Micro services er ikke nødvendigvis «micro» i forretningslogikk eller informasjonsmodell Min DnD historikk: DnD 2010 «ut av Siloene» - Systemarkitektur for migrering inn i skyen SW 2012 – Forenkling og framtidsretting hos Skatteetaten SW 2012 – Massivt skalerbar skatteberegning Ark2012 – Kinderegget; enklere, billigere og mye raskere SW 2013 – Revolusjon kamerater! SW 2014 – Forretningsutvikling igjennom sky-prototyping Ark 2014 – Hemmeligheten bak SkatteInfo SW 2015 – 5 år med forenkling og framtidsretting
  • 3. 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 3 Agenda •Strategien •3 basis teknologier •8 designmønstre •3 komponenter •Egenskapene
  • 4. Strategien 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 4
  • 5. Erkjennelse i 2010 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 5 •Dagens systemer er ikke i stand til å håndtere fremtidens krav •Forretningsbehov •Teknisk •Merkantilt •Forretningsbehov •Part i sentrum; helhet, selvbetjening og risikohåndtering •Hendelsesdrevet; datakvalitet og å være med på det som skjer •Teknisk •Endringsevne; forståelige, skalerbare og testbare systemer •Standardisert; implementere og bruke slik «alle» er vant til •Merkantilt •Markedstilgang; tilgjengelig kompetanse og produkter •Portabilitet; sikre investering ved å kunne flytte •=> Grunnleggende modernisering av kjerneapplikasjoner
  • 6. Hvordan? 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 6 Hvordan kan de klassiske kompliserte fagsystemene (Siloene) flyttes over på en plattform med helt andre premisser (Sky), slik at endringsevnen økes og forvaltningskosten til systemene senkes eller begrenses? Dette er ett paradigmeskifte i software design og implementasjon. Spesielt skalering og robusthet løses helt annerledes, og utfordrer vesentlig hvordan informasjon struktureres.
  • 7. 3 Teknologier 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 7
  • 8. Java •Standardisering •Isolerer funksjonalitet fra infrastruktur •Tilgjengelighet på ressurser •Fleksibilitet i valg av kjøremiljø (fra «lett» i utvikling / test, til «kjempe» i produksjon) •Skalerbar •Sikkerhet •Infrastruktur •Integrasjon •Standardløsninger har Java API •Livsløp •Ikke så mye språket som plattformen 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 8
  • 9. XML •Standardisering •XML Schema Definition •Ferdige komponenter •Isolerer funksjonalitet fra infrastruktur •Selvbærende skjema + forekomst (modell og data) •Kontroll på egen informasjon •Fleksibelt og robust •Integrasjon •Standardløsninger har XML •Livsløp (det vi begynner på nå, skal vare i mange 10-år) •Ikke så mye XML i seg selv, men kan ha egnet implementasjon (JSON) 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 9
  • 10. HTML •Standardisering •Universell utforming •Tilgjengelighet på ressurser •Fleksibilitet i valg av kjøremiljø •Skalerbar •Sikkerhet •Infrastruktur •Integrasjon mellom skjermbilder •Standardløsninger har web-grensesnitt •Lavere brukerterskel -> Alle er vant til å bruke det •Sees i sammenheng med CSS, JavaScript, HTTP og REST 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 10
  • 11. 8 Designmønstre 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 11
  • 12. Domain Driven Design •Dette er ikke ett mønster, men snarere en bibel •Designmønstre for å lage og forvalte store systemer •Ikke lærd over natten, man må leve med den •Legg spesiell vekt på disse delene: 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 12 Viktig område Årsak Ubiquitous language Entydig språk som alle i organisasjonen bruker Bounded Context Respekter at det finnes mange ulike «områder» med ulik forretningslogikk og informasjonsbruk Layered Architecture Skille mellom tilstandsløs forretningslogikk og tilstandsfulle prosesser Modules Systemer består av uavhengige moduler, disse tilbyr tjenester (aka. Micro Services) Aggregate Design Informasjonsmodell avgrenset av bruksmønster (og tjeneste (informasjon entydig til en Micro Service)
  • 13. CQRS •Command Query Resource Segregation •Det må skilles mellom det å lage ett konsistent sett med data, og det å hente det fram igjen •Vi ser dette skille i mange andre sammenhenger slike som •Kamera – Album •Trykkeri – Bibliotek •Lage værmelding – Se værmeldingen •Poenget er å kunne ha kontroll på en gyldig forretningsmessig tilstand og sikre skalering uavhengig på produsent-siden og konsument-siden 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 13
  • 14. BASE •“Basic Availabile, Soft-state, Eventual consistency” •Ordspill mot ACID... •Design for å håndtere CAP teoremet •Consistency (all nodes see the same data at the same time) •Availability (a guarantee that every request receives a response about whether it succeeded or failed) •Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures) •Det finnes mange implementasjoner av dette både for datalagring og for dataprosessering •Dette spiller også sammen med de andre mønstrene 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 14
  • 15. Tuple Space •Teoretisk fundament for «distribuert in-memory parallell prosessering» •Se Space-Based Architectures, som igjen har relasjoner til Cloud Native Architectures •Ikke bokstavelig som i «JavaSpaces» •Micro Services er ikke bare uavhengige tjenester, men informasjonsmengden må også være uavhengige •Twist er at det ikke er Java Objects, med Domain Driven Design «Aggregates» 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 15
  • 16. Event Sourcing •Komponenter må fortelle om endringer i det de er ansvarlige for •Hendelser relevante i forretningsmessige beslutninger •Viktig å modellere riktig; slik at de danner en fornuftig forretningsmessig protokoll og god datagranularitet •Når katta er ute av sekken vil andre systemer reagere på hendelsen. Viktig å respektere at det har en effekt å gjøre om på hendelser •Passer godt i typiske saksbehandlingsapplikasjoner •Ikke en «undo»-strategi i GUI •Vurder løsning ut fra lese og skrive hyppighet 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 16
  • 17. Dokumentbasert lagring •Lagre informasjon i avgrensede informasjonsmengder •Bruk «Aggregate Design» for å modellere disse •En ny versjon er i praksis en ny forretningsbeslutning, og kan knyttes til «Event Sourcing» •Skalerer utmerket horisontalt for ytelse •Skalerer utmerket forvaltningsmessig (av systemet) •Utstyr dokumentet med Metadata 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 17
  • 18. Operational Data Store •Egentlig bare ideen om å lagre alle operasjonelle data i en lagringsarkitektur •Viktig twist er metadata om de forskjellige informasjonsmengdene og som «immutable time-series» dokumenter •ODS støtter implementasjon av strategien på flere områder: •Masterdata, ett sted for konsumenter å henvende seg •Migrering, fordi data fra gamle siloer lagres her (og også skjermer soliene for uhåndterbare krav til oppetid og sikkerhet) •Kundefokus •Risikobasert behandling •Langtidslagring •Det er ikke det å integrere de forskjellige typene som er viktig •Integreringen skjer hos konsumenten! •«Canonical» eller Universell modell er ett anti-pattern 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 18
  • 19. REST •«Representational state transfer» •Den åpenbare kandidaten gitt internett sin utbredelse •Bygger på HTTP (som kanskje burde vært en av teknologiene nevnt ovenfor) •Inneholder også feeds som er en implementasjon for events •Vi er ikke tvingende for WS eller REST •REST’ viktigste bidrag som protokoll er at den er tydelig på tilstandsovergang i et distribuert miljø med varierende latency (RPC og WS skjuler denne kompleksiteten) 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 19
  • 20. 3 Komponenter 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 20
  • 21. SkatteInfo 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 21 • Dokumentlager (SkatteInfo) • Tar forvaltningsloven på kornet • Felles arkivnøkkel • Arkivert og versjonert • Uavhengige «områder» • Skalerbar for ytelse • Enkel for 24/7 bruk • Søkemotor – «Skattefinn» • Felles tilgangskontroll og sporing • Prosesslag (Micro Services) • Årvisse uavhengige komponenter • Hendelsesstyrt gjennomløp • Løpende forretningsmessige vedtak og tilrettelegging • En komponent inneholder forretningslogikk og støtte for saksbehandling for ett «område»
  • 22. Saksmappe 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 22 •Metadata og referanser til saksinnholdet •Hvert vedtak lagres som en ny versjon (xml-dokument) •Fokuser på Sakens innhold og tilstand, ikke prosessen •Rettssikkerhet •Saksbehandlers tilgang styres av Saken, som igjen gir tilgangs til dokumenttyper definert av sakstypen •En Sakstype har en applikasjon med reglene for denne saken •Konsistens sikres ved at saksmappe-dokumentet må være nyere enn alle relevante dokumenter •Forvaltningsloven (NOARK-5) i kjernen av fagsystemet
  • 23. Attributbasert tilgangsstyring (ABAC / PBAC) •Referansearkitektur for tilgangsstyring •Policy Enforcement Point •Policy Decision Point •En policy er bygd opp av følgende attributter •Subject er den som ber om aksess •Action er handlingen som ønskes utført •Resource er informasjonsobjektet som handlingen ønskes utført på •Environment identifiserer i hvilken kontekst objektet blir forespurt på Saksbehandler for en sakstype skal ha tilgang til informasjon som angår saker av denne typen •Versjonerte Saksmappe og SkatteInfo-dokumenter - sammen med metadata - gir en elegant og håndterbar måte av avgjøre «Resource» 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 23
  • 24. Egenskaper 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 24
  • 25. Egenskaper (til Micro Services) ved at moduler lar seg teste hver for seg i en tydelig verdikjede 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 25 Skalerbar Testbar Enkel ved at regler, informasjon og prosess er tettest mulig opp mot forretningsbegrep ved at volum og svartider lar seg løse ved kjøp av mer hardware, og ikke igjennom å skrive om regler, informasjon eller prosess
  • 26. Takk for meg Alle mine presentasjoner ligger på http://slideshare.net/tormodv Blogg: http://tormodv.blogspot.no/ Twitter: @tormodvar LinkedIn: https://no.linkedin.com/in/tormod-varhaugvik-b6170a 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 26