Microservices versus monolithische architectuur: de juiste architectuur kiezen voor je project

Inleiding

Elk softwareproject begint met dezelfde, bedrieglijk eenvoudige vraag: hoe moeten we dit structureren? Als je het juiste antwoord vindt, kan je team sneller opleveren, soepel opschalen en het hoofd koel houden. Als je het verkeerd doet, ben je jaren bezig met het ontwarren van een puinhoop die je zelf hebt gecreëerd.

Het debat over monolithische architectuur versus microservices woedt al meer dan een decennium, en in 2026 is het genuanceerder dan ooit. De vroege hype rond microservices beloofde oneindige schaalbaarheid en autonomie voor teams – maar toen kwam de terugslag, waarbij vooraanstaande bedrijven publiekelijk afstand namen van hun overijverige opsplitsingen. Amazon Prime Video schakelde in 2023 voor zijn monitoringdienst weer over op een monolithische architectuur, waardoor de kosten met 90% daalden. Het SnapCI-team bij ThoughtWorks voegde, zoals bekend, zijn microservices weer samen tot één monoliet nadat het maandenlang had geworsteld met onstabiele servicegrenzen.

Toch is het even gevaarlijk om microservices zonder meer af te wijzen. Bedrijven als Netflix, Spotify en Uber draaien met succes duizenden microservices in productie en voeren honderden keer per dag updates door. De waarheid is dat geen van beide benaderingen universeel „beter“ is – elke benadering lost verschillende problemen op in verschillende fasen van de levenscyclus van een project. Dit artikel biedt je een duidelijk, praktisch kader om te bepalen welke architectuur past bij jouw project, jouw team en jouw tijdschema, zonder de hype.

Wat is een monoliet eigenlijk?

Voordat we partij kiezen, laten we onze termen eerst nauwkeurig definiëren. Een monolithische architectuur houdt in dat je gehele applicatie – gebruikersinterface, bedrijfslogica, gegevenstoegang – zich in één enkele implementeerbare eenheid bevindt. Wanneer je een wijziging wilt uitrollen, bouw en implementeer je het geheel. Monolieten zijn niet automatisch ‘slecht’ of slecht gestructureerd. Een goed ontworpen monoliet maakt gebruik van interne modules, overzichtelijke interfaces en scheiding van verantwoordelijkheden. Zie het als een goed georganiseerd appartementencomplex: alles onder één dak, maar elke kamer heeft een duidelijk doel.

Het probleem ontstaat wanneer de discipline verslapt. Zonder de fysieke barrière van netwerkgrenzen tussen componenten wordt het kinderlijk eenvoudig om module-interfaces te omzeilen. Een ontwikkelaar die onder druk staat vanwege een deadline kan een klasse importeren uit een module die er helemaal niets mee te maken heeft, een gedeelde databasetabel introduceren die twee domeinen aan elkaar koppelt, of een circulaire afhankelijkheid toevoegen die de codebase verandert in wat Martin Fowler een ‘Big Ball of Mud’ noemt. Deze erosie verloopt geleidelijk – je merkt het niet in de eerste maand, maar tegen het derde jaar vereist elke wijziging aanpassingen in vijf verschillende modules, en duurt het 45 minuten om de testsuites uit te voeren.

Monolieten dwingen je ook om horizontaal te schalen als één geheel. Als je module voor betalingsverwerking tijdens Black Friday onder druk komt te staan, kun je niet alleen die module opschalen – je moet de hele applicatie opschalen, inclusief de inlogpagina en het beheerderspaneel dat niemand gebruikt. Dit is inefficiënt en, op grote schaal, duur.

Wat microservices eigenlijk zijn

Microservices hanteren de tegenovergestelde aanpak: elke bedrijfsfunctie draait als een onafhankelijke service, met een eigen codebase, een eigen database en een eigen implementatiepijplijn. Services communiceren via welomschreven API’s – doorgaans HTTP REST of asynchrone berichtenuitwisseling – en geen enkele service kan rechtstreeks toegang krijgen tot de database van een andere service.

