Nederlandstalige Versie

Dans le monde en perpétuelle évolution du développement logiciel, le code hérité est un sujet souvent abordé, mais finalement très peu compris. Le code hérité peut être défini de différentes manières, mais pour cette discussion, nous considérons qu’il s’agit de tout code qui est encore utilisé par une application importante, mais qui devrait être mis à niveau. Il se peut qu’un nouveau style architectural ou de nouvelles normes soient nécessaires, que des cadres obsolètes soient encore utilisés ou que le code soit écrit dans un langage de programmation qui n’est plus pris en charge. Ou alors le code n’est pas travaillé à la base, et se retrouve donc trop souvent pollué de correctifs rapides. En d’autres termes, il s’agit d’un code devenant de plus en plus difficile à maintenir et qui doit être réécrit, mais qui, pour une raison ou une autre, n’est pas pris en main. Certains parlent également de dette technique (technical debt).

Et si nous allions plus loin en essayant non seulement de gérer ce code, mais en plus de l’améliorer de manière proactive ? Pouvons-nous utiliser de nouvelles technologies comme l’IA pour y parvenir ?

Pourquoi le Code hérité est un problème

Le code hérité entraîne un certain nombre de défis. Le plus important d’entre eux est probablement le fait qu’il ralentit le développement et rend la maintenance difficile, ou qu’il nécessite des connaissances spécialisées et des outils obsolètes. Sans les connaissances et les outils adéquats, il peut représenter un coût énorme pour tout éditeur de logiciels. De plus, si les développeurs qui ont écrit le code original ont également quitté l’entreprise, le problème peut se révéler encore plus grave. En parlant des développeurs, c’est également la  dette technique qui constitue l’un des plus grands désagréments dans leur travail.

Il existe heureusement plusieurs façons de relever ces défis, même en utilisant les technologies les plus avancées, telles que l’intelligence artificielle.

Stratégies de gestion du code hérité

Il n’existe malheureusement pas de solution magique permettant de résoudre tous les problèmes liés aux code hérité en une seule fois. Il faut adopter une approche polyvalente faisant appel à plusieurs tactiques à la fois. Pensons à l’analyse du code, à la construction de nouveaux composants de manière modulaire et à la maintenance continue de la base de code pour s’assurer qu’elle reste à jour et bien adaptée aux besoins futurs.

Une première étape consiste à effectuer une analyse statique. Il s’agit d’examiner le code sans l’exécuter afin d’identifier les problèmes potentiels tels que les dépendances, les failles de sécurité ou les “code smells”. En utilisant des outils d’analyse statique, les développeurs peuvent mieux comprendre la structure du code et identifier les zones problématiques à améliorer. Ces outils sont en partie intégrés dans un bon environnement de développement, mais il est souvent possible de leur ajouter une puissance supplémentaire.

Après l’analyse du code, il est essentiel de mettre en place des bancs d’essai, conformément au paradigme du Test Driven Development (TDD). Cela permet de créer un environnement sûr dans lequel divers tests peuvent être exécutés afin de garantir que le code se comporte comme prévu. Les tests sont essentiels pour détecter rapidement les bogues et les problèmes de performance, avant que des changements ne soient apportés. Par ailleurs, si la couverture des tests est suffisante, il devient beaucoup plus sûr de remanier le code, ce que nous devons continuer à faire tout au long du cycle de vie afin de veiller à ce que le code continue d’être amélioré et n’atteigne surtout pas le legacy status. La mise en place de bancs d’essai soutient en outre les processus d’intégration et de déploiement continus (CI/CD)), qui sont essentiels pour la gestion de la qualité à long terme.

Une autre stratégie importante consiste à remanier le code pour le rendre modulaire. En décomposant une base de code monolithique en modules plus petits et plus faciles à gérer, les développeurs peuvent isoler les fonctionnalités, ce qui rend le code plus facile à comprendre, à maintenir et à tester (et peut-être même à réécrire). Cette modularisation permet également à différentes équipes de travailler simultanément sur différentes parties de la base de code, ce qui augmente la productivité et réduit la probabilité d’erreurs.

Le rôle de l’IA dans la gestion de code hérité

L’intelligence artificielle offre de nouvelles possibilités pour la gestion de code hérité, en particulier aujourd’hui, avec l’évolution rapide de l’IA générative. Bien que les capacités actuelles de l’IA soient souvent limitées à des tâches à petite échelle, son potentiel de transformation de la gestion du code hérité est considérable. L’IA peut aider à analyser le code, à écrire des tests, à remanier et même à générer de la documentation. Cela fait de l’IA un outil précieux pour les développeurs.

• Analyser le code : Les outils d’IA peuvent analyser le code pour en déterminer la structure et la fonctionnalité, ce qui permet d’obtenir des informations qui ne sont pas forcément évidentes pour les développeurs humains. Cela peut s’avérer particulièrement utile lorsqu’il s’agit de systèmes hérités complexes ou mal documentés.
• Rédaction de tests : L’IA peut également aider à générer automatiquement des tests basés sur le comportement du code, ce qui permet de gagner du temps et d’améliorer la qualité du code en identifiant les cas marginaux qui pourraient être négligés lors des tests manuels.
• Refonte du code : Les outils pilotés par l’IA peuvent suggérer des améliorations et aider les développeurs à remanier le code graduellement. Ce processus de remaniement continu permet de garder la base de code propre et maintenable, réduisant ainsi la dette technique au fil du temps.
• Génération de documentation : L’IA peut automatiquement générer et actualiser la documentation dans le cadre de CI/CD, ce qui est particulièrement utile dans les grands projets où la maintenance de la documentation peut être un défi.

Ces tâches peuvent principalement être effectuées par le même type d’outils d’IA : les assistants de codage.  Codacy, Snyk et, bien entendu, github CoPilot en sont quelques exemples.

Conclusion : l’avenir de la gestion de code hérité grâce à l’IA

La gestion de code hérité reste un défi complexe qui nécessite une approche stratégique. Cependant, l’émergence de l’IA en tant qu’outil d’analyse, de test et de remaniement du code offre des possibilités de relever ce défi de manière plus efficace et plus rentable. L’évolution de la technologie de l’IA générative est encore en plein essor, et son rôle dans la gestion de code hérité ne fera probablement que s’accroître, offrant davantage de possibilités d’améliorer les processus de développement de logiciels.

Toutefois, il ne faut pas non plus se focaliser sur l’IA : le meilleur remède contre le code hérité est encore de l’éviter, et ce, en appliquant les bonnes tactiques tout au long du cycle de vie du développement logiciel afin de maintenir la conception et le code aussi propres et à jour que possible. Dans un prochain article de blog, nous examinerons cette question plus en détail, en zoomant sur les différentes phases du cycle de vie afin de discuter de la manière d’éviter le code hérité et de la façon dont l’IA peut être utilisée au cours de chaque phase en vue d’y contribuer.

Version française

In de steeds veranderende wereld van softwareontwikkeling is legacy code een onderwerp dat vaak ter sprake komt, maar zelden goed wordt begrepen. Legacy code kan op verschillende manieren worden gedefinieerd, maar voor deze discussie beschouwen we ze als elke code die nog steeds wordt gebruikt door een belangrijke toepassing, maar die zou moeten worden geüpgraded. Misschien zijn er een nieuwe architectuurstijl of standaarden nodig, worden er nog verouderde frameworks gebruikt, of is de code geschreven in een niet langer ondersteunde programmeertaal. Of er is al te vaak niet meer ten gronde aan de code gewerkt en ze is vervuild geraakt met snelle fixes. Met andere woorden, het is code die steeds moeilijker te onderhouden wordt en die opnieuw moet worden geschreven, maar om een of andere reden niet wordt aangepakt. Sommigen noemen dit ook wel eens technical debt.

Maar wat nu als we een stap verder gaan en deze code niet alleen proberen te beheersen, maar ook proactief verbeteren? En kunnen we hierbij gebruik maken van nieuwe technologieën zoals AI?

Waarom Legacy-Code een Probleem Is

Legacy code brengt tal van uitdagingen met zich mee. De grootste daarvan is waarschijnlijk het feit dat ze de ontwikkeling vertraagt en onderhoud bemoeilijkt; of ze vraagt gespecialiseerde kennis van voorbijgestreefde hulpmiddelen. Zonder de juiste kennis en tools kan dit een gigantische kostenpost worden voor elk softwarebedrijf. Als de ontwikkelaars die de oorspronkelijke code schreven, bovendien ook nog het bedrijf verlaten hebben, kan het probleem nog groter worden. Over de ontwikkelaars gesproken: ook voor hen is technical debt een van de grootste ergernissen bij hun werk.

Er zijn gelukkig een aantal manieren om met deze uitdagingen om te gaan, zelfs met behulp van de meest geavanceerde technologieën, zoals kunstmatige intelligentie.

Strategieën om Legacy Code te beheren

Er bestaat, jammer genoeg, geen magische oplossing die alle problemen met legacy code in een keer oplost. Het vereist een veelzijdige aanpak waarbij meerdere taktieken tegelijkertijd worden toegepast. Denk aan het analyseren van de code, het modulair opbouwen van nieuwe componenten en het continu onderhouden van de codebase, om ervoor te zorgen dat deze up-to-date blijft en goed is aangepast aan toekomstige behoeften.

Een eerste stap is het uitvoeren van statische analyse. Hierbij wordt de code onderzocht zonder deze daadwerkelijk uit te voeren, om zo potentiële problemen te identificeren zoals afhankelijkheden, beveiligingslekken, of zogenaamde ‘code smells’. Met behulp van statische analysetools kunnen ontwikkelaars de structuur van de code beter begrijpen en probleemgebieden aanwijzen die verbetering behoeven. Deze tools zijn voor een deel ingebakken in een goede IDE, maar je kan er vaak nog extra kracht aan toevoegen.

Nadat de code is geanalyseerd, is het opzetten van testbanken essentieel, volgens het Test Driven Development (TDD) paradigma. Dit creëert een veilige omgeving waarin verschillende tests kunnen worden uitgevoerd om ervoor te zorgen dat de code zich gedraagt zoals verwacht. Testen is cruciaal om bugs en prestatieproblemen vroegtijdig op te sporen, voordat er wijzigingen worden doorgevoerd. Als er voldoende test coverage is, wordt het trouwens een stuk veiliger om de code te refactoren, hetgeen we tijdens de volledige levenscyclus zullen moeten blijven doen, om ervoor te zorgen dat de code steeds beter wordt en zeker geen legacy status krijgt. Het opzetten van testbanken ondersteunt daarnaast ook continuous integration en deployment (CI/CD) processen, die essentieel zijn voor kwaliteitsbeheer op lange termijn.

Een andere belangrijke strategie is het refactoren van de code om deze modulair te maken. Door een monolithische codebase op te splitsen in kleinere, beter beheersbare modules, kunnen ontwikkelaars functionaliteiten isoleren, wat de code gemakkelijker maakt om te begrijpen, te onderhouden en te testen (en eventueel zelfs om ze te herschrijven). Deze modularisatie stelt verschillende teams ook in staat om tegelijkertijd aan verschillende onderdelen van de codebase te werken, wat de productiviteit verhoogt en de kans op fouten vermindert.

De rol van AI in het aanpakken van Legacy Code

Kunstmatige intelligentie biedt nieuwe mogelijkheden voor het beheren van legacy code, zeker nu, met de snelle evolutie van generatieve AI. Hoewel de huidige mogelijkheden van AI vaak beperkt zijn tot kleinschalige taken, is het potentieel om legacy codebeheer te transformeren aanzienlijk. AI kan helpen bij het analyseren van code, het schrijven van tests, het refactoren en zelfs bij het genereren van documentatie. Dit maakt AI een waardevol hulpmiddel voor ontwikkelaars.

• Code Analyseren: AI-tools kunnen code analyseren om de structuur en functionaliteit te bepalen, waardoor inzichten ontstaan die mogelijk niet direct duidelijk zijn voor menselijke ontwikkelaars. Dit kan vooral nuttig zijn bij het omgaan met complexe of slecht gedocumenteerde legacy-systemen.
• Tests Schrijven: AI kan ook helpen bij het automatisch genereren van tests op basis van het gedrag van de code, wat tijd bespaart en de codekwaliteit verbetert door randgevallen te identificeren die tijdens handmatige tests over het hoofd kunnen worden gezien.
• Code Refactoren: AI-gestuurde tools kunnen verbeteringen voorstellen en ontwikkelaars helpen om code stapsgewijs te refactoren. Dit continue refactoringsproces helpt om de codebase schoon en onderhoudbaar te houden, waardoor technische schuld in de loop van de tijd wordt verminderd.
• Documentatie Genereren: AI kan automatisch up-to-date documentatie genereren en bijhouden als onderdeel van CI/CD, wat vooral nuttig is in grote projecten waar het bijhouden van documentatie een uitdaging kan zijn.

Deze taken kunnen veelal worden uitgevoerd door dezelfde type AI tools: de zogenaamde code assistants. Een aantal voorbeelden zijn Codacy, Snyk en, uiteraard, github copilot.

Conclusie: de toekomst van legacy codebeheer met AI

