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.

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

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

De 3-tier Architectuur

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

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

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

De Moderne Architectuur, Deel 1

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

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

• Front-Facing API Ecosystem

  

   

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

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

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

  

Beschouwingen

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

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

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

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.

The following blog will explain both notions, highlight their similarities and differences and conclude with when to use them.

Introducing the “Contenders”

The Surprising Similarities

Even though so differently defined, these two technologies share some interesting traits!

1. Immutable System of Record

Blockchains are about immutable verified transactions. EDA is about events. Yet these two concepts, when saved into a database or other system of record, are very similar. “Events” can be seen as present on a blockchain: each transaction can be seen as a kind of event: “The event of doing a certain transaction”. These transactions also correspond quite well to real-world events: e.g. “On Monday at 12:05, Yasmin has given BTC 2 to Zeyneb” (where Yasmin and Zeyneb are pseudonyms). This transaction could be modeled as an event!

Similarly, Events – when properly implemented – should be immutable. This is part of their definition: they represent a certain situation occurring at a certain point in time. This is fixed and should not be changed by any further tampering. Future modifications of the situation are represented by new, different events (which may or may not undo the effect of the original event).

In blockchains, the immutability aspect of a transaction is inherent in the technology, the difference with events in it being enforced by the use of strong cryptography. This instead of the clean, sanitary programming and other security measures needed to keep events immutable throughout a system. In fact, events could even be recorded on a blockchain, saving them as transactions! Pushing the latter further, smart contracts also support events, and do this somewhat more directly. In a smart contract, events can be defined as the result of a function, and nodes can be made to look out for certain types of events, and react to them. Surprisingly, these events need not be saved on the blockchain itself (a hash of all function returns is saved instead). Our blockchain expert, Kristof, explains this in more detail in a previous blog.

2. Asynchronicity

Asynchronous Communication is used between the nodes in a blockchain network to transmit new blocks to other nodes. It happens when it happens: when there have been a number of transactions and a new block can be validated by one of the nodes.

In a similar manner, Events are propagated asynchronously to all interested parties within an EDA. There is no reply immediately following a request. Once a subscriber has registered to receive notification of a certain type of events, it will receive them whenever they happen, and as fast as the publisher, along with the underlying middleware and network, will allow.

So on a more abstract level, both of these technologies do the same thing: they use asynchronous communication to transfer information between nodes that are part of a (distributed) system. This allows the partaking systems to act more independently of each other, greatly enhancing the beneficial aspect of loose coupling in computer systems.

3. Eventual Consistency

Besides asynchronous communication, (which is related to this part), both technologies, to a certain degree, practice another principle in like manner: the principle of “eventual consistency”. Roughly, according to the CAP theorem, this principle means sacrificing some immediate Consistency in order to obtain Availability and Partition tolerance more cheaply.

The reason for this is that the network, as well as the individual nodes, can go down without causing a fatal error for the distributed system as a whole. When the part of the network of nodes that was down is back up, they will be made consistent with what has transpired on the online part of the network so far. This could, of course, take a while.

In any case, even when no parts of this network go down, it might take a while for a change to propagate throughout the entire system. Hence, the eventual state of consistency. This is ok, even for transactions, as long as mechanisms are in place to deal with any temporary inconsistencies.

In blockchain, eventual consistency is implied in the distributed and delayed transactional nature of the technology. It is a crucial part of the technology: blocks might take a while to propagate throughout the network, especially when using big blocks and extended networks. This, however, does not prevent the network from continuing to operate.

It is the same in an event driven system, but we have to do some extra work to achieve the same result. When we want great resiliency to failures, we have to make sure that, should a subscriber be out of the game for a while, it can “catch up” on the events it missed. Likewise, the event system should cache any events in case of network failure and keep trying to send them to all subscribers, until the connection can be re-established. There should also be some bookkeeping to see which subscribers haven’t received their events yet, and subscribers should mind if they receive events in correct order. Luckily, some of this work can be simplified, if we make events idempotent: this means receiving the same event twice has no additional side effects. Doubles are also easy for a subscriber to check, since events are unique and usually also have unique timestamps or IDs.

The Big Difference?

Obviously, there are some semantic differences: EDA is a way for services and applications to communicate, whereas blockchain technology is more about the security and storage of their transactions. But the main difference is the trust issue: blockchain allows transactions between parties having less than 100% confidence in the ability of the other parties to correctly handle the data. In the case of events, we have no cryptographic guarantee that the events we are transmitting will be handled correctly.

The Moral of this Story: Is there a winner?

