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.

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.

• “Key questions for the board” uit J.B. Mantas, Intelligent Approaches to AI
• Gartner toolkit: Selecting and Prioritizing AI Use Cases
• De Data Protection Impact Assessment template op gdpr.eu (geen officiële EU-publicatie)
• Het ontwerp van een Trustworthy AI Assessment list, in voorbereiding door de EU High Level Expert Group on AI
• Het overzicht tools voor ethiek van het Kenniscentrum Data&Maatschappij
• De Data Project Checklist van Fast.ai
• …

De ene vragenlijst is technisch, de andere descriptief, nog andere proberen zoveel mogelijk in cijfertjes te gieten. Dé ultieme checklist maken is onbegonnen werk, want veel hangt af van wie het doelpubliek is van de analyse: de projectleider vindt andere dingen belangrijk dan de CEO, de aandeelhouder of de eindgebruiker.

Goed beseffend dat nòg een extra vragenlijst dat probleem niet oplost, kunnen we het toch niet laten om zelf ook enkele overwegingen te lanceren die wij maken in ons werk bij overheidsdiensten. Zonder te claimen volledig te zijn, 5 kernvragen die wij ons vaak stellen:

1. Hoe zou je het probleem oplossen zonder AI?

Is er wel een goede usecase, en vereist die wel een AI-oplossing? Te vaak wordt AI voorgesteld als hét toverstokje dat alle problemen oplost vanuit het niets. Was dat maar waar: in het echte leven zijn AI-systemen moeilijk om goed geconfigureerd te krijgen, vragen ze constante opvolging en monitoring, en veel werkuren door specialisten. Een dure zaak, daarom kan het geen kwaad om eerst grondig na te gaan: wat is eigenlijk het probleem dat we willen oplossen? Is dat welgedefinieerd en goed afgelijnd? Wat is de situatie vandaag en waar willen we naartoe? Weegt de geschatte ROI van een AI-oplossing wel op tegen die van een aanpak met traditionele IT of zelfs manueel werk? Heb je die andere opties überhaupt overwogen?

2. Zijn de succescriteria (KPIs) goed gekozen, gedefinieerd en meetbaar?

Een enkel AI-systeem lost veelal een klein, welomschreven probleem op. Allerlei criteria kunnen aangewend worden om te meten of dat ook voldoende goed gebeurt: precisie en recall, de tijdspanne nodig voor de berekening, de reductie in manueel werk, … Wat men ook hanteert als KPIs, goede meetbaarheid en opvolgbaarheid zorgen voor gemakkelijker monitoren of kwantificeren van de resultaten. Juist meten is niet noodzakelijk gemakkelijk. Welke accuraatheid wordt verwacht van het AI-systeem, wat is “fout” en wat is “correct”? Bij die vergelijkingen mag men gerust de kanttekening toevoegen dat ook mensen fouten maken als zij dezelfde taak manueel zouden uitvoeren. Is er al eens gemeten hoe vaak dat gebeurt en wat de gevolgen daarvan zijn? Vanaf wanneer zou het AI-systeem ook effectief tot verbetering leiden in de praktijk?

3. Welke praktische beperkingen zijn er?

Elk bedrijf dat niet dezelfde cashpositie heeft als pakweg Amazon of Google, past best zijn verwachtingen inzake AI wat naar verhouding aan. Talent is schaars, zeker als iemand naast AI en data science ook nog vertrouwd moet zijn met projectmanagement en de praktische aspecten van softwareontwikkeling. Zelfs met wat geluk op HR-vlak, is technologische infrastructuur nog steeds niet gratis. De trial-en-error methodiek die de ontwikkeling van AI-systemen vaak kenmerkt, vergt een zekere financiële ademruimte – zeker bij toepassingen waarbij 1 iteratie van 1 trainingsproces al tot een aardige energiefactuur leidt. Daarnaast zijn er ook de ethische en legale beperkingen, bijvoorbeeld inzake gebruik van gevoelige gegevens. Veel van de software aan de basis van een AI-systeem zal van derde partijen afkomstig zijn, of gebruikmaken van open source componenten of een (public) cloud – wat risico’s met zich meebrengt aangaande stabiliteit, onderhoudbaarheid, ondersteuning op langere termijn, licentiëring, confidentialiteit van gegevens, …

4. Zijn er genoeg middelen voor deployment, monitoring, onderhoud?

Een AI-systeem bouwen is 1 ding, het in productie zetten is nog iets anders. Er moeten heel wat waters doorzwommen worden voordat een stuk code ontwikkeld op enkele laptops uiteindelijk klaar is om 24/7 blootgesteld te worden aan de buitenwereld. De extra overhead gevormd door CD/CI, backups, testing, code review, etc. is onmisbaar voor de langere termijn maar kost allemaal tijd en geld. AI-projecten zijn anders dan klassieke softwareprojecten in die zin dat het niet afgelopen is eens de software is opgeleverd. Integendeel, bij oplevering begint het pas, en start een fase van actieve monitoring die schier eindeloos kan zijn: blijft de software wel doen wat ervan verwacht wordt in de buitenwereld? Zeker als nieuwe data wijzigt van karakter, zal je vaak actief moeten bijsturen.

5. Hoe transparant is dat allemaal?