Het beheren van legacy code blijft een complexe uitdaging die een strategische aanpak vereist. Maar met de opkomst van AI als hulpmiddel bij het analyseren, testen en refactoren van code, ontstaan er mogelijkheden om deze uitdaging op een meer efficiënte en kosteneffectieve manier aan te pakken. Generatieve AI-technologie is nog in volle ontwikkeling, en haar rol in legacy codebeheer zal waarschijnlijk alleen maar toenemen, wat nog meer kansen biedt voor het verbeteren van softwareontwikkelingsprocessen.

We mogen ons echter ook niet blind staren op AI: het beste medicijn tegen legacy code is ze te voorkomen, en dit door gedurende de volledige softwareontwikkelingslevenscyclus de juiste taktieken toe te passen om het ontwerp en de code zo clean en up-to-date mogelijk te houden. In een toekomstige blogpost zullen we hier nog dieper op ingaan, waarbij we op de verschillende fasen van de levenscyclus inzoomen, om te bespreken hoe we legacy kunnen vermijden, en ook hoe AI tijdens elke fase kan worden ingezet als hulpmiddel daarbij.

De voordelen van het gebruik van EDA zijn legio. Maar hoe gebruik je nu eigenlijk EDA in de praktijk? Wat als je al een enorm ecosysteem van toepassingen hebt die enkel en alleen via synchrone communicatie worden geïntegreerd en je nog nagenoeg geen business Events publiceert? In deze blog-post stellen we een methode voor om een applicatie te laten evolueren om meer Events te gaan publiceren.

Binnen de instellingen van de Sociale Zekerheid groeit het besef dat Event Driven Architecture (EDA) erg nuttig kan zijn als onderdeel van de integratiestrategie (we hebben hierover reeds uitvoerig geblogd en de belangrijkste voordelen zijn ook samengevat in ons webinar van november). We hebben in ons IT ecosysteem echter al een enorm groot aantal systemen en applicaties die hier nog niet noodzakelijk van gebruik maken. Het zou zonde zijn als we ons voor EDA enkel zouden focussen op nieuwe toepassingen – de belangrijkste business Events in het ecosysteem worden waarschijnlijk al gecapteerd door reeds bestaande diensten. Maar hoe kunnen we er dan voor zorgen dat deze Events effectief via EDA technologie – als effectieve IT Events – worden gepubliceerd en beschikbaar worden in het ecosysteem voor subscribers?

In deze blog zullen we een mogelijke stap voor stap benadering bekijken, waarmee we reeds bestaande toepassingen meer Event-Driven kunnen maken. Niet alleen maar door ze stelselmatig meer Events te laten publiceren (al zal dit een logische eerste stap zijn), maar ook door ze hun eigen Events te laten gebruiken.

Een noodzakelijke disclaimer hier, is dat het Event-Driven maken van toepassingen niet het enige is dat zal moeten gebeuren om te evolueren naar een ecosysteem met een ruim en matuur gebruik van EDA. Wat dit allemaal zou moeten inhouden (b.v. het opzetten van een goede Event Broker), staat momenteel nog ter discussie in onze innovatiewerkgroep, al kunnen we daaromtrent uiteraard onze mening geven in een toekomstige blog-post…

Fase 1: Event-Publicatie, “Na de Feiten”

De eerste stap in het refactoren van een bestaande toepassing is meteen ook de belangrijkste voor het ecosysteem: het publiceren van Events. We moeten dit in eerste instantie als een zuivere toevoeging aan de functionaliteiten beschouwen, zonder enige impact op de reeds bestaande. Daarom zullen we een Event pas publiceren “na de feiten”, i.e. nadat alle zaken die normaal gezien door de toepassing worden gedaan, reeds zijn uitgevoerd.

Laten we kijken hoe we dit kunnen doen voor één Event (we kunnen dit uiteraard herhalen om de toepassing meerdere Events te laten publiceren). Beschouw het (informele) sequentiediagram in Fig. 1: een bepaald commando komt binnen in de toepassing (normaal gezien via een API), en er is besloten dat dit aanleiding geeft tot het voorkomen van een bepaald business Event; we willen dit Event dan ook publiceren als gevolg van het ontvangen commando. De toepassing doet reeds ander werk (“Internal Work”) als gevolg van het commando, en het commando moet worden beschouwd als een transactie (zoals we zien in “Command Transaction”).

Om het Event te publiceren met een minimale impact op de werking van de toepassing, zullen we het (via het “EDA Subsystem”) publiceren nadat we de transactie hebben vervolledigd. In de praktijk zal dit b.v. kunnen door (bínnen de transactie) een extra taak in de toepassing te creëren in een aparte thread, die pas wordt uitgevoerd nadat de transactie is afgewerkt (de “publicatietaak”). Het creëren van deze taak zal een zo eenvoudig mogelijke instructie zijn in de programmatie, met een veel kleinere kans op falen dan het effectieve uitvoeren van de taak, en kunnen we daarom dus veilig binnen de transactie doen.

Wanneer dan, achteraf, de publicatietaak effectief wordt uitgevoerd, zal dit door het EDA subsysteem gebeuren, en zullen we dan effectief het Event publiceren (in eerste instantie kan dit als “mock”: een operatie zonder enig effect, later zullen we het Event effectief aanbieden aan de Event Broker). Aldus komt het Event terecht in het ecosysteem en kan men het nuttig beginnen gebruiken.

Fase 2: Event-Publicatie, “In Transactie”

In fase 1 hebben we, om een zo min mogelijke impact te hebben op de performantie en kans op falen van de transactie, een nogal gekunstelde manier moeten gebruiken om het Event te publiceren búiten de transactie om. Een logische volgende stap is dan ook om het publiceren van het Event onderdeel te laten uitmaken van de transactie. Bijgevolg zullen we dan ook garanderen dat, indien de transactie volledig wordt uitgevoerd, het Event ook wordt gepubliceerd. Dit kan een garantie zijn van groot belang voor de Event subscribers verderop in het ecosysteem, vanaf nu kan men erop rekenen dat álle Events van dat type de revue zullen passeren.

Beschouw nu Fig. 2: het verschil met de vorige tekening is niet groot: we zien nu dat het EDA subsysteem wordt opgeroepen tijdens het uitvoeren van het normale werk als gevolg van het binnenkomende commando. Wanneer het Event is gepubliceerd én het andere werk is uitgevoerd, kan de transactie worden afgewerkt. Publicatie van het Event betekent dat we bevestiging hebben gekregen van de Event Broker dat het goed door deze is ontvangen, maar uiteraard niet noodzakelijk reeds naar de subscribers is gestuurd. Dit is net één van de voordelen van de asynchrone communicatie binnen EDA.

Bij deze fase moeten we er wel op letten dat we op een zeer betrouwbare Event Broker kunnen rekenen. Vermits deze online moet zijn om het Event in ontvangst te nemen tíjdens de transactie, zou de transactie worden geblokkeerd indien er daarbij een fout optreedt. Men zou dit als een nadeel kunnen beschouwen, maar we moeten er aan denken dat het Event kan worden gebruikt als plaatsvervanger van het eventuele rechtstreeks oproepen van alle subscribers, indien deze tijdig op de hoogte moeten worden gebracht van wat er wordt beoogd met het uitvoeren van de transactie. Indien men tijdens het verwerken van het commando normaal gezien beroep deed op achterliggende APIs van andere systemen, kan men deze andere systemen nu in plaats daarvan inschrijven op het Event, waardoor deze API calls niet meer hoeven gebeuren en onze toepassing dus niet langer afhankelijk is van de achterliggende. Op deze manier vermínderen we de kans op falen van de transactie indien de Event Broker betrouwbaarder wordt gemaakt dan de andere achterliggende systemen.

Fase 3: Event-First Programming, Transactioneel

Tot nu toe waren onze wijzigingen in de oorspronkelijke toepassing vrij conservatief: het doel was een reeds bestaand systeem Events te laten publiceren ten voordele van het grotere ecosysteem (we zagen daarbij dat dit in principe kan leiden tot het verminderen van het gebruik van APIs van andere systemen en op die manier tot minder afhankelijkheden).

Vanaf fase 3 zullen we echter ook de eigen toepassing gebruik laten maken van de eigen Events, alvorens, als gevolg van het ontvangen van deze Events, het normale werk te doen. Dit noem ik Event-First programming, en het laat toe om een standaard stramien te hebben om te reageren op binnenkomende informatie: alle belangrijke wijzigingen komen nu binnen via Events. Dat betekent dat we op dezelfde manier zullen reageren op de eigen Events, als op andere Events van het ecosysteem, komende van andere toepassingen.

Beschouw Fig. 3: om de transactie (voor het commando) op te volgen, voeren we een extra controller in. Als eerste stap wordt er nu een Event gepubliceerd als gevolg van het binnenkomende commando. Het EDA subsysteem zal dit Event publiceren, en óók de applicatie zelf (naast eventuele andere in het ecosysteem), zullen er zich voor inschrijven. Wanneer het Event dan opnieuw binnenkomt in de applicatie ten gevolge van de subscription, wordt het effectieve werk uitgevoerd dat de applicatie moet doen ten gevolge van het commando. Om de transactie, ten slotte, te kunnen beëindigen, moet de controller worden ingelicht wanneer het werk is gedaan. Hier zijn we vrij om dit opnieuw via een Event te doen, of op een andere manier (gebruik makend van een of ander bestaand mechanisme voor communicatie tussen threads dat wordt aangeboden door de programmeertaal).

Indien we deze fase voor een toepassing volledig implementeren (i.e. toepassen op álle binnenkomende commando’s), kunnen we de toepassing verder gaan modulariseren volgens het principe van CQRS (Command & Query Responsability Segregation). Dit wil zeggen dat modules die reageren op commando’s apart zullen staan van modules die reageren op queries.

Als u heeft opgemerkt dat het een beetje raar is dat we via een extra controller gaan wachten op een bericht dat het werk, als gevolg van ons Event, is gedaan en we onze transactie nu kunnen beëindigen, dan heeft u gelijk: we hebben deze fase eerder als illustratie ingevoegd om het contrast met de volgende fase te verduidelijken. Maar het lijkt ons eerder aangeraden om fase 3 over te slaan en onmiddellijk gebruik te maken van Eventual Consistency!

Fase 4: Eventual Consistency

Tot nu toe hielden we sterk vast aan de transactionaliteit van het uitvoeren van ons binnenkomende commando. Eigenlijk is dit een kunstmatig opgelegde beperking, die ons ervan weerhoudt maximaal in te zetten op de availability van het ecosysteem (zie: CAP theorema). In fase 4 zullen we gaan vertrouwen in het concept Eventual Consistency: we gaan het commando als uitgevoerd beschouwen, van zodra we zeker zijn dat ons Event is gepubliceerd. We gaan er dan van uit dat de toestand van de applicatie (en, per extensie, van het volledige ecosysteem), na verloop van tijd (“eventually”) consistent zal worden en alle nodige zaken zijn gebeurd als gevolg van het commando (ook in andere toepassingen!). Typisch zal deze tijd redelijk kort zijn; we laten enkel de mogelijkheid open dat het langer kan duren, omdat we het falen van een achterliggend systeem nu kunnen toelaten (zie ook het PACELC theorema).

Beschouw nu Fig. 4: eigenlijk doen we hier hetzelfde als in Fig. 3, maar dan met een vereenvoudiging: er hoeft geen feedback meer te komen van “Internal Work” naar de “Controller” voor het commando. Deze laatste zal nu simpelweg het commando als uitgevoerd beschouwen wanneer het Event is verstuurd (we hadden de extra controller eigenlijk terug weg kunnen laten). Met deze manier van werken verkrijgen we het meeste voordeel uit EDA voor de eigen applicatie (het voordeel voor het ecosysteem kregen we reeds in fase 1).

Besluit

In deze blog-post lieten we een mogelijke, stapsgewijze evolutie zien van een computerprogramma dat bij het uitvoeren van een commando een business Event zou moeten publiceren. In de eerste fases wordt de impact geminimaliseerd; in latere fases wordt de toepassing zelf meer Event Driven gemaakt. Het spreekt voor zich dat deze manier van werken niet de enige goede is, en dat men ook niet steeds álle stappen hoeft te zetten.

We beseffen dat de vier fases zeer verboos zijn gedocumenteerd in dit schrijven; voor programmeurs kan dit nogal overbodig lijken. Maar we richten deze blog ook op niet-programmeurs, zodat voor hen een tipje van de sluier wordt gelicht over hoe programmeurs moeten nadenken over het echte binnenwerk van een toepassing, en hoe dit in verband staat met de communicatie op schaal van het ecosysteem waarbinnen een toepassing opereert.

Het publiceren van herbruikbare business Events is cruciaal voor een groot IT ecosysteem, waarbij integraties, louter op basis van APIs, op langere termijn voor een verminderde resiliëntie en agility kunnen zorgen. Een goed evenwicht tussen integraties via zowel synchrone als asynchrone communicatie, waarbij EDA als evenwaardig wordt beschouwd aan API, leidt tot het meest gezonde ecosysteem van applicaties.

