Hændelsesorientering og hype-kurven

Hændelsesorientering er på mange måder et varmt emne for tiden og følger behageligt med i slipstrømmen af både Domain Driven Design, Microservices og nu senest Actor model (Reactive messaging, Akka).

Hændelsesorientering har efterhånden nogle år på bagen hos entusiaster og særligt udvalgte projekter og virksomheder, og man ser og hører derfor om flere og flere succeser med hændelsesorientering. Ser man på hændelsesorientering i forhold til det generelle, danske IT-landskab (især det offentlige), så er det min oplevelse, at interessen findes og at ibrugtagelse går stødt – men langsomt.

En årsag til den langsomme ibrugtagelse kan være, at hændelsesorientering er mange forskellige ting, alt efter hvem man spørger. Det kan være…

  • en måde at anskue forretningen på.
  • en teknisk tilgang til at skabe mere autonome og robuste SOA-services.
  • en måde at integrere systemer på.
  • et programmeringsparadigme.
  • en måde at lagre data på.

Ibrugtagelse af hændelsesorientering er beklageligvis også mest drevet af systemarkitekter og teknikere. I moderne litteratur er hændelsesorientering ofte lettere skjult bag andre, teknisk relaterede koncepter (DDD, Microservices, Akka) og frameworks (NServiceBus, Eventstore). Som nybegynder er det svært at finde ud af hvor man skal kigge for at opnå generel forståelse, samt i hvilken retning man skal kigge for at få løst specifikke problemer.

Jeg synes det til enhver tid er vigtigt, at man tager et ærligt kig på en given tilgang (hændelsesorientering, SOA, request/response, what not) og forholder sig til koncepterne og teknologierne ud fra hvad der reelt tilbydes af fordele – og hvilke ulemper, der følger med. I dette indlæg vil jeg derfor kigge lidt på de generelle termer, der ofte er forbundet med hændelsesorientering, og placere dem subjektivt i forhold til den velkendte hype kurve (gengivet nedenfor).

Dette vil jeg gøre af to grunde – dels for at man som nybegynder har nogle linjer om hvert koncept eller teknologi – dels så både jeg selv og mine kollegaer i branchen ikke nødvendigvis hele tiden taler om at bygge en rumfærge, når blot et papirfly er nødvendigt. Eller, for at sige det lidt mere lige ud af posen, at vi ikke fucker endnu et godt koncept op fordi der udelukkende fokuseres på det nye, uden at tage det gamle i hævd – en tilgang jeg benytter i min kommende guide om design af et hændelsesorienteret system.