De canonieke definitie is afkomstig van James Lewis en Martin Fowler in hun artikel uit 2014 dat de beweging in gang zette: microservices zijn „een benadering waarbij één applicatie wordt ontwikkeld als een reeks kleine services, die elk in hun eigen proces draaien en communiceren via lichtgewicht mechanismen.“ De sleutelwoorden zijn klein, onafhankelijk en lichtgewicht. Een microservice moet klein genoeg zijn zodat één team er van begin tot eind verantwoordelijk voor kan zijn, onafhankelijk genoeg om te worden geïmplementeerd zonder afstemming met andere teams, en communiceren via eenvoudige protocollen in plaats van complexe middleware.

Deze architectuur is ontstaan uit echte problemen bij bedrijven als Amazon, waar de monolithische codebase begin jaren 2000 zo groot was geworden dat voor één enkele implementatie afstemming tussen tientallen teams nodig was. Jeff Bezos vaardigde rond 2002 het beroemde „API-mandaat“ uit: alle teams moesten hun gegevens en functionaliteit via service-interfaces beschikbaar stellen, zonder uitzonderingen. Dit dwong modulariteit af via de organisatiestructuur – de essentie van de wet van Conway in de praktijk.

Netflix volgde een vergelijkbare weg en migreerde van een monolithische datacenterapplicatie naar honderden microservices die op AWS draaien, na een catastrofale databasecorruptie in 2008 die hun dvd-verzending drie dagen lang platlegde. Ze maakten een groot deel van hun tooling open source (Eureka, Hystrix, Zuul), wat de blauwdruk werd voor vroege gebruikers van microservices.

De echte afwegingen

Het framework voor afwegingen bij microservices van Martin Fowler onderscheidt drie voordelen en drie nadelen, en het is essentieel om deze te begrijpen voordat er architecturale beslissingen worden genomen.

Voordelen:

Ten eerste, sterke modulegrenzen. Wanneer modules door netwerkoproepen van elkaar worden gescheiden, zijn de kosten van het omzeilen van een interface direct zichtbaar: er is een nieuw API-eindpunt, authenticatie en documentatie voor nodig. Deze weerstand voorkomt de geleidelijke uitholling waar monolithische systemen onder lijden. Zoals Fowler het stelt: „het gebruik van microservices vergroot de kans dat je een betere modulariteit krijgt.”

Ten tweede: onafhankelijke implementatie. Elke service kan volgens zijn eigen planning worden geïmplementeerd. Voor een cruciale beveiligingspatch voor je authenticatieservice hoef je niet je hele e-commerceplatform opnieuw te bouwen en te implementeren. Dit vermindert de impact van elke wijziging drastisch en maakt snellere releasecycli mogelijk.

Ten derde, technologische diversiteit. Verschillende problemen vragen om verschillende tools. Je aanbevelingsengine kan baat hebben bij het machine learning-ecosysteem van Python, terwijl je betalingsverwerking de typveiligheid van Go of Rust nodig heeft. Met microservices kan elk team de beste taal, het beste framework en de beste database kiezen voor hun specifieke probleem.

Kosten:

Ten eerste, distributiepijn. Netwerkoproepen zijn vele malen trager dan methode-oproepen binnen hetzelfde proces. Elke communicatie tussen services moet omgaan met time-outs, herhalingspogingen, circuitbreakers en gedeeltelijke storingen. Wat ooit een eenvoudige functie-oproep was, wordt een complexe dans van gedistribueerde systeemtechniek.

Ten tweede, uiteindelijke consistentie. In een monoliet kan één enkele databasetransactie de consistentie tussen je bestel- en voorraadsystemen garanderen. Bij microservices heeft elke service zijn eigen database, dus moet je ontwerpen met het oog op uiteindelijke consistentie – een domein waarin zaken tijdelijk niet synchroon kunnen lopen, en je bedrijfslogica moet daar soepel mee omgaan. Dit is echt moeilijk om goed voor elkaar te krijgen.

Ten derde: operationele complexiteit. Het implementeren van tien services is niet tien keer moeilijker dan het implementeren van één – het kan wel honderd keer moeilijker zijn. Je hebt containerorkestratie (Kubernetes), service discovery, gecentraliseerde logboekregistratie, gedistribueerde tracering, geautomatiseerde CI/CD-pijplijnen nodig, en een team dat hier alles van begrijpt. Zonder deze operationele basis worden microservices een nachtmerrie.

Wanneer microservices zinvol zijn