In dit webinar gaan we in de eerste plaats in op waarom EDA belangrijk is, wat EDA precies doet en de plaats die het kan innemen in een toekomstbestendige IT-architectuur zoals wordt nagestreefd in “eGov 3.0”. We focussen vooral op het waarom van EDA, en op welke manier dit paradigma zijn voordelen biedt wanneer het wordt gecombineerd met andere belangrijke ontwerpprincipes. We zullen een “bird’s eye view” ontwikkelen op hoe applicaties op zich, maar ook het ruimere IT-landschap, eruit zouden kunnen zien met een groter gebruik van dit paradigma. Op een aantal zaken zoomen we technisch dieper in om een voldoende ruim begrip van EDA te bekomen, zonder al te veel in detail te gaan.

Een greep uit de andere concepten die we op deze manier toegankelijk willen maken via dit webinar: Domain-Driven Design (DDD), event storming, hexagonal architecture, microservices, modular architecture, loose coupling, … Ten slotte kijken we ook naar wat er bij zal komen kijken om “meer” of “voldoende” EDA te hebben in onze portfolio, en op de “mindset shift” die daarbij als belangrijkste nood – en obstakel – naar boven komt.

Voici quelques-uns des autres concepts que nous nous souhaitons rendre accessibles de cette manière lors de ce webinaire : Domain-Driven Design (DDD), event storming, architecture hexagonale, microservices, architecture modulaire, loose coupling… Enfin, nous examinerons également les éléments à prendre en compte pour avoir “plus” ou “suffisamment” d’EDA dans notre portefeuille, ainsi que le changement de mentalité qui apparaît comme le principal besoin – et obstacle – pour y parvenir.

Recording

Presentation

Event Driven Architecture (EDA) is niet meer weg te schrijven uit moderne software-architectuur. Maar wanneer ben je nu effectief EDA aan het gebruiken? Soms kan het zijn dat dit paradigma in je software-systeem zit, zonder dat je er erg in hebt. En daarnaast gebeurt het ook vaak dat een architect zegt dat zijn systeem EDA gebruikt, maar dat de toehoorders zich daar iets heel anders bij voorstellen dan wat die architect eigenlijk bedoelt. Meestal ontstaat deze verwarring doordat er een aantal verschillende patronen bestaan, die allemaal onder dezelfde noemer van EDA vallen. In deze blog laten we ons licht schijnen op de 4 belangrijkste vormen van EDA.

Alle 4 deze vormen van EDA, zullen natuurlijk gebruik maken van de basis: een set van Event producers kan Events genereren en aan een of ander kanaal geven, waarna de Events worden afgeleverd aan een set van Event consumers. Zowel producers als consumers communiceren enkel met het kanaal (typisch een Event Broker) en hoeven elkaar voor de rest niet te contacteren (althans wat het versturen en ontvangen van de Events betreft).

Event Notification

De eerste manier om aan EDA te doen is de meest eenvoudige: een Event wordt hier simpelweg verstuurd om aan te geven dat er iets is gebeurd. Bijvoorbeeld een ‘CustomerChangedEvent’ om aan te geven dat er iets werd aangepast aan een klantenfiche, of een ‘OrderPlacedEvent’ om aan te geven dat er een nieuw order is.

Belangrijk in dit patroon, is dat de Events verder geen toestand bevatten. Als de ontvangers van het event dus willen weten wát er precies is veranderd aan de klantenfiche, of wát er besteld werd in het order, dan zullen ze toch actief initiatief moeten nemen om aan deze informatie te geraken. Typisch zullen er dan, na het ontvangen van een event, API calls moeten worden gedaan naar het systeem dat rond de bron van het Event ligt, om meer details te bekomen.

De voordelen van dit patroon liggen voornamelijk in de eenvoud ervan: de Events zijn heel erg ‘lightweight’ en eenvoudig te implementeren. Een ander voordeel is dat het systeem dat Events verstuurt, niet hoeft te weten welke systemen er allemaal in de informatie zijn geïnteresseerd: ze zullen de informatie wel komen halen eens ze het Event ontvangen. Er wordt dus al een zekere mate van ‘louse coupling‘ en ‘Inversion of Control‘ bereikt.

Het nadeel van dit patroon is dat het aantal communicaties dat nodig is om bepaalde informatie te verspreiden naar de plaatsen waar ze nodig is, wordt verdubbeld: één keer om het Event te sturen, een tweede maal wanneer er extra informatie wordt gevraagd. Bovendien bestaat er nog steeds een afhankelijkheid in één richting, omdat de systemen die extra informatie nodig hebben, zullen moeten weten waar ze te gaan halen.

Het zal niet verbazen dat deze eenvoudige manier van werken met Events, met overwicht nog steeds de meest gebruikte vorm is, en dat, wanneer er wordt gezegd “ons systeem maakt gebruik van EDA”, er dus meestal Event Notification wordt bedoeld. Dit is echter lang niet de meest krachtige en voordelige manier om van het paradigma gebruik te maken…

Event-Carried State Transfer

Deze tweede manier van werken is de gouden middenweg tussen het toepassen van de volledige kracht van EDA, en het loslaten van de bijhorende complexiteit op een systeem. Het is ook hetgeen de echte voorstanders van EDA begrijpen, wanneer ze van een architect horen dat het paradigma wordt toegepast.

De naam Event-carried State Transfer (EST ?) is gekozen om een beetje te contrasteren met REST (Representational State Transfer). Er is dus sprake van het overbrengen van toestand, t.t.z. effectieve gegevens, tussen systemen. Als we het vorige voorbeeld hernemen, dan zal er aan het CustomerChangedEvent effectief zijn toegevoegd wát er precies is veranderd: minimum wat het nieuwe gegeven is, eventueel ook wat het oude gegeven was, en mogelijks zelfs een hele resem extra gegevens over de klant. Dit vormt meteen ook de moeilijkste evenwichtsoefening bij het ontwerp: hoeveel data zullen we precies toevoegen aan het Event? De bedoeling is natuurlijk dat de ontvanger van het Event alles heeft wat er nodig is om verder te kunnen, zonder nog extra gegevens te moeten gaan opvragen.

De voordelen van dit patroon zijn uiteraard precies de nadelen van het vorige: als het Event het juiste ‘gewicht’ heeft, kan extra communicatie tussen alle partijen worden vermeden, en zijn de systemen dus bijgevolg ook wederzijds onafhankelijk van elkaar: ze hoeven enkel nog met het kanaal te praten via welke Events worden beheerd. Elk systeem kan direct aan de slag met de juiste informatie die door het Event wordt aangeleverd.

Een bijkomend voordeel is dat de Events volgens dit paradigma een grotere mate van herbruikbaarheid hebben: men kan een catalogus aanleggen van Events die beschikbaar zijn in een ecosysteem van applicaties als primaire manier om gegevens over te brengen: een volwaardig alternatief voor RESTful APIs. Elke nieuwe applicatie die de aangeboden informatie kan gebruiken, kan zich dan inschrijven om het desbetreffende Event te ontvangen.

Nadeel is dat deze manier van werken met Events iets meer werk vraagt: men zal moeten nadenken over welke Events het meest nuttig zijn en hoeveel informatie deze best bevatten. Men zal de Events moeten opnemen in een catalogus, zodat ze optimaal worden hergebruikt. Daarnaast krijgt men soms wat overbodig dataverkeer omdat de Events mogelijks meer informatie bevatten dan de ontvanger nodig heeft. De architecturale complexiteit is echter slechts een weinig hoger dan bij Event Notifications (voor de applicties die Events versturen blijft het b.v. gewoon “iets extra doen op sommige momenten”).

Een laatste aandachtspunt is dat het inzetten van EDA om toestand te verspreiden overheen systemen de notie van Eventual Consistency neigt te activeren. Dit kan zowel voordelen als nadelen hebben.

Event-Carried State Transfer komt dan wel al wat vaker voor dan vroeger (en ligt ook meestal aan de basis van het populair geworden event streaming), maar er ligt nog heel wat onaangeroerd potentieel om met deze manier van werken grote voordelen te behalen in sommige applicatie-ecosystemen.

Event Sourcing

Nu komen we bij de echte kern van het paradigma, waarbij we radicaal voor EDA kiezen doorheen het volledige ontwerp van ons systeem. Waar de vorige manieren van werken nog weinig intrusief waren in de architectuur, is dit bij Event Sourcing niet langer het geval: de architectuur is nu volledig op Events gebaseerd.

Bij Event Sourcing zal een systeem niet meer op de normale manier zijn toestand gaan bepalen of bewaren, maar zal de huidige toestand steeds gezien worden als gevolg van het ontvangen van een reeks van Events, die elk een kleine toestandswijziging teweegbrengen. Je kan het zien als een bankrekening: het huidige saldo is simpelweg het resultaat van alle voorbije verrichtingen. Een ander goed voorbeeld betreft versiecontrolesystemen zoals git: bij zo’n systeem is de huidige toestand samengesteld uit alle voorbije ‘commits’. Er zijn nog heel wat meer zaken te vertellen over Event Sourcing, maar we bespraken deze manier van werken reeds uitgebreid in een aantal vorige blogs.

Het grote nadeel van Event Sourcing is de sterk verhoogde complexiteit van de software die volgens dit paradigma is gebouwd. Men zal dus goed moeten overwegen of de krachtige mogelijkheden die door het gebruik ervan ontstaan, deze complexiteit waard zijn. Het feit dat Event Sourcing zelden wordt gebruikt en er daardoor slechts weinig architecten voldoende ervaring mee hebben, maakt dit echter erger dan het zou moeten zijn: eens men deze andere manier van werken in de vingers heeft, kan men pas goed de voordelen ervan appreciëren.

De voordelen van Event Sourcing bevatten namelijk de voordelen van Event-carried State Transfer, en breiden deze nog uit: men heeft nu toegang tot de volledige geschiedenis van de applicatie, en niet enkel de huidige toestand. Hierdoor kan men stukken uit het verleden ‘terug gaan afspelen’, wat goed van pas kan komen bij testing en debuggen, of wat veel mogelijkheden geeft bij analytics van deze gegevens. Een event sourced systeem is door deze geschiedenis ook heel geschikt voor audit logs.

Bij gebruik van Event Sourcing kan men de applicatie zelfs ontwerpen zonder echte database: men kan de huidige toestand gewoon in het werkgeheugen plaatsen, zolang de Events zelf goed worden gepersisteerd. Bij falen kan men dan steeds de toestand terug opbouwen op basis van de Event Store (in de praktijk gecombineerd met snapshots van de toestand op geregelde tijdstippen).

Wanneer men al gebruik maakt van Event Sourcing, dan moet men ervoor opletten niet automatisch ook de volgende stap te nemen…

Command Query Responsibility Segregation

De meeste applicaties worden opgebouwd rond een CRUD (create, read, update, delete) systeem. Soms kan het echter interessant zijn om een applicatie op te splitsen in meerdere componenten: degene die schrijven naar de datastore en degene die er in gaan lezen. Je hebt hier dus verschillende modellen waarmee wordt gewerkt: één dat updates behandelt en één (of meerdere) dat queries behandelt. Deze opsplitsing noemen we Command Query Responsibility Segregation (CQRS). Ook CQRS bespraken we reeds in eerdere blogs.

In theorie kan deze manier van werken zonder EDA, maar in de praktijk zullen Events altijd de beste manier vormen voor de communicatie tussen de verschillende subsystemen. Commando’s resulteren dan in Events met bepaalde inputs, die op hun beurt resulteren in Events betreffende toestands-wijzigingen. Query systemen die kort op de bal moeten spelen, schrijven zich in voor deze events en passen bij elk Event onmiddellijk hun uit te lezen toestand aan.

CQRS introduceert enorm veel complexiteit in een systeem. Het is dus zaak van te kijken of het echt serieuze voordelen kan opleveren. Sommige erg complexe business domeinen hebben baat bij deze opsplitsing, omdat het kan resulteren in een kleinere hoeveelheid logica per deelsysteem, indien dat deelsysteem is toegespitst op slechts één verantwoordelijkheid (update of query). In de meerderheid van de gevallen is er echter grote overlap tussen de logica voor updates en deze voor queries, waardoor het delen van een model efficiënter is. De principes van Domain Driven Design kunnen hier helpen.

Een andere reden om CQRS te gebruiken vinden we in performantie en beschikbaarheid: een systeem dat zelden wordt geüpdated en vaak queries krijgt (of omgekeerd) kan baat hebben bij het splitsen van deze verantwoordelijkheden, zodat de componenten apart kunnen worden geschaald (maar ook hier zijn er, naast CQRS, eventueel alternatieve architecturen mogelijk).

Kort samengevat: CQRS kan heel krachtig zijn, maar is ook erg complex. Use with Caution.

Conclusie

Nu we de vier voornaamste manieren hebben onderscheiden om gebruik te maken van Event Driven Architecture, zijn we in staat om preciezer te communiceren over het paradigma, en voor elk project een weloverwogen keuze te maken tussen de verschillende werkwijzen.

Event Notification kunnen we zien als beginnelingen-EDA, en is het makkelijkst toe te voegen aan een bestaand systeem. Het kan reeds meerwaarde brengen en de betrokkenen ‘opwarmen’ voor het echte werk. Event Carried State Transfer is een krachtiger mechanisme, met een complexiteit die nog goed onder controle blijft. Deze twee eerste methoden om Events te gebruiken, spelen vooral in op de interactie tussen verschillende systemen, en hebben iets minder invloed op de interne werking ervan.

