[BLOG] Event Driven Architecture door Covadis [2019] »

Vrijdag 26 juli 2019

Terug naar overzicht

In de laatste jaren is er door verschillende software bedrijven een switch gemaakt richting Event Driven Architecture (EDA). Hoewel het geen nieuw concept is, is de populariteit de laatste jaren erg toegenomen. Waar komt de fascinatie voor deze architectuur vandaan? En hoe kan het dat het juist de laatste jaren een vogelvlucht heeft genomen?

Wat is event driven architecture?

Allereerst kort een introductie: “wat is event driven architecture?”. Er is niet één antwoord op deze vraag volgens Martin Fowler, de software goeroe van dit moment. Er zijn vier patterns die kunnen worden geschaard onder event driven architecture, dat zijn: Event Notification, Event-Carried State Transfer, Event-Sourcing en CQRS. Voor dit blog worden de eerste twee patterns, die erg veel op elkaar lijken, als uitgangspunt genomen.

De essentie van event driven architecture is dat er wordt gereageerd op wijzigingen in de ‘state’ van een applicatie of wordt gereageerd op externe factoren zoals HTTP requests. Bij een wijziging wordt er een event aangemaakt zodat de overige componenten van de applicatie op dit event kunnen reageren. De tegenhanger van een event driven aanpak is het request response pattern. Het bekendste request response pattern is het HTTP protocol.

Het verschil is het makkelijkste aan te geven met een praktijkvoorbeeld. Stel: een familielid heeft verhuisplannen en stuurt een bericht in de familie appgroep. De rest van de familie kijkt, hopelijk, wat ze kunnen doen en reageren in de app. In dit voorbeeld kan je het whatsapp bericht vergelijken met een event, de rest van de rollen spreken voor zich. Het familielid dat gaat verhuizen is de verzender en de rest zijn de ontvangers. Dit voorbeeld geeft een event driven opzet weer.

Een request response pattern kan je vergelijken met iemand die gaat verhuizen, maar in dit geval wordt er telefonisch contact opgenomen met de familieleden. Aan ieder familielid wordt individueel gevraagd op een bepaalde taak uit te voeren. In dit geval wordt iemand voor een specifieke taak gevraagd en wordt er gewacht op antwoord.

Waarom gebruik je event driven architecture?

Er zijn meerdere redenen waarom je voor een event driven aanpak kunt kiezen. Het heeft namelijk een aantal voordelen. Als je kijkt naar de gegeven metafoor zie je een verschil in aanpak. In de eerste situatie kunnen de familieleden het bericht verwerken, zelf bepalen of ze wat willen doen en vervolgens beslissen wat ze willen doen. Dit heeft verschillende voordelen:

Familieleden kunnen zelf bepalen of ze iets met het bericht willen doen;
Familieleden bepalen zelf wat ze willen doen;
De verzender hoeft niet te weten welke taken zijn familieleden kunnen en willen uitvoeren;
De verzender hoeft niet te wachten op reactie;
De verzender hoeft het telefoonnummer van de ontvangers niet allemaal te hebben;
De verzender hoeft niet met iedereen persoonlijk contact op te nemen.

De voordelen uit het voorbeeld kunnen ook worden toegepast op een event driven aanpak. Laten we een webwinkel als voorbeeld nemen. Op het moment dat er een nieuwe order wordt geplaatst moeten er allerlei verschillende processen worden gestart. De order moet worden gepikt, de orderbevestiging kan worden gemaild en vervolgens de factuur wordt gemaakt.

In het eerste voorbeeld in de bovenstaande afbeelding is weergegeven hoe het proces van een nieuwe order plaatsvindt bij een request response aanpak. De orderservice staat in direct contact met de drie andere services zodat ze hun taken kunnen gaan uitvoeren. De orderservice bepaalt welke functionaliteit van de orderpickservice, factuurservice en mailservice er wordt aangeroepen.

In het geval van een event driven aanpak verstuurt de orderservice een event waarin hij aangeeft dat er een nieuwe order is aangemaakt. De orderpikservice, mailservice en de factuurservice kunnen hier op reageren en zelf beslissen wat ze er mee gaan doen. In dit geval de order pikken, een mail sturen en een factuur maken.

Het voordeel van de laatste optie is dat de orderservice niks van de orderpikservice, mailservice en factuurservice hoeft te weten. Hij hoeft niet eens te weten dat ze bestaan. Het zorgt dus voor een lage koppeling tussen de services. Dit heeft meerdere voordelen. Het belangrijkste voordeel is dat er gemakkelijk services bij kunnen worden geplaatst. Stel dat er nog een extra actie moet worden uitgevoerd. Bijvoorbeeld het inlichten van de bezorgservice dat er een nieuwe order is geplaatst. In het geval van een event driven aanpak kan er een nieuwe service worden gemaakt die reageert op het aangemaakt event. Terwijl bij de eerste aanpak de code van de orderservice moet worden uitgebreid om ook de nieuw gemaakte service aan te spreken.