Microservices komen het best tot hun recht onder specifieke omstandigheden. De eerste is teamomvang. Wanneer je meer dan 15–20 ontwikkelaars aan één codebase hebt werken, schiet de coördinatie-overhead omhoog. Merge-conflicten nemen toe. Er ontstaan wachtrijen voor implementaties. Met microservices kun je de organisatie opsplitsen in kleine, autonome teams, die elk van begin tot eind verantwoordelijk zijn voor hun eigen services – het patroon dat Amazon „two-pizza teams“ noemt.

De tweede voorwaarde is onafhankelijke schaalbehoeften. Als bepaalde delen van je systeem onevenredig zwaar worden belast, kun je door ze te isoleren in afzonderlijke services precies daar schalen waar dat nodig is. Een videotranscodingservice die de CPU tijdens piekuren op 100% houdt, hoeft je gebruikersprofielservice niet mee te slepen.

De derde voorwaarde is goed begrepen domeinen. Sam Newman, auteur van Building Microservices, benadrukt dat het verkeerd afbakenen van servicegrenzen kostbaar is. Het SnapCI-team bij ThoughtWorks bouwde een eerste reeks microservices, ontdekte dat de grenzen daarvan niet overeenkwamen met het daadwerkelijke probleemdomein, en was maandenlang bezig met het bestrijden van wijzigingen die meerdere services betroffen. Uiteindelijk hebben ze alles weer samengevoegd tot een monoliet, het domeinmodel gestabiliseerd en pas daarna services afgesplitst – ditmaal met succes. Als je nog aan het uitzoeken bent wat je product eigenlijk is, verdeel het dan nog niet.

Een nuttige vuistregel: bijna alle succesverhalen over microservices beginnen met een monoliet die te groot werd en opzettelijk werd opgesplitst. Bijna elk greenfield-microserviceproject dat ik heb gezien, liep uiteindelijk ernstig vast. Fowler noemt dit „Monolith First“, en hoewel het geen absolute wet is, is het patroon opvallend genoeg om het als de standaardstrategie te beschouwen.

Wanneer een monoliet de juiste keuze is

Voor de meeste projecten – vooral nieuwe – is een monoliet geen compromis; het is de optimale keuze. Startups die hun eerste product bouwen, beschikken niet over de teamomvang, operationele volwassenheid of domeinkennis om microservices te rechtvaardigen. Een goed gestructureerde monoliet stelt je in staat snel te itereren, vrij te refactoren en je bedrijf te doorgronden voordat je investeert in distributie.

Zelfs op verrassend grote schaal kunnen monolieten werken. Shopify beheert een van de grootste Ruby on Rails-monolieten ter wereld, waarmee transacties ter waarde van miljarden dollars worden verwerkt. Ze hebben zwaar geïnvesteerd in modularisatie binnen de monoliet: duidelijke modulegrenzen, gedisciplineerde patronen voor databasetoegang en een geavanceerde CI-pijplijn. Hun aanpak bewijst dat je sterke modulariteit kunt hebben zonder netwerkgrenzen, mits je engineeringcultuur dit afdwingt.

Voor Belgische kmo’s die interne tools, klantenportalen of B2B-platforms bouwen, is een monoliet bijna altijd het juiste startpunt. Je team is waarschijnlijk klein. Je domein zal evolueren naarmate je van gebruikers leert. De operationele overhead van Kubernetes, service meshes en gedistribueerde tracing zal je meer vertragen dan dat architectonische elegantie je zal versnellen. Bouw eerst een strakke, modulaire monoliet. Splits services pas later af, wanneer – en alleen wanneer – je daar een duidelijke reden voor hebt.

De modulaire monoliet: een pragmatisch middenpad

Als de binaire keuze tussen monoliet en microservices beperkend aanvoelt, komt dat omdat er een derde optie is die de afgelopen jaren aanzienlijk aan populariteit heeft gewonnen: de modulaire monoliet.

Een modulaire monoliet is intern gestructureerd als een reeks microservices – elk bedrijfsdomein is eigenaar van zijn code, zijn databasetabellen en zijn openbare interface – maar draait als één enkel implementeerbaar proces. De grenzen worden afgedwongen door conventies en tooling (architectuurtests, controles op moduleafhankelijkheden in CI) in plaats van door netwerktopologie. Dit biedt je een duidelijke scheiding van verantwoordelijkheden zonder de operationele lasten van gedistribueerde systemen.

