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.

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

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

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

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

Serverless = Event Driven

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

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

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

Voor- en Nadelen

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

Pay Per Use

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

Schaalbaarheid en Elasticiteit

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

Veiligheid

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

Eenvoudige Ontwikkeling, Complex Beheer

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

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

Conclusie

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

_________________________

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

Hergebruik: het gebruiken van een bestaand stuk software voor een nieuwe toepassing.

Het lijkt een eenvoudig principe, maar er komt meer bij kijken dan je zou denken. Vooral wanneer je effectief een software artefact probeert te hergebruiken, creëer je al snel problemen. In deze blog gaan we wat dieper in op dit ogenschijnlijk simpele productiviteitsprincipe.

In mijn blog over Microservices van eind 2017 had ik het reeds kort over “re-use” als een antipatroon: dit ging vooral over hergebruik van code versus hergebruik van grotere componenten, zoals b.v. een API met een daarachterliggende microservice. Dit is een belangrijk voorbeeld van een breder principe: men moet goed weten op welk niveau van modulariteit men hergebruik wenst toe te passen.

Verderop in deze blog gaan we dieper in op drie assen volgens welke we afwegingen zullen moeten maken om te besluiten in welke mate we hergebruik zullen nastreven en toepassen: Het niveau van granulariteit, het niveau van abstractie, en het niveau van functionaliteit.

Daarnaast is het ook zo dat hergebruik maar kan op 2 voorwaarden:

• Er bestaat een dienst, module, bibliotheek, … kortweg, een software artefact, dat herbruikbaar is.
• We gebruiken een methodologie van software ontwikkeling die ons toelaat zaken te hergebruiken. Dit wil zeggen dat we enerzijds in staat zijn om de herbruikbare component te vinden en dat we er toegang toe hebben (en dat deze voldoende is gedocumenteerd), en we anderzijds een architectuur toepassen in de doeltoepassing die toelaat het bestaande artefact ook daadwerkelijk in te zetten.

In deze blog zullen we ons focussen op principes rond het bouwen van herbruikbare artefacten, en dus niet op het tweede aspect: het beheren en gebruiken van een patrimonium van herbruikbare software componenten. Verder gaan we ook niet dieper in op zaken die gerelateerd zijn aan hergebruik, zoals bv. het gebruiken van een gedeelde infrastructuur of het vinden van allerlei synergieën op ándere vlakken.

Spanningsvelden bij het Beschouwen van Hergebruik

Zoals reeds aangehaald, zal mogelijk hergebruik van een software artefact afhangen van een aantal verschillende factoren. Telkens zal er een zeker spanningsveld heersen en zal er een middenweg moeten worden gevonden, die van project tot project of van artefact tot artefact kan verschillen.

Niveau van Granulariteit

De grootte van het software artefact dat we willen hergebruiken, heeft een grote invloed op de mogelijke impact van het hergebruik: het is uiteraard voordeliger als we ineens een volledige, kant-en-klare service kunnen hergebruiken, die duizenden lijnen code encapsuleert, dan wanneer we enkel en alleen, op het niveau van de code, een bepaalde functie van een paar regels code kunnen hergebruiken. Nochtans hebben ze elk hun eigen kracht. Alle artefacten die we gebruiken moeten worden onderhouden; doorgaans is de kost die hiermee gepaard gaat evenredig met de grootte. Daarnaast is het zo, dat men een kleiner bouwblok, indien goed gekozen, vaker zal kunnen hergebruiken dan een groter.
Het spreekt voor zich dat, hoe meer zaken men in één component verpakt, op hoe meer manieren deze component kan hergebruikt worden, maar tegelijk hoe omslachtiger het wordt om dit ook effectief te doen, omdat je teveel bagage meesleept. Beter is het om componenten zo klein mogelijk te houden, zodat ze één functionaliteit aanbieden, en deze kleine componenten dan op zoveel mogelijk plaatsen te gaan inzetten. Hier is echter weeral een spanningsveld: hoe meer componenten er bestaan, des te moeilijker wordt het om te weten dat ze bestaan (en om ze terug te vinden, dus). Kleine componenten bieden daarnaast echter nog vele andere voordelen (bv. microservices en agility, zoals beschreven in de blog daaromtrent).

