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.

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

De Paradox van de Afhankelijkheid

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

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

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

De “Mesh” Architectuur

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

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

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

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

Een aantal helpende Principes

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

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

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

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

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

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

Besluit: even Wennen

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

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

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

REST: de gouden standaard

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

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

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

De pure API aanpak

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

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

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

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

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

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

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

Richting asynchrone communicatie

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

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

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

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

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

Standaarden voor Asynchrone APIs

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

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

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

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

De gebalanceerde aanpak: APIs plus Events

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

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

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

Een aantal extra opmerkingen betreffende deze manier van aanpakken:

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

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

Conclusie

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

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

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

Eventual Consistency is dé truc waarmee vele NOSql databases hun beschikbaarheid gevoelig kunnen verbeteren. Maar kunnen we dit principe ook doortrekken naar de rest van de architectuur, en misschien zelfs laten meespelen op business niveau? Of is het sop de kool niet waard, en moeten we kiezen voor de eenvoudig bruikbare garanties die Strong Consistency ons biedt?

In dit blogartikel gaan we het concept Eventual Consistency (EC) verder uitdiepen. Wat betekent het precies? Wat zijn goede voorbeelden? En – uiteraard – wat hebben we er precies aan? Wanneer wordt dit principe nuttig?

Wat is Eventual Consistency?

Het principe / model van Eventual Consistency bestaat reeds lang, maar werd vooral bekend door het gebruik ervan in NOSql databases. Deze databases waren een broodnodige revolutie toen populaire webtoepassingen een zodanig grote schaal kregen dat traditionele databases ontoereikend bleken.

Het grote voordeel van deze databases is namelijk dat ze enorm schaalbaar zijn en, zelfs bij het voorkomen van netwerkfalen, blijven werken. Het is precies het EC model dat hiervoor zorgt. Maar wat doet dit principe nu juist?

Het Eventual Consistency model is van toepassing op gedistribueerde systemen; m.a.w. systemen met meerdere nodes, verbonden door een netwerk. Een systeem dat als consistentiemodel EC heeft, zal ervoor zorgen dat een update aan een gegeven na verloop van tijd op alle nodes zal geraken. Tot die tijd kan het zijn dat we op bepaalde nodes nog de vorige waarde van het gegeven uitlezen.

Dit is natuurlijk een erg zwakke garantie, maar ze laat toe dat de nodes afzonderlijk kunnen blijven werken, zelfs indien het netwerk ertussen faalt, of indien een aantal nodes een tijdlang uitgeschakeld worden. Wanneer alles terug in orde geraakt, zal het systeem ervoor zorgen dat alles overal terug up-to-date is.

Eventual Consistency wordt ook wel Optimistische Replicatie genoemd. Wanneer een EC systeem de nodige updates heeft verwerkt en terug consistent is, zeggen we dat het systeem is geconvergeerd. De tijd die verstrijkt tussen een update en het convergeren, noemen we de inconsistency window. Deze willen we natuurlijk liefst zo kort mogelijk houden. In de huidige state of the art zal dit in de meeste gevallen, indien er geen falende nodes of netwerkpartities zijn, slechts milliseconden tot seconden duren.

Natuurlijk maakt het Eventual Consistency model het ook wel moeilijker om te redeneren en om te gaan met de data. Zo zijn er een aantal problemen waar developers een antwoord op zullen moeten hebben, indien ze EC willen gebruiken. Wat doe je bijvoorbeeld met clients die een node consulteren die nog niet de laatste nieuwe gegevens heeft? En – erger nog – wat als twee nodes een update binnenkrijgen voor hetzelfde gegeven, vóór ze elkaar op de hoogte hebben gebracht?

De meeste developers zijn gewend aan de luxe van “Strong Consistency” bij de systemen waarop ze verder bouwen. Deze tegenhanger van EC garandeert dat indien er een update is gebeurd, élke leesopdracht die daarna nog volgt deze update zal zien. Daarenboven is het in zo’n systeem niet mogelijk om conflicterende updates te doen aan éénzelfde gegeven.