De GDPR legt beperkingen op aan systemen die automatisch beslissingen nemen: er moet altijd de mogelijkheid zijn om de beslissing te laten (her)bekijken door een mens (art. 22). In het gehele AI-beleid dat de EU hoopt te voeren is transparantie een sleutelwoord, waarmee de EU tracht zich te onderscheiden van andere grootmachten. Het kunnen uitleggen waarom een AI-systeem tot een bepaald resultaat komt is belangrijk voor die transparantie, maar is niet noodzakelijk evident wanneer de trainingsdata onoverzichtelijk groot is, misschien niet onder eigen beheer ligt, of wanneer het aantal parameters van het model onoverzichtelijk groot is. Je wil ook niet met je mond vol tanden staan als ooit een journalist of wakkere burger je voorschotelt: is er een ethische evaluatie en Data Privacy Impact Assessment gebeurd, en waar kan ik mijn data raadplegen en beslissen wat ermee gebeurt?

Praktisch

Veel analyses kunnen erg langdradig zijn, dagen in beslag nemen en leiden tot rapporten van 50 bladzijden die niemand achteraf nog leest. Ook is niet alles even relevant voor elke usecase: een AI die een keukenrobot aanstuurt heeft niet dezelfde KPIs of foutentoleranties als eentje die een pacemaker aanstuurt. Om het overzicht te bewaren kan het handig zijn om, voor de eigen usecases, de belangrijkste vragen uit verschillende analyses mee te nemen in een eigen assessment, waarvan de resultaten bijvoorbeeld in een grafiek zoals deze kunnen weergegeven worden:

Dit was uiteraard maar een greep uit de bedenkingen die men kan maken bij de start van een nieuw AI-project. Zulke denkoefening, vooraleer geld en middelen in de uitvoering te steken, is de investering meestal wel dubbel en dik waard.

______________________

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

Serverless: de ideale link tussen APIs, Events, en je eigen code.

Serverless Computing is een Cloud Computing model waarbij de gebruikers enkel code en een stuk configuratie aanleveren voor een beoogde software, en de cloud provider de volledige verantwoordelijkheid in handen neemt voor het beheer van de onderliggende resources (rekenkracht, geheugen, netwerk, etc.). De gebruikers zijn normaal gezien software ontwikkelaars, en het concept valt dan ook onder de noemer “Platform as a Service” (PaaS). Bij Gartner wordt deze technologie ook Functional Platform as a Service (FPaaS) genoemd. Elders gebruikt men kortweg de term “Function as a Service” (FaaS).

Serverless gaat dus nog een stuk verder dan wat momenteel als “mainstream” PaaS-gebruik kan worden beschouwd: Container platformen en Kubernetes. Bij deze laatste is de developer zelf nog verantwoordelijk voor een deel van de “stack” en bepaalt daarmee zelf voor een groot deel op welke manier de software binnen de container zal werken, en daarmee dus ook over de manier waarop de gecompileerde programmacode wordt geïnstalleerd en uitgerold. Bij Serverless zal men enkel broncode (en een stuk tekstuele configuratie) uploaden naar het platform. De configuratie bepaalt daarbij op welke manier het stuk code kan worden opgeroepen (daarover dadelijk meer). Ook de granulariteit van Serverless is typisch kleiner dan die van Containers: meestal wordt er slechts één specifieke functie per Serverless eenheid geïmplementeerd, tegenover typisch een volledige microservice (of groter…) bij Containers.

Serverless Architecture verwierf bekendheid dankzij het product “AWS Lambda” van Amazon. Dit is momenteel nog steeds het platform waarrond het meest furore wordt gemaakt, mede dankzij een verregaande integratie met de rest van de AWS platformen. Je kan b.v. erg interessante zaken doen rond event-based monitoring. Naast Amazon hebben alle grotere Cloud providers nu wel een Serverless oplossing, en er zijn ook reeds enkele open source initiatieven ontstaan (b.v. Kubeless, een platform dat bovenop een Kubernetes cluster werkt), waarmee je op je eigen infrastructuur een FPaaS kan gaan opzetten.

Serverless = Event Driven

Men kan dus als het ware functies in een Cloud uitrollen, maar hoe worden deze dan uiteindelijk opgeroepen? Daar komt de configuratie bij te pas. Zo’n functie zal men namelijk typisch oproepen als gevolg van één of andere gebeurtenis, en dit zal men dan definiëren in de bijhorende configuratie. Indien het een functie is die een website ondersteunt kan dit b.v. een oproep naar een bepaalde API zijn, waar de functie dan een stukje van implementeert. Maar in principe kan men de functie laten reageren op alle mogelijke soorten gebeurtenissen, zolang men deze gebeurtenissen kan capteren via het gebruikte Cloud platform. Voorbeelden zijn legio:

• Business Events (b.v. een bestelling wordt geplaatst)
• Events gepubliceerd door andere software (mogelijks andere Serverless functies)
• Het binnenkomen van nieuwe data (b.v. door het monitoren van een database of door het volgen van een zogenaamde “stream”, dus eigenlijk een vorm van “Reactive Programming“).
• Het verstrijken van een bepaalde hoeveelheid tijd (dit komt neer op scheduling)
• Het binnenkomen van sensor data (denk aan Internet of Things)

De mogelijkheden zijn in principe eindeloos. Men kan dus eigenlijk stellen dat Serverless Architecture een vorm is van Event Driven Architecture, waarbij van het infrastructuur aspect abstractie wordt gemaakt. Over Event Driven Engineering hebben we reeds uitvoerig geblogd.

