Disclaimers…

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

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

Het voorbeeld: De arbeidsmotor voor de Sociale Zekerheid

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

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

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

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

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

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

Een Business event-verhaal doorheen dit ecosysteem

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

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

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

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

Besluit

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

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

De Paradox van de Afhankelijkheid

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

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

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

De “Mesh” Architectuur

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

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

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

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

Een aantal helpende Principes

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

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

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

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

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

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

Besluit: even Wennen

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

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

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

REST: de gouden standaard

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

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

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

De pure API aanpak

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

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

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

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

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

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

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

Richting asynchrone communicatie

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

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

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

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

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

Standaarden voor Asynchrone APIs

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

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

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

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

De gebalanceerde aanpak: APIs plus Events

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

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

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

Een aantal extra opmerkingen betreffende deze manier van aanpakken:

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

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

Conclusie

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

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

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

At Smals, our goal is to support a plethora of government agencies and to render administration more efficient. APIs play a central role in the exchange of data and the automation of business workflows, both within and between our different clients, and even with private sector stakeholders. The goal is typically not to monetise our work, but to minimise public expenditure. For many years now, software reuse has been a central tenet to this end, and APIs its basic building blocks. In practice, however, reuse would be impossible without a disciplined API management. In this videotalk, we will demonstrate our journey towards the increased adoption and maturity of API governance among government stakeholders using a standards based, inclusive, and bottom-up approach, and give a brief overview of our current challenges.

Recording

Presentation

Web API-ontwikkelingstool in Python. FastAPI is een interessant raamwerk voor het naar productie brengen van toepassingen ontwikkeld in Python. De tool werkt goed, is gemakkelijk te gebruiken en goed gedocumenteerd.

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.

]]> https://www.smalsresearch.be/architecturale-evoluties-deel-1/ Wed, 21 Mar 2018 13:35:54 +0000 /?p=11434 Vroeger was het simpel: je had front end, back end, en database. En toch is dit verre van optimaal. Hoe ziet een architectuur eruit die gebruik maakt van moderne principes en technologieën?

Er zijn heel wat mogelijkheden te overwegen wanneer men de architectuur van een applicatie bepaalt. Dit is nog eens extra het geval wanneer het een applicatie betreft die niet alleen staat, maar op allerlei manieren zal moeten integreren met andere applicaties en diensten, zowel binnen als buiten de eigen organisatie. In een tweedelige blogreeks bespreken we een aantal mogelijkheden die ons worden geboden door een aantal architecturale principes en technologieën, die ik reeds eerder samenvatte als de “Vortex van Enablers“.

In dit eerste deel bespreken we de bovenste regionen van de moderne applicatie architectuur. Alles wat met de interactie met de buitenwereld te maken heeft, zoals clients en 3rd party systemen (die vaak gewoon ook als clients kunnen worden beschouwd). In de volgende blog zal het dan gaan over de meer interne systemen. We beginnen hier met een terugblik op de traditionele 3-tier architectuur.

De 3-tier Architectuur

De 3-tier architectuur kennen we ondertussen stilaan. De verschillende “tiers” die er kunnen bestaan, en de geschiedenis ervan, werden reeds uitvoerig beschreven in de blog Van N-tier naar Microservices.

Deze stilaan verouderde architectuur kent een aantal problemen, niet in het minst qua herbruikbaarheid en integratiemogelijkheden. Zo komt men vaak in de problemen wanneer men nieuwe manieren van interactie wil toevoegen, zoals een mobiele app, of, waarom niet, een conversational interface. Een ander euvel is integratie: wanneer de data nodig is voor andere toepassingen, blijkt de op zichzelf ontworpen 3-tier applicatie vaak te incompatibel, en is men gedwongen de integratie via de data te doen. Dit door ofwel de database te koppelen aan meerdere applicaties via opengestelde fluxen, of d.m.v. het creëren van een duplicaat van de data, dat men dan om de zoveel tijd zal moeten updaten via één of ander ETL mechanisme. Een groot probleem is daarbij ook vaak dat de data semantisch sterk is gekoppeld aan de specifieke applicatiecontext.