Je kan natuurlijk al aanvoelen dat Strong Consistency zijn eigen problemen heeft: wanneer de schaal groter en groter wordt, kan het steeds vaker voorkomen dat clients moeten wachten, omdat het systeem bezig is ervoor te zorgen dat alle nodes consistent zijn. Het systeem wordt daardoor dus minder beschikbaar. Of nog: onvoldoende nodes kunnen met elkaar communiceren om consistentie te garanderen, en het volledige systeem wordt onbeschikbaar. Dit is natuurlijk precies de te maken keuze die wordt geïllustreerd door het CAP / PACELC theorema, waarover we reeds eerder hebben geblogd. Een gedistribueerd systeem moet altijd Partitietolerant zijn (P), dus daarna blijft nog de keuze over om te focussen op Consistentie (C) of Availability (A), maar alle drie samen gaat niet (zelfs de laatste evolutie in databases, de NewSql databases, maken hierin de keuze voor consistentie, al voorzien ze heel wat verbeteringen om toch nog zo beschikbaar mogelijk te zijn).

Voorbeelden

Buiten het typische voorbeeld van NOSql Databases die EC storage kunnen leveren aan applicaties, kunnen we ook een aantal voorbeelden geven waarbij de EC op een hoger niveau van abstractie zijn werk doet binnen een applicatie, en zelfs op business niveau zijn impact heeft.

1. Domain Name System (DNS)

DNS, een zeer bekend systeem in de informatica, koppelt internet domeinnamen aan IP-adressen. Het is een hiërarchisch systeem, doch grotendeels gedecentraliseerd. Noodzakelijkerwijs moet de data sterk verspreid en gerepliceerd worden, want het volledige internet maakt gebruik van dit systeem, en geen enkele individuele machine of zelfs cluster zou deze schaal aankunnen.

Wanneer er een update gebeurt binnen dit systeem, zal dit eerst op één server gebeuren. Deze server (de “authoritatieve server” voor een bepaald domein) heeft dan het correcte IP-adres dat bij een domeinnaam hoort, maar andere servers nog niet. Na verloop van tijd zal de informatie zich echter verspreiden doorheen het hele DNS systeem. Uiteindelijk zullen alle servers die de desbetreffende domeinnaam stockeren, hun cache laten verlopen, en de meest recente versie opvragen, en op deze manier is DNS dus eventually consistent.

Zonder verdere maatregelen, zullen clients die toevallig naar een bepaalde site willen surfen, terwijl de cache van hun DNS server nog naar oude data verwijst, niet naar het nieuwe IP adres kunnen gaan. Met een goed beheer van je DNS data kan je dit echter voorkomen (b.v. op het oude IP adres nog een tijdlang een redirect server plaatsen).

2. Webwinkel

Voor een webwinkel kan elke minuut dat mensen geen bestellingen kunnen doen, een groot verlies betekenen. Beschikbaarheid (van het winkelgedeelte op zijn minst) is dus cruciaal.

Om hiervoor te zorgen, kan er worden gebruik gemaakt van Eventual Consistency in verschillende gradaties. Men zou bijvoorbeeld kunnen stellen dat men veranderingen in het inventorysysteem (b.v. hoeveel van dit artikel is nog in stock?) slechts met enige vertraging laat doorsijpelen tot het frontend systeem, dat de clients bedient, die bezig zijn met winkelen. Je zou dus iets in je winkelkarretje kunnen leggen dat niet meer in stock is. Op het moment echter van de eigenlijke bestelling, zou men wel via een transactie kunnen werken, waarbij men effectief de huidige inventaris gaat nakijken alvorens de bestelling te laten doorgaan. Indien het artikel er niet meer is, krijgt de klant op dat moment een foutboodschap met verontschuldigingen en b.v. de optie om bericht te krijgen wanneer de stock is bijgevuld.

Op deze manier voorziet men reeds een loskoppeling tussen het winkelsysteem zelf, en de inventory backend, waardoor de eerste beschikbaar blijft, zelfs wanneer de laatste niet goed werkt.

