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

REST: de gouden standaard

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

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

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

De pure API aanpak

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

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

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

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

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

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

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

Richting asynchrone communicatie

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

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

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

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

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

Standaarden voor Asynchrone APIs

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

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

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

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

De gebalanceerde aanpak: APIs plus Events

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

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

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

Een aantal extra opmerkingen betreffende deze manier van aanpakken:

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

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

Conclusie

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

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

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

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

Wat is Reactive alweer?

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

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

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

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

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

Het Akka raamwerk

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

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

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

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

Een voorbeeld

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

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

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

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

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

Besluit

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

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

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

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

Een Beetje Geschiedenis

Het “Reactive” Manifest

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

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

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

Functional Reactive Programming

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

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

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

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

Reactive voor Reactive

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

Hoe is dit nu Beter?

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

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

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

Verschil met Event Driven Architecture?

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

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

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

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

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

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

Besluit

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

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

Interessante bronnen

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

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

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

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

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

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

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

_________________________

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