Disclaimers…

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

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

Het voorbeeld: De arbeidsmotor voor de Sociale Zekerheid

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

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

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

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

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

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

Een Business event-verhaal doorheen dit ecosysteem

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

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

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

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

Besluit

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

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

De Paradox van de Afhankelijkheid

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

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

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

De “Mesh” Architectuur

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

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

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

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

Een aantal helpende Principes

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

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

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

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

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

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

Besluit: even Wennen

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

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

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

REST: de gouden standaard

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

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

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

De pure API aanpak

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

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

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

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

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

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

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

Richting asynchrone communicatie

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

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

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

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

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

Standaarden voor Asynchrone APIs

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

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

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

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

De gebalanceerde aanpak: APIs plus Events

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

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

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

Een aantal extra opmerkingen betreffende deze manier van aanpakken:

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

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

Conclusie

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

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

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

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

Wat is Reactive alweer?

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

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

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

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

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

Het Akka raamwerk

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

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

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

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

Een voorbeeld

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

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

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

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

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

Besluit

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

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

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

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

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

Wat is Eventual Consistency?

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

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

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

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

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

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

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

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

Voorbeelden

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

1. Domain Name System (DNS)

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

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

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

2. Webwinkel

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

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

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

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

3. Het bancair systeem

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

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

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

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

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

4. Onze sector?

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

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

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

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

Evaluatie en Besluit

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

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

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

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

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

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

Vorige herfst schreven we onze eerste blog over de veelbelovende technologie NewSQL. Na een pauze en een periode met enkele testen, kunnen we nu bevestigen dat deze nieuwe databases effectief een positieve evolutie zijn.

Evolutie, geen Revolutie

Wat het database gebruik in de IT sector betreft, zien we nog steeds een ruime meerderheid voor traditionele databases. Leidende spelers zijn daarbij MySQL en PostgreSQL. Daarnaast weet ook de NoSQL database MongoDB aardig wat marktaandeel te veroveren. Van een revolutionaire opmars van NewSQL databases kan dus nog geen sprake zijn.

De reeds bestaande databases, zowel OldSQL als NoSQL, staan dan ook niet stil in hun evolutie, en groeien op verschillende vlakken naar elkaar toe. Enkele NoSQL producten bieden b.v. een beperkte ondersteuning voor SQL of SQL-achtige talen aan, en soms ook transacties. De traditionele relationele databases, op hun beurt, bieden allerlei manieren aan om horizontaal te gaan schalen en dus een gedistribueerd systeem op te zetten met een verhoogde beschikbaarheid. Men kan dus stellen dat de verschillende categorieën van databases dichter naar elkaar toegroeien.

Ook NewSQL kan men, zoals we reeds aanhaalden in de vorige blog, eigenlijk beschouwen als een soort naar elkaar toegroeien van beide andere categorieën. Zit er dan nog een effectieve vernieuwing in?

Het antwoord op die vraag situeert zich in een aantal producten die van nul af zijn opgebouwd met de problematiek van dit spanningsveld tussen consistentie en beschikbaarheid in gedachten, en die met een cloud native aanpak zijn ontworpen. Dit wil o.a. zeggen dat dit vanaf het begin een gedistribueerd ontwerp betreft. De basis architectuur en de opzet zijn aldus voldoende verschillend van de andere producten om er effectief het label “NewSQL” aan te hangen. Het resultaat zijn systemen die de gewenste eigenschappen combineren, zonder dat de installatie en het onderhoud nodeloos complex worden.

Om te zien hoe dit spanningsveld precies wordt aangepakt bij NewSQL, moeten we nog eens terugkomen op het befaamde CAP-theorema…

Van CAP naar PACELC

Het Cap theorema gaat vooral in op wat theoretisch niét kan (C, A én P tegelijk hebben). Het vertelt ons echter iets te weinig over wat men dan wel kan doen binnen de grenzen van wat theoretisch mogelijk is.

Wanneer alles redelijk normaal verloopt voor een gedistribueerd systeem, treden er geen netwerkpartities op. Op dat ogenblik kan men dus, in principe, volgens het CAP theorema, zorgen voor beschikbaarheid en consistentie tegelijkertijd. In de praktijk zal dit, indien alles naar wens verloopt en er geen al te zware load op het platform inwerkt, ook zo zijn. Zelfs de “eventual” consistency van NoSQL systemen zal dan slechts seconden zijn i.p.v. de langere tijd die men van “eventual” zou verwachten.

