Kinderegget enklere billigere og mye raskere_baksia
1. ”Kinderegget”;
enklere, billigere og mye raskere
Softwaredesign for ”in-memory” arkitektur
• Hvordan utnytte den nye plattformen?
Tormod Varhaugvik, SKD SITS, Mai 2013
tormodv.blogspot.com
2. Innovasjon fra Skatteetaten
• Designet du nå skal få se, gir helt nye muligheter
• Satt sammen av erfaring, teknologi og gode mønstre
• Mange komplekse domener med sammensatt informasjon og
regler, kan fungere side om side i samme system
• I tillegg til å kunne yte svært mye bedre
• Og være mye lettere å forvalte
• Revolusjon for «Saksbehandlingssystemer»
• Vi bygger nå på denne måten
• Passer både In-Memory, BIG-data og PaaS
• Vi deler!
• Designet er dokumentert i en serie artikler på http://tormodv.blogspot.com
• Kildekoden fra PoC tilgjengelig på GitHub
30.05.2013Skatteetaten 2
3. 30.05.2013Skatteetaten 3
Muligheter
• Flerkjerne CPU
• Mange billige standard maskiner
• Vi må designe for parallellitet
• Skalere ”ut av boksen”
• Ikke alle problemer passer
• Markedssituasjon, nå og framover
• Kompetanse og infrastruktur
• Involvere markedet
• IaaS, PaaS
4. 30.05.2013Skatteetaten 4
DDD i Space Based Arhitecture
Space-Based Architecture (SBA) is a software architecture pattern for
achieving linear scalability of stateful, high-performance applications,
based on Yale’sTuple-Space Model (Source Wikipedia)
Aggregate
En mengde data som
endres samlet
5. 30.05.2013Skatteetaten 5
Realiserbart!
• Erfaring med Smalltalk viste meget stor effektivitet
når man kunne ha forretningslogikk horisontalt
• Ekte objektorientering
• Lekker og veldikeholdbar kode (DSL)
• Kommer langt med en enkel programmeringsmodell
• Erfaring med domene-orientert distribuert system
viser at meldinger til sammen bygger opp ett
system
• En Moduls data kan bygges opp ”fra ingenting”
• Fikk kontroll på datamodellen og forretningshendelser
• Dokumentene er grensesnitt mellom Modulene
• En stor datamodell kan (og bør) deles opp i Aggregater
• Likhet med Finans og Gambling er slående
• Det John Davies / Cameron Purdy har messet om lenge!
6. 30.05.2013Skatteetaten 6
Kontinuerlig tilrettelegging av Aggregater
Forskjellige
aggregater side-om-
side for skattyter
Kontinuerlig
tilrettelegging
Tuple er et xml-
dokument som
inneholder
aggregat
XML for lang
holdbarhet
Processing unit
er en module
Unik produsent
av aggregat
Module har en
bounded context
Last et sett
aggregater og
produserer et nytt
Uavhengige
contexts
Massiv spørring
Alle aggregater
på samme sted
Tilstand på
aggregatet styrer
prosessen
Skiller
produksjon
fra bruk
Alle aggregater
innkapsles i et
super-dokument
Modulene avgir
tjenestekomponenter
til SkatteInfo
SkatteInfo er en
super-repository
Løs kobling
mellom aggregater
(Skattyter, context
og årsversjoner)
http://tormodv.blogspot.com/2010/11/concept-for-datastore-and-processing.html
7. 30.05.2013Skatteetaten 7
Tekniske egenskaper
• Parallelliserbar
• Skill utvalg…
• … fra behandling
• … fra lagring av resultat
• Prosessfokus
• Automatisk saksbehandling
• Manuell saksbehandling
• Kontinuerlig tilrettelegging
• Åpne standarder
• Kapsle inn forretningslogikk
• xml, java, kontainer, web
• Leverandør / plattformuavhengig
• Plattform i utvikling
• Objektorientert
• Rik semantikk, DSL
• xml 1:1 med java (aggregatet)
• Test og drift
• Automatisk / avgrenset test
• Omkjøring ifbm feilretting
• Simulering / ”dry run”
http://tormodv.blogspot.com/2010/12/continual-data-hub-architecture-and.html
9. 30.05.2013Skatteetaten 9
Del opp problemet – ”Aggregate design”
Nøkkel-objekt
”Aggregate root”
Nøkkel-objekt
”Aggregate root”
Nøkkel-objekt
Tydelig tilgang,
konsistens og
innkapsling
•God innkapsling er egentlig bare god design
•God tjenesteorientering
•Det gir forvaltbare og testbare komponenter
•Der gir uavhengige informasjonsmengder
•Uavhengighet gir parallellitet
A
B
C
Informasjon
kan ikke sees
på alene!
Oppførsel må
også med…
Nå har vi 3
aggregater:
A, B og C
10. 30.05.2013Skatteetaten 10
Grid arkitektur: Monster minne
Applikasjon
Minne og prosessering som
omfatter flere maskiner
Disklager i bakkant
C
B
A
Key
Key
Key
Value
Value
Value
• Frikobling i datalaget
• Sammensetting skjer i Applikasjon
• Forretningslogikk skjer i Applikasjon
• Nøkkelobjektet kan være sammensatt
• Applikasjon er upåvirket av volum og krav til svartid
• Big Data – NoSQL – Natural Format
Value
Key
Aggregate
Header
Value
11. The XML-document – Master template
30.05.2013 12
Head
Document internal state
Aggregate
Anomalies
Audit
• The Head is
• key object
• classification of information
• also a protocol and interface
• The Head is to the Repository as
a Library Catalogue Card is to a
Library
• Robust and Consistent
• Independent and Shardable
• Reduced I/O and Concurrent
• Historically Correct
• Business Event and Data
• External XML-schemas
• Search Engine
• (Only one producer, this is no database system!)
12. The XML-document – Tax Assessment form
30.05.2013 13
• Main subjects are debit and
credit of a transaction, under
what legislation, at what time,
and who we should trust this
information
• Immutable when ‘public’
• New version on update
• Transparency by referencing
underlying documents
• Consistency by referencing
underlying documents
• Complete audit in the same
document
• Insight without business logic
• The interface to any consumer
GUID,
concerns,
reported by,
schematype,
legitimate period [income year, date period],
timestamp,
state [private, public, deleted, replaced]
replaced by GUID
phase [prognosis, prefilled, delivered, assessed, complaint]
version
module state [new, manual handling, finished]
field2.1.1
text
value
ref GUID
field3.1.12.7
…
field5
GUID
description
concerns fields this.URI
user name
timestamp
event, reason
concerns fields this.URI
13. The Application – Cloud Enabled
• The Business Logic run here
• Overly simplified, but still illustrates that information is taken out of their
coarse documents, and - through an Anti Corruption Layer -, structured
in a specific Domain
• Eventually Consistent: Comparing last version of C to new version
of C as a consequence of changes to A or B is vital
30.05.2013 14
C
B
A
Key
Key
Key
Value
Value
Value
Services User Interface
ACL
TaxInfoRepository
Other Repositories and Services
ACL
ACL
14. 30.05.2013Skatteetaten 15
Continual Aggregate Hub
• Big Data repository of Documents
• Immutable & versioned (legislation)
• All versions and business side-by-side
• Simple for 24/7 usage
• Search engine
• Access control
• In-memory processing layer
• Explicit code, Transient, Versioned
• A Module consists of business logic and its GUI
• Design patterns
• Domain Driven Design
• Tuple Space, CQRS, BASE, SOA, ODS
• XML-documents, plain Java and REST
100’ of document types
100’ of applications
Cloud enabled
Vast deployment options
16. 30.05.2013Skatteetaten 17
Utfordringen => Proof of concept
• Hvordan skifte kurs?
• Beslutningstagerne kan ikke dette
• Skape felles forståelse rundt arkitekturdiskusjoner og valg
• Å redusere risiko i planlegging og estimering
• Innsalg og troverdighet
• 1000 ganger ytelse?
• Hardware < 10%?
• Kodeforvaltning skost < 30%?
• => Særlig!
http://tormodv.blogspot.com/2011/09/tax-norways-proof-of-concept.html
Okt ’09: Utfordringen VA
Mars ’10: Godkjent VA
Mai ’11: Gjør PoC
Jan ’12: PoC Suksess!
Mars ’12: Endre kurs…
Mars ’13: PaaS…
Jan ’13: 1. i produksjon
FUD
17. 30.05.2013Skatteetaten 18
Proof of Concept mål
• Enkel; ved at regler, informasjon og
prosess er tettest opp mot
forretningsbegrep
• Testbar; ved at moduler lar seg teste hver
for seg i en tydelig verdikjede
• Skalerbar; ved at volum og svartider lar
seg løse ved kjøp av mer hardware, og
ikke igjennom å skrive om regler,
informasjon eller prosess
http://tormodv.blogspot.com/2011/09/tax-norways-proof-of-concept.html
18. 30.05.2013Skatteetaten 19
Kjøremiljø
30.05.2013 19
Maskin (server) Maskin (server) Maskin (server)
Grid-node (JVM)
Skattefamilie
Lønns- og trekkoppgaver
Saldo- og rentemeldinger
PSA
Grid-node (JVM)
Skattefamilie
Lønns- og trekkoppgaver
Saldo- og rentemeldinger
PSA
Grid-node (JVM)
Skattefamilie
Lønns- og trekkoppgaver
Saldo- og rentemeldinger
PSA
• Alle noder er funksjonelt like
• Hver node har sin andel data
• Skattefamilie samlokalisert
• ”Grid” skjermer teknisk kompleksitet
(partisjonering, søk, jobber, redundans, overflow,
lagring, failover, indekser, med mer.)
• Transparent for logikken
• Flokkoppførsel
• Elastisitet, omkonfigurasjon
• Overvåkning (teknisk)
• Konsistens (funksjonelt)
• ”Rett på jernet”, ikke virtualiser
• Hva hvis strømmen går?
19. 30.05.2013Skatteetaten 20
Estimert fullskala produksjon
• 28.000 Selvangivelser (3kB) i sekundet (ca 3 min)
• 56.000 Skatteberegninger (1,5kB) i sekunder (ca 90 sek)
• 5.100.000 Selvangivelse & Skatt og Skattekort
• 80.000.000 Grunnlagsdata & Underskjemaer (1,5kB)
• 120 Gb RAM netto
• 370 Gb RAM brutto med 1x redundans og indekser
• 12 Servere (Intel i7) a 32 GB
• Last av XML fra fil: 6000tps => 5 timer
• Ekstrem ytelse ikke så viktig i seg selv, men gir handlingsrom
• Kost ca 400.000 i servere og 1 million i lisens
• Minneallokering tar tid, ikke logikk
http://tormodv.blogspot.com/2012/01/tax-norways-poc-results.html
20. Deploy muligheter
• In-memory – Processing Grid (~GemFire)
• Pro. Ultra low latency. Elastic (scale and re-balance)
• Con. Cost. (Open Source not stable enough). Heap limitation leads to
many VM’s. Business code and data are close, leads to deployment
issues.
• In-memory – Data Grid (~Terracotta)
• Pro. Elastic (scale and re-balance). Number of VM’s solely by
processing modules. Business code and data are separate, better
deploy situation. Low latency (serialisation, but on same machine).
• Con. Cost.
• Distributed database – Big Data (~Hadoop)
• Pro. Super simple VM (jetty) that only handle local data. Cost. (Open
Source stable). Business code and data are separate, better deploy
situation. Number of VM’s solely by processing modules.
• Con. Slow elastic (scale and re-balance). Disk-to-disk. Latency (map-
reduce)
30.05.2013Skatteetaten 21
21. 30.05.2013Skatteetaten 22
Erfaring
• Konseptet innfrir!
• Forretningsnær og vedlikeholdbar kode kan yte sykt bra
• Funksjonelle tester som regneark
• Kode som fagperson kan lese (DSL)
• Informasjonsmodellen er også viktig
• Åpne standarder gir verktøy, komponenter og markedsstøtte
• Handlingsrom for valg av kjøreplattform, skalere ved behov
• Omskriving av «Legacy» er høyst oppnåelig
• La POJO utvikling være styrende, ikke xml-definisjoner
• Passer også for andre applikasjonstyper
• Lagre aggregatet når det passer, mye trenger ikke lagres
putSumPost("3.4", sum(post("3.1.14"), minus(post("3.3.13"))))
putSumPost("3.5.1",hvis(post("3.3.7.3")).er(kr(0)).brukDa(hvis(post("3.5.1.1")).ikke
Er(kr(0)).brukDa(post("3.5.1.1"))))
22. 30.05.2013Skatteetaten 23
Softwaredesign er gull
• Ta det på alvor, det er lov å tenke seg om
• Fysiske lover kan ikke brytes,
… men ting kan gjøres smart
• Isoler foretningslogikk fra teknisk arkitektur
• Ta grep om tilstand på Aggregat-nivå
• Software må skrives om for å dra nytte av ”dette nye i skyen”
• Testbarhet, enkelhet og parallellitet går hånd i hånd
• Gull også for de som ikke har store datamengder
• Dette er forretningssystemet, ikke baren «cache»
Lev deg inn i DDD. POJO er din beste venn
http://tormodv.blogspot.no/2012/02/module-and-aggregate-design-in-cah.html
23. Takk!
• http://domaindrivendesign.org/library/vernon_2011
• http://www.infoq.com/minibooks/domain-driven-design-quickly
• http://tormodv.blogspot.com/2011/02/comment-on-restful-soa-or-domain-driven.html
• http://tormodv.blogspot.com/2010/11/concept-for-datastore-and-processing.html
• http://tormodv.blogspot.com/2011/02/document-store-for-enterprise.html
• http://tormodv.blogspot.com/2012/01/tax-norways-poc-results.html
• http://tormodv.blogspot.no/2012/02/module-and-aggregate-design-in-cah.html
• http://tormodv.blogspot.com/2011/09/dont-let-enterprise-service-bus-lead-to.html
• http://tormodv.blogspot.com/2013/01/target-architecture-looking-good.html
• http://www.slideshare.net/tormodv
• http://www.tu.no/it/2012/10/19/1000-ganger-raskere-skatteoppgjor
• http://heroku.com
• http://www.regjeringen.no/nn/dep/fin/pressesenter/pressemeldingar/2012/enklare-for-
naringslivet-med-edag.html?id=682401
30.05.2013 24
My blogs are written for stakeholders and architects, and meant to be as timeless as possible.
24. Platform as a Service (Heroku)
• «Container» og «stack»
• Grensesnitt-container
(maskin og bruker)
• Arbeider-container
• Køer, Timere
• Logging og overvåkning
• HTTP (HTML/REST)
• Hendelses-drevet
• Orkestrering styres av
arbeider-container
• Datalager tilpasset struktur
• Datalager innkapslet av
grensesnitt-container(e)
30.05.2013Skatteetaten 25
Tilstand
Heroku er valgt som eksempel på PaaS, og ment illustrerende.
Det er på ingen måte et valg eller anbefaling fra Skatteetaten.