De monoliet slaat terug: hoe je weet dat je architectuur je team in de houdgreep heeft

Het begint altijd onschuldig. Een startup, een slimme codebase, een team van vier man dat lekker door kan bouwen. Jaren later zit je met een applicatie die zo groot is geworden dat niemand meer precies weet wat er in zit. Elke deployment voelt als Russische roulette. Je senior developer is de enige die de betalingsmodule echt begrijpt, en hij is net drie weken met vakantie naar Thailand.

Welkom in de houdgreep van de monoliet.

Veel Nederlandse dev-teams herkennen dit patroon, maar weinigen durven de stap te zetten naar microservices. Want laten we eerlijk zijn: een architectuurmigratie is niet alleen een technisch vraagstuk. Het is ook een politiek gevecht, een organisatorische operatie, en soms gewoon een kwestie van overleven.

Hoe weet je dat het tijd is?

Niet elke monoliet is een probleem. Sterker nog: voor veel teams is een goed onderhouden monolithische applicatie prima. De vraag is wanneer je architectuur overgaat van 'solide fundament' naar 'actief obstakel'.

Een paar concrete signalen die je niet kunt negeren:

Deployments duren uren, niet minuten. Als je team meer tijd kwijt is aan het uitrollen van een kleine bugfix dan aan het schrijven ervan, heb je een probleem. In een gezonde setup deploy je kleine, onafhankelijke stukken code. Als alles samen moet worden uitgerold, betaal je elke keer de volle prijs.

Eén bug legt drie teams stil. Een fout in de facturatielogica crasht ook de productcatalogus en de gebruikersomgeving. Dat is geen toeval — dat is tightly coupled code die zijn grenzen heeft bereikt.

Nieuwe developers raken verdwaald. Als het onboarden van een junior developer twee maanden duurt omdat de codebase zo complex is, dan kost je architectuur je geld. Elke dag.

Teams blokkeren elkaar. Team A kan niet deployen omdat team B nog niet klaar is. Team B wacht op team C. Iedereen wacht op iedereen. Dit is geen planningsprobleem — dit is een architectuurprobleem.

De politieke dimensie: dit wordt geen technisch gesprek

Hier wordt het interessant. Want zodra je intern begint te pleiten voor een microservices-migratie, stap je een mijnenveld in. En dat mijnenveld heeft niets met code te maken.

Je CTO heeft de monoliet zelf gebouwd. Je productmanager wil weten waarom features ineens langer duren. Finance vraagt waarom er opeens drie keer zoveel cloud-kosten zijn. En je collega's zijn bang dat hun domeinkennis — die ze jarenlang hebben opgebouwd — ineens minder waard is.

Dit zijn legitieme zorgen. Neem ze serieus.

De sleutel is om de conversatie te verschuiven van 'onze architectuur is fout' naar 'onze architectuur past niet meer bij onze ambities'. Dat is een ander gesprek. Minder defensief, meer toekomstgericht. Je verkoopt geen technische schuld — je verkoopt schaalbaarheid, autonomie voor teams, en snellere time-to-market.

Maak het concreet. Bereken hoeveel developer-uren er maandelijks verloren gaan aan trage deployments en onnodige afhankelijkheden. Zet daar een bedrag naast. Plotseling is de migratie geen kostenpost meer, maar een investering.

De migratie: niet alles tegelijk

Een veelgemaakte fout is denken dat je de monoliet in één grote beweging kunt vervangen. Dat kan je niet. En als je het probeert, leg je je bedrijf plat.

De slimmere aanpak heet de Strangler Fig Pattern — vernoemd naar een boom die langzaam zijn gastheer omhult en vervangt. Je bouwt nieuwe functionaliteit als losse services, terwijl de monoliet zijn bestaande taken blijft uitvoeren. Stukje bij beetje verschuif je verkeer naar de nieuwe services, totdat de monoliet leeg is en je hem rustig kunt uitschakelen.

Praktisch betekent dit:

1. Identificeer de grenzen. Welke domeinen zijn het meest onafhankelijk? Denk aan authenticatie, notificaties, of rapportage. Dit zijn goede kandidaten voor de eerste services.

2. Begin met wat pijn doet. Welk deel van de applicatie zorgt voor de meeste frustratie? Dat is je startpunt. Niet omdat het makkelijk is, maar omdat succes hier de organisatie overtuigt.

3. Bouw een API-gateway. Voordat je iets migreert, zorg je voor een centrale ingang die verkeer kan routeren naar zowel de monoliet als de nieuwe services. Dit is je schakelpunt.

4. Investeer in observability. Microservices zijn per definitie complexer om te monitoren. Zorg dat je logging, tracing en alerting op orde zijn vóór je de eerste service live zet. Tools als Grafana, Jaeger of OpenTelemetry zijn hier je vrienden.

5. Organiseer teams rond services. Conway's Law is geen mythe: je systemen gaan lijken op je organisatiestructuur. Als je wil dat services echt onafhankelijk zijn, moeten de teams dat ook zijn.

Wat niemand je vertelt over microservices

Microservices lossen veel problemen op, maar introduceren ook nieuwe. Eerlijkheid hierover is geen zwakte — het is noodzakelijk voor een realistisch migratieplan.

Netwerkcommunicatie tussen services kan falen. Distributed transactions zijn een stuk complexer dan lokale database-transacties. Je hebt meer infrastructuur nodig, meer tooling, en developers die begrijpen hoe gedistribueerde systemen werken.

Dit betekent niet dat je het niet moet doen. Het betekent dat je het met open ogen moet doen. Investeer in kennis. Stuur mensen naar conferenties. Lees de post-mortems van bedrijven die het voor je hebben gedaan — Netflix, Zalando, en ja, ook kleinere Nederlandse scale-ups die hun verhaal hebben gedeeld op meetups in Amsterdam en Utrecht.

De opstand organiseren

Als je eenmaal het politieke draagvlak hebt en een technisch plan, is het tijd om te handelen. Maar vergeet niet: een migratie is een marathon, geen sprint.

Zet kleine, meetbare mijlpalen. Vier successen — ook de kleine. Communiceer transparant over wat werkt en wat niet. En geef je team de ruimte om te leren terwijl ze bouwen.

De monoliet heeft je lang genoeg gegijzeld. De opstand begint niet met één grote revolutie, maar met honderd kleine beslissingen die samen de architectuur van de toekomst vormen.

Je codebase heeft je team lang genoeg gedomineerd. Nu is het tijd om de rollen om te draaien.