Nochtans moet men in dit geval ook nog keuzes maken… Het PACELC theorema, een uitbreiding op het CAP theorema, stelt namelijk dat men in afwezigheid van netwerkpartities, moet kiezen tussen latency en consistentie. NoSQL trekt hier duidelijk de kaart van latency: men aanvaardt onmiddellijk een request van een client, en rekent op de eventual consistency om alle nodes van het systeem op een redelijke tijd in orde te krijgen. NewSQL systemen daarentegen, kiezen consistentie: vooraleer de request wordt aanvaard, zorgt men ervoor dat voldoende nodes akkoord zijn en wanneer de request aanvaard is, zal dit ook zo zijn op de meeste nodes, zodat de consistentie gegarandeerd is over het gehele systeem. Deze fase van “akkoord bereiken” tussen de nodes zal de werking natuurlijk enigszins vertragen.

De afkorting PACELC kan men dan via het volgende zinnetje opbouwen: Bij netwerkpartitie (P), moet men kiezen tussen beschikbaarheid (Availability) en Consistentie (C), en anders (Else), tussen latency (L) en consistentie (C).

Wanneer men over voldoende performantie beschikt, het systeem niet overbelast is, en er geen fouten optreden, zal men in de praktijk weinig merken van dit verschil tussen latentie en consistentie. Maar de specifieke garanties die worden geboden zijn echter wel heel belangrijk om weten wanneer men deze databases gaat gebruiken, vermits er altijd wel iets zal misgaan en er altijd wel een situatie kan optreden die het systeem te zwaar belast. Wil men ten allen tijde kunnen rekenen op consistentie, of op een zo hoog mogelijke beschikbaarheid en het zo weinig mogelijk missen en zo snel mogelijk afhandelen van requests? Een banktoepassing zal typisch het eerste willen, een webshop misschien eerder het tweede (en als er iets misgaat door inconsistentie in de data, maakt men dit achteraf wel goed met de klant).

In de praktijk is PACELC eigenlijk nuttiger dan CAP: indien men een systeem met hoge beschikbaarheid wil voorzien, moet men de facto aan duplicatie gaan doen, ook van data. Vanaf het moment dat data gedupliceerd wordt en verspreid over meerdere plaatsen, zal men een afweging moeten maken tussen hoe consistent men deze wil houden, en hoe snel men er mee wil kunnen werken.

NewSQL in de Praktijk: Testresultaten

We testten 3 verschillende NewSQL producten tijdens deze studie: CockroachDB, TiDB en NuoDB. Het voornaamste doel van de test was om het gedrag bij het uitvallen van nodes te testen. De theorie stelt dat deze databases netjes blijven werken zolang een meerderheid van de nodes draait en deze elkaar kunnen zien. Op die manier kan er altijd een concensus worden bereikt betreffende transacties.

De test ging als volgt: eerst bouwen we een cluster van 3 nodes voor elk van deze producten; daar wordt eventueel nog een load balancer aan toegevoegd en ook voorzien we een machine die als client zal optreden. Daarna volgen er twee testen waarbij we de cluster vanaf de client machine bestoken met requests. We gebruiken hierbij de TPCC, dit is een gestandaardiseerde test voor OnLine Transaction Processing (OLTP) Databases, het soort databases die we typisch gebruiken als backend voor online toepassingen (de typische tegenhangers zijn databases die zich focussen op analytics). De TPCC is “test C” van de TPC (transaction processing performance council), en wordt vandaag beschouwd als de meest typische maatstaf.

De twee testen verschillen in het volgende: de eerste keer gaat er niets mis: alle drie de nodes blijven netjes werken. Bij de tweede test-run zullen we echter na een tijdje één van de nodes geforceerd uitschakelen, alsof deze een stroompanne ondervindt. Deze node zal dan de helft van de testperiode uitgeschakeld blijven, om dan, nog tijdens de test, terug op te worden gestart.