Maar ook de context van het hergebruik speelt een rol bij overwegingen betreffende de grootte van de component: de functie van een paar regels code: zullen we deze enkel hergebruiken binnen eenzelfde project? Of als deel van een bibliotheek of raamwerk dat nog door vele andere projecten kan worden gebruikt? Hier zat de essentie van het verhaal bij microservices: men moet goed waken over de onfhankelijkheid van deze wonderen van de moderne architectuur: wanneer twee microservices gebruik maken van eenzelfde stuk code, heeft men in principe een afhankelijkheid gecreëerd tussen de beide.

Mate van Abstractie

De mate van abstractie van software kan sterk variëren. Men kan een stuk software bouwen, nauwelijks parametriseerbaar, specifiek voor één welbepaalde taak. Dit zal nauwelijks herbruikbaar zijn. Maar indien men te ver probeert te gaan in de mate van abstractie die een stuk software aanbiedt, krijgt men uiteindelijk iets dat onbruikbaar is voor het oorspronkelijk doeleinde, omdat het zo generisch is, dat er nog heel veel werk bij komt kijken om het als dusdanig te parametriseren aan het doel waarvoor het werd ontworpen. Bovendien is software met een hoge mate van abstractie vaak ook moeilijker te begrijpen voor ontwikkelaars. Hier komt het er dus op neer een gouden middenweg te vinden: voldoende abstractie, zodat er binnen het business domein, en zoniet op een technisch vlak, nog enige kans bestaat op later hergebruik, maar niet teveel, zodat het artefact nog voldoende snel en eenvoudig inzetbaar is voor het oorspronkelijke doel. Daar komt dan wel nog een tweede spanningsveld roet in het eten gooien: dat van kost versus mate van abstractie. Een stuk software op een meer generische manier ontwerpen, vraagt doorgaans meer resources en een langere ontwikkeltijd dan om iets te bouwen voor één welbepaald doel. Men kan dus niet tegelijkertijd van een team van ontwikkelaars verwachten om zoveel mogelijk kostenbesparend te werken en enorm veel functionaliteit op te leveren tegen strakke deadlines, en tegelijkertijd geweldig herbruikbare (en onderhoudbare, robuuste, stabiele, … ) producten af te leveren.

Hoogte in de functionele stack

Een afgewerkte software, gebouwd voor een specifiek doel, met een eigen UI, is ongeveer wat als het hoogste in de “functionele stack” beschouwd kan worden. Dit is nauwelijks herbruikbaar, want purpose-built (met een grote uitzondering voor SaaS-software). Lager in deze stack vindt men business-domein-specifieke bibliotheken en APIs. Deze zijn, binnen een bepaalde context, al een stuk herbruikbaarder (maar niet onmiddellijk functioneel inzetbaar zonder er iets vóór of rond te bouwen). Nog lager in de stack vindt men zaken die over domeinen heen herbruikbaar zijn: database software, cloud platformen, algemene software libraries en raamwerken. De laagste elementen in de stack, daar denken we zelfs al niet meer bij na wanneer we ze hergebruiken: het gaat om constructies die in bijna alle programmeertalen voorkomen (gegevensstructuren zoals arrays, ondersteuning voor reguliere expressies, etc.).

Bedrijven die een sprong maken naar een Cloud Platform, maken typisch ook een sprong in herbruikbaarheid wat betreft het niveau in de functionele stack. Het gebruik van zaken als virtualisatie zorgt er bv. voor dat het veel sneller gaat om infrastructuur te koppelen aan een applicatie en dat deze koppeling ook bruikbaar is voor gelijkaardige applicaties (door de configuratie van zo’n machine te hergebruiken). Hogerop in de stack laat een platform als Kubernetes en het gebruik van containers toe dat men software images van over de hele wereld, en bovendien ook de eigen images, kan hergebruiken.

Wat kan ons Helpen?