Waarom gebruik je geen event driven aanpak?

Wanneer er informatie aan de gebruiker moet worden getoond is een event driven aanpak niet de beste keuze. Vergelijk het een beetje met de verhuizing. Als je zeker moet weten dat iemand een bepaalde taak oppakt dan kun je het beste direct contact opnemen. In gevallen dat je moet controleren of een bericht is aangekomen of waar je gelijk reactie wilt, is een request response aanpak beter.

Houd er rekening mee dat het opzetten van een event driven architectuur zorgt voor complexiteit. Er moet een platform worden gekozen voor de events, denk hierbij aan Event Grid van Microsoft Azure. Kijk dus goed of een event driven aanpak toepasbaar is op jouw project, of de voordelen opwegen tegen de nadelen en kijk daarnaast ook of het de investering waard is. Heb je een project waarbij schaalbaarheid en uitbreidbaarheid niet erg belangrijk zijn? Dan is een event driven aanpak vaak niet de beste oplossing.

Vanwaar de vogelvlucht?

Event driven aanpak is hot. Volgens onderzoeksbureau Gartner is het een van de 10 technologische trends van 2018. Hier zijn meerdere redenen voor:

Schaalbaarheid wordt steeds belangrijker. Er wordt steeds meer en frequenter gebruik gemaakt van digitale oplossingen. Dit zorgt ervoor dat er steeds meer aanvragen en data moet worden afgehandeld. Een event driven aanpak is goed schaalbaar en vandaar past het goed bij de huidige vraag naar schaalbaarheid.
De tweede reden is de groei van IoT. Er komen steeds meer slimme apparaten die communiceren met andere services en applicaties. De meest effectieve manier om dit te doen is door middel van events. Een andere manier is door elk uur de status van een sensor te controleren, maar dit is een stuk minder effectief. Als we het weer met ons verhuisvoorbeeld vergelijken: Elk uur de sensor controleren is vergelijkbaar met iemand die elk uur vraagt of je al gaat verhuizen, terwijl het veel effectiever als jij aangeeft dat je gaat verhuizen.
De laatste factor die ik wil noemen is de migratie naar de cloud. Het is tegenwoordig toegankelijk geworden om een event driven architectuur op te zetten. Waar je eerder zelf een platform voor events moest kiezen en daarna ook onderhouden en hosten, is dat door de komst van de cloud providers een stuk eenvoudiger geworden.

Quo Vadis

Covadis gebruikt een event driven aanpak op meerdere manieren. Het makkelijkste voorbeeld zijn de IoT apparaten waar wij informatie van ontvangen. In het afgelopen jaar hebben we bijvoorbeeld ConnectedGreen gemigreerd van een request response aanpak naar een event driven aanpak. Wij gebruiken een event driven aanpak steeds meer, maar we kijken wel goed of de voordelen opwegen tegen de nadelen.

Steeds meer bedrijven vragen om een event driven aanpak. Exact heeft vanaf 1 januari 2018 rate limits ingesteld op hun API waardoor het een stuk minder aantrekkelijk is om periodiek te controleren op wijzigingen. In plaats daarvan kan er veel beter gebruik worden gemaakt van hun webhooks en reageren op wijzigingen wanneer ze plaatsvinden. De vraag naar schaalbaarheid en beschikbaarheid leidt ertoe dat het steeds noodzakelijker wordt om software zo te bouwen dat er makkelijker kan worden geschaald en dat er eenvoudig nieuwe componenten kunnen worden toegevoegd. Een event driven aanpak is hiervoor de oplossing.

Wil je meer weten over een event driven aanpak? Of eens kijken of dit ook bij jouw project past? Neem contact met ons op! Dat is een stuk effectiever dan dat wij jou periodiek bellen 😉

Neem contact op

Tim Boerman

Tim Boerman is de projectleider van het Innovatielab. Dit lab is de R&D afdeling van Covadis. Hier werken talentvolle ontwikkelaars aan prototypes voor onze opdrachtgevers. Hiermee is Tim de slijper die van de ruwe diamanten ware edelstenen maakt. Als correspondent in het land der nieuwe technieken weet Tim van alle relevante noviteiten en aankondigingen. Via zijn blogs houdt hij ons allen op de hoogte, als zijn favoriete NBA team tenminste niet speelt.