De TPCC is in principe ook een performantietest, dus we kunnen eigenlijk ook zien hoeveel verkeer deze databases aankunnen. Dit was echter niet het hoofdopzet van de test en de resultaten kunnen hierdoor wat meer uit elkaar liggen. Ook spelen er bepaalde aspecten aan sommige NewSQL databases, die een impact hebben op de performantie, niet mee in onze test, vanwege de setup (verschillende nodes op virtuele machines, echter allen op dezelfde fysieke machine). Zo is de fysieke afstand tussen nodes belangrijk, en vaak is het ook van belang of de systeemklokken op de verschillende nodes niet teveel van elkaar afwijken (Voor Google Spanner rolt men hiertoe atoomklokken uit in de verschillende datacenters; er bestaan echter ook aanvaardbare goedkopere oplossingen).

Voor de drie geteste databases bekwamen we gelijkaardige resultaten. Alle drie bleven ze functioneel bij het falen van één van de drie nodes. Bij de laatste, NuoDB, vroeg dit echter extra configuratiewerk. Voor CockroachDB en TiDB was dit out-of-the-box ondersteund. Daarnaast werd de performantie weinig beïnvloed door het node-falen; er waren nauwelijks minder transacties in de testperiode (enkel voor NuoDB was het verschil iets groter). Wat wel opviel, was dat enkele transacties een stuk langer duurden. We vermoeden dat deze transacties werden gedaan op het moment van het node-falen, waardoor ze werden benadeeld. Al bij al voldeden de drie geteste producten echter wel goed aan onze verwachtingen van beschikbaarheid. Hieronder een voorbeeld van de cijfers van de test van CockroachDB.

Besluit

NewSQL databases beginnen vrij matuur te zijn. Ze zijn een prima keuze wanneer we voor een toepassing de voorkeur geven aan het gemak van data die consistent blijft en ondersteuning voor SQL, maar tegelijk toch een zeer goede beschikbaarheid willen. Het gedistribueerd karakter is ingebouwd in de technologie (ze zijn dus ‘cloud native’), waardoor ze zich veel gemakkelijker dan de traditionele relationele databases laten uitrollen in clusters van meerdere evenwaardige nodes (‘multi-master‘, i.t.t. de zgn. ‘master-slave’ setup), waarvan slechts een meerderheid operationeel moet blijven om het systeem beschikbaar te houden.

We kunnen echter ook enkele aandachtspunten aanduiden. Om een effectief systeem met hoge beschikbaarheid te hebben, moet men deze databases in principe uitrollen op verschillende locaties (eventueel zelfs in verschillende datacenters). Dit om ervoor te zorgen dat de kans zo klein mogelijk is dat verschillende nodes tegelijk falen. Tegelijk is het van belang dat deze nodes vlot met elkaar kunnen communiceren (en dat dit verkeer niet wordt onderschept) en op systemen draaien met een zo gelijk mogelijke systeemklok (voor sommige architecturen), anders wordt de performantie aangetast.

Deze aandachtspunten in beschouwing genomen, kunnen we echter besluiten dat NewSQL databases een goede keuze vormen wanneer men een cluster van redundante databases wil uitrollen voor verhoogde beschikbaarheid.

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

Een Beetje Geschiedenis

Het “Reactive” Manifest

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

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

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

Functional Reactive Programming

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

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

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

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

Reactive voor Reactive

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

Hoe is dit nu Beter?

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

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

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

Verschil met Event Driven Architecture?

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

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

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

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

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

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

Besluit

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

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

Interessante bronnen

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

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

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

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

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

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

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

_________________________

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

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

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

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

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

Serverless = Event Driven

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

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

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

Voor- en Nadelen

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

Pay Per Use

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

Schaalbaarheid en Elasticiteit

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

Veiligheid

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

Eenvoudige Ontwikkeling, Complex Beheer

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

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

Conclusie

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

_________________________

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

We zullen het daarbij hebben over een aantal categorieën of grootteordes van services: microservices, miniservices en macroservices. En dan zetten we er ook nog zogenaamde nanoservices langs, die eigenlijk (nog?) geen officiële definitie hebben… Al deze architecturele paradigma’s zijn in zekere mate geïnspireerd door de reeds langs gekende Service-Oriented Architecture (SOA).