I often see blockchain solutions being forwarded to enable and improve communication of certain “transactions”, or “information” – but we might as well just call these “events” – between different parties. Usually, greater resiliency to failures because of the distributed nature, the resulting interoperability between independent parties using the same blockchain technology, and the improved agility resulting from the asynchronous nature of the communication, are acclaimed as great and “new” benefits. This is partly what prompted me to write this blog. I feel that, in a lot of cases, these solutions would greatly benefit from relying on Event Driven Architecture (and other effectual design principles) instead!

So when should we use blockchain technology? The answer lies in the big difference: Trust. When tamperproof transactions are needed, because the communicating parties cannot fully trust each other or a central party; or when contracts need to be enforced cryptographically for the same reason, blockchain then becomes an ideal PART of the solution (but the system might still benefit from the use of events, among many other “digital transformation enabling” technologies). For a more detailed model on when or when not to use blockchain, see the decicion model made by my colleague.

In any case, these two technologies are both very important evolutions, but they are dwarfed in usefulness and transformation potential by another: Application Programming Interfaces. APIs increasingly form the basis of any good digital platform, and are the preferred way to let applications and services communicate, and businesses interoperate. The so-called API Economy has already grown vigorously, and this trend will not stop any time soon. Events may even be transmitted over APIs (an example being Google’s Pub/Sub API). And Blockchain platforms, of course, should also offer reusable APIs to allow their easy exploitation. More on APIs can be expected in future blog posts.

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

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

Een aantal voorbeelden:

1. Chipkaarten

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

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

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

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

      

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

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

3. Civiele “Half-Open” Data

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

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

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

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

Digitale transformatie

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

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

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

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

“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.

Er was eens… een metrorit. En voor metroritten heb je tegenwoordig een MOBIB-kaart nodig. Dit deed me terugdenken aan het verhaal van de smartcards, en hoe we er veel te veel nodig hebben… Bij deze dan het lang beloofde derde deel van dat verhaal.

Over Metro- en Treinkaarten

Onlangs moest ik na lange tijd nog eens de metro nemen. Ik wist dat mijn papieren kaartje met magneetstrip ondertussen niet meer geldig zou zijn: de overschakeling naar MOBIB is nu volledig doorgevoerd. De MOBIB-kaart is RFID technologie, waardoor je ze kan gebruiken door ze gewoon tegen een kaartlezer tegen te houden (je hoeft ze nergens in te steken). Meer over deze technologie kan je terugvinden in één van onze techno’s: Het ABC van RFID.

Nu, ik heb reeds een treinabonnement, en ook dit staat op een MOBIB-kaart… van de NMBS. Ik moest er dus achter zien te komen of ik deze ook voor de metro kon gebruiken. Na wat zoekwerk, zag ik dat ik online een account kon aanmaken bij de MIVB en dat ik een bestaande MOBIB-kaart kon koppelen aan mijn account. Wanneer ik dit echter probeerde, wist het systeem mij te vertellen dat mijn kaart niet gekend was, maar dat dit wel het geval zou zijn indien ik deze eerst kon opladen via één van de GO-machines in de metrostations.

Zo gezegd zo gedaan, en – wonder boven wonder? – dit werkte inderdaad zoals aangegeven: ik kon mijn NMBS-kaart gebruiken als houder voor het saldo van mijn metroritten, en ik kon deze kaart daarna ook effectief koppelen aan mijn online profiel bij MIVB. (Eén mankement: het resterend saldo aan ritten is niet zichtbaar; maar misschien is dit ook voor de eigen kaarten van MIVB geen feature? – graag een comment indien iemand dit weet!)

Wat leren we nu uit dit verhaal?

• Ten eerste, de technologische mogelijkheden om het probleem van het teveel aan kaarten in mijn portefeuille op te lossen, zijn reeds duidelijk aanwezig, maar, gezien het aantal kaarten dat ik nog nodig heb, is er nog geen verregaande implementatie gebeurd (zo is mijn abonnement bij De Lijn, verkregen via NMBS, nog steeds een stukje papier, en een koppeling met bijvoorbeeld de Belgische eID is nog steeds beperkt tot de occasionele online aankoop van een treinticket). Conclusie: nog steeds geen one card to rule them all…
• Ten tweede: de netwerken van MIVB en NMBS zijn voorlopig nog onvoldoende geïntegreerd om reeds bij de aanmaak van een nieuwe kaart bij één firma, rechtstreeks ook de nodige gegevens te versturen aan de andere. Op zich is dit soort integratie misschien nogal veeleisend, maar in deze nieuwe wereld van de IT, met zijn Cloud, zijn microservices, en vooral, zijn API economy, zijn er toch wel een aantal architecturen te bedenken waarin dit geen probleem zou mogen zijn. Het “only once principe” is echter vaak meer een verhaal van politiek en economie, dan van technologie.