Kunnen we nu doorheen de anaylse van deze verschillende dimensies van hergebruik een rode draad trekken? Op welke manier zullen we het vaakst “de gulden middenweg” kunnen exploiteren? Hier speelt de gebruikte methodologie van software ontwikkeling een rol, en zeker ook de architectuur van zowel het mogelijks herbruikbare artefact en van de doeltoepassing. Moderne architecturale principes hebben hier vrijwel altijd een streepje voor, en de software industrie blijft hierin innoveren. Modulariteit is één van de sterkste drijvende krachten (ik verwijs opnieuw naar microservices, en nu misschien ook al naar FPaaS).

Over MicroServices en APIs

Ik heb nu reeds tweemaal modulariteit en microservices aangehaald, maar daar moet wel een serieuze kanttekening bij worden gemaakt.

Microservices zijn OP ZICH NIET herbruikbaar. Het zijn de APIs die men rond diensten bouwt, die herbruikbaar zijn door andere zaken.

Van cruciaal belang is dus het ontwerp van deze APIs, rigoureus volgens standaarden (REST) die nog eens zijn versterkt door een weldoordachte huisstijl (of beter nog, “sector-stijl”). Daarnaast moet men bij het ontwerpen van deze APIs goed rekening houden met de hierboven beschreven mate van abstractie en hoogte in de functionele stack. Bovendien moeten de APIs ook bekend zijn, en toegankelijk zijn. Het laatste vergt goed API management en sterke documentatie (en “kruisbestuifmensen” die kunnen fungeren als katalysatoren, overheen projecten), en ook een vlot proces van het ter beschikking stellen van APIs. Bij dit laatste spelen zaken zoals GDPR uiteraard een rol, maar spijtig genoeg ook af en toe politieke redenen (men wil soms te hard zijn “eigenaarschap” over bepaalde diensten of data behouden, en men belemmert om deze reden het hergebruik; of nog vindt men van zijn eigen systemen dat deze “te uniek” zouden zijn om in een hergebruik-kader te functioneren). Ten slotte is het ook van belang dat de systemen die schuilgaan achter de APIs, voldoende schaalbaar zijn, zodat ze bij toenemend gebruik nog kunnen volgen.

Wanneer we over APIs spreken, spreken we hier dus over het hergebruik van (werkende) diensten. Dit is de belangrijkste vorm wat betreft zelfgemaakte software artefacten. Het hergebruik van (eigen) code is iets totaal anders. Dit kan zelfs contraproductief zijn: één van de krachtigste eigenschappen van microservices binnen een moderne architectuur, is hun onderlinge onafhankelijkheid: een microservice moet volledig op eigen benen kunnen staan (eigen werking, eigen logica, eigen data(-base), eigen (deeltje van de) infrastructuur, … De enige connectie met de buitenwereld is via Events (zie verder) en een API ! ). Daarnaast maakt men ze zo klein mogelijk. Dit maakt ze enorm flexibel (“agile”): men kan ze apart van andere zaken onderhouden, aanpassen, vervangen (vandaar ook dat ze klein moeten zijn, “rip-and-replace” mag niet teveel kosten). Deze flexibiliteit maakt het mogelijk voor een softwarebedrijf om enorm snel op veranderende behoeften van de business in te spelen, doordat het geheel aan microservices continu en heel snel kan evolueren zonder volledig offline te gaan of langdurige aanpassingsprojecten en redeployments te moeten ondergaan. Welnu, vermits microserives zo onafhankelijk mogelijk van elkaar moeten zijn, kan het soms contraproductief zijn om zaken (niet alleen code maar bv. ook een bepaalde database) te gaan hergebruiken tussen meerdere microservices. Dergelijk hergebruik creëert afhankelijkheden en verplichtingen die de wendbaarheid van een microservice doen afnemen! Enkel zeer algemeen inzetbare bibliotheken (typisch 3rd party, vaak open source) vormen goede kandidaten om binnen een microservice herbruikt te worden; deze zitten typisch iets lager op de functionale stack dan het (business) domein waar de microservice rond is opgebouwd.

Event Driven Architecture