We kunnen nu wel al iedereen gerust stellen: er bestaat geen “one size fits all”; alle groottes van services zullen nuttig zijn in de portfolio van applicaties, diensten en componenten die een IT-bedrijf zal ondersteunen. Deze heterogeniteit wordt ook vooropgesteld door Gartner en ze noemen dit de MultiGrained Mesh App and Service Architecture (MG-MASA). Het belangrijkste daarbij is dat alle componenten hierin zo onafhankelijk mogelijk ontwikkelbaar zijn, terwijl ze toch vlot met elkaar kunnen communiceren en integreren.

Met uitzondering van de dubieuze term “nanoservices”, zullen we van klein naar groot gaan: we zullen eerst grondig definiëren wat microservices nu eigenlijk zijn, alvorens de “grotere” services te bespreken.

MicroServices: van Startup tot Web Scale speler

Microservices zijn onafhankelijke diensten met een sterk beperkte scope. Ze volgen rigoureus een aantal architecturale principes waardoor ze extreem wendbaar ( agile ) zijn en ook heel flexibel schaalbaar. Ze zijn zo ontkoppeld mogelijk van andere applicaties en diensten, doch communiceren er ook mee. Deze schijnbare tegenstrijdigheid wordt doorgaans opgevangen door een Event-Driven Architecture, dewelke losgekoppelde communicatie in gedistribueerde systemen ondersteunt.

De beperkte scope en bijgevolg doorgaans kleinere codebase is ook voor een stuk wat een microservice zo wendbaar maakt: ze kunnen door een klein devops team worden ontwikkeld en onderhouden en meermaals daags opnieuw uitgerold worden met veranderende features. Een grote applicatie die aldus ondersteund wordt door een groep van microservices, zal constant online blijven maar continu kleine veranderingen ondergaan en dus voortdurend evolueren. Op deze manier zorgt de microservices architectuur dus voor extreem door-gedreven Continuous Delivery. Andere aspecten van deze architectuur zijn het principe van “single responsability” (wat op hetzelfde neerkomt als de beperkte scope), extreme schaalbaarheid en – indien de microservice gepersisteerde data beheert, exclusieve toegang (= “eigenaarschap” of ownership) tot zijn database (of andere persistentie-oplossing), in het kader van de loskoppeling.

Microservices zijn op de kaart gezet door toepassing bij een aantal grote en bekende bedrijven als Twitter, Airbnb, Disney, Dropbox, GE, Goldman Sachs, en uiteraard ook grote Cloud spelers  zoals Amazon en Google. Microservices, volgens de strikte definitie, zijn echter bij veel middelgrote bedrijven nog zeldzaam, al evolueren sommige miniservices (zie verder) na een tijdje wel tot een groepje microservices, doordat aparte functionaliteiten worden afgesplitst.

Ze worden qua aangeboden functionaliteit opzettelijk en strikt beperkt gehouden: normaal gezien wordt er slechts één specifieke feature ondersteund, of één bounded context binnen een domein (voor meer info over deze term, kijk naar Domain Driven Design (DDD)). Doordat ze zo klein zijn en slechts één functionaliteit hebben, en apart uitrolbaar zijn, vormen microservices dus de ultieme vorm van flexibele schaalbaarheid. Een applicatie bestaande uit vele microservices kan optimaal gebruik maken van beschikbare resources: elke component die iets meer gebruikt wordt dan een andere, kan apart opgeschaald worden. Componenten die minder vaak nodig zijn, worden omlaag geschaald.

De onafhankelijkheid van een microservice beperkt zich best niet tot fysiek afzonderlijke deployments. Ook gedeelde libraries kunnen namelijk worden beschouwd als een te grote afhankelijkheid tussen verschillende microservices. Op deze manier wordt hergebruik soms een anti-patroon (“anti-pattern”). Het gaat dan natuurlijk wel om de code die het domein implementeert, er is weinig op tegen om utilitaire bibliotheken, zoals een logging raamwerk, te hergebruiken in meerdere microservices.

Microservices vinden we dan ook vooral terug bij bedrijven die op grote schaal (“web scale”) actief zijn, en dusdanig grote volumes moeten ondersteunen dat elke uitgespaarde percent benodigde resources een enorme kostenreductie tot gevolg heeft. We denken dan aan grote mediaspelers als Netflix, winkels als Amazon en Zalando, en uiteraard ook de Twitters, Facebooks en Googles van deze tijd.