Gartner Hype Cycle.svg
Gartner Hype Cycle” by Jeremykemp at English Wikipedia. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

  • Hændelsesorientering generelt
    Kort forklaring: Lad os sige, at du i Objektorientering / DDD anskuer din omverden verden som objekter, der kan modelleres i et system. Hændelsesorientering handler om, at der kan identificeres, navngives og specificeres hændelser, som interessante objekter i din omverden kan komme ud for. At en borger skifter efternavn vil kunne blive identificeret som en hændelse (“Borgers efternavn ændret”), der kan refereres til i forretningen, samt benyttes både i analyse, design og konkret implementering af et system. Objektorientering / DDD og hændelsesorientering kan gå hånd i hånd.
    Placering på kurven: Jeg har konkret, positiv erfaring med hændelsesorientering, så personligt ligger hændelsesorientering på Plateau of Productivity. Hændelsesorientering kommer dog ofte med en ny teknisk tilgang (ofte beskedudveksling), og jeg er lidt afventende på, om de ekstra elementer i teknologistakken vil give bagslag generelt. Jeg tror mange af mine kollegaer i branchen ligger samme sted. For visse føler jeg dog hændelsesorientering ligger på Peak of Inflected Expectations, fordi hændelsesorientering bliver forklaret som en løsning på stort set alle de dårligdomme vi har i vores nuværende systemer, hvilket jeg mener er at sætte forventningerne en anelse for højt.
    For mange af mine kunder ligger konceptet hændelsesorientering tæt på Technology Trigger, dvs. et meget nyt koncept, som ligger langt fra deres forretningsmæssige og teknologiske virkelighed (på trods af, at de ville få meget ud af benytte hændelsesorientering).
  • Event sourcing
    Kort forklaring: Hvis man anskuer virkeligheden som en strøm af hændelser, og man fanger og gemmer denne strøm af hændelser i en database, vil man kunne udlæse dem efter behov for at (1) interagere med deres akkumulerede tilstand programmatisk og (2) lave analyser på dem. Modsat tidligere punkt om hændelsesorientering, kan man næsten sige, at man her anskuer hændelsen som primær og objektet mere sekundært – et objekts tilstand er givet af alle dets hændelser, hvilket manifesteres konkret ved at hændelserne gemmes i enkle tabeller og objektet udlæses herfra, når der er brug for det. Dette åbner op for mange fordele: domænemodellen kan ændres på en mere fleksibel måde (fleksibiliteten er dog størst, hvis hændelserne ikke kræver ændringer) og analysespørgsmål kan opfindes lang tid efter at hændelserne indtraf. Det sidste er svært ved en traditionel “state” / relationel database, hvor man først vil begynde at registrere relevante data efter man har fundet et nyt, analytisk fokusområde.
    Placering på kurven: Personligt har jeg set fordelene ved event sourcing. Det er lettere af ændre i domænemodellen, da det ikke kræver ændringer til databaseskemaet. For at kunne lave udlæsninger af informationerne på en performancemæssigt acceptabel måde, vil der være behov for at lave læsemodeller (a la CQRS, se senere), som opdateres på baggrund af hændelserne. For mig personligt ligger event sourcing lige nu på Through of Disillusionment. Det er et markant anderledes paradigme, og der mangler generelt god tooling. Jeg er 100% for at gemme alle hændelser til senere brug / inspektion, men personligt hælder jeg nok mere til at bruge hændelser ud fra tilgangen “objekter med hændelser”, ikke “objekter baseret på hændelser”. Der er meget vedligehold af læsemodeller fra denne tilgang.
  • CQRS
    Kort forklaring: Grundlæggende koncept: Hold API for ændringer til modellen adskilt fra API til forespørgsler (hvor API her kan henvise til enhver grænseflade, både webservice og / eller domæneservice). Ofte sættes dette paradigme i forbindelse med asynkronitet, messaging og event sourcing, men det behøver ikke være sådan. CQRS giver grundlæggende god mening, selv ved helt simple, synkrone request/response systemer. Hvem har ikke prøvet at skulle forsøge at få Nhibernate eller Entity Framework til at performe godt ved udlæsning af mange informationer? Med CQRS bruger man domænemodellen til at lave strukturerede, tilladte opdateringer (inkl. valideringer osv.), men (potentielt!) en anden tilgang til at udlæse data hurtigt – eksempelvis rå udlæsning af data eller ved brug af en minimal, sekundær model.
    CQRS kan altså starte med at være en simpel opdeling af kode inkl. brug af samme domænemodel til begge. API’erne for opdateringer og forespørgsler kan herefter udvikle sig i hver sin retning, efterhånden som kravene ændrer sig (data kan caches osv). Når man kommer helt derhen, hvor selv en synkron, låst opdatering skader performance af læsning af selvsamme data, kan man overveje at introducere hændelser og asynkronitet, med de udfordringer der nu følger med (eksempelvis at læsedata er forældet).
    Placering på kurven: For mig personligt ligger CQRS på Slope of Enlightenment. Jeg synes CQRS giver god mening, men er lidt afventende til om hvorvidt det virkelig er værd at vedligeholde en model for strukturerede opdateringer og en anden for udlæsning. Introduktion af en læsemodel kan heldigvis udskydes til man begynder at få problemer, så startomkostningerne behøver ikke være så store. Dertil kommer udfordringer med eksempelvis sikkerhed på læsemodellen. Jeg tror mange af mine kollegaer ser det på samme måde. For mange af mine kunder vil jeg tro dette forståelsesmæssigt ligger et sted imellem Technology Trigger og Slope of Enlightenment, dog uden at have set nogen konkret gøre brug af konceptet.
  • Event storming
    Kort forklaring: Event storming handler om at finde modellen til et problemområde / proces udfra og ind, baseret på identifikation af hændelser. I stedet for at identificere objekter / aggregater / flows og dernæst hændelser (indefra og ud, så at sige), identificerer man hændelserne og forsøger derefter at koble dem til passende domæneobjekter.
    Placering på kurven: Hverken jeg eller mine kunder har erfaring med brug af event storming, og jeg må derfor placere konceptet tæt på Technology Trigger. Jeg tror det kan være en god idé med en udfra-og-ind tilgang, som supplement til etablerede tilgange. Alt efter konteksten kan pro-argumentet med, at UML tager lang tid og er komplekst, klinge hult – det er ikke alle steder man har så travlt, at analyse og design faserne for et system skal pløjes igennem hurtigst muligt. Omvendt er det selvfølgelig heller ikke nødvendigt at gøre tingene mere besværlige end nødvendigt. Jeg har ikke hørt om kunder eller kollegaer i branchen, som har erfaring med Event storming.
  • Microservices
    Kort forklaring: SOA klinger i dag ofte negativt. Det er egentlig selvforskyldt, både hos kunder og professionelle i branchen. På et tidspunkt midt i nullerne blev der sat et lighedstegn imellem SOA og webservices. Som følge heraf blev vores services ikke robuste og ikke autonome. Dertil var ansvarsområderne også generelt for store for hver service. Microservices kan, efter min mening, ses som en genfødsel af SOA. Målet er stadig autonome services, men teknologistakken er udvidet typisk med messaging og ansvarsområdet mindskes efter devisen”gør én ting godt”. Dertil er der koblet hændelsesorientering som en del af kommunikationsparadigmet imellem services.
  • Placering på kurven: For mig ligger microservices et sted imellem Peak of Inflated Expectations og Trough of Disillusionment. På den ene side giver det mening med services, der kun skal gøre en ting godt. Det har jeg konkret prøvet, dog mere som mini-SOA services end deciderede microservices (hvis vi altså SKAL sætte en etikette på). På den anden side har jeg hørt om kollegaer i branchen, som nu sidder på en service-portefølje på over 2000 microservices. Når vi er nede i den granularitet kan jeg ikke lade være med at tænke på, om man efterhånden er der, hvor man blot udstiller et repository via webservices. Dette kan give et bagslag både i form af høj, operationel vedligeholdelsesomkostning og langsom videreudvikling, da logikken i de små microservices er alt for udstillet. Men det vil vise sig, hvor microservices reelt lander. Microservice envy hos Thoughtworks omtaler bevæggrunde og granularitet, Martin Fowler er inde på omkostningerne ved microservices.
Christer Ø. on twitterChrister Ø. on linkedin
Christer Ø.
Software Development Consultant stratal ApS
Christer Østergaard er freelance forretningsanalytiker og softwarearkitekt med mere end 16 års erfaring. Har arbejdet med STAR (tidl. Arbejdsmarkedsstyrelsen), DSB, Kommunernes Landsforening, Digitaliseringsstyrelsen, Egmont, Banedanmark, Elsparefonden, Armada Shipping, Unik HR, Fødevareministeriet og Ministeriet for Flygtninge, Indvandrere og Integration, Knowledge Cube, mikz.com, Ankestyrelsen m.fl. Dertil et par Open Source projekter. Lige nu læser Christer Data and Reality. Christer er klar til at sikre leverance af nye softwareprodukter fra 1. Januar 2016.