In deze context komen we best ook terug op Event Driven Architecture. Events zijn één van de datastructuren die men het dichtst bij de werkelijkheid kan doen aanleunen. Het gaat om een opdracht of aangifte of aanvraag die binnenkomt, een gebeurtenis uit de echte wereld die men modeleert, een bepaald gegeven dat beschikbaar wordt, een verandering van een reeds gekend gegeven, …
Deze zaken kunnen allemaal veel letterlijker gemapt worden op de werkelijkheid, dan wanneer ze eerst reeds binnen een bepaalde context (meestal de toepassing via dewelke ze het eerst worden ingevoerd) worden verwerkt. Hoe dichter deze informatie aanleunt bij de werkelijke wereld, hoe herbruikbaarder ze is voor andere zaken. Hetzij andere toepassingen die reeds bestaan en anders moeten wachten tot de data (soms in batch) wordt doorgestuurd of kan worden opgehaald via API, hetzij toepassingen die men pas zal bedenken doordat de events al bestaan (het zogenaamde kruisbestuiven binnen een applicatie ecosysteem).

Zaak is dus van events heel goed te ontwerpen, vooral op het niveau van business events, en van deze meer en meer te gaan (her-)gebruiken. Naast mogelijk hergebruik heeft dit ook een mooie standaardisatie tot gevolg in de manier waarop applicaties (asynchroon) communiceren en data geprolifereerd wordt binnen een netwerk van toepassingen, en bovendien krijgt men de data op die manier veel sneller op alle plaatsen waar men ze nodig heeft, waardoor men op business niveau veel sneller kan reageren en flexibeler kan zijn. Goede documentatie van de events die men reeds heeft gedefiniëerd is dan uiteraard heel belangrijk. Ten slotte heeft men via events automatisch de volledige geschiedenis van de gegevens en niet alleen van de huidige toestand. Deze geschiedenis kan eveneens hergebruikt worden bij o.a. het aanpassen en testen van toepassingen, het ontwikkelen van nieuwe zaken, en verregaande analyse (evt. ook voor het trainen van een AI)

Besluit

Wanneer men praat over herbruikbaarheid, is het belangrijk te verduidelijken of men het nu over code, dan wel APIs, diensten, componenten, infrastructuur of volledige software-pakketten gaat hebben. Samenvattend komt dit neer op het definiëren van de modulariteit, de mate van abstractie en de hoogte in de functionele stack van hetgeen men zou willen hergebruiken. Daarenboven moet men de afweging maken tussen de herbruikbaarheid van een artefact en de kostprijs om het te bouwen en onderhouden.

Indien men met al deze aspecten rekening houdt, kan men besluiten dat hergebruik niet altijd alleszaligmakend is en dat het soms zelfs contraproductief kan zijn. Het belangrijkste hergebruik zal zich vaak ook niet op het niveau van de code bevinden.

Wat applicatie architectuur in het algemeen betreft, maar dan nu specifiek toegepast op herbruikbaarheid, kunnen we daarnaast besluiten dat APIs (ondersteund door microservices, uitgerold op containers) en Event Driven Architecture een grote meerwaarde kunnen bieden.

Verdere resources:

• Een boek over het hergebruik van software: https://vijaynarayanan.gitbooks.io/art-of-software-reuse/content/
• Over de val van genericiteit en ‘super’-libraries, en de voordelen van modulariteit: http://josdejong.com/blog/2015/01/06/code-reuse/
• Over de valstrikken van “code reuse” en hoe management dit echter meestal ziet: https://blog.ndepend.com/code-reuse-not-good-goal/
• Over de kost van hergebruik: https://dzone.com/articles/economics-reuse
• Bedenkingen bij extreme programming, een methodologie dewelke “design for reuse” eigenlijk afraadt: https://www.infoq.com/news/2009/04/agile-code-reuse
• Talk van Rob Pike, met de quote “A little copying is better than a little dependency” (code reuse zorgt voor dependencies!): https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s
• Martin Fowler over, o.a. , reuse: https://martinfowler.com/bliki/Seedwork.html
• Methodologische tips voor hergebruik: https://www.infoq.com/articles/vijay-narayanan-software-reuse
• Hoe reuse aanpakken op bedrijfsniveau: http://www.cs.cmu.edu/afs/cs/usr/ppinto/www/reuse.html