Maar doordat het een nieuwe, moderne manier van ontwikkelen is, zijn microservices ook enorm populair bij startups. Deze hebben vaak het voordeel dat ze van nul kunnen beginnen met hun technologie, zonder enige legacy, en dat ze met kleine teams en een frisse bedrijfscultuur werken. Een Devops en Agile cultuur zijn namelijk sterke vereisten om microservices te kunnen ontwikkelen; hun architectuur verschuift namelijk de complexiteit weg van de binnenkant van een monoliet, maar recht naar de onderlinge interacties tussen vele (gedistribueerde) applicatiecomponten. Het voordeel  van microservices voor de startups is weliswaar dat ze op technologisch vlak een stuk robuuster zijn bij eventuele plotse groei, en ze de wendbaarheid ook goed kunnen gebruiken om snel in te spelen op marktopportuniteiten (er zijn reducties in ontwikkelingstijd tot 75% geschat).

APIs en Microservices

Microservices worden vaak beschouwd als de ideale manier om een API te implementeren. Dit is inderdaad een goede werkwijze, maar dan met één hele belangrijke caveat: de onafhankelijkheid van de microservice moet gewaarborgd blijven. Het scheiden van een API en zijn implementatie is een fundamenteel principe bij SOA, dat nog belangrijker wordt in de context van de extreme vereisten die aan een microservices architectuur worden gesteld.

Een API moet behandeld worden als een product. Geregeld worden APIs namelijk naar buiten toe opengesteld (en soms zelfs effectief gemonetariseerd), en op zijn minst dienen ze als interface naar andere software componenten (en dus andere ontwikkelteams) toe. Ze hebben dus nood aan een rigoureus change management.

De microservices daarentegen moeten snel kunnen evolueren en aangepast kunnen worden. Soms worden ze zelfs volledig vervangen (ze zijn disposable: het verlies blijft beperkt doordat ze kleiner zijn). Sowieso zal één microservice ook nooit een volledige API implementeren (tenzij als het echt om een miniscuul klein product zou gaan): achter de API bevindt zich doorgaans een hele batterij van componenten, waarbij verschillende microservices de effectieve business logica zullen uitvoeren. Andere componenten zijn bijvoorbeeld een Event bus, maar ook en vooral een API bemiddelingstool (“mediation”), die ervoor zal zorgen dat de calls naar de API bij de correcte afhandeling terecht komen, en op die manier de microservice loskoppelen van de ondersteunde API. Deze tools zijn doorgaans vervat binnen de context van een API Gateway of API Management suite.

De Pragmatische Aanpak: MiniServices

De term “microservice” wordt vaak misbruikt om eender welke kleine en herbruikbare dienst te benoemen. Maar zoals we hierboven zagen, voldoet dit nog lang niet aan de eigenlijke definitie, en is het ook zo dat een microservice zijn eigen API best niet zelf publiceert.

De categorie die dan ook door vele “enterprise niveau” bedrijven het vaakst wordt toegepast, is eigenlijk de miniservice, ook al zijn deze bedrijven snel om te zeggen dat ze een “microservices architectuur” gebruiken. De architecturen lijken dan ook wel enigszins op elkaar en enkel de grootte en scope (en het uiteindelijke doel) verschillen hier nog.

Miniservices implementeren geen volledige applicatie, en zullen normaal gezien ook slechts een stukje van een extern gerichte API invullen. Ze focussen zich op de functionaliteiten verband houdende met een bepaald subdomein in de applicatie. Wanneer we de principes van Domain Driven Design (DDD) volgen: een miniservice kan een volledig domein implementeren, maar eventueel ook een niet al te kleine “bounded context”, of alles wat ertussen ligt.

Miniservices zijn onafhankelijk van elkaar te ontwikkelen en uit te rollen, waardoor er een flexibiliteit ontstaat: doordat men werkt met kleinere componenten die losjes gekoppeld zijn en die men daardoor apart kan ontwikkelen en laten evolueren, kan men iets sneller de functionaliteiten veranderen via een meer agile ontwikkelingsmethode, en men kan dus sneller op de bal spelen. Hierdoor kan men beter ten dienste staan van de business, die sneller zijn product kan laten aanpassen aan veranderende marktomstandigheden. Dit komt dus neer op een afgezwakte versie van de vereisten voor microservices.