De zaken veranderen wanneer we kijken naar Event Sourcing en CQRS. Deze paradigma’s werken echt in op de kern van de architectuur binnen een welbepaald systeem, en voegen een behoorlijke dosis complexiteit toe. In bepaalde gevallen is dit het echter waard, vanwege de krachtige en unieke voordelen die op deze manier worden verkregen.

Disclaimers…

Eerst en vooral een aantal disclaimers: de auteur is geen expert op vlak van het business domein, en er zijn dus geen garanties betreffende de juistheid van wat er verteld wordt rond deze zaken. Integendeel, er zullen sterke vereenvoudigingen worden gemaakt, en zelfs kleine aanpassingen, om beter te kunnen dienen als voorbeeld voor de technologische principes die we hier in de verf willen zetten. Het is dus eerder te beschouwen als “geïnspireerd door” en niet “gebaseerd op” hoe de sociale zekerheidssector werkt, en deze laatste moet bovendien heel breed worden genomen: mogelijks zouden sommige van de voorbeeldapplicaties eerder bij werkgevers of sociale secretariaten uitgerold zijn dan bij een instelling van de sociale zekerheid.

Verder is dit voorbeeld “greenfield IT”, en houdt het geen rekening met reeds bestaande toepassingen, legacy software en de in de voorbije jaren, zelfs decennia, opgebouwde complexiteit van de systemen die dit business domein reeds ondersteunen. Daarenboven maken we hier gebruik van geavanceerde Event Driven Architecture concepten, zoals Event Sourcing en CQRS, ook weer ter illustratie van deze technologieën; in de werkelijkheid zijn deze paradigma’s echter soms van een te grote technische complexiteit om te overwegen, en zullen ze enkel daar worden ingezet waar specifieke, moeilijk te behalen niet-functionele vereisten er om vragen.

Het voorbeeld: De arbeidsmotor voor de Sociale Zekerheid

In het voorbeeld krijgen we een aantal applicaties en diensten rond arbeid en zal er voor de integratie gebruikgemaakt worden van APIs en Event Driven Architecture (EDA). Werkgevers zullen gegevens doorgeven die verband houden met arbeidsrelaties die ze hebben met hun personeel: de aanvang en het stopzetten van contracten, data die verband houdt met geleverde prestaties (“werkuren”), en zaken rond het salaris en het uitbetalen ervan. Applicaties voor werkgevers zullen hen helpen te bepalen hoe hoog het loon is dat ze moeten uitkeren en in welke delen het is opgedeeld, en verder zullen ze zien waar ze staan betreffende de sociale zekerheidsbijdragen die ze verschuldigd zijn. Werknemers krijgen een applicatie om een overzicht te krijgen op hun carrière, en de fiscus (als externe partner in dit ecosysteem) kan informatie krijgen betreffende de inkomsten van de werknemers en de bedrijfsvoorheffing. De KSZ, ten slotte, kan waken over de toegang tot gegevens.

In Fig. 1 zien we een collectie van IT services die dit business domein zouden kunnen ondersteunen (om de complexiteit te beperken zijn noch alle systemen, noch alle communicaties tussen de weergegeven systemen, opgenomen; het doorsturen van gegevens naar de fiscus is hier b.v. niet te zien).

Links op de figuur staan een aantal APIs (altijd ondersteund door hun implementerende services) die vooral zullen worden gebruikt om gegevens binnen te krijgen van de werkgevers: alle data die verband houdt met arbeidsrelaties, geleverde prestaties en uitbetaalde salarissen (de Salary Suggest & Payment API kan ook worden gebruikt om een suggestie te krijgen van het salaris dat moet worden betaald, berekend volgens de regels van de kunst).

Meer naar het midden vinden we de systemen die deze data eerder zullen verwerken: deze staan los van de “input” systemen en krijgen hun data van deze laatste via events. We volgen hier dus op macroniveau het principe CQRS, in die zin dat we het verzamelen van de gegevens (welke tot een “command” tot verwerking ervan zullen leiden) scheiden van de verwerking ervan (die zal leiden tot nieuwe, via “query” raadpleegbare gegevens).

Het betreft ten eerste het consolideren van veranderingen in arbeidsrelaties, om zo altijd een up-to-date beeld te hebben van de huidige bestaande relaties, maar ook op de historiek. Ten tweede is er een berekeningsmodule voor salarissen, die ten gepasten tijde kan geactiveerd worden om de salarisvoorstellen te maken en uit te sturen. Het derde systeem is de WorkTime engine: deze krijgt een event binnen, telkens er gegevens binnenkomen betreffende prestaties, en zal deze consolideren tot een up-to-date view van wat er op dat moment gekend is betreffende deze gegevens (er kunnen bijvoorbeeld ook correcties van vorige data binnenkomen, die dan in rekening worden gebracht). Als voorlaatste zien we dan een systeem dat effectief uitbetaalde salarissen zal opvolgen en verwerken, en ten slotte hebben we nog de contribution engine, die op basis van heel wat gegevens uit de andere systemen en regelgeving, voorzien door een “Contribution & Tax Rules System”, de contributies berekent die de werkgevers zullen moeten volstorten. Ook dit laatste kan een real-time optelsom laten zien van wat tot dan gekend is, maar evengoed kunnen we hier maandelijks of driemaandelijks een event laten genereren om het saldo voor die periode mee te delen.

Rechts op de tekening zijn er dan de integraties met verdere backend systemen te zien: Work Task Control vangt events op om de werkprocessen van de medewerkers uit de Sociale Zekerheid te informeren, Human Notifications kan naar events luisteren die via een ander communicatiekanaal aan mensen moeten worden meegedeeld, Process Orchestrator ontvangt en verstuurt events om op die manier iets complexere processen vooruit te helpen (b.v. trimestriële of maandelijkse afrekeningen), Realtime Analytics kan live de eventstroom in de gaten houden en op basis van wat er binnenkomt intelligente beslissingen nemen en verdere signalen (events) uitsturen, en Audit Logging, ten slotte, zal elk event ontvangen dat relevant is betreffende het loggen van de toegang tot, of wijziging aan gegevens (zelfs elk opvragen van data via één van de APIs kan een event veroorzaken dat dan kan worden gelogd als “entiteit X (iets of iemand) kreeg toegang tot een bepaald gegeven”). Dit laatste systeem kan in principe bij de KSZ staan, die onder andere dit soort opdracht hebben.

Een Business event-verhaal doorheen dit ecosysteem

Laten we op zoek gaan naar een aantal Events die van belang zijn in dit business domein (de techniek “event storming” begint hier ook mee; we zullen hier echter al direct een wat technischer bril op zetten, en tegelijk het gegevensverkeer binnen het ecosysteem meevolgen). We doen dit via het voorbeeld van werknemer Willy C, die wordt aangenomen door het bedrijf Acme NV.

• Eerst wordt Willy aangeworven als arbeider; hij krijgt een contract. Een aantal gegevens hiervan worden doorgegeven aan de Contracts API, en dit leidt tot een WorkRelationStartedEvent.
• Dit event wordt opgevangen door de Relationship Engine, die de gegevens via API ter beschikking zal stellen, en door de Process Orchestrator, die een schedule zal starten om acties te ondernemen wanneer het tijd wordt om b.v. Willy zijn salaris te betalen.
• Na een tijdje zal Willy beginnen werken en uren kloppen. WorkTimePerformed Events worden gegenereerd na gebruik van de WorkTime API. We laten in het midden hoe granulair deze events zijn. Technisch kan alles, wettelijk moet dit pas na een bepaalde termijn gebeurd zijn. Het kan echter ook nuttig zijn voor de werkgever om dit eerder door te sturen: degenen die b.v. elke dag, of na elke shift, de gewerkte uren doorgeven, hebben een betere “live view” bij het consulteren van hun gegevens via een dashboard, dan werkgevers die de gegevens pas doorgeven op het einde van de maand.
• De WorkTimePerformed Events worden hoofdzakelijk verwerkt, en goed bewaard (d.m.v. Event Sourcing) door de WorkTime Engine. Deze zal alle gegevens netjes samenvoegen zodat men steeds een correct beeld heeft op hoeveel totale prestaties er reeds zijn geleverd door welke werknemer, voor welk bedrijf, gedurende eender welke periode. Dit wordt dan opnieuw via een API aangeboden, en aldus is dit dus een voorbeeld van CQRS: de gegevens komen binnen via de WorkTime API (en bijhorende service) en kunnen worden geraadpleegd via de Consolidated View API van de WorkTime Engine. Voor het gemak zullen de APIs echter via eenzelfde webadres worden geraadpleegd (de APIs kunnen apart worden ontwikkeld en onderhouden, om daarna samen te worden aangeboden door een API management oplossing).
• Ook correcties in arbeidstijd (b.v. door laattijdig aanvragen van verlof) komen het ecosysteem binnen via WorkTimePerformed Events, waarin de correctie staat. De WorkTime Engine zal alle events netjes opslaan en met correcties rekening houden in het afgeleide datamodel.
• In Willy’s contract staat dat Acme om de 2 weken zijn loon zal uitkeren, rekening houdend met de effectief gewerkte uren. De Payment Suggest Engine zal voorafgaand aan de uitbetaling ervan de huidige stand van zaken opvragen bij de WorkTime Engine (dit op commando van de Process Orchestrator). Op basis hiervan, en via de salarisgegevens verkregen van de Current Contracts API, kan de Payment Suggest Engine dan een brutoloon berekenen. In dit voorbeeld lijkt het heel eenvoudig, maar deze dienst zou kunnen worden uitgebreid met alle mogelijke vormen van loon (b.v. cafetariaplan, mobiliteitsvergoeding, maaltijdcheques, etc.). Wanneer de berekening klaar is wordt een BruteSalaryProposal Event verstuurd.
• Dit laatste event wordt opgevangen door een dashboard voor de werkgever of zijn sociaal secretariaat. Er zal data in staan waarmee de werkgever zijn volledige “payslip” kan invullen: in dit vereenvoudigde voorbeeld kennen we dan het brutoloon, de werknemersbijdrage, het belastbaar loon, de bedrijfsvoorheffing en het nettoloon. Het loon kan dan door de werkgever worden uitbetaald: hoe dit precies gebeurt, laten we buiten beschouwing.
• Uiteindelijk zal dus op de een of andere manier een betaling van het salaris gebeuren (al dan niet overeenkomend met de suggestie). Ook dit komt als data ons systeem binnen via een API die de werkgever of het sociaal secretariaat moet aanroepen: De Payment API (die in de tekening deel uitmaakt van de Salary Suggest & Payment API) en gaat dan als een SalaryPayed Event naar de Salary Engine om de gegevens te verwerken. Een niet afgebeelde Banking Monitoring Service zal daarnaast monitoren wanneer er betalingen binnenkomen van de RSZ bijdragen, welke zullen resulteren in EmployeeContributionPayed Events, die ook naar diezelfde Engine kunnen worden gestuurd. Via de Consolidate Salary Info API kan men al deze gegevens historisch raadplegen.
• Dashboard services voor de werkgever, zowel als voor de werknemer, kunnen eveneens van deze gegevens gebruik maken om ze te laten zien aan de eindgebruiker.
• Na een kwartaal zal Acme zijn werkgeversbijdragen moeten betalen. Hiertoe zal de Contribution Engine in actie komen, in opdracht van de Process Orchestrator. Deze engine zal, door allerlei gegevens te raadplegen van een aantal APIs binnen het ecosysteem, de bijdrage berekenen en een event uitsturen. Op deze manier kan de informatie dan in het dashboard van de werkgever terechtkomen, maar ze wordt eveneens door Human Notifications opgevangen om een factuur naar de eBox te kunnen sturen. Daarnaast zal ook Work Task Control ingeschreven zijn op dit event, zodat processen en dossiers rond de werkgever Acme kunnen worden geüpdated.

We kunnen uiteraard blijven doorgaan met uit te leggen welke events er zijn en waarvoor deze allemaal nuttig kunnen zijn, maar we gaan ons beperken tot dit nog relatief eenvoudige voorbeeld. Deze manier van werken is eindeloos flexibel: elke service binnen dit ecosysteem kan, indien nodig, reageren op bepaalde gebeurtenissen en de nodige acties ondernemen, en dit kan dan zowel gaan om standaard business processen, als om ondersteunende zaken zoals audit logging en realtime analytics.

We hebben hier een globaal overzicht geschetst van een ecosysteem van applicaties. Dit zegt natuurlijk nog niet in detail hoe elk van deze systemen intern zullen werken (en verder opgedeeld zijn in modules). Event Sourcing kan een logische keuze zijn om de CQRS die we hier voorzien te ondersteunen, maar dit is niet noodzakelijk de beste keuze. Event Sourcing kan daarnaast b.v. ook van pas komen indien we “herspeelbaarheid” van wat er zich in een applicatie heeft afgespeeld willen bekomen. De meeste applicaties hebben echter voldoende lichte niet-functionele vereisten om een eenvoudiger intern ontwerp toe te laten. Wat we wel zien is dat een basis gebruik van EDA, ook zonder deze geavanceerde concepten, maar wel verdergaand dan enkel lege notificaties, het systeem erg gemakkelijk her- en uitbreidbaar maakt (met nieuwe events en nieuwe consumerende services die elkaar “kruisbestuiven” zonder van elkaar afhankelijk te worden).