“Card Management as a Service”

Ik zou hier graag reeds even vooruitblikken op een toekomstige blog, waarin ik de voordelen van een gescheiden beheer van gegevensnetwerken versus er van gebruik makende toepassingen wil toelichten: Stel dat we één instelling hadden die het beheer van de kaarten en de ermee gepaard gaande gegevens, netwerken en basisdiensten op zich nam, en dat de andere bedrijven, zoals de vervoersmaatschappijen in kwestie, van deze diensten gebruik maakten. Dit zou ervoor zorgen dat alles wat met kaarten te maken had, efficiënter zou kunnen worden gemaakt wegens schaalvoordelen, én dat de vervoersmaatschappijen zelf deze verantwoordelijkheid niet meer hoefden te dragen. Dit is eigenlijk precies één van de belangrijke verwezenlijkingen van Cloud, en, meer in het bijzonder, het “as a Service” verhaal, maar dan toegepast op chipkaarten. Daarnaast kan men het ook bekijken in een microservices en API context (“you build it, you run it”).

Hierover dus later meer. Waar ik het nu verder over wil hebben is de toekomst…

De Nabije Toekomst?

Vandaag is het reeds mogelijk om met je smartphone vervoersbewijzen aan te kopen, betalingen te doen, ja, zelfs jezelf te identificeren voor gebruik van overheidstoepassingen. Een toekomst waarin we geen kaarten meer nodig hebben, maar waarin deze volledig zijn vervangen door de smartphone, is dus zeker technisch realiseerbaar, en op lange termijn misschien zelfs realistisch. Het belangrijkste probleem hierbij is er één dat slechts langzaamaan kan worden opgelost: de logistiek van het on-boarden van alles en iedereen die nu nog met kaarten werkt, en van alles en iedereen die nu nog geen smartphone heeft. In een nog verdere toekomst zullen we misschien zelfs de portefeuille in zijn geheel kunnen afschaffen, indien we dit ook met het systeem van cash geld zouden doen!

Science Fiction

Wat als we dan nog eens een paar decennia verder in de toekomst kijken? We zien reeds nu zaken opduiken als bio-authentication, waarbij we onze vingerafdrukken, stem, gezicht, of zelfs context gebruiken om te authenticeren. Daarnaast doet men ook gericht onderzoek naar nanotechnologie, robotica, artificiële intelligentie, Internet of Things, … Allemaal zaken die ervoor zorgen dat technologie en ons lichaam steeds dichter bij elkaar komen en uiteindelijk zelfs kunnen worden samengevoegd.

Uiteindelijk zou het dan mogelijk worden dat de smartphone wordt vervangen door een scherm op de huid van onze arm (zie filmpje hierboven voor wat binnenkort al kan!), met alle nodige technologie netjes verborgen aan de binnenkant van ons lichaam! Sterker nog: het scherm zou evengoed virtueel voor onze ogen kunnen worden getoverd, dankzij technologie rechtstreeks in onze ogen of hersenen. Op die manier hebben we niets meer nodig: al het nodige dragen we steeds met ons mee, zoals we dat met ons lichaam doen. En onszelf identificeren om ons vervoersbewijs te legitimiseren, doen we door eens te wuiven.

Op zich een groot gemak, maar uiteraard is hier ook een duistere zijde aan verbonden: het zou wel eens heel moeilijk kunnen worden om “off-the-grid”, of “offline” te gaan, of om zonder al deze technologische snufjes te kunnen. Sterker nog: we zouden Big Brother scenario’s kunnen krijgen, of een regelrecht doembeeld, zoals in de film “In Time“. Maar goed: wat er met een technologie gedaan wordt, staat los van de technologie zelf (ook met een eenvoudige hamer kan je zowel bouwen als verwonden).

Besluit

Er staan ons nog een aantal wonderlijke technologische evoluties te wachten, maar er blijft vooral nog veel werk aan de winkel wat betreft het vereenvoudigen van het leven van de gewone burger, met al zijn chipkaarten, zijn smartphone en zijn muntjes van twee eurocent, en van alle administratie die daarbij komt kijken. Samenwerking, integratie, en het zo breed mogelijk invoeren van het only once principe zijn de boodschap.

Op termijn kan deze architecturale stijl de grenzen tussen verschillende applicaties gaan vervagen, om ze te transformeren tot een applicatie-ecosysteem bestaande uit vele herbruikbare, onafhankelijk uitrolbare en afzonderlijk schaalbare componenten.

De Geschiedenis van “Tiers”