Wat data betreft, heeft men opties: in sommige gevallen kan men ervoor opteren om de database die onder een miniservice staat, nog bruikbaar te houden voor andere applicaties en diensten; soms is dit gewoon gemakkelijker en efficiënter dan de data via de API bloot te stellen, of op een moderne gedistribueerde manier te verspreiden zoals dit bij microservices gebeurt. Men moet hier echter mee oppassen en het beperken, want hierdoor creëert men quasi onherroepelijk afhankelijkheden. Beter is het om wat de data betreft toch eerder richting microservices architectuur te evolueren en de miniservice exclusieve toegang tot zijn data te geven.

Volgens een schatting van Gartner zal tegen 2019 90% van de organisaties het microservices paradigma te disruptief vinden en eerder gebruik maken van miniservices.

Er zijn, ten slotte, nog een aantal andere alternatieven voor een microservices aanpak, naast miniservices. Zo bestaan er PaaS platformen waarbij er sterk visueel kan worden ontwikkeld (met zogenaamde “zero coding”) en men op die manier de productiviteit kan laten stijgen. En voor het implementeren van business processen kan men nog gebruik maken van BPMS suites, die ook hier vaak een sterke automatisatie toelaten op een meer grafische manier.

Old School: de MacroService

Macroservices representeren de traditionele SOA aanpak, die nu sterk in vraag wordt gesteld door de IT industrie. Via een macroservice brengt men een volledige applicatie of dienst online, in één grote deployment; deze ondersteunt dan een typische request/response API. Het woord service kan dan in hoofdzaak worden aangewend doordat men de applicatie of dienst heeft ge-“service enabled”. Er wordt m.a.w. een SOAP of (beter!) een REST API aangeboden aan de buitenwereld om met de macroservice te interageren. Vaak is het ook zo dat deze applicatie bovenop een database gebouwd wordt, via dewelke nog wordt geïntegreerd met andere toepassingen.

Momenteel is het sterk afgeraden om op deze manier een nieuwe applicatie op te bouwen, maar deze systemen hebben echter wel nog af en toe hun nut! Vele bedrijven hebben namelijk een bepaald arsenaal aan zogenaamde “legacy” toepassingen, die vaak nog belangrijke taken verrichten, en die te groot en te complex (en dus te duur) zijn geworden om ze volledig te vervangen door een moderne variant die dezelfde kernfunctionaliteit encapsuleert. Wat men dan op z’n minst kan doen om deze applicaties beter te kunnen integreren met de nieuwere generatie componenten, is ze te “service enablen”. Dit betekent dat men er een laag rond bouwt die een moderne (REST) API zal aanbieden waarmee andere toepassingen dan gemakkelijker verbinding kunnen maken. De laag zal ervoor zorgen dat de buitenwereld niets hoeft te merken van de soms rare zaken die met de legacy toepassing kunnen misgaan, of van de esoterische programmeertalen en protocols die erin worden gebruikt.

Let wel dat er steeds moet worden afgewogen om zulke applicaties toch niet te re-engineeren. Wanneer het echt om de core business van een bedrijf gaat, en men wil kunnen inspelen op b.v. een veranderende markt (m.a.w. wanneer men wendbaarder, meer agile, wil zijn), kan het op langere termijn soms voordeliger zijn om ze te vervangen door een meer op microservices geïnspireerde architectuur. Het gebruik van MacroServices is eerder geschikt voor applicaties die minder vaak veranderingen dienen te ondergaan, maar die wel via een API moeten kunnen worden aangesproken. Soms kan het ook gaan om aangekochte software, die dus inherent niet onder de eigen controle zit en niet kan ge-reëngineered worden.

De Toekomst is hier: NanoServices

NanoServices kan twee zaken betekenen. Enerzijds is het een door sommige mensen aangewende term om op een anti-patroon bij het bouwen van microservices te duiden: namelijk een te sterke beperking van de scope, op een manier die zinloos is. Het komt er dus op neer dat men goed moet nadenken over de bounded context en het te verwachten aparte gebruik van de diensten die deel uitmaken van een applicatie.