Deze blog is het tweede deel van een reeks, waarin we een aantal mogelijkheden die ons worden geboden door goede architecturale principes en technologieën, zullen toelichten. Een aantal van deze zaken werden ook reeds in vroegere blogs besproken, en de meeste worden ook nog eens samengevat in de blog “Vortex van Enablers“. De eerste blog van deze reeks beschouwde de gedeeltes van een applicatie-architectuur die de gebruikersinterface en externe clients ondersteunen: Architecturale Evoluties, deel 1.

In dit deel duiken we dieper in de applicatie, en zullen we beschouwen hoe we de interacties met onze applicatie verder kunnen afhandelen. Interacties kunnen via allerlei wegen onze applicatie binnenkomen (b.v. aanvragen vanuit een GUI, requests via een extern-gerichte API, maar ook interne, geplande acties die op bepaalde momenten worden gestart). Voor de binnenste onderdelen van de architectuur is dit onderscheid echter van minder belang. Wel belangrijk is of het gaat om een vraag om output te genereren (dit zullen we een query noemen), of dat het eerder gaat om nieuwe input (vaak een command genoemd, maar dit komt eigenlijk overeen met een Event). Soms zijn deze beide vormen gecombineerd (er is nieuwe input, die op zich al tot nieuwe output moet leiden), maar vaak is het mogelijk om deze aspecten in de verwerking van de interactie voldoende gescheiden te houden.

De Moderne Architectuur, Deel 2

In het eerste deel van deze blogreeks beschreven we reeds hoe alle externe interactie met onze applicatie kon worden herleid tot het oproepen van Restful APIs, die we konden aanbieden via één of meerdere microservices. In dit tweede deel kunnen we ons daardoor volledig focussen op de interne werking van een collectie microservices, die samen een applicatie (of een groep van applicaties) ondersteunen. Dit is een radicale breuk met de meer traditionele 3-tier of n-tier architecturen van weleer. Gartner heeft deze nieuwe trend de naam “MASA” gegeven, wat staat voor Mesh App and Service Architecture: een zeer modulair and flexibel aanpasbaar netwerk van oplossingen die de dynamisch veranderde behoeften vanuit de business snel kunnen opvangen.

Eén opmerking die we voor de volledigheid nog moeten maken, is dat het in deel 1 om interactie met écht externe zaken ging, zoals de clients en 3rd party applicaties. Dit leidt er doorgaans toe dat we sterk gestandaardiseerde interactievormen via het web zullen gebruiken (waardoor vrijwel enkel REST APIs kunnen worden beschouwd). Integratie binnen het eigen ecosysteem kan echter, naast APIs, ook nog via de Event Bus gebeuren, die op zich gebouwd is bovenop het principe van asynchrone uitwisseling van berichten tussen de services. Dit duale principe (synchroon REST kanaal en asynchroon event kanaal, ook reeds toegelicht in de blog over Data Centric IT) moet volstaan om alle communicatie tussen de verschillende onderdelen van een applicatie (of ecosysteem) in goede banen te leiden. Op zijn beurt laat deze ogenschijnlijke beperking toe om de technische kant van het verhaal te standaardiseren.

• Een woordje over de MASA

Zoals reeds gezegd, staat MASA voor “Mesh App & Service Architecture”. Het woordje “mesh” (= een fijnmazig net) betekent dat de huidige architectuur uit vele aparte onderdelen zal bestaan, die via steeds veranderende configuraties met elkaar communiceren. Het model dat we in deze blogreeks uit de doeken doen, namelijk een ecosysteem van samenwerkende microservices, communicerend via Event Bus en RESTful APIs, is daarbij eigenlijk nog een eenvoudige versie. In de praktijk zal men evolueren naar ingewikkelder patronen, waarbij in deze mesh ook legacy toepassingen zullen verweven zitten, alsook zaken die in de Cloud draaien i.p.v. op het lokale netwerk, afzonderlijke functies die volgens het zogenaamde “Serverless” principe werken, en zelfs IoT devices. Dit soort gemengde architectuur ontstaat doordat vele organisaties nu eenmaal legacy toepassingen draaiende moeten houden, en doordat er een grote heterogeniteit aan projecten te volbrengen is, hetgeen er voor zorgt dat er vaak ook verschillende keuzes gemaakt worden wat betreft de onderliggende platformen. In zo’n geval is het echter ook belangrijk (of zelfs nog belangrijker) dat men tracht de communicatiepatronen tussen al deze verschillende zaken te standaardiseren, om aldus de compatibiliteit en integreerbaarheid te maximaliseren.