De meest traditionele applicaties zijn monolithisch: één programma dat al zijn functies vervult zonder afhankelijk te zijn van externe hulpmiddelen. Lang geleden werden de meeste applicaties op deze manier gebouwd, en vandaag zijn heel wat desktop applicaties hier nog steeds voorbeelden van. Met de opkomst van netwerken en Database Management Systemen (DBMS), werd echter voor vele applicaties een meer component-gebaseerde uitrol nodig. Voor een gedistribueerde applicatie werd het b.v. nodig om een “client” en een “server” of “backend” te hebben, om op die manier een gebruiker toe te laten de applicatie op een andere plaats (op een andere machine) te gebruiken dan de plaats waar de kern van de applicaties zich bevindt (meestal ook met het doel om meerdere gebruikers gelijktijdig van de applicatie gebruik te kunnen laten maken). Dit wordt de “client-server” of “2-tier” architectuur genoemd. Voor applicaties, die aan geavanceerde I/O doen, werd het daarnaast ook noodzakelijk om de verantwoordelijkheid hiervoor bij een DBMS te leggen. Dit systeem wordt dan de “data tier” van de applicatie.

Uiteraard leidden deze twee architecturen reeds snel tot de zogenaamde “3-tier” architectuur, met een client tier en een backend die werd gesplitst in een tier voor de business logic en een data tier. Tegenwoordig zijn er vaak nog meer opsplitsingen mogelijk. In de context van web-applicaties zal men b.v. de client tier nog in twee delen splitsen: de eigenlijke client in de browser, en een “web tier” om de client via het web te kunnen aanbieden. Men zou deze laatste zelfs nog kunnen opdelen in aparte servers voor het statische en dynamische gedeelte van de applicatie. Ook wordt het mogelijk dat een applicatie meerdere verschillende databronnen gebruikt, of dat haar business logica verdeeld geraakt over meerdere tiers (b.v. application logic vs domain logic). Langzaamaan verdwijnt dan ook de notie van tiers (waarbij men een min of meer hiërarchische en lineaire relatie verwacht tussen de componenten), om plaats te maken voor een flexibeler systeem, waarbij de communicatie flexibeler vormen kan aannemen…

Tiers of Lagen?

De opdeling in tiers klinkt allicht bekend in de oren voor wie reeds met software architectuur bezig is, en doet ook denken aan de opdeling van een applicatie in lagen (“layers”). De beide termen, tiers en layers, worden soms zelfs als synoniemen beschouwd (zuiver taalkundig zijn ze dat ook, en in het Nederlands kunnen we ze beide vertalen als “lagen“). Dit is logisch: er is een grote similariteit tussen deze beide concepten, en bijgevolg is er dus enige verwarring aanwezig.

Lagen voorzien in een logische scheiding binnen de architectuur van een applicatie, waarbij het zaak is om tussen deze lagen, die functioneel gezien zo coherent mogelijk moeten zijn, een zo groot mogelijke onderlinge onafhankelijkheid te creëren (het zogenaamde “loskoppelen“). Ze hebben eerder als doel om functionele belangen (user interface (UI), applicatielogica, business logica, data access, etc.) gescheiden te houden en de applicatie aldus makkelijker onderhoudbaar te maken op lange termijn, doordat deze belangen apart benaderd kunnen worden. Tiers daarentegen, zijn fysiek gescheiden onderdelen van een applicatie, die apart van elkaar worden ontplooid, waardoor ze niet alleen het aparte onderhoud en de aparte ontwikkeling verder doortrekken, maar ook apart hergebruiken en schalen mogelijk maken.

De verwarring tussen de beide concepten ontstaat allicht omdat de logische layers in de praktijk zeer vaak corresponderen met de fysieke tiers: de UI zit in de client tier, de business logica zit in de logic tier, en de database-laag komt overeen met de data tier. De scheiding in losgekoppelde lagen is daarnaast de ideale manier om ervoor te zorgen dat tiers los van elkaar kunnen worden gedeployed. Daarenboven wordt het onderscheid ook vervaagd in de context van de Cloud: Tiers zijn dan wel fysiek gescheiden, maar door het gebruik van Cloud-technologie (IaaS of PaaS) kunnen ze evenwel worden gehost op dezelfde fysieke of zelfs virtuele machine. Ze zouden eenvoudig in verschillende Containers kunnen worden geplaatst (zij het JEE, Docker of andere containers).

Om te besluiten: layers vormen dus de bouwstenen van een applicatie op een logische manier, en beïnvloeden sterk de architectuur en het design ervan. Tiers, op hun beurt, definiëren de opdeling van een applicatie in onafhankelijk uitrolbare componenten. Ze hebben ook een sterke impact op de architectuur, maar eerder op het niveau van de interacties tussen de applicatie en andere systemen binnen een groter geheel, en op het niveau van de infrastructuur. Tiers kunnen moeilijk zonder layers: het loskoppelen van delen van de applicatie is nodig om ze apart te kunnen uitrollen. Beide zijn onontbeerlijk om de complexiteit van een applicatie in beheersbare blokken op te delen.