Voor- en Nadelen

Serverless is een nuttige technologie aan het worden, met duidelijke voordelen. Er moet echter nog een beetje gezocht worden naar oplossingen voor enkele problemen…

Pay Per Use

In de meeste platformen zal men een Serverless functie enkel uitvoeren en dit aanrekenen, wanneer ze daadwerkelijk wordt opgeroepen. Je betaalt dus enkel voor het daadwerkelijke verbruik ervan, en wanneer ze niet wordt gebruikt, betaal je niets. Dit principe noemt men “Scale to Zero”. Dit kan echter ook een nadeel zijn: als de functie echt enorm veel gebruikt wordt, zal de prijs typisch nogal oplopen en kan het interessanter worden deze op een andere manier aan te bieden (b.v. door een aantal containers die men permanent actief maakt, aan een lagere maandelijkse kost).

Schaalbaarheid en Elasticiteit

Deze aspecten zijn nu heel gemakkelijk. Een functie heeft typisch geen toestand, en vermits de developer enkel rekening moet houden met de code voor één uitvoering, is het de Cloud provider die instaat voor het verzorgen van parallellisatie en alle andere aspecten die bij een verhoogde schaal komen kijken. Men krijgt dus als het ware een zeer flexibele schaalbaarheid cadeau (en in het geval van een publieke Cloud Provider ook een quasi oneindige). Daartegenover staat weliswaar dat de performantie bij een laag gebruik iets slechter kan zijn, vermits een serverless functie normaal gezien pas wordt geïnitialiseerd (en resources krijgt) op het moment dat ze wordt opgeroepen.

Veiligheid

Ook het veiligheidsaspect is een tweesnijdend zwaard: alhoewel men zich minder zorgen moet maken over de veiligheid van onderliggende infrastructuur (de Cloud Provider doet dit normaal gezien volgens de state of the art), vergroot men op een andere manier de zogenaamde “attack surface”. Typisch zal men voor een volledige oplossing heel veel kleine functies nodig hebben, en het aantal toegangswegen tot de applicatiecode is op die manier groter.

Eenvoudige Ontwikkeling, Complex Beheer

De productiviteit van de ontwikkelaars zal waarschijnlijk een stuk hoger zijn, gezien ze enkel rekening moeten houden met functionaliteit en code, en veel minder belang moeten hechten aan onderliggende infrastructuur. Daartegenover staat een verhoogde vendor lock-in: een stuk van de code en de configuratie zal typisch gebruik maken van vendor-specifieke functies, die men bij een andere provider niet zal terugvinden.

Daarnaast is er een groot nadeel verbonden aan het bouwen van een groot web van interopererende functies: de complexiteit van dit gedistribueerde geheel. Er ontstaat als het ware een doos vol kleine “legoblokjes” van allerlei functies, die men dan wel nog met een goed plan tot een mooi geheel in elkaar zal moeten puzzelen. In principe is dit niet nieuw: zelfs binnen monolithische applicaties moet men aandacht besteden aan allerlei componenten en stukken code die onderling afhankelijk zijn, omdat ze elkaar oproepen of dezelfde resources gebruiken. Maar doordat deze complexiteit nu verschuift naar de configuratie en het platform, en ze typisch overheen een netwerk zal reiken, wordt het een probleem van beheersbaarheid en routering, eerder dan van code kwaliteit. Men zal nog goede manieren moeten vinden om dit soort zaken beter te gaan ondersteunen, misschien zelfs door encapsulatie, zoals dit reeds vrij goed op punt staat voor het eigenlijke programmeerwerk.

Conclusie

Serverless Architecture is een snel maturerende technologie met duidelijke voordelen. De FaaS platformen maken zeker deel uit van wat de aantrekkingskracht van de Cloud groter maakt. Ze moeten zich echter nog iets grondiger gaan bewijzen: nu komt het er op aan om de laatste nadelen, zoals de beheersbaarheid, nog op punt te stellen en om de meest nuttige toepassingen voor deze architectuur te vinden en te bouwen.

_________________________

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.

Hergebruik: het gebruiken van een bestaand stuk software voor een nieuwe toepassing.

Het lijkt een eenvoudig principe, maar er komt meer bij kijken dan je zou denken. Vooral wanneer je effectief een software artefact probeert te hergebruiken, creëer je al snel problemen. In deze blog gaan we wat dieper in op dit ogenschijnlijk simpele productiviteitsprincipe.

In mijn blog over Microservices van eind 2017 had ik het reeds kort over “re-use” als een antipatroon: dit ging vooral over hergebruik van code versus hergebruik van grotere componenten, zoals b.v. een API met een daarachterliggende microservice. Dit is een belangrijk voorbeeld van een breder principe: men moet goed weten op welk niveau van modulariteit men hergebruik wenst toe te passen.

Verderop in deze blog gaan we dieper in op drie assen volgens welke we afwegingen zullen moeten maken om te besluiten in welke mate we hergebruik zullen nastreven en toepassen: Het niveau van granulariteit, het niveau van abstractie, en het niveau van functionaliteit.

Daarnaast is het ook zo dat hergebruik maar kan op 2 voorwaarden:

• Er bestaat een dienst, module, bibliotheek, … kortweg, een software artefact, dat herbruikbaar is.
• We gebruiken een methodologie van software ontwikkeling die ons toelaat zaken te hergebruiken. Dit wil zeggen dat we enerzijds in staat zijn om de herbruikbare component te vinden en dat we er toegang toe hebben (en dat deze voldoende is gedocumenteerd), en we anderzijds een architectuur toepassen in de doeltoepassing die toelaat het bestaande artefact ook daadwerkelijk in te zetten.

In deze blog zullen we ons focussen op principes rond het bouwen van herbruikbare artefacten, en dus niet op het tweede aspect: het beheren en gebruiken van een patrimonium van herbruikbare software componenten. Verder gaan we ook niet dieper in op zaken die gerelateerd zijn aan hergebruik, zoals bv. het gebruiken van een gedeelde infrastructuur of het vinden van allerlei synergieën op ándere vlakken.

Spanningsvelden bij het Beschouwen van Hergebruik

Zoals reeds aangehaald, zal mogelijk hergebruik van een software artefact afhangen van een aantal verschillende factoren. Telkens zal er een zeker spanningsveld heersen en zal er een middenweg moeten worden gevonden, die van project tot project of van artefact tot artefact kan verschillen.

Niveau van Granulariteit

De grootte van het software artefact dat we willen hergebruiken, heeft een grote invloed op de mogelijke impact van het hergebruik: het is uiteraard voordeliger als we ineens een volledige, kant-en-klare service kunnen hergebruiken, die duizenden lijnen code encapsuleert, dan wanneer we enkel en alleen, op het niveau van de code, een bepaalde functie van een paar regels code kunnen hergebruiken. Nochtans hebben ze elk hun eigen kracht. Alle artefacten die we gebruiken moeten worden onderhouden; doorgaans is de kost die hiermee gepaard gaat evenredig met de grootte. Daarnaast is het zo, dat men een kleiner bouwblok, indien goed gekozen, vaker zal kunnen hergebruiken dan een groter.
Het spreekt voor zich dat, hoe meer zaken men in één component verpakt, op hoe meer manieren deze component kan hergebruikt worden, maar tegelijk hoe omslachtiger het wordt om dit ook effectief te doen, omdat je teveel bagage meesleept. Beter is het om componenten zo klein mogelijk te houden, zodat ze één functionaliteit aanbieden, en deze kleine componenten dan op zoveel mogelijk plaatsen te gaan inzetten. Hier is echter weeral een spanningsveld: hoe meer componenten er bestaan, des te moeilijker wordt het om te weten dat ze bestaan (en om ze terug te vinden, dus). Kleine componenten bieden daarnaast echter nog vele andere voordelen (bv. microservices en agility, zoals beschreven in de blog daaromtrent).

Maar ook de context van het hergebruik speelt een rol bij overwegingen betreffende de grootte van de component: de functie van een paar regels code: zullen we deze enkel hergebruiken binnen eenzelfde project? Of als deel van een bibliotheek of raamwerk dat nog door vele andere projecten kan worden gebruikt? Hier zat de essentie van het verhaal bij microservices: men moet goed waken over de onfhankelijkheid van deze wonderen van de moderne architectuur: wanneer twee microservices gebruik maken van eenzelfde stuk code, heeft men in principe een afhankelijkheid gecreëerd tussen de beide.

Mate van Abstractie

De mate van abstractie van software kan sterk variëren. Men kan een stuk software bouwen, nauwelijks parametriseerbaar, specifiek voor één welbepaalde taak. Dit zal nauwelijks herbruikbaar zijn. Maar indien men te ver probeert te gaan in de mate van abstractie die een stuk software aanbiedt, krijgt men uiteindelijk iets dat onbruikbaar is voor het oorspronkelijk doeleinde, omdat het zo generisch is, dat er nog heel veel werk bij komt kijken om het als dusdanig te parametriseren aan het doel waarvoor het werd ontworpen. Bovendien is software met een hoge mate van abstractie vaak ook moeilijker te begrijpen voor ontwikkelaars. Hier komt het er dus op neer een gouden middenweg te vinden: voldoende abstractie, zodat er binnen het business domein, en zoniet op een technisch vlak, nog enige kans bestaat op later hergebruik, maar niet teveel, zodat het artefact nog voldoende snel en eenvoudig inzetbaar is voor het oorspronkelijke doel. Daar komt dan wel nog een tweede spanningsveld roet in het eten gooien: dat van kost versus mate van abstractie. Een stuk software op een meer generische manier ontwerpen, vraagt doorgaans meer resources en een langere ontwikkeltijd dan om iets te bouwen voor één welbepaald doel. Men kan dus niet tegelijkertijd van een team van ontwikkelaars verwachten om zoveel mogelijk kostenbesparend te werken en enorm veel functionaliteit op te leveren tegen strakke deadlines, en tegelijkertijd geweldig herbruikbare (en onderhoudbare, robuuste, stabiele, … ) producten af te leveren.

Hoogte in de functionele stack

Een afgewerkte software, gebouwd voor een specifiek doel, met een eigen UI, is ongeveer wat als het hoogste in de “functionele stack” beschouwd kan worden. Dit is nauwelijks herbruikbaar, want purpose-built (met een grote uitzondering voor SaaS-software). Lager in deze stack vindt men business-domein-specifieke bibliotheken en APIs. Deze zijn, binnen een bepaalde context, al een stuk herbruikbaarder (maar niet onmiddellijk functioneel inzetbaar zonder er iets vóór of rond te bouwen). Nog lager in de stack vindt men zaken die over domeinen heen herbruikbaar zijn: database software, cloud platformen, algemene software libraries en raamwerken. De laagste elementen in de stack, daar denken we zelfs al niet meer bij na wanneer we ze hergebruiken: het gaat om constructies die in bijna alle programmeertalen voorkomen (gegevensstructuren zoals arrays, ondersteuning voor reguliere expressies, etc.).