• De Duale Service Interface: CQRS

In de introductie vermeldden we reeds het onderscheid tussen commando’s en queries. CQRS staat voor Command Query Responsability Segregation, wat zoveel betekent als “scheiding van de verantwoordelijkheid voor het afhandelen van commando’s en queries”. In de praktijk wil dat zeggen dat we zullen proberen om een logische scheiding te krijgen tussen de systemen die commando’s verwerken en tussen degene die vragen beatwoorden. Dit is schematisch weergegeven in onderstaande Fig. 2.

Queries kunnen doorgaans rechtstreeks door een API worden beantwoord, al dan niet door de vraag, mogelijks in stukjes gekapt, aan een verdere API door te geven. Uiteindelijk zullen het de onderliggende (micro-)services zijn die het echte werk doen van opzoeken in databases en eventueel nog een paar bewerkingen uitvoeren om het antwoord in de gevraagde vorm te krijgen. Wat betreft de interactie tussen verschillende services, hoeft hier dus niet te worden afgeweken van RESTful synchrone communicatie.

Het ligt iets anders voor commando’s. Wanneer we volledig het paradigma van Event Sourcing toepassen, zullen we een commando steeds omzetten in een gebeurtenis (b.v. het commando “bestel één blockchain boek” wordt dan het event “bestelling van één blockchain boek geplaatst“). Deze omzetting zal door een eerste laag van services worden gedaan, speciaal gebouwd voor het opvangen van dergelijke commando’s vanuit de client side.

Het commando kan dan verder worden afgehandeld als een typisch event: het komt op de Event Bus terecht en alle geïnteresseerde diensten zullen het asynchroon ontvangen en kunnen behandelen (één backend service zal b.v. de inventory aanpassen; een andere zet het verpakken op gang en nog een andere verwittigt de koerierdienst). In elk geval is het creëren van afgeleide informatie (b.v. de hoeveelheid in stock) een verantwoordelijkheid van een microservice die daarvoor zijn eigen database zal hebben.

Wanneer nu later een vraag toekomt die betrekking heeft op informatie beïnvloed door een eerder commando, dan zal deze geforward worden naar de microservices die deze up-to-date informatie controleren (b.v. de vraag “hoeveel van die blockchain boeken zijn er nog in voorraad” komt uiteindeljik terecht bij de service voor de inventory). Vermits events asynchroon werken kan het soms zijn dat een vraag nét te snel komt en de informatie dus niet volledig up-to-date is (meestal is het echter een kwestie van enkele seconden). Vandaar dat het bij dit soort architecturen aangewezen is de principes van “eventual consistency” goed toe te passen, en zelfs door te trekken tot op business niveau.

Bovenstaande Figuur 3 toont een iets gedetailleerder voorbeeld. In de figuur zien we dat er achter de App API, 2 Command APIs en 1 Query API schuilgaan. Daarnaast zien we een door meerdere zaken gebruikte Event Bus, waarvan alle events ook in een centrale event store terecht komen. Sommige backend microservices communiceren rechtsreeks met de bus en spelen dus kort op de bal; daarnaast is er een service die vooral gebruik maakt van de event store en die dus meer zaken kan doen met historische events (b.v. analytics). Verder zien we dat er een legacy systeem communiceert via het event kanaal en dat een aantal services APIs aanbieden, sommige zelfs rechstreeks aan externe systemen. Er is een kort scenario uitgewerkt in de tekening:

