Dagen din startet kanskje med at du våknet opp, tok deg en dusj, tok på klær, spiste frokost - hvis du har bil, startet denne for å komme til jobben. I disse korona-tider ramlet du kanskje bare inn på hjemmekontoret.
Alle disse tingene er hendelser som beskriver hvordan morgenen din var.
I software har vi i alle år bare vært mest interessert i øyeblikksbildet som er her og nå. Uten tanker om hvordan vi kom dit. For å forstå hvordan vi kom til nåsituasjonen, har vi benyttet oss av logger fra databaser og applikasjoner.
I Aksio har vi snudd dette bildet på hodet og ser alt ut fra hendelser. Dette tankesettet kalles «Event Driven».
Men vi går et skritt videre - vi er «Event Sourced». Alle hendelser skal lagres. Hendelsene får nøye gjennomtenkte navn, holdes så små som det er hensiktsmessig. Ut fra dette kan vi skape så mange øyeblikksbilder vi ønsker, såkalte «Projections».
For oss er den tradisjonelle databasen bare et sted for øyeblikksbilder. Den faktiske kilden til sannheten er i vår «Event Store».
- De som ikke har et aktivt forhold til dataene sine lever på overtid, og vil slite fremover
Cloud first
I tradisjonelle databaser snakkes det om ACID (Atomicity, Consistency, Isolation, Durability). Dette er typiske egenskaper i transaksjonelle systemer.
For å få mest mulig utbytte av en distribuert virkelighet - i cloud - har vi valgt andre ord bak forkortelsen ACID; Associative, Commutative, Idempotent, Distributed:
- Associative - samme resultat uavhengig av gruppering
- Commutative - samme resultat uavhengig av rekkefølge
- Idempotent - utføre samme operasjon flere ganger og man kan forvente samme resultat
- Distributed - spredd ut og uavhengig
Med disse egenskapene blir det lettere å bryte opp softwaren vi lager og gjøre den distribuert. Her passer Event Driven og Event Sourced inn som hånd i hanske. Vi kan lettere flytte løsningene rundt og skalere hver komponent etter behov. Løsningene er løsere koplet til hverandre - uten direkte bindinger.
Brukerne vil oppleve et system som er mer responsivt og med færre uforståelige tekniske begrensninger. Med denne tilnærmingen kan løsningene også utvikles mer smidig.
Vi kan enkelt legge til nye mikrotjenester som drar nytte av hendelser fra andre mikrotjenester. Hver mikrotjeneste lever et autonomt liv, og vil ha kopier av det den er interessert i fra andre mikrotjenester.
- Vi snakker mye om å jobbe kontinuerlig i tverrfaglig team. Denne artikkelen handler om det motsatte
Ytelse og skalerbarhet
Alt dette kommer med en pris og utfordringer.
Det å være Event Sourced betyr at vi har sannheten i en Event Store som vokser og vokser over tid. Vil ikke dette gi utfordringer på ytelse og skalerbarhet?
Vi har ikke én stor Event Store. Vi har brutt denne opp. Hver mikrotjeneste har sin egen Event Store og egen database for lagring av projiserte øyeblikksbilder (Projections). Våre løsninger er SaaS-systemer som tilbys til flere kunder. Hver kunde har sin egen Event Store og tilhørende databaser. Dermed blir databasene mindre og lettere å håndtere.
Når det gjelder ytelse, spiller vi sjelden av alle hendelsene sekvensielt fra starten av historien. Dette gjøres typisk kun ved endring av en projeksjon. Når en avspilling er ferdig, er det kun nye hendelser som produseres fortløpende som da påvirker projeksjonene.
Har du mikrotjenester? Da bør du sjekke ut gRPC!
GDRP og endringer
Våre systemer håndterer stort sett bare persondata, så for oss er håndtering av disse kritiske, og GDPR en essensiell del.
I en Event Store hvor vi bare legger til og ikke endrer eksisterende data, blir det utfordrende. Vi håndterer dette ved å kryptere data per person per datatype med en krypteringsnøkkel. Fremfor da å slette hendelser, så kaster vi nøklene når en person skal slettes.
På den måten mister vi kun tilgang til de dataene som er personlige, og ikke selve hendelsen - og dermed opprettholder vi hva som har skjedd i systemet fra begynnelsen. Dette gjør at vi fremdeles kan fremskaffe statistikk og sporbarhet i løsningen utenom personsensitive data.
En annen utfordring kan være håndtering av endringer i selve programvaren. Hva skjer med hendelser når programvaren som skal tolke dem blir endret?
Hendelsene som vi lagrer har versjonsinformasjon. En hendelse er knyttet til en versjon av programvaren. Med migrerings-script kan hendelser tolkes av ulike versjoner av programvaren. Dette gjør programvaren «endringsvillig» og er med på å frikoble data og programvare på nye måter.
Andre fordeler
Siden alt er hendelser, kan hver enkelt mikrotjeneste bli mer responsiv på når noe skjer. Det er lettere å lage brukeropplevelser hvor brukeren også får beskjeder når noe endres.
Mikrotjenestene snakker med hverandre gjennom hendelser. De lever sitt eget liv, kan oppgraderes sømløst ved behov, integreres enkelt med nye mikrotjenester eller med en tredje part.
Sporbarhet er en av de store fordelene. Alt som har skjedd er lagret. Vi ser hvilken bruker eller system som har forårsaket en hendelse. Dette skaper trygghet for kunden og for sluttbruker. Ved å analysere mønstre i hendelser, kan vi lettere forstå bruksmønstre og se muligheter for automatisering.
Sånn takler Geodata 100.000 forespørsler i minuttet med Kubernetes
Oppsummering
Etter å ha jobbet med Event Driven-tankesett og Event Sourcing i mer enn 10 år, kan jeg si at det har levert solid verdi.
Det er litt sånn «I’m never going back»-følelse.
Fremgangsmåten har utfordringer, og kanskje spesielt knyttet til overgangen fra hvordan vi tradisjonelt har tenkt utvikling. Det er lite helhetlige verktøy, og det kan være krevende.
Vi har derfor valgt å bygge verktøyene selv. Dette gir oss fleksibilitet og åpner mulighetsrommet for hva vi trenger. Det gir oss også rom for innovasjon, noe vi deler åpent på GitHub. Vi går en fremtid i møte der Askio leverer en solid Event Driven plattform i tillegg til solide løsninger innen forsikring og pensjon der alt er sporbart og der GDPR håndteres gjennomgående i alle deler av løsningene.