Richting Microservices

Over de interessante evoluties binnen applicatie-architectuur en lagen, kunnen we in de toekomst nog een blog schrijven. Vandaag ligt de focus op tiers, en hoe het opsplitsen van een applicatie in componenten en diensten verregaande gevolgen kunnen hebben voor applicatie-ecosystemen.

Ik heb het reeds in verscheidene blogs over applicatie-ecosystemen gehad, maar nagelaten het concept eenduidig te definiëren. Bij deze dan een poging tot definitie:

Een ecosysteem van applicaties is een groep applicaties (en gerelateerde IT entiteiten) die werken rond een gelijkaardig business domein, of die toebehoren aan eenzelfde organizatie (of beide). Soms betreft het zelfs groepen van applicaties die rond verschillende maar gerelateerde business domeinen werken. Typisch verwerken ze dezelfde of sterk gerelateerde gegevens, en vrij vaak interageren ze ook met elkaar, en/of worden ze gebruikt door dezelfde groep van eindgebruikers.

Hieruit volgt dat binnen een applicatie-ecosysteem er een groot potentieel (!) bestaat voor hergebruik. Of dit potentieel effectief wordt gehaald, hangt sterk af van gemaakte keuzes betreffende enterprise, applicatie en systeem-architectuur.

Een kritiek die is komen te ontstaan op de N-tier architectuur, is dat een applicatie nog steeds te geïsoleerd en self-contained is: alle business-logica zit vaak in één tier, alle persistentie-logica in een andere, etc. Men zou zelfs kunnen zeggen dat we de monolithische applicatie hebben vervangen door monolithische tiers! En dit terwijl applicaties steeds complexer worden en verregaandere behoeften hebben, zoals de integratie van business rules, taakbeheer en workflows; allemaal zaken die zo complex zijn, dat ze al een toepassing op zichzelf kunnen vormen.

Service Oriented Architecture (SOA) is een stap in de goede richting, maar historisch gezien richt deze methodiek zich op interacties tussen verschillende applicaties, binnen het ruimere opzicht van enterprise architectuur. Microservices nemen de ideeën van N-tier en SOA samen, en drijven ze naar een nieuw summum: elke aparte applicatie wordt nu beschouwd als zijn eigen mini-ecosysteem van onafhankelijk uitrolbare diensten, zich elk focussend op een verschillende business capabiliteit, zo klein gemaakt als maar kan (vandaar “micro”), en met zo min mogelijk gecentraliseerde orchestratie. Meestal heeft elke microservice – indien deze nood heeft aan persistentie – ook zijn eigen database (of een ander soort persistentiesysteem), die enkel en alleen voor deze microservice wordt ingeschakeld.

Deze stijl verhoogt sterk de Agility van SOA: de kleinere services kunnen meer cohesief op zichzelf staan, en intern zijn ze meestal ook eenvoudiger dan volledige applicaties typisch zijn. Daarnaast kunnen onderhoud en evolutie van alle microservices apart van elkaar worden beheerd. Dit alles maakt dat deze aparte microservices makkelijker te bouwen en onderhouden zijn dan de volledige applicatie (uiteraard kruipt er wel enig werk in het op een goede manier opdelen van de applicatie in verschillende microservices). Men kan zelfs zo ver gaan als volledige microservices te vervangen door nieuwere en betere: indien ze klein genoeg zijn, kan de kost gerechtvaardigd zijn om een dergelijk stuk software – huiver – weg te gooien.

Daarnaast wordt het voor ontwikkelteams ook mogelijk om flexibeler te kiezen welke technologie, welke talen en welke raamwerken ze zullen gebruiken om hun specifieke microservice zo optimaal mogelijk te implementeren. Ze zouden Java, Node.js, of eender welke andere technologie kunnen kiezen, zo lang ze maar overeenkomen over een gestandaardiseerd communicatiekanaal. Dit kanaal, op zijn beurt, zien we meer en meer evolueren richting RESTful APIs: een robuuste de facto standaard.

Deze evolutie wordt verder nog versterkt door de opkomst van Container technologie: deze zijn de infrastructuurplatformen van de toekomst (of zelfs al van vandaag), en zijn “lichter” en makkelijker inzetbaar dan virtuele machines, waardoor het kosten-effectief wordt om een groter aantal kleinere services te hosten i.p.v. een klein aantal zwaardere applicatie(s)(-tiers). De beide technologische evoluties werken op die manier hand in hand om de schaalbaarheid van applicaties te verbeteren op een fijnmazig niveau: elke microservice kan onafhankelijk van de andere worden geschaald, en via containers kan er voor worden gezorgd dat de eronder liggende infrastructuur, gebruikt door het geheel aan services, een betere match vormt met het evoluerend verbruikspatroon.