Men kan hier de Eventual Consistency zelfs nog verder doortrekken: we laten de bestelling doorgaan zonder de inventory op te nemen in de transactie, en we brengen deze pas later (eventually) up-to-date. Zo kan een klant een item zelfs bestellen indien het niet meer in stock is. Uiteraard zal er echter wel iets moeten gebeuren in zo een geval. We kunnen dan op zoek gaan naar mitigerende processen op business niveau. Er kan bijvoorbeeld een email gestuurd worden met verontschuldigingen: “spijtig genoeg moeten we dit artikel nabestellen en zal het dus iets later zijn; u krijgt de verzendingskosten terug of mag de bestelling alsnog annuleren”. Of nog: “We kunnen dit helaas nu niet leveren; we annuleerden uw bestelling en u krijgt een waardebon”. Hier zijn tal van mogelijkheden, de ene al klantvriendelijker dan de andere, waaruit de business kan kiezen als strategie.

3. Het bancair systeem

Het lijkt misschien contra-intuïtief, maar een aantal aspecten van het bancair systeem, bijvoorbeeld bij het “settlen” van rekeningen, zijn via EC geregeld, en dit was noodzakelijkerwijs zelfs al zo voordat er sprake was van computers!

Wanneer in de IT een voorbeeld van de bankwereld wordt gebruikt, zal men typisch de atomaire transactie uitleggen die moet gebeuren bij een overschrijving: indien één rekening gedebiteerd wordt, moét de andere gecrediteerd worden, of vice versa. Dit is natuurlijk een voorbeeld van Strong Consistency.

Maar er zijn tal van manieren waarop de stand van een rekening niet overeenkomt met wat de waarde ervan zou moeten zijn, rekening houdend met alle transacties die al hebben plaatsgevonden of nog moeten plaatsvinden. Zo kan ik b.v. allerlei online zaken bestellen op zondag, terwijl ik zaterdag al ben gaan winkelen. De bancontact transactie van de winkel is nog niet doorgekomen, en het saldo op mijn rekening is dus een pak hoger, waardoor ik meer geld kan uitgeven dan ik heb. Op maandag wordt alles dan vereffend en komt mijn rekening onder nul. Gelukkig werd op vrijdag mijn loon gestort en komt dit óók maandag tot uiting op mijn rekening. Net op tijd om de cheque aan te kunnen die geïnd zal worden op dinsdag, maar die ik reeds een week geleden aan iemand heb gegeven voor een grote aankoop, met de vraag of die even wou wachten met het innen.

Er kunnen dus allerlei zaken gebeuren die het saldo van een rekening beïnvloeden en die soms zelfs het saldo van de rekening nakijken, zonder dat het saldo al met al deze zaken rekening houdt. De rekeningstand is dus “eventually consistent”: uiteindelijk komen alle transacties erop terecht, maar dit kan even duren.

De bankwereld heeft geen probleem met het bestaan van dit soort inconsistenties in hun systeem, die zelfs op business niveau zichtbaar zijn. Misbruik ervan wordt dan ook vrijwel geheel vermeden door allerlei provisies (eveneens op business niveau): b.v. wetten die fraude strafbaar maken.

4. Onze sector?

We kunnen niet direct voorbeelden geven van zaken die binnen onze sector via eventual consistency zijn geïmplementeerd, maar we kunnen wel eens verkennen waar er eventueel mogelijkheden bestaan om dit in de toekomst te gaan doen.

Als we de typische workflows binnen de overheid in beschouwing nemen, zien we dat er geregeld processen zijn waarbij iets wordt aangevraagd, of een dossier wordt ingediend, dat dan later wordt nagekeken en wordt verwerkt met menselijke tussenkomst. Dit is een heel goede indicator dat we misschien wel EC kunnen gebruiken, gezien er reeds een natuurlijke vorm van uitstel in het proces zit. Hetzelfde zien we bij die processen waarin gegevens verplicht moeten worden ingediend, maar niet noodzakelijkerwijs onmiddellijk worden behandeld door de desbetreffende overheidsdienst.