Verderop in deze blogreeks gaan we bekijken hoe het beter kan, met een modernere architectuur. Uiteraard is dit echter geen zwart-wit verhaal. De beschreven voorbeeldoplossing zal op een behoorlijk verregaande manier verschillen van de traditionele oplossing, maar er zijn uiteraard ook allerlei tussenoplossingen en middenweg-scenario’s te bedenken. Een zeer eenvoudig voorbeeld is bijvoorbeeld het koppelen van de verschillende tiers binnen zo’n verouderde architectuur via RESTful APIs (zie Fig. 2). Dit is een vaak broodnodige upgrade, die nu reeds op veel plaatsen wordt toegepast. Het is een goed begin, maar meestal nog onvoldoende om de flexibiliteit en herbruikbaarheid te bereiken die we beogen met een echte modernisering.

De Moderne Architectuur, Deel 1

De moderne architectuur bestaat uit de culminatie van een aantal belangrijke architecturale principes, zoals Restful API‘s, Event-Driven Architecture (EDA) en MicroServices, waarover ik reeds meerdere blogs heb geproduceerd (Al deze technologieën maken ook deel uit van de Vortex van Enablers). In de laatste, over Services in alle Maten, gaf ik reeds een uitgebreid, zei het vaag blijvend, voorbeeld over hoe een API (een op clients gericht product !) kan worden geïmplementeerd door een combinatie van (interne) microservices, die met elkaar kunnen communiceren via REST en EDA.

Laten we nu iets concreter ingaan op hoe een modern gebouwde applicatie kan worden gebouwd gebruik makende van deze technologieën. Een dergelijke applicatie staat echter nooit alleen, dus we beschouwen deze samen met zijn onmiddellijke omgeving, bestaande uit clients, maar ook andere applicaties en diensten.

• Front-Facing API Ecosystem

  

   

  We beginnen ons verhaal bij de Front End. Dit betekent dat we de modernisering van de eigenlijke client en gebruikers-interface (UI) in deze blog buiten beschouwing laten. Dit betekent echter niet dat daar geen evoluties zouden zijn, of dat de architectuur van een “app” zelf geen modernisering zou behoeven.

  Naar de clients en de buitenwereld toe, zijn APIs de belangrijkste evolutie van de voorbije jaren. Meer en meer zal men APIs zélf gaan aanbieden als product naar derde partijen toe, en eveneens naar andere applicaties en diensten binnen de eigen onderneming. Daarbovenop komt nog dat er een proliferatie is geweest aan verschillende kanalen via dewelke een applicatie kan worden gebruikt. Dit zorgt ervoor dat de front end meer en meer een product op zich wordt, dat zich vooral moet bezighouden met het aanbieden van de nodige faciliteiten voor alle mogelijke vormen van interactie met de buitenwereld, en vooral niet met enige andere zaken, zoals de business logica zelf.

  Omdat het een goed principe is om alles zo modulair mogelijk te maken (hoe kleiner de aparte componenten, hoe makkelijker men ze afzonderlijk kan aanpassen, of zelfs vervangen via het rip-and-replace principe), bekomt men zo uiteindelijk een volledig ecosysteem van gerelateerde APIs, elk bevoegd voor het afhandelen van een bepaald type interactie met de buitenwereld. De API die achter de traditionele web app staat, zal aldus verschillen van de API die gebruikt wordt voor 3rd party clients. Afhankelijk van hoe sterk de verschillen zijn, kan men er al dan niet voor opteren om achter al deze APIs nog een verenigende API te plaatsen, die zaken zal bevatten die door alle extern gerichte APIs kunnen worden (her-)gebruikt. Een uitgebreid voorbeeld zien we in Figuur 4 (vele andere voorbeelden zijn mogelijk; zo zou de mobiele app ook met de webserver kunnen communiceren).

  

Beschouwingen

Wanneer men het voorbeeld bekijkt, zou men kunnen zeggen dat het er ingewikkelder uitziet dan vroeger, toen dit nog gewoon “de bovenste tier” was. Schijn bedriegt echter: de APIs worden nu gedragen door gespecialiseerde microservices die met elkaar samenwerken. Dit gedistribueerd systeem heeft uiteraard zijn eigen complexiteit, maar de oorspronkelijke tier had die ook in zekere mate: alleen was ze daar geïnternaliseerd binnen één monolithische component.