Besluit

Event Driven Architecture en het gebruik van APIs vormen samen het bindweefsel van communicatie tussen diensten in een applicatie ecosysteem. Het fictieve voorbeeld in deze blog laat zien hoe ze elk in hun kracht staan: APIs voor de onmiddellijke ontsluiting en het beschikbaar stellen van bestaande gegevens (vaak zelfs als “authentieke” bron) en EDA voor het realtime en transparant consumeren van alle mogelijke informatie van zodra deze beschikbaar wordt, op een manier die de agiliteit en beschikbaarheid van het volledige ecosysteem sterk verhoogt.

Bij het software bouwen, maken we meestal geen op zichzelf staande programma’s meer. We bouwen vandaag eerder Applicatie Ecosystemen. Wanneer we dus een stuk software schrijven, mogen we niet zomaar de ontwikkeling lokaal optimaliseren, maar moeten we ook continu rekening houden met het grotere geheel. In deze blog maken we een verkenning van een aantal zaken waar we rekening mee moeten houden bij het bouwen van een ecosysteem, en van concrete principes die we kunnen toepassen bij het uitbouwen van een erbij passende modulaire architectuur.

De Paradox van de Afhankelijkheid

Er heerst grote waarde in zaken met elkaar verbinden, en in reeds bestaande zaken te hergebruiken bij het bouwen van nieuwe dingen. Gegevens, en ook de manier waarop ze worden verwerkt, ja, soms zelfs hele stukken van een applicatie, van één instelling, kunnen ook van pas komen bij een andere. En uiteraard geldt hetzelfde ook al binnen één en dezelfde instelling. Er is dus een meerwaarde te vinden door zaken met elkaar te verbinden en door zaken van elkaar te gaan hergebruiken. Dit is ook het hele opzet achter het ReUse verhaal binnen onze sector. Connecties en communicaties tussen systemen creëren hergebruik, efficiëntie en business waarde.

Maar wanneer we zaken verbinden, maken we ze van elkaar afhankelijk. Die afhankelijkheid heeft op technisch vlak vooral nadelen. Denk maar aan het onbeschikbaar zijn van een dienst waarvan andere diensten rechtstreeks afhangen; vaak worden deze laatste dan eveneens onbeschikbaar. Maar ook semantisch maakt het de zaken moeilijker. We mogen niet zomaar puur lokaal nadenken over alle concepten die we in onze computerprogramma’s verwerken; nee, we moeten er rekening mee houden dat ze geïntegreerd of hergebruikt kunnen worden. We moeten ervoor proberen te zorgen dat de betekenis ervan voorbijgaat aan wat puur noodzakelijk is voor ons specifieke geval. Dat soort zaken maakt het ontwikkelen van software een stuk moeilijker. Dit niet doen is echter nog erger: de “technical debt” die ontstaat door teveel kortetermijn- en lokaal denken, zal dan op termijn alleen maar onbeheersbaarder worden.

En dat is dus de paradox: de afhankelijkheid tussen de systemen binnen een applicatie ecosysteem creëert enorme business waarde, maar maakt de IT een stuk lastiger (en duurder).

De “Mesh” Architectuur

Een goede architectuur kan echter soelaas brengen in dit verhaal, en consequent rekening houden met hergebruik kan uiteindelijk zelfs geld gaan besparen. Het gebruik van een Service Oriented Architecture (SOA) is daarbij één van onze belangrijkste wapens om de afhankelijkheden in ons ecosysteem de baas te kunnen, met de Microservices Architectuur als ultieme voorbeeld. Dit zijn echter slechts voorbeeld technische implementaties van het belangrijke concept Modulariteit (dat men in principe zelfs binnenin een monolithisch systeem kan implementeren). Wat proberen we hiermee te bereiken?

• Modules zijn zo onafhankelijk van elkaar als maar kan (maar maken toch van elkaar gebruik vanwege de waarde die dit heeft): ze zijn liefst “loosely coupled”: veranderingen in de werking of het ontwerp van één module hebben zo weinig mogelijk impact op de werking of het ontwerp van een andere. Dit laat toe om ze apart van elkaar te laten werken en ze te laten onderhouden door aparte teams, zonder dat er continu overleg of downtime moet zijn (in het geval van een monoliet verliest men wel dit downtime voordeel).
• Modules zijn voldoende klein. Men volgt hier de Unix filosofie “do one thing and do it well”. In de praktijk wil dit zeggen dat modules gericht zijn op het aanbieden van één bepaalde business capabiliteit, die in principe apart kan worden gedeployed. Hoe men precies de context van een service afbakent, is één van de belangrijkste onderdelen van de Domain Driven Design (DDD) ontwikkelingsmethode.

Het tweede punt is niet te onderschatten en één van de moeilijkste zaken, reeds bij de business en functionele analyse en ook verderop in het ontwerp van software. In deze blog richten we ons echter op de aspecten van een groter ecosysteem, en daarom zullen we ons hier beperken tot de eerste vraag:

Hoe houden we onze modules zo goed mogelijk onafhankelijk, terwijl we ze toch laten communiceren?

Een aantal helpende Principes

We gaan er vanaf hier van uit dat we onze modules verpakken in aparte services, en we zullen nu een aantal ontwerpprincipes overlopen die ons gaan helpen bij het uitbouwen van een ecosysteem architectuur waarin we een grote onafhankelijkheid, maar ook herbruikbaarheid, van onze services nastreven.

1. Het gebruik van APIs. Dit principe is reeds goed gekend en vormt een basissteen van SOA: Een service stelt zich open naar de buitenwereld toe via zijn API, en deze API is dan ook het enige waarvan andere services afhankelijk kunnen zijn. Op die manier beperkt men dus de afhankelijkheid die andere zaken m.b.t. een service zullen hebben, tot wat strikt noodzakelijk is. Men is hier echter wel nog semantisch en syntactisch afhankelijk van de APIs van andere services die men wenst te gebruiken, en ook technisch afhankelijk van het online zijn van die andere services.

2. Het gebruik van Events. Event Driven Architecture is ook al oud, maar maakt meer recent furore dankzij de Reactive beweging. In plaats van (of naast) communicatie via een API, kan men de communicatie tussen services ook via het versturen van events laten gebeuren. Daar hoort bij dat een service die een event verstuurt, niet op voorhand weet welke andere services dit event zullen ontvangen. Services hebben hier enkel controle over de events die ze zelf versturen en dewelke ze zelf wensen te ontvangen. Het is duidelijk dat hier de onafhankelijkheid nog sterker is dan in het geval van APIs: men is niet langer rechtstreeks afhankelijk van de interface, noch van het online zijn, van een andere service. Men is enkel nog technisch afhankelijk van het online zijn van de Event Bus (een middleware systeem dat men met grote redundantie kan opzetten), en semantisch afhankelijk van de definitie van de betrokken events (een niet te vermijden afhankelijkheid die wordt opgelegd door de business vereiste van het gebruik van de betreffende business capabiliteit die door het event mede wordt ondersteund).

3. CQRS. Wanneer we microservices bouwen die zo klein en onafhankelijk mogelijk zijn, betekent dit eigenlijk dat we een onderscheid moeten beginnen maken tussen services die data binnenkrijgen en/of (deels) verwerken, en services die daarop verder bouwen om informatie te verschaffen en vragen te kunnen beantwoorden. Typisch zullen dit verschillende business capabilities zijn, en dus een aparte service vereisen. Bovendien maken we de microservices liefst zo klein, dat er vaak data van meerdere microservices afkomstig, nodig zal zijn om bepaalde queries te beantwoorden, waardoor het sowieso minder vanzelfsprekend wordt om de queries te implementeren als onderdeel van één van die microservices; ook daardoor wordt het dus logischer om ze in een aparte dienst te deployen. Dit principe noemen we Command Query Responsability Segregation (CQRS): we scheiden de ver-antwoordelijkheid voor het behandelen van commando’s (opnemen en verwerken van data) en die voor het beantwoorden van queries (teruggeven van, meestal verwerkte, data) in aparte services.

4. Sagas. Soms is het nodig dat in een applicatie zaken gebeuren die ofwel gezamenlijk slagen, ofwel gezamenlijk falen. Dit noemt men een transactie. Zoals reeds in een eerdere blog vermeld, is het nuttig om transacties binnen onze systemen te minimaliseren en goed na te denken op business niveau of ze echt wel nodig zijn. Desalniettemin zullen we ze toch niet geheel kunnen vermijden. Binnen één microservice is de implementatie hiervan doorgaans geen probleem: de onderliggende database zal dit ondersteunen volgens het tweefasig “commit” protocol (2 Phase Commit, 2PC). Wat we echter absoluut moeten vermijden, is om dit protocol toe te passen op meerdere services tegelijk in een gedistribueerde omgeving. Om dan toch tegemoet te komen aan de nood aan gedistribueerde transacties, kunnen we sagas gebruiken. Een saga bestaat uit een reeks lokale transacties (binnen één service), waarbij elke service een event zal publiceren om de volgende transactie binnen de saga te triggeren in de volgende service die eraan meedoet. Indien één van de lokale transacties faalt, dan zal het verstuurde event verschillen van wat het normaal is, en dan volgen compenserende transacties in de services die reeds aan beurt kwamen, om de eerdere veranderingen terug ongedaan te maken. Men kan sagas op 2 manieren implementeren: de eerste is een choreografie, waarbij de services zelf weten wat ze wanneer moeten doen (op basis van de events die ze binnenkrijgen). De tweede optie is de orchestratie, waarbij één service zal optreden als de organisator van het gebeuren en de transactie stap voor stap opvolgt. De communicatie met participerende services kan hier ook met events plaatsvinden, maar eventueel ook via rechtstreekse API calls om de opeenvolgende opdrachten te geven (de antwoorden komen dan wel best via events terug binnen in de orchestrator, anders zondigt men tegen CQRS). Een voorbeeld van een saga (met choreografie) is het verhaal van de webshop in de vorige blog over Event-Driven APIs.

Naast deze 4 principes zijn er nog een aantal secundaire ondersteunende zaken die we mogelijk kunnen doen binnen ons ecosysteem. Denk bijvoorbeeld aan het gebruik van Event Sourcing, of het inzetten van NewSQL databases om een microservice met toestand goed te kunnen schalen. Deze zaken bespraken we reeds voldoende in vorige blogposts.

Besluit: even Wennen

Een moderne architectuur voor een complex Applicatie Ecosysteem bestaat uit meer dan alleen maar APIs, en kan best stevig gebruik maken van de toegevoegde waarde die EDA en CQRS bieden. Wanneer men eerder traditionele architecturen gewend is, is de verhoogde complexiteit natuurlijk even wennen. De voordelen overwegen volgens ons echter op de nadelen van deze leercurve. Eens men deze zaken in de vingers heeft en een aantal keer heeft toegepast, zal men zowel op technisch vlak als op business vlak de pluspunten beginnen ondervinden.

Om het allemaal een beetje behapbaarder te maken, zullen we in een volgende blog trachten deze principes verder te illustreren aan de hand van een voorbeeld applicatie ecosysteem.

We hadden het op deze blog reeds uitvoerig over het gebruik van APIs als bouwsteen voor herbruikbare software. RESTful APIs hebben uiteraard heel wat voordelen, maar toch moeten we opletten dat we ze niet altijd en overal gaan inzetten. Er zijn namelijk ook nadelen verbonden aan deze manier van werken. Met deze blog willen we er op wijzen dat asynchrone, Event-Driven communicatie tussen de systemen soms een veel beter resultaat oplevert, dan het zuivere gebruik van RESTful APIs.

REST: de gouden standaard

We hebben er zelf reeds enkele malen op gehamerd: RESTful APIs zijn al jaren de de facto standaard voor de communicatie tussen services en hebben ons tal van voordelen gebracht. Zo maken ze het b.v. eenvoudig om diensten te kunnen ontwikkelen op een technologie-agnostische manier, zolang de API maar goed gestandaardiseerd is. Een REST API geeft je ook rechtstreekse controle over wat een service voor jou doet en laat toe om gedistribueerde transacties uit te voeren.

Het belangrijkste voordeel van REST is dat de technologie heel goed ingeburgerd en breed geaccepteerd is. Het is daardoor makkelijk om ontwikkelaars te vinden die ermee om kunnen gaan. Ondertussen zijn er ook tal van goede raamwerken rond gebouwd en ook standaarden voor de definitie en omschrijving van APIs, waardoor RESTful APIs de ultieme bouwstenen van herbruikbaarheid zijn geworden.

Het gevaar is echter dat RESTful APIs zó nuttig zijn, dat ze als een gouden hamer gaan worden gebruikt: deze RESTful hamer werkt zo goed, dat elk project en elk probleem als een spijker wordt beschouwd. Kortom, de technologie wordt steevast toegepast, daar waar soms andere keuzes een betere oplossing kunnen vormen. Er zijn namelijk een aantal nadelen verbonden aan een aanpak enkel en alleen gebaseerd op APIs…

De pure API aanpak