Bedrijven die een sprong maken naar een Cloud Platform, maken typisch ook een sprong in herbruikbaarheid wat betreft het niveau in de functionele stack. Het gebruik van zaken als virtualisatie zorgt er bv. voor dat het veel sneller gaat om infrastructuur te koppelen aan een applicatie en dat deze koppeling ook bruikbaar is voor gelijkaardige applicaties (door de configuratie van zo’n machine te hergebruiken). Hogerop in de stack laat een platform als Kubernetes en het gebruik van containers toe dat men software images van over de hele wereld, en bovendien ook de eigen images, kan hergebruiken.

Wat kan ons Helpen?

Kunnen we nu doorheen de anaylse van deze verschillende dimensies van hergebruik een rode draad trekken? Op welke manier zullen we het vaakst “de gulden middenweg” kunnen exploiteren? Hier speelt de gebruikte methodologie van software ontwikkeling een rol, en zeker ook de architectuur van zowel het mogelijks herbruikbare artefact en van de doeltoepassing. Moderne architecturale principes hebben hier vrijwel altijd een streepje voor, en de software industrie blijft hierin innoveren. Modulariteit is één van de sterkste drijvende krachten (ik verwijs opnieuw naar microservices, en nu misschien ook al naar FPaaS).

Over MicroServices en APIs

Ik heb nu reeds tweemaal modulariteit en microservices aangehaald, maar daar moet wel een serieuze kanttekening bij worden gemaakt.

Microservices zijn OP ZICH NIET herbruikbaar. Het zijn de APIs die men rond diensten bouwt, die herbruikbaar zijn door andere zaken.

Van cruciaal belang is dus het ontwerp van deze APIs, rigoureus volgens standaarden (REST) die nog eens zijn versterkt door een weldoordachte huisstijl (of beter nog, “sector-stijl”). Daarnaast moet men bij het ontwerpen van deze APIs goed rekening houden met de hierboven beschreven mate van abstractie en hoogte in de functionele stack. Bovendien moeten de APIs ook bekend zijn, en toegankelijk zijn. Het laatste vergt goed API management en sterke documentatie (en “kruisbestuifmensen” die kunnen fungeren als katalysatoren, overheen projecten), en ook een vlot proces van het ter beschikking stellen van APIs. Bij dit laatste spelen zaken zoals GDPR uiteraard een rol, maar spijtig genoeg ook af en toe politieke redenen (men wil soms te hard zijn “eigenaarschap” over bepaalde diensten of data behouden, en men belemmert om deze reden het hergebruik; of nog vindt men van zijn eigen systemen dat deze “te uniek” zouden zijn om in een hergebruik-kader te functioneren). Ten slotte is het ook van belang dat de systemen die schuilgaan achter de APIs, voldoende schaalbaar zijn, zodat ze bij toenemend gebruik nog kunnen volgen.

Wanneer we over APIs spreken, spreken we hier dus over het hergebruik van (werkende) diensten. Dit is de belangrijkste vorm wat betreft zelfgemaakte software artefacten. Het hergebruik van (eigen) code is iets totaal anders. Dit kan zelfs contraproductief zijn: één van de krachtigste eigenschappen van microservices binnen een moderne architectuur, is hun onderlinge onafhankelijkheid: een microservice moet volledig op eigen benen kunnen staan (eigen werking, eigen logica, eigen data(-base), eigen (deeltje van de) infrastructuur, … De enige connectie met de buitenwereld is via Events (zie verder) en een API ! ). Daarnaast maakt men ze zo klein mogelijk. Dit maakt ze enorm flexibel (“agile”): men kan ze apart van andere zaken onderhouden, aanpassen, vervangen (vandaar ook dat ze klein moeten zijn, “rip-and-replace” mag niet teveel kosten). Deze flexibiliteit maakt het mogelijk voor een softwarebedrijf om enorm snel op veranderende behoeften van de business in te spelen, doordat het geheel aan microservices continu en heel snel kan evolueren zonder volledig offline te gaan of langdurige aanpassingsprojecten en redeployments te moeten ondergaan. Welnu, vermits microserives zo onafhankelijk mogelijk van elkaar moeten zijn, kan het soms contraproductief zijn om zaken (niet alleen code maar bv. ook een bepaalde database) te gaan hergebruiken tussen meerdere microservices. Dergelijk hergebruik creëert afhankelijkheden en verplichtingen die de wendbaarheid van een microservice doen afnemen! Enkel zeer algemeen inzetbare bibliotheken (typisch 3rd party, vaak open source) vormen goede kandidaten om binnen een microservice herbruikt te worden; deze zitten typisch iets lager op de functionale stack dan het (business) domein waar de microservice rond is opgebouwd.

Event Driven Architecture