Anderzijds kan men de term ook officieus gebruiken als bijnaam voor de zogenaamde Serverless diensten, of nog Function Platform as a Service (FPaaS). Via deze platformen kan men hele kleine stukjes code uitrollen zonder zich iets te moeten aantrekken van onderliggende infrastructuur, en deze aan te bieden via een kleine API. De granulariteit van de manier van ontplooien zorgt er daarbij voor dat men vaak nog kleiner kan gaan dan bij microservices. Uiteraard moet men erover blijven waken dat het zin blijft hebben om de functionaliteit zodanig in stukjes te kappen, wil men niet in het gelijknamig benoemde anti-pattern terechtkomen.

Serverless Architecture maakt momenteel grote furore in de public cloud en er zijn ook al enkele open source oplossingen om een dergelijk platform in het eigen datacenter op te zetten.

Besluit: Wat moeten we nu Bouwen?

De microservices architectuur is een zeer goede blauwdruk voor software ontwikkeling. De voordelen van wendbaarheid en flexibiliteit zijn een must voor bedrijven die goed willen kunnen inspelen op de markt en de klant, en een robuuste portfolio aan herbruikbare services willen uitbouwen.

De vereisten om aan échte microservices ontwikkeling te doen zijn echter erg hoog, en het is niet altijd noodzakelijk om zulke extreme flexibiliteit en schaalbaarheid te behalen. Vaak is het voldoende om de microservices architectuur eerder benaderend na te streven via het bouwen van zogenaamde miniservices. In de meeste gevallen is dit dan ook de aangewezen manier van werken.

Wanneer legacy toepassingen moeten worden ontsloten en er geen grote nood is aan het wendbaarder maken van deze applicaties, maar wel een ontsluiting via een goede API, dan kan het voldoende zijn om een services laag rond deze applicaties te bouwen en er op die manier een zogenaamde macroservice van te maken, die vanaf dan vlot mee kan integreren met de rest van de portfolio. Denk echter goed na of toekomstige wendbaarheid en flexibiliteit echt wel van minder belang zijn, alvorens dergelijke technische schuld (technical debt) te betonneren.

NanoServices, ten slotte, indien het niet om het anti-patroon gaat, zijn zeker iets waar men mee mag beginnen experimenteren. Het voordeel om zich niets meer van infrastructuur te hoeven aan te trekken en de beschikbaarheid en schaalbaarheid op een quasi magische manier cadeau te krijgen, is niet te onderschatten. In een toekomstige blog wordt er zeker nog teruggekomen op deze Serverless Architectures.

“Digitale Transformatie”

Wanneer men het tegenwoordig heeft over bovenstaand buzzword, zal men steevast een aantal technologische evoluties opsommen die een verregaande impact op onze wereld hebben, en bijgevolg ook op de business, (in het bijzonder de IT business). We denken dan Big Data + Analytics, Sociale Media, Cloud en Mobile; de zogenaamde “Nexus of Forces“.

Het is wel waar dat deze nexus nogal wat furore maakt, maar die kan dat, doordat er, onderliggend, een aantal andere technologische evoluties spelen, die het de software engineering wereld mogelijk maken om al deze krachten voldoende te ondersteunen. Evoluties die, als het ware, ervoor zorgen dat de software die deze nexus draaiende houdt, kan worden gebouwd en ontplooid op een beheersbare manier, zonder dat ontwikkelaars ten onder gaan aan de groeiende complexiteit. Een aantal van die evoluties vatten we hier nu samen onder de noemer “Vortex of Enablers”. (Over vele van deze technologieën hadden we het reeds eerder – volg de links voor meer informatie.)

Enablers 1 en 2: Verregaande Virtualisatie met Cloud & Containers

De Cloud is niet meer weg te denken, maar welke technologie gaat er precies achter schuil? Oorspronkelijk werden er enorme sprongen voorwaarts gemaakt door het virtualiseren van machines, en infrastructuur in het algemeen (IaaS). Maar nu zien we de platformen pas echt ook voor ontwikkelaars tot wasdom komen. PaaS platformen zijn, dankzij de verschroeiend harde introductie van Container technologie, uitgegroeid tot de virtualisatiekeuze bij uitstek. Het worden nu zelfs vaker en vaker in de eerste plaats “Container Platformen“. Momenteel zijn Containers niet meer weg te denken uit Software Engineering, en ze zijn ook een belangrijke enabler voor DevOps. Maar het verhaal zal hier nog niet eindigen. Aan de horizon duikt reeds een nog hoger niveau van virtualisatie op: het zogenaamde Serverless Computing (zie ook onze research radar).