1. Een update wordt gevraagd, wat zich vertaalt in een reeks van events die door een aantal services verwerkt worden. Het event komt uiteraard in de event store terecht.
2. Een andere update zorgt er uiteindelijk voor dat er events ontstaan die aanpassingen doen gebeuren aan een database van afgeleide informatie, behorende tot een bepaalde microservice.
3. Een query vraagt informatie op via API, en uiteindelijk wordt een API van de microservice van stap 2 aangeroepen; deze zal dus van de geüpdate informatie uit de database van stap 2 gebruik maken.
4. Een andere query doet een iets diepgaandere vraag. Via verschillende calls tussen deelnemende services, wordt er uiteindelijk informatie opgevraagd uit de event store.

Dit verhaal is, vanwege het gebruik van Events, voor een deel asynchroon. Sommige cliënts zullen echter zo synchroon mogelijk moeten worden geüpdated. Hoe kunnen zij vlot op de hoogte worden gebracht van de meest recente informatie? Ter herinnering: in een volledig synchrone wereld zal een cliënt als antwoord op een commando ook onmiddellijk de nieuwe toestand meekrijgen. Met de nieuwe architectuur moet de cliënt echter “gissen” na hoeveel tijd hij een query naar de server moet sturen, om er zeker van te zijn dat het effect van zijn laatste commando in rekening is gebracht. Dit giswerk kan men echter vermijden. Sowieso is het niet zo efficiënt om ervan uit te gaan dat het altijd de cliënt is die alle communicatie moet initiëren. We zullen er dus voor zorgen dat ook de server dit initiatief kan nemen. Als gevolg van een binnenkomend Event moet ook de server in staat zijn om op dat moment een bericht te sturen naar de client. Er zijn ondertussen verschillende manieren waarop een cliënt aan een server zijn interesse kan laten blijken in het krijgen van callbacks wanneer up-to-date informatie beschikbaar is, en er zijn zelfs al full-duplex communicatiemogelijkheden voor applicaties op het web. (WebSocket is een vrij modern voorbeeld).

Indien het niet mogelijk is de client op een manier te bouwen dat deze door de server kan worden gecontacteerd, en het is evenwel belangrijk dat de client zo snel mogelijk up-to-date informatie krijgt, dan is er nog een noodoplossing mogelijk. We kunnen alsnog een API voorzien die toelaat dat men via één enkele request zowel een update doet als de nieuwe informatie meekrijgt in het antwoord. Desalniettemin zullen we het CQRS patroon voor het grootste gedeelte respecteren in de backend. Het volstaat om de API zo te bouwen, dat hij de request zelf opdeelt in een commando en één of meerdere queries. De microservice die achter deze API schuilgaat, zal dan eerst het event lanceren om het commando uit te laten voeren, en zal vervolgens wachten tot er genotificeerd komt via de juiste events, die de afhandeling van dit commando aangeven. Daarna kan de service overgaan tot het lanceren van de queries en dan vervolgens zelf antwoorden op de vraag van de client. Dit patroon zorgt er wel voor dat soms de client wat langer (synchroon) zal moeten wachten op zijn antwoord, omdat het asynchrone gedeelte volledig aan de serverkant moet worden afgehandeld.

Conclusie

We zien hoe een moderne architectuur ervoor zorgt dat men een applicatie (of groep applicaties) kan opdelen in zo klein mogelijke microservices, elk met hun eigen verantwoordelijkheid. Deze zijn efficient te onderhouden en ook vervangbaar, wat het gehele systeem een ongeziene flexibiliteit geeft om zich aan te kunnen passen aan zowel veranderende functionaliteit als aan veranderingen aan de infrastructuur of de benodigde capaciteit. Daarnaast hebben we een gestandaardiseerde manier van communiceren toegelicht, die ervoor zorgt dat de mesh van apps, de “MASA”, continu kan veranderen en groeien, doordat men alle onderdelen gemakkelijk via het netwerk met elkaar kan laten communiceren. Ten slotte konden we ook zien hoe CQRS hiervan gebruik maakt om een nette afhandeling van alle mogelijke vragen te voorzien, gebruik makende van Events, die ook de historiek en traceerbaarheid van het systeem garanderen, van client tot backend.

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

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

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

De 3-tier Architectuur

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

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

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

De Moderne Architectuur, Deel 1

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

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

• Front-Facing API Ecosystem

  

   

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

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

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

  

Beschouwingen

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

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

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

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.

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.