Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fra silo til micro services

1,578 views

Published on

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.

Published in: Software
  • Be the first to comment

Fra silo til micro services

  1. 1. Fra Silo til Micro Services; 3 + 8 + 3 Tormod Varhaugvik, SKD, SW 2016
  2. 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. 3. 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 3 Agenda •Strategien •3 basis teknologier •8 designmønstre •3 komponenter •Egenskapene
  4. 4. Strategien 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 4
  5. 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. 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. 7. 3 Teknologier 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 7
  8. 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. 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. 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. 11. 8 Designmønstre 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 11
  12. 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. 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. 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. 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. 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. 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. 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. 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. 20. 3 Komponenter 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 20
  21. 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. 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. 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. 24. Egenskaper 12.02.2016Fra Silo til Micro Services; 3 + 8 + 3 24
  25. 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. 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

×