Enabler 3: MicroServices

MicroServices zijn de manier bij uitstek waarmee we complexe IT systemen kunnen opdelen in vele kleinere en makkelijker onderhoudbare componenten. Ze zorgen ervoor dat we een verzameling van toepassingen kunnen bouwen die allemaal potentieel klant zijn van elkaar en elk hun stukje van het geheel uitvoeren. Daarnaast zijn ze typisch klein en onafhankelijk, waardoor ze ideaal zijn om uitgerold te worden via een container platform.

Enabler 4: Event Driven Software Engineering

Over Events hadden we het al uitgebreid in vorige blogs. In het algemeen merken we dat dit mechanisme aan populariteit wint om een dynamisch en snel veranderende wereld, die continu nieuwe data genereert, te kunnen vatten in IT.

Events lenen zich dan ook heel goed voor het capteren van data: alles wat in een computersysteem binnenkomt, kan namelijk worden gezien als een Event, en het gebruik hiervan als primaire databron is soms handiger dan wanneer men de ervan afgeleide data zou gaan bewaren. In een overheidscontext zien we bijvoorbeeld de notie van civic moments aan belang winnen, hetgeen eigenlijk niet minder dan business Events zijn voor overheidstoepassingen.

Enabler 5: Steeds Betere Web Raamwerken

Het venster dat de klant krijgt op een IT-toepassing, is de client. Het is dan ook enorm belangrijk dat deze goed is gebouwd en vooral handig is in gebruik. De meeste client toepassingen zijn momenteel webgebaseerd of mobiel, en ook in deze laatste categorie wint webtechnologie gestaag aan belang. Het trio Html, Css en Javascript blijft dan ook de manier bij uitstek om een eindgebruikerstoepassing te bouwen, en elk jaar zien we wel een nieuw raamwerk populair worden in deze wereld; raamwerken die het makkelijker maken om sneller grotere, complexere en mooiere toepassingen te bouwen. Daarnaast wordt deze technologie ook steeds beter ondersteund door de technologie die er aan server-zijde bij komt: we krijgen haast onbeperkte schaalbaarheid en robuustheid wanneer we toestandsloze webtoepassingen gaan hosten op container platformen, gebruik makende van microservices als backend, op hun beurt ontsloten door (vaak RESTful) API’s (en, waarom niet, werkend via node.js).

Enabler 6: API’s

Het aanbieden van een degelijke API is de ideale manier om de functionaliteiten van een IT systeem beschikbaar te stellen aan andere. API’s hebben reeds een hele evolutie achter de rug: eerst waren er vooral (taal-specifieke) programmatorische API’s, daarna werden componenten steeds beter interoperationeel dankzij eerst SOAP-, en daarna REST-gebaseerde API’s. Momenteel zijn er heuse API Management platformen, die, naast beheer van API’s, ook voor de interoperabiliteit van heel wat communicatieprotocollen kunnen zorgen.

Via API’s kan men een sterk hergebruik van data bekomen: gegevens die reeds verwerkt zijn door één toepassing, worden op die manier beschikbaar voor een hele resem andere; vaak zijn dit dan microservices, maar ook frequent client-toepassingen op het web. De API’s worden bovendien vaak ook aangeboden aan derde partijen en daarbij soms ook gemonetariseerd. Uiteindelijk ontstaat er een hele “API Economy”: meer en meer toepassingen ontstaan eenvoudigweg doordat de data die ze nodig hebben, reeds beschikbaar is, en makkelijk consumeerbaar via zo’n API.

De Vortex

De relaties tussen de verschillende opgesomde technologische evoluties hier beschreven, zijn duidelijk waar te nemen: dit blijkt reeds uit de tekst. Op dit moment hebben we dan ook een unieke smeltkroes: de effecten van deze enablers op software engineering versterken elkaar, en vormen zo het fundament van de vele zaken die er bovenop worden gebouwd: de digitale economie.