In deze context komen we best ook terug op Event Driven Architecture. Events zijn één van de datastructuren die men het dichtst bij de werkelijkheid kan doen aanleunen. Het gaat om een opdracht of aangifte of aanvraag die binnenkomt, een gebeurtenis uit de echte wereld die men modeleert, een bepaald gegeven dat beschikbaar wordt, een verandering van een reeds gekend gegeven, …
Deze zaken kunnen allemaal veel letterlijker gemapt worden op de werkelijkheid, dan wanneer ze eerst reeds binnen een bepaalde context (meestal de toepassing via dewelke ze het eerst worden ingevoerd) worden verwerkt. Hoe dichter deze informatie aanleunt bij de werkelijke wereld, hoe herbruikbaarder ze is voor andere zaken. Hetzij andere toepassingen die reeds bestaan en anders moeten wachten tot de data (soms in batch) wordt doorgestuurd of kan worden opgehaald via API, hetzij toepassingen die men pas zal bedenken doordat de events al bestaan (het zogenaamde kruisbestuiven binnen een applicatie ecosysteem).

Zaak is dus van events heel goed te ontwerpen, vooral op het niveau van business events, en van deze meer en meer te gaan (her-)gebruiken. Naast mogelijk hergebruik heeft dit ook een mooie standaardisatie tot gevolg in de manier waarop applicaties (asynchroon) communiceren en data geprolifereerd wordt binnen een netwerk van toepassingen, en bovendien krijgt men de data op die manier veel sneller op alle plaatsen waar men ze nodig heeft, waardoor men op business niveau veel sneller kan reageren en flexibeler kan zijn. Goede documentatie van de events die men reeds heeft gedefiniëerd is dan uiteraard heel belangrijk. Ten slotte heeft men via events automatisch de volledige geschiedenis van de gegevens en niet alleen van de huidige toestand. Deze geschiedenis kan eveneens hergebruikt worden bij o.a. het aanpassen en testen van toepassingen, het ontwikkelen van nieuwe zaken, en verregaande analyse (evt. ook voor het trainen van een AI)

Besluit

Wanneer men praat over herbruikbaarheid, is het belangrijk te verduidelijken of men het nu over code, dan wel APIs, diensten, componenten, infrastructuur of volledige software-pakketten gaat hebben. Samenvattend komt dit neer op het definiëren van de modulariteit, de mate van abstractie en de hoogte in de functionele stack van hetgeen men zou willen hergebruiken. Daarenboven moet men de afweging maken tussen de herbruikbaarheid van een artefact en de kostprijs om het te bouwen en onderhouden.

Indien men met al deze aspecten rekening houdt, kan men besluiten dat hergebruik niet altijd alleszaligmakend is en dat het soms zelfs contraproductief kan zijn. Het belangrijkste hergebruik zal zich vaak ook niet op het niveau van de code bevinden.

Wat applicatie architectuur in het algemeen betreft, maar dan nu specifiek toegepast op herbruikbaarheid, kunnen we daarnaast besluiten dat APIs (ondersteund door microservices, uitgerold op containers) en Event Driven Architecture een grote meerwaarde kunnen bieden.

Verdere resources:

• Een boek over het hergebruik van software: https://vijaynarayanan.gitbooks.io/art-of-software-reuse/content/
• Over de val van genericiteit en ‘super’-libraries, en de voordelen van modulariteit: http://josdejong.com/blog/2015/01/06/code-reuse/
• Over de valstrikken van “code reuse” en hoe management dit echter meestal ziet: https://blog.ndepend.com/code-reuse-not-good-goal/
• Over de kost van hergebruik: https://dzone.com/articles/economics-reuse
• Bedenkingen bij extreme programming, een methodologie dewelke “design for reuse” eigenlijk afraadt: https://www.infoq.com/news/2009/04/agile-code-reuse
• Talk van Rob Pike, met de quote “A little copying is better than a little dependency” (code reuse zorgt voor dependencies!): https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s
• Martin Fowler over, o.a. , reuse: https://martinfowler.com/bliki/Seedwork.html
• Methodologische tips voor hergebruik: https://www.infoq.com/articles/vijay-narayanan-software-reuse
• Hoe reuse aanpakken op bedrijfsniveau: http://www.cs.cmu.edu/afs/cs/usr/ppinto/www/reuse.html

Deze blog is het tweede deel van een reeks, waarin we een aantal mogelijkheden die ons worden geboden door goede architecturale principes en technologieën, zullen toelichten. Een aantal van deze zaken werden ook reeds in vroegere blogs besproken, en de meeste worden ook nog eens samengevat in de blog “Vortex van Enablers“. De eerste blog van deze reeks beschouwde de gedeeltes van een applicatie-architectuur die de gebruikersinterface en externe clients ondersteunen: Architecturale Evoluties, deel 1.

In dit deel duiken we dieper in de applicatie, en zullen we beschouwen hoe we de interacties met onze applicatie verder kunnen afhandelen. Interacties kunnen via allerlei wegen onze applicatie binnenkomen (b.v. aanvragen vanuit een GUI, requests via een extern-gerichte API, maar ook interne, geplande acties die op bepaalde momenten worden gestart). Voor de binnenste onderdelen van de architectuur is dit onderscheid echter van minder belang. Wel belangrijk is of het gaat om een vraag om output te genereren (dit zullen we een query noemen), of dat het eerder gaat om nieuwe input (vaak een command genoemd, maar dit komt eigenlijk overeen met een Event). Soms zijn deze beide vormen gecombineerd (er is nieuwe input, die op zich al tot nieuwe output moet leiden), maar vaak is het mogelijk om deze aspecten in de verwerking van de interactie voldoende gescheiden te houden.