Wanneer we tegenwoordig software ontwikkelen, zullen we dit niet meer monolitihisch doen. Om de beschikbaarheid te verhogen en om elastisch schaalbare diensten te bouwen, zullen we de functionaliteit zo goed mogelijk verdelen over een aantal zo klein mogelijke services, mogelijks zelfs microservices. Deze zullen dan samen, onderling communicerend, alle functionaliteit voor een applicatie, of meerdere applicaties, implementeren. Bij een enigszins naïeve aanpak zal men al deze communicatie eenvoudigweg voorzien d.m.v. het gebruik van RESTful APIs, en zal elke dienst de andere diensten synchroon oproepen wanneer deze de functionaliteit ervan nodig heeft.

Voor alle duidelijkheid: een synchrone oproep is een oproep die onmiddellijk antwoord verwacht van de tegenpartij. Een asynchroon bericht is éénrichtingsverkeer (al kan er – later – wel een antwoord komen in de vorm van een ander asynchroon bericht; het verschil is dat de eerste partij niet wacht op een antwoord en gewoon zijn werk verder zet).

Laten we het voorbeeld in Figuur 1 bespreken: Het betreft een webwinkel, opgebouwd via een microservices aanpak, waarbij alle microservices met elkaar communiceren via hun APIs. In de figuur staan 14 point-to-point afhankelijkheden; we zullen deze overlopen aan de hand van een typisch scenario.

1. De gebruiker logt in (REST call van Webstore Site naar Customer voor de gebruikersgegevens)
2. Customer doet ook een call naar Cart om een eerder opgeslagen winkelkarretje in te laden
3. De gebruiker winkelt: calls naar Catalog (query) en calls naar Cart (update)
4. Op zijn beurt zal Catalog de Inventory service aanroepen om te zien wat voorradig is
5. De gebruiker wil afrekenen: call van Site naar Checkout
6. Checkout roept Customer en Cart op, om de adresgegevens van de klant in te laden en de inhoud van het karretje
7. Call van Checkout naar Shipping voor de verzendingskost
8. Achter de schermen roept Shipping hiertoe mogelijks een externe API op van de koerier
9. De betaling wordt gestart: call van Checkout naar Payment
10. Payment roept Customer op voor de opgeslagen betalingsgegevens
11. Na de betaling werkt de Checkout module het order af met een Call naar Shipping en naar Inventory
12. Ook Orders krijgt een call om het afgewerkte order op te slaan
13. De klant kijkt zijn bestellingen nog eens na: call van Customer naar Orders

Zoals we kunnen zien heeft de microservices approach al een voordeel tegenover de monolithische aanpak: er mogen een paar services plat zijn, en mensen kunnen toch winkelen (zonder in te loggen zijn enkel cart, catalog en eventueel inventory nodig). Enkel tijdens een checkout zijn zowat alle services nodig (behalve de catalog).

Dit laatste blijft natuurlijk een probleem: door de vele onderlinge afhankelijkheden tussen de services, kunnen er cascades ontstaan: de onbeschikbaarheid van één service kan de werking van vele andere verstoren en zelfs verhinderen. Daarnaast moet men met al deze afhankelijkheden rekening houden wanneer men een nieuwe versie van een service wil bouwen. Verder is het ook zo dat we van alles impliciet een transactie maken (en als één stap faalt, faalt de hele transactie), terwijl dit misschien niet noodzakelijk is op business niveau. Dit transactionele aspect verplicht ons ook om telkens alle stappen opnieuw te doorlopen in geval van een fout, en kan er, indien er zaken weggeschreven worden tijdens de transactie, ook voor zorgen dat we zaken terug actief ongedaan moeten maken indien er een fout is opgetreden, om te vermijden dat de achterliggende data corrupt wordt.

De directe koppeling tussen de vele diensten heeft nog een ander gevolg: de onafhankelijkheid van de microservices komt in het gedrang. Het hoofddoel van een microservices aanpak, is dat men een collectie onafhankelijk opererende diensten verkrijgt, die afzonderlijk van elkaar kunnen opereren en evolueren. Hoe sterker ze echter gekoppeld zijn aan elkaar, hoe minder groot deze onafhankelijkheid wordt.

Richting asynchrone communicatie

We hebben reeds in vorige blogs besproken wat Event-Driven Architecture (EDA) is en welke geavanceerde toepassingen er bestaan, gebaseerd op dat paradigma. Kort herhaald, gaat het hier over asynchrone communicatie tussen toepassingen, doordat ze events publiceren en zich op events van andere systemen kunnen abonneren. Dit zorgt voor een extra indirectie tussen de toepassingen, en op die manier kunnen ze onafhankelijker van elkaar opereren. Een EDA systeem is ook erg uitbreidbaar: je kan altijd extra services toevoegen aan het geheel, die reeds bestaande events gaan gebruiken om nieuwe functionaliteit te implementeren, en die op hun beurt nieuwe events kunnen publiceren. Op die manier krijg je een groeiend ecosysteem van nuttige Events, net zoals je ook met APIs een ecosysteem kan ontwikkelen.

De wereld heeft echter niet stilgestaan sinds onze vorige posts over EDA en ondertussen zijn er op technologisch vlak al heel wat interessante evoluties bijgekomen. Het is nu zelfs vrij gemakkelijk geworden om ook de front-ends van applicaties aan te sluiten op een Event-Driven omgeving. Je kan je natuurlijk gaan afvragen of er ondertussen ook nog geen standaarden bestaan voor EDA, op basis waarvan we herbruikbare zaken kunnen gaan ontwikkelen, en die zijn er ook stilaan. Het voornaamste wat we kunnen doen om EDA goed te kunnen gebruiken, is echter eerst en vooral ze als “first class citizen” gaan beschouwen vanaf de business analyse, en niet langer als een louter technische vernuftigheid die een aantal problemen in systemen kan oplossen.

Beschouw Events als First Class Citizen: neem ze mee in je visie en vanaf de business analyse.

De meeste business domeinen zijn intrinsiek Event-gebaseerd. Denk maar aan een aangifte die binnenkomt, een betaling die moet worden gedaan, een taak die is uitgevoerd, … Dit zijn allemaal “gebeurtenissen” die in de business zelf voorkomen en aldus business events. Eén van de taken die zou moeten gebeuren aan de start van elke analyse, is de tijd nemen om aan Event Storming te doen: een soort brainstorm naar alle business events die zich in een bepaald process of domein afspelen. Daarna kan de functionele analyse hier mee verder gaan om te bepalen hoe de communicatie tussen de te ontwikkelen systemen zich zal afspelen en hoe de business processen zullen worden geïmplementeerd.

Op IT vlak zullen de business events, en daarbijkomend waarschijnlijk nog een aantal eerder technische events, zich dan uiteindelijk vertalen in de events die over de bus worden gestuurd en deel kunnen gaan uitmaken van een ecosysteem van herbruikbare events. Daartoe is het ook echter van belang dat de events, net zoals herbruikbare APIs, gecatalogiseerd en goed gedocumenteerd worden, zodat er maximaal voordeel uit het bestaan van deze events kan worden gedistilleerd in nieuwe toepassingen. Wat we dus willen zeggen met “first class citizen”, is dat events op dezelfde manier zouden moeten worden behandeld als APIs, in een Event-first strategie. We willen echter niet afdoen van APIs, daarom wordt het een API+Event-first strategie.

Standaarden voor Asynchrone APIs

Zoals daarnet aangehaald, zijn er op technisch vlak dus ondertussen verschillende goed ingeburgerde technologieën om asynchrone communicatie te voorzien tussen systemen, en waarmee men dus Events kan ondersteunen. De Cloud heeft deze evolutie enorm versneld. We sommen er een aantal op:

• Webhooks / REST hooks. Ook wel reverse APIs genoemd. Via webhooks kan men nog steeds RESTful werken: er wordt een API aangeboden waar een client een adres van een zogenaamde “callback API” kan gaan posten. Later zal de server via dit adres de client kunnen antwoorden. Het voordeel van deze manier van werken is dat men ze op kan laten gaan in de RESTful aanpak. Het nadeel is dat er nog steeds van een synchrone connectie sprake is op het moment van de registratie en op het moment van de callback. Daarnaast is de performantie en veiligheid ook minder dan met de andere methodes.
• Websockets. Dit is het hippe nieuwe protocol voor de browser, waarmee deze een full-duplex kanaal met een webserver kan onderhouden. Full-duplex will zeggen dat men in beide richtingen kan communiceren en dat eender welke kant de communicatie kan starten. Op deze manier kan men dus een webtoepassing in de browser live updaten via events die van de server komen. Deze technologie is dus specifiek nuttig voor het UI-gedeelte van een gedistribueerd systeem: ze zorgt ervoor dat de asynchrone communicatie tot bij de eindgebruiker kan worden gebracht.
• Server Side Events. Dit is een specificatie ingebakken in HTML 5, en daardoor compatibeler dan het nieuwere websockets. Het betreft echter éénrichtingsverkeer, maar dan van de server naar de clients, waardoor men dus een eenvoudigere manier heeft om toch events naar een browser te sturen.
• GraphQL. Een vrij recente query taal om APIs te beschrijven en bijhorende runtime. Deze technologie wordt gepromoot als meer gericht op de client dan op de server. Dit is omdat de client precies kan uitdrukken wat hij van de server wil krijgen, in plaats van enkel gebruik te kunnen maken van op voorhand vastgelegde zaken, zoals in REST. Dit is dus in principe eerder een concurrent voor REST. Je kan echter in GraphQL zogenaamde “subcriptions” aanmaken, waardoor de server je op de hoogte kan houden van een aantal zaken, en aldus is ook hier sprake van asycnhrone communicatie waarmee men aan EDA kan doen.
• gRPC. Dit is een raamwerk dat wordt gepromoot door de Cloud Native Computing Foundation (CNCF). Het is bedoeld om performant Remote Procedure Calls (RPCs) te kunnen maken en aldus eveneens een concurrent voor REST. gRPC bieft een streaming API aan (erg handig bij gebruik van de Reactive principes), waarmee ook asynchrone stromen van berichten (en dus ook Events) kunnen worden behandeld.
• CloudEvents. Ook dit is een initiatief van de “Serverless Working Group” van de CNCF. Het betreft een standaardisering van het beschrijven van events op Publisher niveau, waarbij men zich vooral richt op standaard manieren om de metadata te beschrijven. Een jaar geleden kwam versie 1.0.1 uit. Men werkt verder aan verschillende SDK’s voor talen en er zijn ook specificaties van hoe de standaard te koppelen aan bepaalde technologieën, zoals Event Brokers (de technologie achter de EventBus).
• AsyncAPI. Dit initiatief is de industriestandaard aan het worden. AsyncAPI doet voor EDA wat OpenAPI reeds doet voor RESTful APIs; de twee worden samen ondersteund door de Linux Foundation. Het betreft hier een specificatie van zowel de Events zelf, als de producers en consumers ervan, op een manier die door een computer kan worden verwerkt. Daardoor kan men dan automatisch goede documentatie genereren, aslook stubs voor code, die kan worden gebruikt in de systemen die met de Events zullen omgaan. Deze specificatie gaat veel verder dan CloudEvents, en trekt ook meer aandacht van developers. Ze zit ondertussen aan versie 2.2.0. Op dit moment zijn er ook al verschillende technologieën ondersteund voor de effectieve implementatie van de Events: o.a. Apache Kafka, AMQP, IBM MQ, MQTT, SNS, WebSockets, en JMS.

Ondanks alle nieuwe ontwikkelingen op gebied van EDA, willen we hier echter niet gaan beweren dat alles nu Event-Driven moet worden, en al zeker niet dat we APIs zouden moeten afschaffen. Events zijn, evenmin as APIs, het antwoord op alles. Ook EDA heeft een aantal nadelen: de asynchrone communicatie inherent aan Events, zorgt ervoor dat systemen die events van elkaar willen gebruiken, op een bepaald niveau “Eventually Consistent” worden, en dus niet meer transactioneel zijn. Dit kan in principe voordelig zijn op een aantal punten, maar het zorgt ervoor dat het minder makkelijk is om erover te redeneren indien men gewend is dat alles ten allen tijde consistent wordt gehouden. Het zijn dus systemen die soms iets ingewikkelder in elkaar zitten en minder gemakkelijk te voorspellen zijn: je hebt, binnen één systeem, geen directe controle over wat er allemaal zal gebeuren als gevolg van een Event dat je de wereld instuurt (je hebt enkel controle over wat je kan doen met inkomende Events). Dit alles zorgt ervoor dat het niet altijd even gemakkelijk is om zulke (groepen) systemen te testen en debuggen, temeer omdat er ook minder veel mensen te vinden zijn die er ervaring mee hebben.

Maar, zoals reeds gezegd, EDA kan heel krachtig zijn, en leunt vaak sterk aan bij het business model. Het ideale antwoord over wat we nu best gebruiken, zal dus, zoals gewoonlijk, ergens in het midden liggen…

De gebalanceerde aanpak: APIs plus Events

Zoals we hebben aangetoond in de vorige sectie, heeft een Eventgedreven aanpak een aantal sterke pluspunten; niet in het minst een resiliënter systeem dat beter voorzien is op toekomstige aanpassingen en uitbreidingen en dus tot op business niveau agile is. Uiteraard zijn er ook een aantal beperkingen, en we gaan dus zeker geen pleidooi houden om vanaf nu alle services zuiver Event-driven te maken. Het antwoord zal een hybride aanpak zijn.