Kijken we anderzijds naar de gezondheidssector (eHealth). Hier is het uiteraard cruciaal dat de toegang tot patiëntendossiers een zo hoog mogelijke beschikbaarheid biedt. Maar is het absoluut noodzakelijk dat de informatie tot op de seconde up-to-date is? Persoonlijk zou ik denken van niet. Indien mijn huisarts mijn dossier een half uurtje geleden heeft geüpdated, is het allicht niet erg dat ze dit in het ziekenhuis nog niet kunnen zien. De volgende dag, als ik naar het ziekenhuis ga, wil ik dit uiteraard wel, maar tegen dan heeft men tijd genoeg gehad om alle nodes van het systeem voldoende met elkaar te laten communiceren.

En wat met apothekers die de verzekerbaarheid van iemand moeten nagaan? Het is cruciaal dat deze informatie beschikbaar is wanneer iemand een medicijn komt kopen. Maar de kans dat dit gegeven is veranderd gedurende het voorbije half uur is enorm klein; ook hier kan men dus overweg met gegevens die niet tot op de seconde up-to-date zijn. Voeg daarbij eventueel een mitigerende regel op business niveau toe, voor de minieme hoeveelheid uitzonderingen waarbij men toch een medicijn zonder korting zou verschaffen terwijl de klant hier wel recht op had (b.v. een terugbetaling achteraf, wanneer dit wordt vastgesteld dankzij de zich convergerende gegevens).

Evaluatie en Besluit

De voorbeelden maakten het reeds duidelijk: Eventual Consistency kan ervoor zorgen dat een systeem gewoon blijft doorwerken, zelfs wanneer er zaken mislopen. Op die manier kan de resiliëntie gevoelig worden verhoogd. Er moet in zo’n geval echter wel met een aantal inconsistenties in de data worden rekening gehouden, op IT vlak óf op business vlak, en dit maakt het complexer om over deze systemen te redeneren en om deze te bouwen. En uiteraard heeft een complex systeem ook een verhoogde kans op falen, net door de verhoogde kans op fouten die deze complexiteit met zich meebrengt.

We zullen dan ook een afweging moeten maken, samen met de business, om te zien waar de prioriteiten liggen. Hoe belangrijk is het dat dit systeem een beschikbaarheid heeft van vele negens (99,9% beschikbaarheid, “triple nine availability”, is b.v. nog haalbaar zonder EC voor een niet al te groot systeem)? Hoeveel data zal het systeem op termijn gaan bevatten / behandelen? In welke mate zal het moeten schalen voor gebruik door vele gelijktijdige clients?

We kunnen stellen dat Eventual Consistency enorm vruchten begint af te werpen, wanneer men met systemen te maken krijgt van een redelijk grote schaal. Voor dit soort systemen wordt het sowieso complex om ze draaiende te houden en zal de bijkomende complexiteit die EC met zich meebrengt, relatief een minder groot verschil maken. Het voordeel van de verhoogde resiliëntie zal in dat geval meer doorwegen. Sommige experts stellen zelfs dat sterke consistentie een sprookje wordt vanaf een bepaalde (erg grote) schaal, en dat men dus op een bepaald moment altijd naar eventual consistency zal moeten grijpen bij een sterk groeiend systeem.

Indien men echter met een klein systeem zit, b.v. bedoeld voor intern gebruik en met beperkte volumes aan data, dan zal het sop de kool meestal niet waard zijn en kan men, voor het gemak, best gebruik maken van Strong Consistency, wat het veel eenvoudiger maakt voor de ontwikkelaars van het systeem om het te bouwen en onderhouden.

Ten slotte kan men best bij elk project van enige omvang eens kritisch kijken naar de business processen die worden gedigitaliseerd. Vergen alle te implementeren functionaliteiten daadwerkelijk sterke consistentie doorheen het volledige proces? Moet alle data binnen de paar seconden gegarandeerd overal up-to-date zijn? Of zijn er misschien van nature stappen aanwezig waar menselijke tussenkomst is vereist, en men dus sowieso met wachttijden zit? Bestaan er eventueel op business niveau reeds mitigerende processen om om te gaan met een inconcistentie?

Vaak zal men dan zien dat sterke consistentie toch niet nodig is, en zeker niet overheen het volledige systeem, en ontstaan er dus mogelijkheden om de resiliëntie te verbeteren via Eventual Consistency.