Jarenlang werden microservices gezien als dé oplossing om complexe softwarearchitecturen beheersbaar te houden. Nu lijkt er een tegenbeweging op gang te zijn gekomen die juist weer teruggrijpt op de monolithische aanpak.
In de nieuwste aflevering van Business Vooruit met IT bespreken Peter Jansen, Martin van de Goor, Daniël de Jong-Veldstra deze ontwikkeling: waar komt de tegenbeweging vandaan? En is er een manier om het beste van beide werelden te combineren?
Microservices werden ruim tien jaar geleden populair. Peter Jansen, software-architect: “Ze zijn destijds ontstaan vanuit een bepaalde behoefte: traditionele monolieten waren na jaren onderhand ondoorgrondelijke kluwen code geworden. Dat maakte het onderhoud lastig, zeker als er meerdere teams bij betrokken waren. Ook stonden monolieten een korte time-to-market in de weg. Microservices werden destijds voor het eerst toegepast bij grote Amerikaanse techbedrijven en streamingdiensten en daarna werd het principe door de hele software community omarmd. Maar de meeste organisaties hebben heel andere behoeftes. Spotify of Netflix hebben bijvoorbeeld een enorme behoefte aan schaalbaarheid, die bij onze klanten een stuk kleiner is.”
Volgens IT-consultant Daniël de Jong-Veldstra is de hype rondom microservices dan ook deels veroorzaakt door de behoefte van IT-professionals om aan de slag te gaan met de nieuwste manieren van werken: “Dat noemen we intern ook wel eens convention-driven architecture: op een conferentie wordt iets nieuws gepresenteerd en vervolgens wil iedereen het graag gaan toepassen.”
De praktijk blijkt weerbarstiger dan de theorie. Kleine teams worstelen met de complexiteit van gedistribueerde systemen. Software-architect Martin van de Goor: “Bij kleinere organisaties zie je dat microservices vaak worden toegepast omdat het een moderne manier van softwareontwikkeling is. Maar de complexiteit van microservices wordt daarbij onderschat.”
“Binnen microservices is het bijvoorbeeld heel moeilijk om de scoping van stories te maken, omdat je opeens veel meer verantwoordelijkheden hebt over verschillende services”, vult Daniël aan. “Soms heeft een team de verantwoordelijkheid over vier microservices, waardoor je al snel geneigd bent om de hele functionaliteit als één geheel te zien. Wat je dan ziet, is dat er grote, complexe changes over meerdere services heengaan.”
Er is een middenweg die de beste eigenschappen van microservices toepast binnen één applicatie: de modulaire monoliet, ook wel ‘modulith’ genoemd. De praktische voordelen: ontwikkelaars kunnen veel sneller een prototype bouwen zonder de overhead van gedistribueerde systemen. “Je kunt lokaal één applicatie draaien, een paar events of calls maken en vervolgens testen of je flow logisch is”, legt Daniël uit. “Je kunt dus heel snel iets neerzetten om te kijken of de grote logische lijnen kloppen, zonder dat je alles als kleine hapjes klaar moet hebben staan.”
Het tijdperk van de microservices heeft een belangrijke les met zich meegebracht: het belang van duidelijke grenzen tussen componenten. Daniël: “Als je software gaat ontwikkelen, moet je vanaf dag één heel goed letten op het vervagen van grenzen. Wanneer dat gebeurt, dan gaan verschillende onderdelen door elkaar heen lopen en dan wordt de complexiteit alleen maar groter.”
Om deze grenzen te bewaken, zijn verschillende tools beschikbaar, waaronder ArchUnit. Ook kun je als team het secure by default-principe hanteren om ervoor te zorgen dat de grenzen tussen modules niet worden overschreden: “Standaard is een module gesloten”, legt Daniël uit. “Je mag niet aan een andere module zitten. Als je dat wel wilt, moet je een specifieke regel introduceren. Zo moet je er altijd expliciet over nadenken voordat je grenzen overschrijdt.”
Een voordeel van de modulaire monoliet: deze sluit schaalbaarheid in de toekomst niet uit. Daniël: “Je kunt verschillende varianten implementeren, zoals een event-driven systeem waarbij events in-memory worden verstuurd. Later kun je daar eenvoudig een andere tool achter zetten, zoals Kafka, zonder dat je code daar last van heeft.”
Deze flexibiliteit maakt het mogelijk om geleidelijk te evolueren. “Je ziet pas waar je winst moet maken, als je een bottleneck ontdekt. Stel dat een service tien andere services achter elkaar aanroept, dan kun je dat oplossen door ze asynchroon te maken en over verschillende pods te verdelen. Zo los je schaalbaarheid op zonder direct naar microservices te gaan.”
Een overeenkomst tussen de modulaire monoliet en microservices: voor beide aanpakken is Domain-Driven Design (DDD) waardevol. “Het helpt je in het afbakenen van wat de scope is van je functionaliteit en je domein. Een praktische aanpak voor domeinmodellering is Event Storming, wat een waardevolle toevoeging om je domein te ontdekken. Dit helpt om te bepalen welke delen van het model bij elkaar horen en wat eventually consistent mag zijn.”
Wanneer kies je voor een modulaire monoliet en wanneer voor microservices? Volgens Martin hangt die keuze af van specifieke behoeften. “Er moet een duidelijke aanleiding zijn, zoals schaalbaarheid: als we nu dit deel van de applicatie moeten schalen en de hele applicatie keer twee wordt te duur, dan is dat een goede reden om dat stuk los te weken.”
“Je moet kijken naar de verwachte levensduur van je applicatie,” vult Peter aan. “Is het iets voor een korte campagne? Dan hoef je niet veel tijd te spenderen aan complexe architectuur. Verwacht je dat de applicatie over tien jaar nog draait? Dan is het zeker de moeite waard om met deze tools en technieken aan de slag te gaan.”
Hoe dan ook, is het niet meer vanzelfsprekend om in een microservices-architectuur te werken, concludeert Daniël: Ik denk dat we nu weer terugkomen in een swing waarbij je moet gaan verdedigen waarom je er een microservice van wil maken, in plaats van andersom.”
Kortom: het is belangrijk om de juiste afwegingen te maken om tot een gefundeerde keuze te komen, in plaats van mee te rennen met de laatste hype.
Luister hier naar de podcast van Business vooruit met IT over dit onderwerp