Microservices maken het mogelijk voor een organizatie om meer Agile te werken en cross-functionele teams te bouwen, gefocust op business capabiliteiten, i.p.v. teams gefocusd op specifieke IT functies (UI specialisten, middleware specialisten, DBA’s, …). Wanneer een applicatie monolithisch wordt gebouwd, is er vaak veel heen-en-weer “gedoe'” tussen verschillende teams nodig om cross-functionele zaken te implementeren, met het gevaar dat business logica doorsijpelt op plaatsen waar deze niet hoort te zitten (b.v. in de UI of de data laag). Een meer expliciete scheiding van de applicatie in service componenten maakt de grenzen duidelijker, zowel tussen de microservices als tussen de teams die ze implementeren, waardoor er meer onafhankelijkheid in het implementatieproces kan worden gestopt. Een meer servicegericht model van samenwerking wordt op deze manier mogelijk: teams worden klant van elkaar omdat hun producten klant zijn van elkaar.

Ecosystemen van Services

Binnen een applicatie-ecosysteem van enige omvang, is er altijd al op vele niveau’s de nood geweest aan integraties. Met een beetje geluk waren deze integraties gekend wanneer een applicatie werd gebouwd, maar vaak is het echter zo dat de nood aan integratie achteraf ontstaat, wanneer een applicatie reeds enige tijd in productie is. Integraties komen ook voor op het UI niveau, waar ze leiden tot portaal technologie en integration-at-the-glass. Of ze komen voor op het niveau van de data, wat vaak tot gevolg heeft dat een database wordt gedeeld tussen verschillende applicaties. Er zijn reeds verdienstelijke pogingen gedaan om al deze integraties op te vangen via middleware, maar zelfs de alomtegenwoordige Enterprise Service Bus (ESB) is geen panacee.

We kunnen nooit vrij zijn van de onverwachtheid van sommige integratie-behoeftes, maar microservices kunnen een aantal van de moeilijkheden helpen verminderen. Enerzijds komt dit door de standaardisatie van de communicatie tussen microservices. Anderzijds doordat business capabiliteiten dankzij deze architectuur worden opgedeeld in kleinere stukken, wordt het makkelijker om een component te gaan hergebruiken in een andere applicatie, en deze apart te schalen indien hij daardoor zwaarder belast wordt. Bovendien kunnen we applicaties op zo’n manier opsplitsen, dat hergebruik wordt aangemoedigd: er zullen enerzijds applicatiespecifieke microservices deel uitmaken van een applicatie, maar anderzijds zullen er ook microservices zijn die een bepaalde business problematiek of capabiliteit ondersteunen, die onafhankelijk is van applicatielogica; deze laatste zijn vaak in meerdere toepassingen nuttig. Verder kunnen we ook nog microservices hebben die verantwoordelijk zijn voor een bepaald deel van de persistentie-behoeften van de applicatie. Services zo klein dat ze data betreffen die ook door andere applicaties gebruikt wordt. Deze “data services” zullen de poortwachters zijn van de data: zij encapsuleren de databases (of maken deel uit van een algemenere Data as a Service aanpak) en hebben meerdere applicaties als klant.

Uiteindelijk leidt deze opdeling in services tot een heel ander ecosysteem: niet één van monolithische of tiered applicaties, maar één van intergeconnecteerde microservices. En deze grote groep microservices kan dan “ten dienste” staan van specifieke “client”-componenten die een UI bevatten en dus de gebruikers toelaten dit ecosysteem te gebruiken op verschillende manieren. Dezelfde achterliggende dienst kan bijvoorbeeld een rol spelen binnen een web-toepassing, maar ook in een mobiele toepassing.

Eén probleem is dat deze sterke interconnectiviteit tussen een steeds groter wordende groep microservices kan gaan lijken op een onbeheersbaar kluwen (zogenaamde point-to-point integraties). Er zijn echter een paar zaken die dit effect tegengaan:

• Enerzijds is de point-to-point integratie slechts een integratie op conceptueel niveau. Op technisch vlak zal dit worden opgevangen door middleware-technologie, zoals de ESB. Zolang een dienst een logisch en leesbaar adres heeft, kan deze op die manier worden aangesproken. De werkelijke localisering en verbinding is de verantwoordelijkheid van een onderliggend platform.
• Daarnaast kan men ook twee reeds eerder besproken principes toepassen: die van Data-Centric IT, en die van Event-Driven Architecture. Deze zijn compatibel met elkaar en met Microservices, en zorgen samen voor een beheersbaar “inter-service” communicatiemodel: samen kunnen deze methodieken er namelijk voor zorgen dat een dienst enkel moet weten welke data en events er nodig zijn en hoe deze kunnen worden geadresseerd. Er zijn uiteraard nog externe zaken nodig die geen data of Event zijn, maar dit zijn dan meestal generieke en nuttige diensten, zoals het genereren van pdf’s of het aanroepen van eerder technische capabiliteiten, zoals authenticatie of logging.
• Ten slotte komen er specifiek voor deze problematiek ook oplossingen te voorschijn onder de noemer van API management. De publieke interface van een microservice kan namelijk gezien worden als een API (Application Programming Interface). Naast het beheer van een veelvoud aan APIs, richten deze platformen zich ook vaak op het beheer van de levenscyclus van de erachterliggende diensten.

Besluit

Microservices zijn als deployment architectuur een perfecte match voor Agile software ontwikkeling, en verankeren de goede principes van Service Oriented Architecture. Ze maken het mogelijk software op een flexibeler manier te ontwikkelen, met vele kleine componenten, waardoor er sneller kan worden ingespeeld op veranderende behoeften. Ze laten herbruikbaarheid toe op een fijnmazige manier, en verhogen de efficiëntie in het gebruik van resources. Ook met de huidige ontwikkelingen op vlak van infrastructuur: Containers, gaan ze heel goed samen. Samen daarmee, en met EDA en REST, vormen ze een blauwdruk om een applicatie-ecosysteem future-proof op te bouwen.

Data Centric IT

De meeste informatici weten wel wat data is, en wat databases zijn, maar zijn toch vooral ‘opgevoed’ met een focus op applicaties, algoritmes, enz. De applicatie is uiteraard erg belangrijk: ze verricht het nuttige werk van een computersysteem. Toch moeten we dit nuanceren. Een applicatie is eigenlijk enkel een hulpmiddel voor het manipuleren van de data. Als we er eens bij stil staan, dan komen we tot de vaststelling dat nagenoeg elke applicatie die we kennen, dient om data uit te lezen, in te voeren, mooi/anders weer te geven of te bewerken. Dit geldt zowel voor eindgebruikersapplicaties als voor applicaties die enkel I/O doen (b.v. de zogenaamde ‘batch’ applicaties). Dus eigenlijk is de data de centrale asset van een IT-systeem!

Dan kunnen we ons de vraag stellen of we hier bij het ontwikkelen van de architectuur van computersystemen niet meer rekening mee zouden moeten houden? We kunnen de data voorop stellen als centrale entiteit bij de communicatie tussen verschillende applicaties en gebruikers, en ook binnen verschillende subsystemen binnen applicaties. Doen we dit consequent, dan evolueren we stilaan naar een Data-Centric aanpak van IT.

REST

REST staat als acroniem voor ‘Representational State Transfer’. Deze wijze van data-overdracht heeft een aantal verschillende eigenschappen, waaronder dat men heel eenvoudig via http(s!) en via gebruik van eenvoudige principes als CRUD (Create – Read – Update – Delete) verschillende systemen kan laten communiceren. Voor de rest ga ik hier niet meer verder over uitweiden in deze blog, behalve één belangrijke eigenschap: een goedgemaakte REST API biedt een zelf-descriptief overzicht op data (zogenaamde resources), en niet op methodes. (Voor een mooie en praktische uitleg over REST, kan ik verwijzen naar stackoverflow en ook naar deze leuke.)

Men kan dit principe nog anders uitleggen: de namen die men aan de functies geeft die men in een REST API (Application Programming Interface) kan oproepen om een resultaat te bekomen, zullen geen werkwoorden zijn, maar naamwoorden. Een voorbeeld maakt dit een stuk duidelijker:

Nemen we een applicatie die als één van haar functionaliteiten een lijst van personen/gebruikers beheert. Het is de bedoeling dat andere applicaties personen kunnen zoeken, opvragen, toevoegen, veranderen en verwijderen. In plaats van op de traditionele manier een programmatorische  API of een SOAP (Simple Object Access Protocol) webservice aan te bieden, openen we via een RESTful webservice een raam op de door de applicatie beheerde gegevens. Dit ziet er dan b.v. als volgt uit:

• “GET www.app.be/rest/user”: geeft alle beheerde personen (meestal geeft men daarbij slechts een beperkt aantal gegevens per persoon)
• “POST /user” (we laten het eerste deel van de url vanaf nu achterwege, dit is altijd hetzelfde): laat toe om de gegevens voor een nieuwe persoon door te sturen.
• “GET /user/100023”: geeft detailgegevens over persoon met volgnummer 100023

