Kinderegget enklere billigere og mye raskere_baksia

”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

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.2013 Skatteetaten 2

http://tormodv.blogspot.com/


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


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


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!


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











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











Softwaredesign


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


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

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!)

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

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

AC

L

TaxIn

fo R

epository

Other Repositories and Services

ACL

ACL


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


Proof of concept


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











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












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



PSA

Grid-node (JVM)

Skattefamilie



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?


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








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)



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"))))


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












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.










http://tormodv.blogspot.com/2011/02/document-store-for-enterprise.html

























http://www.slideshare.net/tormodv














http://tormodv.blogspot.no/2013/01/target-architecture-looking-good.html








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










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)


Tilstand

Heroku er valgt som eksempel på PaaS, og ment illustrerende.

Det er på ingen måte et valg eller anbefaling fra Skatteetaten.

Technology

Kinderegget enklere billigere og mye raskere_baksia