De Moderne Architectuur, Deel 2

In het eerste deel van deze blogreeks beschreven we reeds hoe alle externe interactie met onze applicatie kon worden herleid tot het oproepen van Restful APIs, die we konden aanbieden via één of meerdere microservices. In dit tweede deel kunnen we ons daardoor volledig focussen op de interne werking van een collectie microservices, die samen een applicatie (of een groep van applicaties) ondersteunen. Dit is een radicale breuk met de meer traditionele 3-tier of n-tier architecturen van weleer. Gartner heeft deze nieuwe trend de naam “MASA” gegeven, wat staat voor Mesh App and Service Architecture: een zeer modulair and flexibel aanpasbaar netwerk van oplossingen die de dynamisch veranderde behoeften vanuit de business snel kunnen opvangen.

Eén opmerking die we voor de volledigheid nog moeten maken, is dat het in deel 1 om interactie met écht externe zaken ging, zoals de clients en 3rd party applicaties. Dit leidt er doorgaans toe dat we sterk gestandaardiseerde interactievormen via het web zullen gebruiken (waardoor vrijwel enkel REST APIs kunnen worden beschouwd). Integratie binnen het eigen ecosysteem kan echter, naast APIs, ook nog via de Event Bus gebeuren, die op zich gebouwd is bovenop het principe van asynchrone uitwisseling van berichten tussen de services. Dit duale principe (synchroon REST kanaal en asynchroon event kanaal, ook reeds toegelicht in de blog over Data Centric IT) moet volstaan om alle communicatie tussen de verschillende onderdelen van een applicatie (of ecosysteem) in goede banen te leiden. Op zijn beurt laat deze ogenschijnlijke beperking toe om de technische kant van het verhaal te standaardiseren.

• Een woordje over de MASA

Zoals reeds gezegd, staat MASA voor “Mesh App & Service Architecture”. Het woordje “mesh” (= een fijnmazig net) betekent dat de huidige architectuur uit vele aparte onderdelen zal bestaan, die via steeds veranderende configuraties met elkaar communiceren. Het model dat we in deze blogreeks uit de doeken doen, namelijk een ecosysteem van samenwerkende microservices, communicerend via Event Bus en RESTful APIs, is daarbij eigenlijk nog een eenvoudige versie. In de praktijk zal men evolueren naar ingewikkelder patronen, waarbij in deze mesh ook legacy toepassingen zullen verweven zitten, alsook zaken die in de Cloud draaien i.p.v. op het lokale netwerk, afzonderlijke functies die volgens het zogenaamde “Serverless” principe werken, en zelfs IoT devices. Dit soort gemengde architectuur ontstaat doordat vele organisaties nu eenmaal legacy toepassingen draaiende moeten houden, en doordat er een grote heterogeniteit aan projecten te volbrengen is, hetgeen er voor zorgt dat er vaak ook verschillende keuzes gemaakt worden wat betreft de onderliggende platformen. In zo’n geval is het echter ook belangrijk (of zelfs nog belangrijker) dat men tracht de communicatiepatronen tussen al deze verschillende zaken te standaardiseren, om aldus de compatibiliteit en integreerbaarheid te maximaliseren.

• De Duale Service Interface: CQRS

In de introductie vermeldden we reeds het onderscheid tussen commando’s en queries. CQRS staat voor Command Query Responsability Segregation, wat zoveel betekent als “scheiding van de verantwoordelijkheid voor het afhandelen van commando’s en queries”. In de praktijk wil dat zeggen dat we zullen proberen om een logische scheiding te krijgen tussen de systemen die commando’s verwerken en tussen degene die vragen beatwoorden. Dit is schematisch weergegeven in onderstaande Fig. 2.

Queries kunnen doorgaans rechtstreeks door een API worden beantwoord, al dan niet door de vraag, mogelijks in stukjes gekapt, aan een verdere API door te geven. Uiteindelijk zullen het de onderliggende (micro-)services zijn die het echte werk doen van opzoeken in databases en eventueel nog een paar bewerkingen uitvoeren om het antwoord in de gevraagde vorm te krijgen. Wat betreft de interactie tussen verschillende services, hoeft hier dus niet te worden afgeweken van RESTful synchrone communicatie.

Het ligt iets anders voor commando’s. Wanneer we volledig het paradigma van Event Sourcing toepassen, zullen we een commando steeds omzetten in een gebeurtenis (b.v. het commando “bestel één blockchain boek” wordt dan het event “bestelling van één blockchain boek geplaatst“). Deze omzetting zal door een eerste laag van services worden gedaan, speciaal gebouwd voor het opvangen van dergelijke commando’s vanuit de client side.

Het commando kan dan verder worden afgehandeld als een typisch event: het komt op de Event Bus terecht en alle geïnteresseerde diensten zullen het asynchroon ontvangen en kunnen behandelen (één backend service zal b.v. de inventory aanpassen; een andere zet het verpakken op gang en nog een andere verwittigt de koerierdienst). In elk geval is het creëren van afgeleide informatie (b.v. de hoeveelheid in stock) een verantwoordelijkheid van een microservice die daarvoor zijn eigen database zal hebben.