Het cruciale voordeel is dat het herschikken van grenzen weinig moeite kost. In een microservices-architectuur is het verplaatsen van een stuk functionaliteit van de ene service naar de andere een migratie in meerdere stappen, met API-versiebeheer, gegevenssynchronisatie en gecoördineerde implementaties. In een modulaire monoliet is het een eenvoudige herontwerp van de code. Wanneer je je domein nog aan het leren bent – wat bij de meeste projecten veel langer duurt dan iemand wil toegeven – is deze flexibiliteit van onschatbare waarde.

De modulaire monoliet dient ook als de ideale opstap naar microservices. Zodra de grenzen zich stabiliseren en een specifieke module daadwerkelijk onafhankelijke schaalbaarheid of een andere technologiestack nodig heeft, haal je alleen die module eruit en maak je er een aparte service van. De rest van het systeem blijft monolithisch, en je hebt alleen de complexiteit toegevoegd die je daadwerkelijk nodig hebt. Zo werkt Shopify, en zo kiezen veel pragmatische teams ervoor om in 2026 te werken.

Het besluitvormingskader

Hier volgt een praktisch kader voor het nemen van deze beslissing, gebaseerd op de gecombineerde wijsheid van Fowler, Newman en jarenlange ervaring in de sector:

Begin met een monoliet als:

• Je team bestaat uit minder dan 15 ontwikkelaars
• Je een nieuw product bouwt en het domein nog aan het verkennen bent
• Je schaalbaarheidsbehoeften voorspelbaar en gematigd zijn
• Je geen operationele infrastructuur hebt (Kubernetes, CI/CD-pijplijnen, monitoring)
• Je snel moet opleveren en moet itereren op basis van gebruikersfeedback

Overweeg een modulaire monoliet als:

• Je team groeit, maar nog niet de schaal van microservices heeft bereikt
• Je duidelijke bedrijfsdomeinen hebt, maar eenvoud bij de implementatie wilt
• Je je wilt voorbereiden op toekomstige opsplitsing zonder nu al de volledige prijs van gedistribueerde systemen te betalen
• Je applicatie organisch complex is, maar niet op enorme schaal

Splits microservices af als:

• Specifieke modules daadwerkelijk onafhankelijk moeten kunnen schalen
• Verschillende delen van het systeem baat hebben bij verschillende technologiestacks
• Meerdere teams onafhankelijk van elkaar moeten kunnen implementeren volgens verschillende tijdschema’s
• Je duidelijke, stabiele domeingrenzen hebt
• Je operationele volwassenheid gedistribueerde systemen aankan

Begin met microservices als:

• Je team heeft aanzienlijke ervaring met microservices
• Je vervangt een goed begrepen legacy-systeem met stabiele grenzen
• Je organisatie is al gestructureerd rond autonome teams
• Het domein is goed ingeburgerd en zal waarschijnlijk niet significant veranderen

Een nuttig denkkader: de kosten voor het extraheren van een service uit een goed gestructureerde monoliet zijn lager dan de kosten voor het weer samenvoegen van microservices met slecht afgebakende grenzen. Het is bijna altijd veiliger om het in het begin wat eenvoudiger aan te pakken.

De Belgische praktijk

Voor Belgische bedrijven brengt de architecturale keuze specifieke overwegingen met zich mee. Het Belgische tech-ecosysteem wordt gedomineerd door kmo’s, waarvan er vele kleine ontwikkelingsteams van drie tot tien mensen hebben. De operationele complexiteit van microservices – het beheren van Kubernetes-clusters, service meshes, gedistribueerde tracing en multi-service CI/CD – vereist vaardigheden die duur en schaars zijn op de Belgische markt.

Dat gezegd zijnde, worden Belgische bedrijven die actief zijn in logistiek, fintech en e-commerce vaak geconfronteerd met reële schaalbaarheidsuitdagingen. Een in Brussel gevestigd logistiek platform dat realtime tracking verzorgt voor duizenden zendingen in de haven van Antwerpen, kan daadwerkelijk baat hebben bij het onafhankelijk uitbouwen van zijn tracking- en meldingsdiensten. De sleutel is om de bedrijfsbehoefte de architectuur te laten sturen, en niet het enthousiasme voor de architectuur het bedrijf te laten sturen.

