Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
I gamle dage – det vil sige i forrige årtusinde – holdt man kurser i database-design, og på de kurser rendte man altid ind i Alice og Bob:
Casen var at Alice og Bob har hver sin konto i samme pengeinstitut. Alice beslutter at overføre 10 kroner til Bob. Det vil sige, at Alices konto skal nedskrives med 10 kroner. Bobs skal opskrives med 10 kroner.
Hvis ikke begge processer lykkes (eller hvis ikke begge mislykkes) så har vi kaos: Banken har foræret 10 kroner til Bob, eller banken har hugget 10 kroner fra Alice.
It-teknisk indebærer det, at bankens database skal bringes i en konsistent tilstand efter transaktionen, og løsningen indebærer et 'commit'-begreb.
Det vil sige, at først efter at databasen får tilbagemelding fra begge konti om, at handlingen er lykkes (herunder: at Alices konto ikke går i negativ saldo), markeres 'ok'.
I modsat fald markeres 'fejl', og hvis én af de to konti har gennemført, så vil databasesystemet rulle denne opdatering tilbage.
Desuden vil databasen i de nanosekunder hvor transaktionen kører, markere Alice og Bobs konti som utilgængelige for andre transaktioner – det vil sige, at hvis Clarissa kræver 20 kroner fra Alice, må denne transaktion vente til Alices indestående igen er kendt.
Vi har en arkitektur hvor data og tilstande er Gud, hvor databasen er centrum.
'SQL-database og commit' er begreberne her. Ordet 'commit' betyder: At skabe enighed om en tilstand.
Hændelsesorienteret arkitektur har sejret big time
Men i vore dage... Alice og Bob har konto i hver sin fintech-virksomhed, og den finansielle branche går ud på at forbinde alle disse aktører.
Hændelsesforløbet skilles dermed ad.
Det er ikke længere den koordinerede håndtering af tilstandene hos Alice og hos Bob; det er en transaktion (en hændelse) som skal håndteres i flere it-systemer.
It-teknisk er løsningen at have et sikkert kommunikationslag som kan garantere at de 10 kroner fra Alices konto i Fintech-A når frem til Bobs konto i Fintech-B på et eller andet tidspunkt.
Det vil sige, at hvis Fintech-B er lukket ned på grund af strømsvigt eller hackerangreb, så står pengene sikkert og venter i kommunikationslaget.
Der er ikke behov for nogen overordnet kontrol på at transaktionen fungerer.
Vi har en arkitektur bygget op om uafhængige hændelser.
Sikker kommunikation bliver Gud: For eksempel 'Visa' og 'Nets' er firmaer som har slået sig op på at indgå i et sådant kommunikations-lag i den finansielle branche.
Men hændelsesorienteret arkitektur er mere: Det har naturligt nok bredt sig til en ide om, at også den interne organisering af et firmas it skal bygge på 'kommunikation mellem micro-services'.
Et argument for dette er, at SQL-databaser ikke skalerer perfekt.
Du kan ikke bare tilføje servere ad libitum: Der skal være en fælles commit-mekanisme og dermed (groft sagt) et krav om, at hele molevitten ligger i samme adresseringsrum.
Så hvis du vil vokse til Amazon-størrelse, kan du ikke bygge på SQL.
64 bits adressering giver rigtig meget plads, men 10.000 servere kan ikke dele det samme adresseringsrum.
En IBM-mainframe har for eksempel 50 fler-kærne processorer, som skyder mod samme adresseringsrum.
Flere sådanne kan kobles sammen, men der ligger nogle fysiske begrænsninger og lurer her.
Et andet argument ligger i selve begrebet 'micro-services', det vil sige ideen om at hele systemet kan udvikles via et stort antal små og helt uafhængige funktioner, som hver servicerer et enkelt aspekt.
Et sådant setup gør jo planlægning og opbygning af systemet nemmere end hvis 'alt hænger sammen' som det gør i tilstandsorienteret arkitektur, med kravet om fælles datastrukturer og fælles commit.
Det her ligner et paradigmeskifte: Ud med SQL-databasen (Oracle, Db2, ...), ind med hændelserne.
Slagord som 'ud med mainframe', 'væk fra legacy', 'data-lake', 'micro-services', 'noSQL-databaser' dækker typisk over en overgang fra tilstandsorienteret til hændelsesorienteret arkitektur.
Selv om ikke alt i verden kan føres ind under denne diskussion: Der er andre moderniseringsbehov end tilstande kontra hændelser.
Og en SQL-database kan udmærket håndtere hændelser; omend det kan være en unødig kompleks teknik i forhold til opgaven. Hændelser skal aldrig opdateres; sket er sket.
Ordet (produktet) 'Kafka' er nok den klareste markør for, at vi snakker hændelsesorienteret arkitektur. 'Kafka' er en kommunikationsprotokol uden et commit-begreb.
Hændelsesorienteret arkitektur betyder, at man holder styr på transaktionerne, men ikke på deres resultat. Man vedligeholder ikke nogen database med saldo for hver konto, man registrerer blot alle transaktionerne (hændelserne) i en række 'flade' databaser.
Ok, ikke helt flad: en hændelse beskrives i en datastruktur og kan rumme nøglehenvisninger til referencetabeller.
Ud fra hændelserne kan man på et hvilket som helst tidspunkt finde en hvilket som helst saldo ved at scanne databaserne igennem.
Der bliver ikke noget commit-problem. Hændelsen i det indledende eksempel skal blot registreres som én hændelse: 'flyt 10 kroner fra Alice til Bob'. (Og da der var flere firmaer involveret, sendes blot denne hændelse til de øvrige firmaer via sikker kommunikation).
Hvis nogen på et tidspunkt efterspørger saldo hos Bob (eller hos Alice) adderes blot alle transaktioner, som rammer kontoen.
Problemet med overtræk af konti løses ved at håndtere og vedligeholde en kreditvurdering.
Altså at besvare spørgsmålet 'Er Alice tæt på sin kreditgrænse?'. Dette ligger lige til højrebenet for en micro-service.
At maskinerne er blevet hurtige og rummelige spiller ind her.
Med et antal 3 Ghz processorer og et antal 64 bit adresseringsrum tager det ikke mange øjeblikke at scanne firmaets databaser igennem. ('G'et i Ghz står jo for en milliard logiske operationer pr sekund).
Man kan stramme denne argumentation: Hvorfor så bruge tid på databasedesign og -normalisering, når hverken plads eller tid bør være et problem længere?
Overhovedet er tilstandsbegrebet en pladsbesparende sammenfatning af et hændelsesforløb. For eksempel tilstanden 'dårlig betaler' frem for personens faktiske betalingsforløb.
Men hvorfor spare plads?
Krypteret kommunikation er en væsentlig forudsætning
Sikker kommunikation er dog nok væsentligere, end at maskinerne er blevet hurtige: Krypteret kommunikation betyder 100 procents sikkerhed for, at de bits, der sendes ind i kommunikationssystemet, når frem til modtageren; støj på linjen kan hverken tilføje eller fjerne bits undervejs.
Krypteret kommunikation er ikke bare, at Darth er afskåret fra at lytte med på kommunikationen mellem Alice og Bob, det er mindst lige så vigtigt, at krypteringen garanterer, at det, der når frem, er korrekt.
TCP-IP-protokollen bag internettet har det problem, at hashdannelsen er for svag: Ikke alle bit-fejl i kommunikationen bliver afsløret. (TCP-IP-standarden blev fastlagt i 1982, og ud fra datidens ressourcer),
Men med kryptering ovenpå TCP-IP, så spiller det korrekt. En fælles, overgribende 'mainframe'-agtig opbygning er ikke længere nødvendig.
Så vi gamle mainframe-folk med vores perfekte viden om SQL, commit og databasedesign, kan godt pakke sydfrugterne.
... mens Alice og Bob har været ændringsparate: Alice krypterer med sin private nøgle plus Bobs offentlige nøgle, Bob dekrypterer med sin private nøgle og Alices offentlige nøgle. Vi bruger ikke længere Alice og Bob til at forklare database-commit, men til at forklare sikker kommunikation mellem servere indenfor og udenfor egen organisation.
Hvor på hype-kurven er vi?
'Word' og 'Excel' var i gamle dage programmer, som gemte hele det aktuelle udseende af dokumentet, når man trykkede 'save'.
Hvis maskinen gik ned, inden man gjorde dette, ja så var ens ændringer gået tabt.
Flere personers ændring i samme dokument kunne ikke håndteres: dokumentet var låst for andre, så længe du arbejdede i det.
Men i dag: grundideen i programmerne er nærmere 'at logge tasteanslag'. Ud fra logningen kan du så danne og fremvise uddrag af dokumentet på skærmen.
Du kan også lige så nemt fremvise, hvordan dokumentet så ud bagud i tiden: Du har en perfekt registrering.
Håndtering af pegefelt gør tingene noget mere komplekst, men med registrering af 'hændelser' i stedet for 'dokument' har du teknikken bag, at man i Microsoft Teams kan fornøje sig med samtidig editering af et dokument fra flere brugere.
Og begrebet 'save' er blevet morfar-agtigt; virkeligheden flyder (som den jo gør), at fastlåse en række konsistente helhedsbilleder af et område... hvorfor dog gøre det?
Selv SQL-databasen, Den Hellige Gral i tilstandsorienteret arkitektur, er delvist hoppet på hændelsesvognen: Db2 bygger i dag på, at alle opdaterende hændelser mod databasen logges – ikke at før- og efter-images af entiteter (dvs. tilstande) logges, som de gjorde i gamle dage. Fra denne hændelses-logning kan databasen rekonstrueres i tilfælde af strømsvigt eller det der er værre.
'AI', dvs. kunstig intelligens, er koblet til ovenstående diskussion.
Mottoet for AI er vel 'End of Theory', altså at vi teoretikere sammen med de andre konspirations-teoretikere godt kan pakke vore sydfrugter sammen:
Lovmæssighederne ude i virkeligheden afsløres via AI, altså ved at finde mønstre i hændelserne, ved at trawle data-søens registreringer af hændelser igennem, ikke via dybsindige sproglige, skriftlige analyser, ikke ved at skabe begrebsapparater og så bruge disse tilstands-begreber til at skabe modeller og skabe forståelse og skabe forudsigelses-kraft.
Albert Einsteins tilgang – glem den. Hvis Alice ønsker viden om Bob, så bruger hun kunstig intelligens til at finde mønstre i hans handlinger, hans hændelser.
Ok, vi er nok her ved at bevæge os ind på et område på hype-kurven, som mangler bæredygtighed: Så entydigt er begrebet 'moderne it' heller ikke. Og 'teorier' og 'begreber' indgår fortsat i vores virkelighedsopfattelse.
Hændelsesorienteret arkitektur har af gode grunde sejret big time, men verden er ikke flad, og håndtering af komplekse datastrukturer i et tidsforløb er stadig et interessant design-princip.
Normaliseringsbegrebet i databasedesign er ikke bare en forældet kamp for at spare plads, det kan bidrage til begrebsmæssig afklaring.
Sankt Peter og hændelsesorienteret arkitektur
At arbejde med begrebs-afklaring og begrebs-opbygning ligger dybt i vores tænkning og vores (vaklende) intelligens, og ligger dermed dybt i vores juridiske strukturering af samfundet.
Det var – i gamle dage – kun Vorherre og Sankt Peter forundt at 'gøre regnebrættet op', og vurdere hele striben af gode og dårlige gerninger. Vi jordiske mennesker måtte (og må?) nøjes med vore kategorier og tilstande, såsom at ham personen der tilhører 'de brådne kar'.
Handelsplatformen 'Amazon' er pga. størrelsen bundet til at køre hændelsesorienteret arkitektur, og det går også fint, faktisk helt forrygende.
Men en konsekvens af arkitekturen er, at Amazon ikke kan svare her og nu på, om det her lyserøde hundedækken eller bogen 'The Da Vinci Code' lige er blevet udsolgt; det kræver et gennemløb af hændelsesregistrene for at opgøre en lager-status.
Ikke noget stort problem for Amazon. Just-in-time håndtering af varestrømme prøver at gøre begrebet lager-status irrelevant.
Det går ikke helt så nemt hos Monte Python: Der er talrige indicier på, at papegøjen er død, dvs. en række hændelser peger i den retning. Men tilstanden 'This parrot is a dead parrot', bliver aldrig konkluderet. Hvilket giver en vanskelig handels-situation.
Virkeligheden består af hændelser, som i en efterkalkulation summerer sig op i tilstande.
Hændelserne skal registreres, hvis vi skal nå frem til en konklusion, et billede af hvad tilstanden er. Og ja, nye hændelser vil til stadighed modificere billedet og ændre den tidligere konklusion.
Dette flimrende billede kan gerne opfattes som 'det moderne samfund'.
At holde styr på tilstande, på bankkonti, og på hvem der ejer hvad, var mere i fokus i min barndom tilbage i 1950'ernes mangel-samfund. Mens i vore dage: delebiler erstatter stolte bilejere, etc.
Samfundet er dog generelt ikke blevet mindre juridisk præget end den gang. Om der så ligger en anakronisme i det eller ej: Juridisk at kunne fastslå tilstande versus lovregler betyder meget - her i landet, og ikke mindst i USA.
Hændelsesorienteret arkitektur passer rigtigt godt ind i det moderne samfund, problemet er bare, hvor moderne det moderne samfund egentligt er.
Jura ser ikke samfundet som et flow af hændelser men forudsætter, at tilstande lader sig fastslå.
Det er ikke nok, at man når som helst kan trække en konklusion om saldoen og kreditværdigheden; opgaven er at samle et konsistent billede af situationen på et givet tidspunkt, og herudfra foretage den juridiske afgørelse.
Typeeksemplet er 'at gå konkurs'. Delinkventen mener naturligvis, at han er lige ved at ramme den næste guldåre, så hvis bare vi venter lidt, og lader de kommende hændelser hænde... Mens juraen forsøger at opbygge et konsistent billede, en tilstand, på et fastlagt tidspunkt.
Inspector Barnaby fokuserer på tilstande
Offentlig administration – og en del privat ditto – er fundamentalt forskellig fra situationen, når 'Amazon' sælger et lyserødt hundedækken.
Hændelser er stadig fundamentet, men tilstands-håndtering er langt mere i fokus. Det er, som når inspector Barnaby går rundt i sin tv-serie og spørger: "Hvor var du kl 23.21 fredag aften?".
Opgaven er at finde ud af, hvor alle Midsomers sære eksistenser befandt sig på dette tidspunkt. Ikke hvor de befinder sig nu eller for lidt siden, ikke at koble sig ind på det flow af hændelser, som udgør deres videre liv.
Opgaven er at summere en lang række forskellige hændelsesregistreringer op til en status på et givet tidspunkt. At trawle hændelser igennem på juridisk fastlagt vis...
At kalde noget sådant for en micro-service, et lille lag ovenpå hændelsesregistreringerne, kan være ganske misvisende.
Fx: Der registreres en fartbøde, og systemet checker, hvor mange klip der findes i kørekortet i forvejen for at danne en konklusion.
Eller: En person rejser ind i USA. Hvad har vi registreret på ham, er der et mønster i hans rejser, bidrager denne indrejse til dette mønster? Hvilken tilstand kan vi fastslå, og skal han afvises, arresteres, eller få lov til at komme ind?
Der findes små og store administrative systemer, men indenfor det offentlige betyder juridisk nidkærhed opsamlet i en voksende lovgivning, at systemerne tenderer mod at være store og med omfattende datagrundlag.
Så hændelsesorienteret arkitektur kan glide over i tilstandsorienteret arkitektur, og SQL-databasen kan blive en central del af løsningen.
Hvorvidt det andet store dyr i Åbenbaringen: mainframen, også indgår i løsningen, afhænger at behovet for tværgående commit.
Hvis databaseposterne begynder på at blive gift med hinanden, skilt, indgå aftaler, danne fælles firmaer etc., så kan det være en fordel at kunne håndtere tværgående commit i et stort fælles adresseringsrum.
Dette kan også håndteres på tværs af flere servere, men hvis serverantallet stiger, vil låsningsproblemer blive et issue.
'All theories are wrong, but some are useful'
En vis Stewart Alsop blev i 1991 kendt for evnen til at spå om fremtiden: "I predict that the last mainframe will be unplugged on 15 March 1996."
Han så det indlysende: At systemer bygget på et antal servere er nemmere og billigere at håndtere end en monolitisk mainframe.
Men han manglede en forståelse for, hvad en mainframe kan som rammen for en stor monolitisk SQL-database med fælles adresseringsrum. Og hvorfor dette SQL-setup – mainframe eller ej – stadig har sin niche, nemlig tilstandsorienteret arkitektur.
En niche, som kan skyldes manglende mulighed for nytænkning; en niche, som kan skyldes træghed i samfundets juridiske strukturer, men som også kan skyldes, at opgaven kun kan løses i tilstandsorienteret arkitektur.
"All theories are wrong, but some are useful", sagde Albert Einstein engang, dvs. vores konklusioner om verdens tilstande er nok forkerte, men vi er nødt til at have nogen.
'Moderne it' defineres bedst ud fra sin modsætning: SQL. Ligesom for eksempel liberalisme fremstår klarest, når man beskriver socialismens idealer. Uden modsætninger, ingen begreber.
Men, som i den politiske debat, er en meget sort-hvid holdning ikke konstruktiv.
Ovenstående bør være paratviden for en it-arkitekt – men er dette tilfældet, eller har vi blot it-evangelister gående iblandt os?
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.