Wanneer nu later een vraag toekomt die betrekking heeft op informatie beïnvloed door een eerder commando, dan zal deze geforward worden naar de microservices die deze up-to-date informatie controleren (b.v. de vraag “hoeveel van die blockchain boeken zijn er nog in voorraad” komt uiteindeljik terecht bij de service voor de inventory). Vermits events asynchroon werken kan het soms zijn dat een vraag nét te snel komt en de informatie dus niet volledig up-to-date is (meestal is het echter een kwestie van enkele seconden). Vandaar dat het bij dit soort architecturen aangewezen is de principes van “eventual consistency” goed toe te passen, en zelfs door te trekken tot op business niveau.

Bovenstaande Figuur 3 toont een iets gedetailleerder voorbeeld. In de figuur zien we dat er achter de App API, 2 Command APIs en 1 Query API schuilgaan. Daarnaast zien we een door meerdere zaken gebruikte Event Bus, waarvan alle events ook in een centrale event store terecht komen. Sommige backend microservices communiceren rechtsreeks met de bus en spelen dus kort op de bal; daarnaast is er een service die vooral gebruik maakt van de event store en die dus meer zaken kan doen met historische events (b.v. analytics). Verder zien we dat er een legacy systeem communiceert via het event kanaal en dat een aantal services APIs aanbieden, sommige zelfs rechstreeks aan externe systemen. Er is een kort scenario uitgewerkt in de tekening:

1. Een update wordt gevraagd, wat zich vertaalt in een reeks van events die door een aantal services verwerkt worden. Het event komt uiteraard in de event store terecht.
2. Een andere update zorgt er uiteindelijk voor dat er events ontstaan die aanpassingen doen gebeuren aan een database van afgeleide informatie, behorende tot een bepaalde microservice.
3. Een query vraagt informatie op via API, en uiteindelijk wordt een API van de microservice van stap 2 aangeroepen; deze zal dus van de geüpdate informatie uit de database van stap 2 gebruik maken.
4. Een andere query doet een iets diepgaandere vraag. Via verschillende calls tussen deelnemende services, wordt er uiteindelijk informatie opgevraagd uit de event store.

Dit verhaal is, vanwege het gebruik van Events, voor een deel asynchroon. Sommige cliënts zullen echter zo synchroon mogelijk moeten worden geüpdated. Hoe kunnen zij vlot op de hoogte worden gebracht van de meest recente informatie? Ter herinnering: in een volledig synchrone wereld zal een cliënt als antwoord op een commando ook onmiddellijk de nieuwe toestand meekrijgen. Met de nieuwe architectuur moet de cliënt echter “gissen” na hoeveel tijd hij een query naar de server moet sturen, om er zeker van te zijn dat het effect van zijn laatste commando in rekening is gebracht. Dit giswerk kan men echter vermijden. Sowieso is het niet zo efficiënt om ervan uit te gaan dat het altijd de cliënt is die alle communicatie moet initiëren. We zullen er dus voor zorgen dat ook de server dit initiatief kan nemen. Als gevolg van een binnenkomend Event moet ook de server in staat zijn om op dat moment een bericht te sturen naar de client. Er zijn ondertussen verschillende manieren waarop een cliënt aan een server zijn interesse kan laten blijken in het krijgen van callbacks wanneer up-to-date informatie beschikbaar is, en er zijn zelfs al full-duplex communicatiemogelijkheden voor applicaties op het web. (WebSocket is een vrij modern voorbeeld).

Indien het niet mogelijk is de client op een manier te bouwen dat deze door de server kan worden gecontacteerd, en het is evenwel belangrijk dat de client zo snel mogelijk up-to-date informatie krijgt, dan is er nog een noodoplossing mogelijk. We kunnen alsnog een API voorzien die toelaat dat men via één enkele request zowel een update doet als de nieuwe informatie meekrijgt in het antwoord. Desalniettemin zullen we het CQRS patroon voor het grootste gedeelte respecteren in de backend. Het volstaat om de API zo te bouwen, dat hij de request zelf opdeelt in een commando en één of meerdere queries. De microservice die achter deze API schuilgaat, zal dan eerst het event lanceren om het commando uit te laten voeren, en zal vervolgens wachten tot er genotificeerd komt via de juiste events, die de afhandeling van dit commando aangeven. Daarna kan de service overgaan tot het lanceren van de queries en dan vervolgens zelf antwoorden op de vraag van de client. Dit patroon zorgt er wel voor dat soms de client wat langer (synchroon) zal moeten wachten op zijn antwoord, omdat het asynchrone gedeelte volledig aan de serverkant moet worden afgehandeld.

Conclusie

We zien hoe een moderne architectuur ervoor zorgt dat men een applicatie (of groep applicaties) kan opdelen in zo klein mogelijke microservices, elk met hun eigen verantwoordelijkheid. Deze zijn efficient te onderhouden en ook vervangbaar, wat het gehele systeem een ongeziene flexibiliteit geeft om zich aan te kunnen passen aan zowel veranderende functionaliteit als aan veranderingen aan de infrastructuur of de benodigde capaciteit. Daarnaast hebben we een gestandaardiseerde manier van communiceren toegelicht, die ervoor zorgt dat de mesh van apps, de “MASA”, continu kan veranderen en groeien, doordat men alle onderdelen gemakkelijk via het netwerk met elkaar kan laten communiceren. Ten slotte konden we ook zien hoe CQRS hiervan gebruik maakt om een nette afhandeling van alle mogelijke vragen te voorzien, gebruik makende van Events, die ook de historiek en traceerbaarheid van het systeem garanderen, van client tot backend.

]]>