We gaven vroeger al een een eerder abstract voorbeeld van hoe deze verschillende zaken kunnen worden gecombineerd in onze blogs. Nu zullen we dit iets concreter maken: in figuur 3 overlopen we hetzelfde voorbeeld als dat van figuur 1, maar dan met een combinatie van API gebruik en Events.

1. De gebruiker logt in (API call naar Customer; “Login”-Event 1 )
2. De Cart Service ziet event 1 en verstuurt zelf een event met de vorige inhoud van het karretje (“Cart Updated”-Event 2 )
3. De front-end ziet event 2 en laat de kar-inhoud zien aan de gebruiker
4. De gebruiker winkelt (API calls naar Catalog; “Product Chosen”-Event 3 )
5. De Cart Service ziet event 3 en past het karretje aan (nogmaals “Cart Updated”-Event zoals 2, niet apart getoond)
6. Ook Checkout ziet de “Cart Updated” events en bewaart de aankopen (“Cart Updated”-Event zoals 2, niet getoond)
7. De gebruiker wil een checkout doen (API calls naar checkout en shipping, voor de verzendingskost)
8. De gebruiker bevestigt het order (API call naar checkout; “Order Confirmed”-Event 4 )
9. Event 4 wordt opgepikt door Cart (kar leegmaken) en Orders (order bewaren)
10. Event 4 wordt eveneens gezien door Inventory (Inventory wordt gereserveerd)
11. De gebruiker wordt ook omgeleid naar Payment en voert de betaling uit (API call naar payment)
12. Er gebeurt een succesvolle betaling (“Payment Received”-Event 5 )
13. De Orders Service ziet event 5 en stuurt zelf een event (“Order Ready-to-Pack”-Event 6 )
14. De Shipping Service vangt event 6 en regelt het versturen bij de koerier
15. Ook de Inventory service ziet event 6 (Inventory wordt finaal aangepast en pak-opdracht gaat naar magazijn)
16. De klant die zijn orders raadpleegt, kan dat nog via een API call (De Orders Service kunnen we via CQRS bouwen: het deel dat actief zaken verwerkt en business beslissingen neemt is volledig Event-Driven; een tweede component van de service observeert alle gerelateerde events en bouwt een resulterend relationeel model op, dat makkelijk kan worden gequeried)
17. Hier stopt het voorbeeld van Fig. 1, maar we zouden nog verder kunnen gaan: wanneer het pakket klaar staat, zal er opnieuw een event hiervoor zijn en kan de effectieve verzending gebeuren via de koerier. Daarna zijn er nog tracking events, enz.

Een aantal extra opmerkingen betreffende deze manier van aanpakken:

• In dit scenario zien we dat de front-end meer rechtstreeks gebruik maakt van een aantal achterliggende diensten, en er dus in principe van afhankelijk wordt. We moeten echter onthouden dat dit geen alles-of-niets afhankelijkheid is, zoals een aantal van de point-to-point verbindingen in het eerste scenario. De afhankelijkheid geldt enkel voor welbepaalde functionaliteiten, die afzonderlijk van elkaar onbeschikbaar kunnen zijn.
• We hebben hier ook de mogelijkheid de betaling achteraf in orde te brengen indien de betaling zou mislukken of de Payment Service niet beschikbaar is. Shipping schiet pas in actie nadat het event “Payment Received” is gepasseerd. In beide scenario’s hebben we eventuele 3rd party API calls naar Betalingsfirma’s (b.v. PayPal) achterwege gelaten, wat een extra kans op falen introduceert. In het eerste scenario zou hierdoor de volledige transactie van de bestelling mislukken (hetgeen ook het geval is bij vele echt bestaande webshops, maar b.v. niet bij een geavanceerde webshop als Amazon, waar men de betaling asynchroon achter de schermen kan regelen).
• Zowel de Cart als de Checkout service houden een winkelmandje bij, maar toch verschillen ze. De Cart service is verantwoordelijk voor de opslag van het mandje overheen verschillende gebruikersessies (en kan eventueel nog wishlists en favorieten en dergelijke functionaliteiten aanbieden). De Checkout service houdt het enkel gedurende één sessie bij tot het een effectief order wordt, en voegt de bestemming en de verzendingskost toe. We zouden hier echter kunnen overwegen om de checkout functies ook in Cart onder te brengen.
• Merk op dat we in geen van beide scenario’s (zuivere API aanpak en hybride) een laatste check van de inventory doen bij het bestellen. Indien echt nodig op business niveau, zouden we dit in beide gevallen synchroon (en transactioneel) doen (met gevolgen voor de resiliency en klantentevredenheid). We kiezen er echter voor op business niveau dit niet te doen en een eventueel stocktekort op business niveau aan te pakken (zie het voorbeeld in de blogpost over Eventual Consistency).
• Om de afhankelijkheid van de externe shipping API te reduceren, kunnen we er in beide scenario’s voor zorgen dat we de prijzen cachen, of zelf op business niveau vastleggen zonder dit dynamisch op te vragen bij de koerier. Op die manier bestaat de afhankelijkheid enkel op het moment van het effectieve aanmaken van de verzending (en later bij het traceren; wat in principe ook best Event-Driven is, maar in externe APIs is dit vaak niet voorzien).

Zoals we kunnen zien aan de hand van dit voorbeeld, kan een hybride aanpak interessante voordelen hebben: de services zijn heel wat minder sterk afhankelijk van elkaar en zijn zelfstandiger. Men kan kiezen op welke events te reageren en welke events uit te sturen, zonder een API te wijzigen; de service kan op deze manier makkelijker evolueren of verplaatst worden. Er is ook een verbeterde resiliëntie: wanneer een service uitvalt, blijven een aantal events onbehandeld. Maar wanneer de service terug online komt, kan dit werk worden ingehaald en gaat het proces gewoon verder. Er is dus sprake van tijdelijke degradatie en uitstel, maar niet van verloren gegane transacties of een cascade van falen. Men moet er wel op letten dat de EventBus een hoog niveau van beschikbaarheid heeft, net zoals de andere middleware platformen waar men de applicaties op bouwt, en de onderliggende infrastructuur.

Conclusie

Een Software Development strategie gebaseerd op het bouwen van RESTful APIs is een goed startpunt. We mogen ons echter niet blindstaren op de voordelen van REST en alleen maar van deze oplossing gebruik maken.

Een Eventgedreven aanpak heeft een aantal sterke pluspunten; niet in het minst een resiliënter systeem dat beter voorzien is op toekomstige aanpassingen en uitbreidingen, en dus tot op business niveau agile is.

In een optimaal gebalanceerde Softwareontwikkelingsstrategie is dus zeker ook ruimte voorzien voor asynchrone communicatie en eventual consistency, door gebruik te maken van Event Driven Architecture. Het is dan ook van groot belang hiermee rekening te houden vanaf het vormen van een visie, tijdens de business analyse en daarna doorheen het hele ontwikkelingsproces.

In een vorige blog gaven we reeds een uitvoerige inleiding van het “Reactive” paradigma. Vermits dit toch wel een belangrijke en invloedrijke zaak geworden is binnen de developer wereld, lijkt het ons nuttig om hier op terug te komen en wat dieper in te gaan op een voorbeeld van een Reactive framework: het Akka framework, één van de pioniers binnen de Reactive beweging.

Wat is Reactive alweer?

Reactieve systemen worden gezien als één van de belangrijkste ontwikkelingen om systemen responsiever te maken voor meer veeleisende eindgebruikers, en om overweg te kunnen met de grote hoeveelheid data die moderne systemen overspoelt. Zogenaamde “wearables” en andere IoT zaken kunnen bijvoorbeeld een constante stroom aan data genereren. Wanneer men dan de data van vele honderden van zulke devices moet verwerken, komen traditionele systemen vaak in de problemen. Maar ook voor ‘gewone’ toepassingen kan deze technologie heil brengen, doordat de responsiviteit en resiliëntie ook kunnen worden verhoogd.

Aan de grondslag van Reactive ligt het feit dat het “message driven” is (Zie Fig. 1). Men zal een systeem bouwen aan de hand van een aantal met elkaar communicerende subsystemen die berichten zullen uitwisselen. Dit kan zowel rechtstreeks als via het publish/subscribe mechanisme van Events. Deze communicatie is altijd inherent asynchroon. Men weet niet wanneer er op een bericht zal worden gereageerd en men gaat er ook niet expliciet op wachten. Deze vorm van communicatie tussen componenten zorgt ervoor dat ze losjes gekoppeld zijn en locatietransparant. Dit “message driven” fundament leidt verder tot verschillende voordelen.

Eerst en vooral zorgt dit voor resiliëntie. Asynchrone communicatie laat toe om componenten veel onafhankelijker van elkaar te laten opereren dan synchrone communicatie, wat ervoor kan zorgen dat één component verder kan indien de andere (tijdelijk) faalt. De manier waarop berichten behandeld worden bij Reactive maakt ook van foutmeldingen gewone berichten; men behandelt deze als ‘first class citizen’, en niet zozeer als een uitzondering. Het omgaan met fouten en met niet-werkende componenten wordt dan als van nature mee opgenomen in het programmeren van zo’n systeem.

Ten tweede stijgt ook de elasticiteit. Bij reactieve systemen is de berichtenstroom heel belangrijk. Men kan deze gaan monitoren en ingrijpen wanneer deze sterk in volume toe- of afneemt, en snel reageren door meer componenten op te starten (of te stoppen), om deze berichten af te handelen. Ook het feit dat het systeem bestaat uit een heel aantal samenwerkende componenten, en niet afhankelijk is van een centrale bottleneck, komt de schaalbaarheid ten goede.

Ten slotte moet dit alles samen zorgen voor een verhoogde responsiviteit. Men zorgt ervoor dat men tijdig en vooral binnen een bepaalde tijd kan reageren op alle binnenkomende berichten, voor een consistente Quality of Service.

Het Akka raamwerk

Akka zag het licht in 2009 als één van de eerste raamwerken die het principe van het Actor programmeermodel naar een mainstream server programmeertaal bracht. Het is beschikbaar zowel voor de programmeertaal Scala (een taal die werkt op de JVM), waar het in principe voor is gebouwd, als voor Java (waar het iets meer boilerplate code vergt). Tegenwoordig maakt het deel uit van het Lightbend platform, samen met het Play raamwerk en de taal Scala.

Actoren kan men zien als kleine onafhankelijke machines binnen een softwaresysteem. Ze communiceren enkel met de buitenwereld (en dus met andere actors) via asynchrone berichten. Wanneer een actor een bericht krijgt, kan deze een aantal verschillende dingen doen: lokale code uitvoeren, zijn eigen toestand veranderen, zelf berichten uitsturen, andere actoren creëren, en beslissen hoe op het volgende bericht zal worden gereageerd. Een actor leeft dus volledig binnen zijn eigen executie-stack. Men kan deze dus beschouwen als een apart proces of een aparte thread, maar in een raamwerk als Akka is het mogelijk om deze veel efficiënter te instantiëren dan dat (zelfs threads zijn nog relatieve zwaargewichten, terwijl een actor in akka maar een paar honderd bytes hoeft in te nemen; één thread zal dan ook typisch vele actors tegelijk aansturen). Daarnaast kan men er voor zorgen dat een actor een andere actor als “supervisor” krijgt. Deze zal in het oog houden of de gesuperviseerde actor faalt, en kan dus indien nodig gepast reageren.

Eén van de meest interessante zaken aan actors is dat het voor de programmeur transparant kan gemaakt worden waar een actor zich bevindt: het kan een andere actor binnen hetzelfde proces zijn, een actor binnen een ander proces op dezelfde machine, of een actor aan de andere kant van het internet: de programmeur kan deze op dezelfde manier behandelen. Dit is één van de eigenschappen die Akka Cloud Native maakt: het is een technologie gebouwd vóór de Cloud, waarmee men optimaal kan gebruik maken van de eigenschappen van de Cloud.

Naast de ‘core’ Akka bibliotheek, bestaan er ook nog heel wat modulaire uitbreidingen, zoals b.v. voor het werken met streams, persistentie, webservers en http, en allerlei integraties, zoals b.v. met het Play framework, of met Apache Kafka. Ook RESTful APIs worden ondersteund.

Een voorbeeld

In de code duiken zou een beetje te technisch worden, maar we kunnen toch illustreren wat men met deze manier van programmeren kan bereiken aan de hand van een eenvoudig voorbeeld.

In onderstaande figuur zie je een tekening van een aantal actoren in een boekenwinkel systeem en de berichten die ze elkaar sturen: er zijn klanten, de boekenwinkel zelf, en bedienden (die boeken opsturen). Het systeem zal als volgt werken: klanten sturen bestellingen naar de winkel; deze zal de bestellingen verder doorgeven aan een bediende. Deze hebben wat tijd nodig om een bestelling af te handelen, dus er zijn er meerdere, om meer bestellingen aan te kunnen. Hoe de winkel kiest welke taak aan welke bediende te geven, zouden we op verschillende manieren kunnen oplossen (b.v. “neem een willekeurige vrije bediende”), maar zoveel detail laten we hier niet zien.