België kent ook een sterke traditie van pragmatische engineering. De aanpak „eerst een modulaire monoliet, uitbouwen wanneer nodig“ sluit goed aan bij de Belgische bedrijfscultuur van afgewogen, weloverwogen investeringen in plaats van het najagen van Silicon Valley-trends. Het is een aanpak die rekening houdt met budgetbeperkingen en tegelijkertijd de deur openhoudt voor toekomstige groei.

Belangrijkste conclusies

De architectuur volgt de organisatie, niet andersom. De structuur van je systeem moet de structuur van je team weerspiegelen – dit is de wet van Conway, en het negeren ervan is de snelste weg naar architectonische mislukking.

‘Monolith First’ is geen compromis; het is een strategie. Bijna elke succesvolle implementatie van microservices begon als een goed gestructureerde monoliet. Beginnen met microservices bij een volledig nieuw project is een van de meest betrouwbare manieren om jezelf door over-engineering in een hoek te manoeuvreren.

De modulaire monoliet is je beste vriend. Je kunt 80% van de voordelen van microservices (duidelijke grenzen, teamautonomie, onderhoudbare code) behalen met 20% van de operationele kosten. Dit is de pragmatische weg voor de meeste Belgische kmo’s.

Splits services af met een reden, niet omdat het een trend is. Onafhankelijke schaalbaarheid, technologische diversiteit en teamautonomie zijn geldige redenen. „Omdat Netflix het zo doet“ is dat niet. Elke afgesplitste service voegt operationele complexiteit toe die moet worden gerechtvaardigd door een duidelijk zakelijk voordeel.

Domeingrenzen zijn alles. Verkeerd omgaan met servicegrenzen is duurder dan welke architecturale keuze dan ook. Investeer tijd in het begrijpen van je domein – gebruik Domain-Driven Design, event storming, welke methode ook werkt – voordat je gaat opdelen.

Volgende stappen

Deze week: Evalueer je huidige architectuur. Als je een monoliet hebt, beoordeel dan eerlijk de modulariteit ervan. Zijn er duidelijke, gedocumenteerde modulegrenzen? Kan een nieuwe ontwikkelaar de structuur van de codebase binnen een dag begrijpen? Zo niet, begin dan met interne modularisering voordat je aan extractie denkt.

Deze maand: Voer samen met je team een domeinmapping-oefening uit. Breng je afgebakende contexten in kaart met behulp van Event Storming- of Domain-Driven Design-workshops. Het resultaat is geen code – het is een gedeeld begrip van waar je natuurlijke grenzen liggen.

Binnen drie maanden: Als je een module hebt geïdentificeerd die daadwerkelijk onafhankelijke implementatie of schaalbaarheid nodig heeft, plan dan één extractie. Extraheer één service, stabiliseer deze en leer van de operationele ervaring voordat je een tweede extraheert. Weersta de verleiding om alles in één keer te extraheer.

Binnen zes maanden: Evalueer. Heeft de extractie de implementatiesnelheid of schaalbaarheid daadwerkelijk verbeterd? Rechtvaardigde de operationele overhead de verandering? Pas je strategie aan op basis van echte gegevens, niet op basis van architectonische dogma’s.

Heb je deskundige begeleiding nodig? Het kiezen van de juiste architectuur is een van de beslissingen met de hoogste inzet in de softwareontwikkeling. Bij Omnistack helpen we Belgische bedrijven bij het ontwerpen, bouwen en verder ontwikkelen van softwarearchitecturen die aansluiten bij hun team, hun budget en hun ambities. Neem contact met ons op om je project te bespreken.

Conclusie

Het debat over monolieten versus microservices is uitgegroeid van een ideologische strijd tot een praktisch technisch gesprek, en dat is een goede zaak. In 2026 zijn de beste teams niet degenen die een kant kiezen en die verdedigen – het zijn degenen die de afwegingen begrijpen en weloverwogen keuzes maken op basis van hun specifieke context.

Begin eenvoudig. Bouw vanaf dag één modulariteit in, zelfs als alles in één enkel proces draait. Laat je architectuur evolueren naarmate je team en je inzicht groeien. Splits services af wanneer je daar een duidelijke reden voor hebt, niet eerder. Deze aanpak komt misschien niet zo indrukwekkend over in conferentiepresentaties, maar levert software op die werkt, schaalbaar is wanneer dat nodig is, en je team productief en tevreden houdt.

De beste architectuur is immers niet degene met de meeste services of het strakste diagram. Het is degene die je helpt waarde te leveren aan je gebruikers, vandaag en morgen.