Het is dus eigenlijk alsof je rechtstreeks in een hiërarchische structuur van je gegevens alle nodige bewerkingen kan uitvoeren. Uiteraard zal de achterliggende applicatie niet zomaar alles toelaten: ze zal nog steeds verantwoordelijk zijn voor controle op input, en voor authenticatie en autorisatie van de systemen die van de RESTful service gebruik maken. De beveiliging in een dergelijke aanpak gebeurt best volgens de principes van Data-Centric Security, daar deze als van nature in een dergelijke Data-Centric Architecture thuishoren.
Uiteindelijk kan veelvuldig toepassen van RESTful principes om applicaties aan te sturen, leiden tot een mooi Data-Centric Ecosysteem, waar de principes van deze architectuur doorgetrokken zijn over een groot aantal verschillende applicaties: In plaats van elke applicatie nog een aparte url te geven, zal men eerder een algemene url opzetten voor de data binnen de gehele groep samenwerkende applicaties (e.g. ‘data.socialsecurity.be’ zou dit kunnen zijn voor alle applicaties binnen de sociale zekerheid). Vele applicaties samen, elk verantwoordelijk voor hun stukje van de hiërarchie, zullen instaan voor deze ene grote RESTful data API, en alle applicaties zullen er op hun beurt weer gebruik van kunnen maken, zonder dat ze zich iets hoeven aan te trekken van waar de data vandaan komt of naartoe gaat (of door welke applicatie ze wordt beheerd). De applicaties hoeven elkaar op deze manier niet meer te kennen of te adresseren; ze hebben enkel het adres nodig van de data. In een enterprise omgeving zal men typisch gebruik maken van een ‘API management suite‘ om zo’n RESTful API, of groep ervan, te beheren.

Men kan het toepassen van dit principe ook zien als een vorm van Data Virtualization, aangezien men services aanbiedt om de data, die normaal gezien in onderliggende databases zit, virtueel te ontsluiten. Indien men deze architectuur via Cloud-technologie implementeert, kan men het ook zien als een vorm van Data-as-a-Service (DaaS). Wanneer men de data ook aanbiedt aan externe partijen, kan het eventueel gaan om Open Data.

Het doortrekken van deze architectuur over de gehele organisatie, of zelfs over meerdere samenwerkende organisaties, kan sterke synergieën teweeg brengen, doordat de data voor alle applicaties éénvormig beschikbaar wordt, en doordat het gemakkelijker wordt om reeds door RESTful services ontsloten data te gaan hergebruiken vanuit meerdere applicaties. Dit leidt uiteindelijk tot wat men noemt, een bloeiende ‘API economy‘. Uiteraard is een goede governance over de data, een Enterprise Information Model, en een sterk Master Data Management van belang om hiermee echt succesvol te zijn.

Communiceren via REST of via EDA ?

Via RESTful services kan je dus in principe alle applicaties die dit vereisen, met elkaar laten communiceren. Dezelfde mogelijkheden heb ik echter eerder al voorgesteld in de context van Event Driven Architecture (EDA) in twee eerdere blogs (basis en geavanceerd). Je kan je afvragen of dit niet redundant is, of welke van de twee nu de beste oplossing is?

Het antwoord is – je had het allicht zien aankomen – dat beide oplossingen hun plaats hebben in een gedistribueerd ecosysteem. Events werken namelijk typisch asynchroon, terwijl REST synchroon kan worden gebruikt. Dit betekent dat een applicatie onmiddellijk op de hoogte kan worden gebracht, indien er een voor haar interessant Event beschikbaar is. Indien de applicatie echter meer data nodig heeft, die zich niet in een beschikbaar huidig Event bevindt, dan kan het deze gaan opvragen d.m.v. het gebruik van een RESTful service. Het besluit is dus dat we Events kunnen gebruiken om nieuwe gegevens zo snel mogelijk over het netwerk te verspreiden, naar alle belanghebbenden, en dat we RESTful services kunnen gebruiken om reeds gekende informatie universeel ter beschikking te stellen op het netwerk, waar alle geïnteresseerden ze kunnen gaan raadplegen. Een mooi complementair geheel dus – en het goede nieuws is dat de beide benaderingen meestal ondersteund kunnen worden door één en dezelfde onderliggende middleware technologie (typisch, de ‘Enterprise Service Bus‘ (ESB) ).

Besluit

Net zoals REST, passen Events heel goed in een Data-Centric Architectuur: Events, zeker business Events, zijn namelijk ook data, en een belangrijke informatiebron voor Analytics. Samen met REST hebben we dus de twee stukken van de communicatiepuzzel binnen Data-Centric IT volledig in handen.