Verder zijn er heel wat voordelen verbonden aan de nieuwe architectuur: microservices, die via APIs communiceren, kan men veel sneller aanpassen of zelfs herontwikkelen. Hierdoor kan men sneller reageren op veranderende noden van de business. Daarenboven heeft het ook technische voordelen: de communicatie is nu gestandaardiseerd over http, waardoor (soms onverwachte) integraties een stuk soepeler kunnen worden geïmplementeerd. Bovendien kan men microservices apart schalen, en kan het systeem als geheel zich dus veel elastischer gedragen, afhankelijk van de belasting die het ondervindt. Ten slotte zijn microservices het ideale complement van containers: de basis bouwsteen van een moderne Cloud infrastructuur. Typisch zal men één microservice op één container uitrollen.

In het vervolg zullen we zien hoe commando’s (zaken die de toestand van de applicatie kunnen veranderen) en query’s (zaken die informatie opvragen uit applicaties) uit deze bovenste regionen naar de verder liggende backends worden gestuurd en daar worden behandeld. Daar zal ook de kracht van Event Driven Architecture tot zijn recht komen.

Totaaloplossingen hebben als voordeel dat men onmiddellijk beschikt over een werkend systeem dat alle nodige componenten bevat. In proefprojecten en in een eerste fase zijn totaaloplossingen dus zeker een goede benadering om snel resultaten te kunnen boeken.

Hoe meer van dergelijke totaaloplossingen er naast elkaar gebruikt beginnen te worden hoe meer de problemen van deze systemen echter naar boven zullen beginnen komen. De problemen die kenmerkend zijn voor totaaloplossingen zijn onder meer:

• Als de patiënt een tweede opinie wil dan kan de tweede arts de parameterwaarden niet analyseren indien hij niet hetzelfde systeem gebruikt.
• Een gelijkaardig probleem doet zich voor indien een patiënt van arts wenst te veranderen. Indien deze een ander systeem gebruikt, dan moet de patiënt leren werken met een nieuw toestel. Dit is niet voor alle patiënten evident.
• Omgekeerd kan een arts ook niet gemakkelijk beslissen om een andere analysesoftware te gebruiken. Andere softwareleveranciers zullen vaak geen toegang hebben tot het gesloten systeem, waardoor de arts nagenoeg verplicht is om dezelfde software te blijven gebruiken. Volledig veranderen van systeem is bij een gesloten omgeving niet evident omdat alle patiënten van de arts dan ook een ander registratietoestel dienen te gebruiken.
• Als de systemen worden aangeboden door een ziekenhuis dan zal de huisarts van de patiënt niet altijd een licentie hebben van de gebruikte analysesoftware. Het is voor een huisarts ondoenbaar om over verschillende softwarelicenties te beschikken.

Zoals eerder gezegd zijn in proefprojecten of in een eerste fase totaaloplossingen de snelste manier om resultaten te kunnen behalen. Voordat er echter een wildgroei ontstaat van oplossingen die naast elkaar gebruikt worden zou het misschien goed zijn om na te gaan of er geen oplossing gevonden kan worden voor bovenstaande problemen. In deze blogpost wordt een aanzet gegeven van een mogelijke oplossingspiste.

Oplossingsvoorstel

Ideaal gezien zou dus zowel de patiënt als de arts / ziekenhuis de vrijheid moeten hebben om zelf te bepalen welke registratietoestellen of software zij respectievelijk gebruiken. Een volledige loskoppeling tussen de systemen die instaan voor de registratie van de gegevens en de software die instaat voor de verdere verwerking zou tegemoetkomen aan een groot deel van de eerder opgelijste problemen.

Een volledige ontkoppeling is echter maar mogelijk wanneer een onafhankelijke partij instaat voor een centraal beheer van de medische parameters. Over wie de onafhankelijke partij zou moeten zijn die verantwoordelijk zou worden voor het registratieplatform wordt in deze blogpost geen uitspraak gedaan. Diverse pistes zijn hiervoor mogelijk.

Het centrale register houdt de waarde van de gemeten parameters bij en stelt deze ter beschikking van de hiertoe gemachtigde gebruikers. De onderstaande afbeelding stelt deze manier van werken schematisch voor.

