Presentasjon fra Arkitektur i praksis på Software 2016. Modernisering av gamle systemer viser seg meget vanskelig. Det er ikke bare å skrive om. Skatteetaten har klart ett paradigmeskifte både på arkitektur og implementasjon, og presenterer mønstre bak reelle løsninger. For å dra nytte av nye teknologier (PaaS, In-memory, NoSql, Reactive, Immutable) må du forstå hvordan domenet skal representeres i det nye. Jeg opplever at det er utfordrende for mange å forstå dette paradigmeskiftet, som representerer løsninger for det 21. århundre. 3 basisteknologier, 3 sentrale komponenter og bruk av 8 designmønstre presenteres i detalj for å forklare helheten.
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
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.
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
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
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
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