De bediende die een bestelling krijgt wordt “bezig” (een andere toestand dan “vrij”) en zal uiteindelijk een boek terugsturen naar de klant (in het geval van het IT systeem dat dit systeem modelleert, kan dit b.v. een bericht zijn met de tracking code van het pakket). Daarna wordt de bediende terug “vrij”.

Soms gaat er echter iets mis met de bestelling: de bediende vindt b.v. het boek niet dat de klant wil. In dat geval stuurt deze een verontschuldigend bericht terug naar de klant, met een cadeaubon. Als er echter te vaak van deze dingen gebeuren, krijgt een bediende teveel stress en geeft deze er de brui aan (zijn actor gaat in error-modus). Dit geeft dus een foutmelding, die geëscaleerd wordt naar de supervisor van de bediende, in dit geval de winkel (zie Fig. 3). Deze zal dan moeten beslissen wat er met de fout gebeurt: we kiezen ervoor om de bestelling aan een andere bediende te geven en de gestresseerde bediende een paar dagen “verlof” te geven (waarna zijn actor terug in toestand “vrij” zal komen).

Dit voorbeeld illustreert het principe van resiliëntie, gebruikmakende van actoren: de fout wordt niet speciaal als fout behandeld, maar als een bericht naar de winkel, die het probleem op dat niveau kan oplossen. Er wordt ook niet alleen gezorgd voor fout-tolerantie, maar ook voor veerkracht: uiteindelijk zal de foutieve actor worden hersteld en terug ter beschikking komen van de pool. Deze veerkracht maakt net het verschil tussen gewone fout-tolerantie en echte resiliëntie.

Besluit

De meeste bestaande raamwerken voor Reactive systemen focussen zich op het gebruik van streams van berichten/events, en op hoe deze zo efficiënt mogelijk te behandelen. Een raamwerk zoals Akka doet het net iets anders, door gebruik te maken van het actor paradigma. Dit biedt een verfrissende kijk op multi-threaded programming, en kan het bouwen van sommige systemen net iets gemakkelijker maken.

Het gebruik van actoren verhoogt in ieder geval het niveau van abstractie wanneer men over parallellisme en multi-threading probeert te redeneren, een oefening die berucht is voor zijn moeilijkheid.

Actors lijken erg nuttig voor het modelleren van zaken die een toestand en een gedrag vertonen in de echte wereld, zoals mensen, machines, of bedrijven. In het algemeen zijn ze goed inzetbaar wanneer je systeem goed decomposeerbaar is in een set van onafhankelijke taken, of een set van taken die een bepaalde workflow volgt. Ten slotte zijn ze ook erg geschikt voor het programmeren van Event Driven systemen.

U heeft het buzzword “Reactive” misschien al gehoord. Deze nieuwe architecturale principes om software mee te bouwen zouden heel wat van de “problemen” oplossen waar huidige software mee kampt. De Reactive Revolution zou systemen robuuster, resiliënter en flexibeler maken; klaar om toekomstige requirements sneller op te vangen. Maar wat is hier nu eigenlijk van aan?

Een Beetje Geschiedenis

Het “Reactive” Manifest

De huidige hype rond Reactive Systems is ontstaan in de nasleep van het publiceren van het ‘Reactive Manifesto‘. Een manifest is een openbare verklaring die een aantal principes uiteenzet volgens een nadrukkelijke mening en vaak ook mensen uitnodigt deze te onderschrijven. Het reactive manifest werd een eerste keer gepubliceerd door iemand van de firma ‘Lightbend‘, makers van een cloud platform dat volgens deze principes werkt. De tweede en huidige versie van dit manifest dateert van 16 september 2014. Het werd reeds door duizenden mensen onderschreven.

Wat zegt dit manifesto? Een systeem moet responsief, resiliënt, elastisch en message-driven zijn. In de eerste versie was dit nog interactief, resiliënt, schaalbaar en event-gedreven, maar men wou dit algemener gaan verwoorden. Er wordt in het manifest uiteraard iets dieper ingegaan op elk van deze aspecten, maar niet diep genoeg om nu precies te weten hoe je volgens deze principes software kan bouwen, en waar de naam “reactive” nu eigenlijk vandaan komt. Wat dit laatste betreft vinden we meer uitleg in een blogpost van de oorspronkelijke auteur, en in de eerdere versies van het manifest: het gaat om een aantal verschillende principes, die allemaal tot gevolg hebben dat het systeem beter en sneller zal reageren op allerlei zaken:

• react to events: the event-driven nature enables the following qualities:
• react to load: focus on scalability rather than single-user performance
• react to failure: build resilient systems with the ability to recover at all levels
• react to users: combine the above traits for an interactive user experience

Functional Reactive Programming

Het woord “reactive” zien we in de IT-geschiedenis echter nog veel eerder opduiken: het gaat dan om Reactive Programming. Dit is een manier om te programmeren die zich toespitst op het omgaan, op een declaratieve manier, met stromen van data en het propageren van veranderingen in die data (en ook met steeds binnenkomende nieuwe data). Ze is sterk verwant aan “Dataflow Programming“.

Om het iets concreter te maken, kan men dit vergelijken met spreadsheets, zoals gekend van b.v. Excel. Wanneer men in een werkblad een gegeven in een cel verandert, veranderen onmiddellijk alle cellen die van dit gegeven zijn afgeleid, a.h.w. zonder dat er eerst nog expliciete berekeningen voor moesten worden verricht. Uiteraard gebeuren deze berekeningen wel op de achtergrond: Excel maakt dit transparant, net zoals reactieve programmeertalen dit doen voor hun datastromen: verandert er iets in de bron-stroom, dan volgt ook onmiddellijk de uitgangsstroom.

Aan het bovenstaande principe wordt dan nog Functioneel Programmeren toegevoegd. Dit is een manier van programmeren die zich focust op het vrijwaren van de eigenschappen van pure functies: functies die enkel rekening houden met hun argumenten (niet met toestand elders in het programma) en ook alleen maar een resultaat teruggeven (en dus ook niets veranderen aan de toestand van het programma). Functioneel programmeren maakt het veel gemakkelijker om over code te redeneren. Wanneer met dit doortrekt in een architectuur, bekomt men componenten die men gemakkelijker elastisch kan schalen, die men makkelijker redundant kan uitrollen tegen falen, etc.

Functioneel Reactief Programmeren is momenteel populair en wordt mogelijk gemaakt door een aantal frameworks die goed zijn in te bedden in bestaande platformen. Onder de noemer ReactiveX vinden we bijvoorbeeld ondersteuning voor dit paradigma voor een heel aantal populaire talen, vertaald in specifieke libraries per taal (o.a. voor Kotlin, Java, .Net, Scala, Python, C++, en Javascript). ReactiveX heeft behoorlijk wat invloed gehad op programmeren en krijgt nog steeds de nodige aandacht op conferenties. Het is goed om deze manier van programmeren als software ontwikkelaar in de toolbox te hebben.

Reactive voor Reactive

En wat heeft “Reactive Programming” nu uiteindelijk te maken met de eerder genoemde Reactive Systems? In principe kan je reactieve systemen implementeren zonder dit paradigma, maar het gebruik ervan maakt het bouwen van de systemen echter wel een stuk makkelijker. De middelen die worden voorzien door de reactieve programmeerframeworks maken het namelijk een stuk eenvoudiger om “reactief te zijn” wanneer men zo’n systeem bouwt. De meeste zaken die zo’n systeem in en uitgaan zijn immers te behandelen als datastromen waar men op moet reageren, met als meest typische voorbeeld de stroom van binnenkomende berichten/events.

Hoe is dit nu Beter?

Reactieve systemen zijn Cloud-native, en focussen op 4 zaken: Responsiviteit, Resiliëntie, Elasticiteit, en asynchrone communicatie via berichten. Uiteraard zijn de eerste 3 van deze kenmerken al voordelen op zich, maar hoe worden deze nu effectief verwezenlijkt?

Het belangrijkste element in de architectuur van Reactieve systemen is de asynchrone communicatie via berichten, meestal onder de vorm van Events. Doordat Consumenten en Producenten van Events elkaar niet hoeven te kennen, bekomen we een grotere onafhankelijkheid van deze componenten ten opzichte van elkaar. Men zegt dan ook dat ze ‘loosely coupled’ zijn. Daarenboven zorgt de asynchrone communicatie voor een kleinere latentie en hogere doorvoer van de gegevensuitwisseling tussen de componenten, wat de performantie ten goede komt en zodat de systemen meer ‘Responsive’ zijn. De losse koppeling of onafhankelijkheid is iets wat we ook reeds bij microservices als thema zagen: zulke componenten worden makkelijker elastisch schaalbaar t.o.v. elkaar en kunnen ook afzonderlijk redundant worden gemaakt, waardoor ze resiliënter worden tegen falen. Indien het berichtenuitwisselingssysteem een tijdelijke uitval van één van de componenten kan opvangen (door berichten te bufferen b.v.), is ook het systeem als geheel resiliënter dan een systeem waarbij er synchrone comunicatie wordt gebruikt en elke component onmiddellijk antwoord verwacht van een andere.

Uiteraard moeten in het asynchrone geval de componenten die falen ook wel zo snel mogelijk terug online komen, zodat berichten (inkomende datastromen) zo snel mogelijk worden afgehandeld en er in het systeem als geheel geen te grote wachttijden ontstaan (wat ook een vorm van onbeschikbaarheid is).

Verschil met Event Driven Architecture?

De hier opgesomde voordelen lijken sterk op de voordelen van Event Driven Architecture (EDA), en reactive maakt ook gebruikt van Events. Waar zit dan precies het nieuwe?

De belangrijkste nieuwigheid zit hem in dit geval in de schaal en de benodigde performantie van deze systemen. Waar men in een traditioneel publish-subscribe model af en toe een berichtje kreeg, zit men nu met stromen van data die eigenlijk volcontinu de componenten binnen het systeem bombarderen. Het schaalbaar en elastisch, en ook simpelweg efficiënt maken van elke afzonderlijke component, was nog nooit zo belangrijk.

En dan nog kan het gebeuren dat één component niet meer kan volgen. Er is dan zogezegd een te grote druk (pressure) op de component. Om te vermijden dat deze bezwijkt, heeft men een mechanisme nodig om de rest van het systeem, en dan voornamelijk de bron van de te grote druk, te informeren. Als dit ervoor kan zorgen dat de druk minder wordt, dan kan de component blijven werken en dan is dit voor het systeem als geheel minder erg dan wanneer deze weg zou vallen.

Dit terugkoppelingssignaal noemen we het aangeven van back pressure (de back pressure zelf is het niet meer kunnen volgen; het niet aankunnen van de inkomende ‘druk’). Het zorgt er dus voor dat het bronsysteem wat minder berichten naar de desbetreffende component zal sturen. Zoiets kan natuurlijk verder propageren doorheen het hele systeem; uiteindelijk kan dit zelfs bij de gebruiker geraken, die dan een mindere performantie merkt. Maar dit is uiteraard nog altijd beter dan een plots falen (graceful degradation). Andere componenten in het systeem kunnen hier op hun beurt ook op gaan reageren en meer middelen beginnen vrijmaken op de onderliggende infrastructuur, zodat men kan gaan schalen om de verhoogde druk beter aan te kunnen.

Het monitoren van falende componenten gaat bij Reactive systemen ook verder dan de traditionele monitoring die we zien vanuit de infrastructuur en op het niveau van het PaaS platform. Het is deels ingebouwd in de systemen zelf, zodat deze ook zelf de verantwoordelijkheid kunnen nemen. Men maakt hiervoor o.a. gebruik van het zogenaamde actor model en van supervision trees. In detail ingaan op deze zaken zou ons voor deze blog te ver leiden.

Kortom, een Event Driven Architecture vormt de basis waarop allerlei andere, verregaandere zaken mogelijk worden, om uiteindelijk te komen tot iets wat dan “Reactive” kan worden genoemd.

Besluit

Reactive systems zijn bedoeld om op grote schaal enorme hoeveelheden werk te verzetten, en dit met een sterke resiliëntie. Ze zijn specifiek ontworpen om optimaal in een Cloud te kunnen werken.

De truuk bestaat hem eruit de architectuur zodanig op te bouwen dat elke component op zich sterk staat, maar dat ook de communicatie tussen de componenten meehelpt om onverwachte zaken op te vangen. Het belangrijkste paradigma van Reactive is de asynchrone communicatie, meestal onder de vorm van Events. Daarnaast is het ook nuttig om bij de implementatie gebruik te maken van Functional Reactive Programming.

Interessante bronnen

https://4everinbeta.com/2015/01/15/is-reactive-programming-more-than-just-hype/

http://www.reactive-streams.org/

https://blog.redelastic.com/what-is-reactive-programming-bc9fa7f4a7fc

https://itnext.io/demystifying-functional-reactive-programming-67767dbe520b

https://www.scnsoft.com/blog/java-reactive-programming

https://medium.com/@GumtreeDevTeam/reactive-programming-hype-or-truth-e6fba44ace76

https://spring.io/blog/2016/06/07/notes-on-reactive-programming-part-i-the-reactive-landscape

_________________________

Dit is een ingezonden bijdrage van Koen Vanderkimpen, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.