Het grote voordeel van een volledige loskoppeling is dat er een gelijk speelveld wordt gecreëerd voor alle partners. Spelers kunnen zich specialiseren in een unieke functie zonder dat ze ook moeten voorzien in de andere componenten van een gesloten systeem. Verder in deze blogpost wordt er dieper ingegaan op het feit dat de creatie van een gelijk speelveld kansen kan bieden aan nieuwe innovatieve spelers.

Patiënt

De patiënt zou over de vrijheid moeten beschikken om zelf te bepalen welk toestel hij wenst te gebruiken. Deze vrijheid is natuurlijk enigszins beperkt omdat het toestel in staat moet zijn om met het platform dat de medische parameters beheert te communiceren. Het lijkt aangewezen om deze communicatie zoveel mogelijk te baseren op internationale standaarden. De Continua standaard van de Personal Connected Health Alliance (http://www.pchalliance.org/) is bijvoorbeeld een internationale standaard voor medische registratietoestellen. Deze standaard beschrijft onder meer de interface tussen de meettoestellen en de gateway die instaat voor het verzenden van de waardes naar een centraal platform. De website van de organisatie die verantwoordelijk is voor deze standaard bevat een lijst met alle registratietoestellen die momenteel al voldoen aan hun standaard.

Arts

Indien een arts niet langer gebruik moet maken van specifieke software dan kan de functionaliteit om de parameterwaarden te visualiseren en analyseren ingebouwd worden in de eigen EMD software. Dit zou als voordeel hebben dat de parameterwaarden gekoppeld kunnen worden aan de al beschikbare informatie over de patiënt. Door deze koppeling zou dus een vollediger beeld ontstaan van de patiënt binnen de eigen EMD-software.

Anonimisatie van parameterwaarden

Medische parameters zijn gevoelige informatie en moeten dus maximaal beschermd worden. Anderzijds kan het onder voorwaarden beschikbaar stellen van deze parameters aan derden het ontstaan van een volledig nieuwe dienstverlening tot gevolg hebben. Het lijkt daarom aangewezen om de parameters in een afzonderlijke omgeving op te slaan met een eigen technische identificatiesleutel. De relatie met de burger zou dan bijgehouden kunnen worden in bijvoorbeeld een van de bestaande kluizen (Vitalink, RSW of BGN). De zorgverstrekker die toegang heeft tot de informatie in een van de kluizen beschikt over alle identificatiesleutels om de parameters van een specifiek persoon op te halen. Enkel wie toegang heeft tot het parameterplatform krijgt geanonimiseerde gegevens te zien.

Ontstaan van nieuwe innovatieve dienstverlening

Zoals in voorgaande paragraaf aangegeven kan overwogen worden om de geanonimiseerde parameterwaarden ter beschikking te stellen voor verdere verwerking. Deze gegevens kunnen aanleiding geven tot het ontstaan van een nieuwe dienstverlening. Organisaties kunnen bijvoorbeeld de gegevens gebruiken om continu de ingegeven waarden te bewaken. Geavanceerde data analyse technieken of AI detectiemechanismes kunnen ontwikkeld en toegepast worden op de gegevens uit het parameterplatform om eventuele problemen te signaleren. Deze start ups kunnen hun business model bouwen op een toegang tot deze gegevens en hierrond een dienstenaanbod creëren. Het eenvoudig toegankelijk maken van deze gegevens verlaagt de drempel om een nieuwe dienstverlening op te starten. De initiële opstartkosten worden sterk verlaagd indien er geen end-to-end oplossing gerealiseerd moet worden.

Anderzijds kunnen nieuwe spelers ook nieuwe registratietoestellen of apps ontwikkelen en deze aansluiten op het registratieplatform. De enige voorwaarde hierbij is dat deze voldoen aan de gebruikte standaarden. Om deze spelers toe te laten hun toestellen internationaal te vermarkten is het terug belangrijk dat de door het parameterplatform gebruikte standaarden internationale standaarden zijn.

Algemene opmerking over deze blogpost: deze post ging voornamelijk uit van de arts als verwerker van de gezondheidszorgparameters. Evengoed zou een gelijkaardig verhaal geschreven kunnen worden voor de andere gezondheidszorgverstrekkers.

Daarnaast spreekt het voor zich dat bovenstaande enkel mogelijk is indien een oplossing wordt gevonden voor de diverse problemen die er nu zijn bij de invoering van telecare oplossingen (terugbetalingsmodel, juridische aansprakelijkheid,… ) en dat er bij de uitwerking van een oplossing rekening moet gehouden worden met de GDPR regelgeving.

______________________

Dit is een ingezonden bijdrage van Renzo Lylon, business consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

In een vorige blog had ik het reeds over het uitbesteden van gemeenschappelijke zaken, nodig voor meerdere ondernemingen, applicaties & diensten, aan een derde, hierin gespecialiseerde partij. Hetgeen deze laatste partij doet, noemen we “horizontale dienstverlening”; men opereert namelijk in een horizontale markt.

Nu wil ik graag enkele voorbeelden geven van hoe de overheid hetzelfde zou kunnen doen via een data-centric eGovernment (bovenop de vele zaken die ze reeds doet, met b.v. sterke eID authenticatie, de G-Cloud, en het eHealth platform).

Een aantal voorbeelden:

1. Chipkaarten

   In diezelfde vorige blog vernoemde ik de voordelen die er zouden ontstaan indien we het beheer van chipkaarten zouden afzonderen bij één horizontale chipkaartenbeheerder, en alle gebruikers van deze kaarten dan hiervan gebruik zouden kunnen maken. In een vergevorderd stadium zou het zo in principe zelfs mogelijk worden dat we via één enkele chipkaart van allerlei diensten, aangeboden door verschillende bedrijven (overheid of privé) gebruik kunnen maken, en we dus niet met een veelheid van de plastieken ondingen in onze portefeuille zouden moeten rondlopen. Dergelijke dienstverlener zou zelfs via een SaaS platform ook aan kleine ondernemingen een paar opties kunnen geven om b.v. aan een bestaande QR code op de chipkaart van een persoon, een klantenkaart te koppelen. Kortom, “one card to rule them all“. Misschien zou de overheid dit kunnen aanbieden via de eID?

2. “Waar-woon-ik-as-a-Service”

   Een eenvoudig, maar krachtig voorbeeld van nuttige en toch min of meer private data, zijn adressen en adreswijzigingen. Wat als elke adreswijziging die iemand onderging, onmiddellijk door alle (overheids-)diensten, door de post, door koeriers, en eventueel door een resem andere belanghebbenden was geweten? Dit scenario werkt als volgt:

   1. De burger verhuist, en de nodige (fysieke) controles gebeuren.
   2. De gemeenteambtenaar voert dit gegeven in (Dit gegeven valt trouwens onder de noemer “civic moment“: een belangrijke gebeurtenis in de levensloop van een burger (of bedrijf), die een aantal administratieve gevolgen kan triggeren).
   3. Vanaf dan zijn deze gegevens (zowel het nieuwe adres als de adresverandering) automatisch beschikbaar voor alle overheidsdiensten die er sowieso recht op hebben. Dit is mogelijk via het opvragen van de gegevens (b.v. via REST APIs), maar evenzeer kunnen sommige applicaties onmiddellijk op de hoogte worden gebracht (via Events). Bijgevolg kunnen deze diensten dus automatisch eventuele veranderde rechten en plichten van de burger die van zijn adres afhangen, aanpassen, en uiteraard ook hun briefwisseling naar het nieuwe adres richten.

      

   4. Daarnaast kan de overheid, als data custodian (zo noemen we de horizontale dienst van het databeheer), ook een applicatie aanbieden aan de burger zelf, waar deze de mogelijkheid krijgt om applicaties van andere bedrijven toegang te geven tot deze gegevens. Dit zou een beetje kunnen werken zoals een Google of Facebook account: ook tot deze accounts kan men (beperkte en specifieke) toegang verlenen aan andere applicaties. De burger zou dus b.v. op die manier aan Bpost de toestemming kunnen geven om deze gegevens automatisch te ontvangen. Vanaf dan zou de post automatisch naar het nieuwe adres kunnen worden doorgestuurd. Sterker nog: men zou het zo kunnen regelen, dat men brieven kan versturen op naam (en/of eventueel een unieke identifier die een burger voor zichzelf kan genereren in de toepassing), en dat de post deze dan vanzelf aan het juiste adres levert. Op die manier zou men niet meer overal zijn échte adres moeten opgeven en verhoogt men dus zelfs de privacy van de burger.
   5. Ook andere koeriersbedrijven zouden op deze dienst kunnen intekenen en door de burger geauthenticeerd kunnen worden om gebruik te maken van diens door de service gekende adres. Ik wacht trouwens nog steeds op de mogelijkheid om een account te creëren bij een koeriersbedrijf en daarna niet meer mijn adres te moeten geven in elke aparte webshop die ik gebruik, maar gewoon te kunnen aanvinken dat mijn gekozen koerier mijn adres reeds kent!

   In het voorbeeld maakte ik abstractie van een eventueel apart correspondentie-adres, of het gebruik van meerdere adressen, maar deze zou men even goed door de burger zelf kunnen laten beheren in een centraal aangeboden toepassing.

3. Civiele “Half-Open” Data

   Naast het adres heeft de overheid nog een schat van andere informatie over haar burgers en bedrijven. We moeten uiteraard rekening houden met de privacy van dergelijke data, maar desalniettemin kan deze functie van Data Custodian worden uitgebreid met heel wat interessante mogelijkheden. (Ik verwees in de chipkaartenblog reeds naar het gescheiden beheer van gegevensnetwerken versus de applicaties die ervan gebruik maken. De vortex van enablers maakt dit reeds perfect mogelijk.)

   Men zou bijvoorbeeld automatisch rechten kunnen afleiden uit bepaalde situaties die burgers ondergaan (verlies van werk, fysiek letsel, …) indien deze gebeurtenissen (dit zijn Civic Moments en Events!) en hun corresponderende nieuwe gegevens snel en automatisch door alle nodige diensten werden opgevangen.

   In het voorbeeld van het fysiek letsel zou de burger aan een dokter de toestemming kunnen geven om gegevens i.v.m. langdurige werkonbekwaamheid automatisch door te sturen naar instanties die hiervoor uitkeringen betalen. Een gelijktijdig gevolg, met communicatie naar de Fod SZ, zou kunnen zijn dat de burger automatisch een parkeerkaart voor personen met een handicap zou krijgen toegestuurd.

   Deze, en nog vele andere mogelijkheden die ontstaan door de juiste data op het juiste moment op de juiste plaats te krijgen, tonen nogmaals aan dat data-centric IT meer dan ooit van belang is (en – niet te vergeten – data-centric security).

Digitale transformatie

Het eGovernment heeft onlangs reeds een fenomenale stap vooruit gezet als horizontale dienstverlener via de G-Cloud, die ervoor zorgt dat men op infrastructuur- en middlewarevlak synergieën kon creëren. Nu is stilaan het moment aangebroken om verder te beginnen denken: ook bovenop de infrastructuur, binnen en tussen applicaties en vooral door hergebruik van gegevens, ligt er nog een goudmijn van mogelijkheden op ons te wachten. In dergelijke context praat men momenteel dan ook graag over “Digital Transformation” (een evolutie die eigenlijk al heel lang gaande is).

Tot nu toe focuste deze trend zich binnen de overheid daarbij vooral op kostenbesparingen: hoe hetzelfde doen, maar dan op een efficiëntere manier? Dit is uiteraard nuttig, maar Digitale Transformatie gaat veel verder dan dat (ook volgens de blogosphere, en ook wanneer het specifiek over Cloud gaat). De ware kracht van deze trend mag niet verloren gaan in oeverloze discussies over hoe alles goedkoper kan, of hoe de bestaande zaken met de nieuwe technologie efficiënter kunnen worden gemaakt.

Ik durf hierbij zelfs Bob Lewis bij te treden: IT plannen moeten niet gedreven worden door de noden van de business, maar de business strategie moet gedreven worden door de nieuw beschikbare technologische mogelijkheden!

Welnu: de technologieën die een grote evolutie mogelijk maken, zijn gearriveerd. Laten we onze inspiratie de vrije teugels geven, en bedenken wat voor interessante diensten we nog kunnen bieden, aan zowel de ambtenaren van ons land, als aan zijn burgers en bedrijven.