Van monoliet naar microservices: wanneer loont het?

Microservices zijn sexy. Iedereen praat erover, conferentiepresentaties zijn er vol mee en je voelt de subtiele druk om "ook te migreren". Maar de vraag is niet of microservices technisch interessant zijn. De vraag is of de migratie voor jou op dit moment loont. En dat antwoord is vaker "nee" dan de hype suggereert.

Wat een monoliet eigenlijk is

Een monoliet is een applicatie waarbij alle functionaliteit als één deployable unit gebundeld is. Één build, één deployment, één proces. Dat klinkt als een limitatie, maar het heeft serieuze voordelen: eenvoud in debuggen, geen netwerkcommunicatie tussen services, transacties zijn eenvoudig te beheren en je codebase is op één plek.

De meeste succesvolle SaaS-bedrijven begonnen als monoliet. Basecamp is er nooit volledig van af. Stack Overflow draait nog altijd grotendeels op één ASP.NET-monoliet. Shopify decomposeerde pas serieus toen ze richting honderden engineers gingen. Een monoliet is geen legacy-antipatroon, het is een rationele keuze voor een team dat snelheid boven abstractie stelt.

De problemen beginnen als je monoliet groeit tot iets dat niemand meer volledig begrijpt, waarbij een kleine wijziging in module A onverwacht gedrag veroorzaakt in module C, en waarbij een deployment een uur of langer duurt omdat alles mee moet.

Wanneer microservices de juiste stap zijn

Microservices lossen een specifiek probleem op: organisatorische en technische complexiteit bij schaal. Ze zijn niet een betere manier om software te bouwen, ze zijn een manier om te schalen als één codebase en één team niet meer werken.

De signalen dat het moment aanbreekt:

• Deploymentpijl: je kunt geen kleine wijziging uitrollen zonder alles te deployen. Elke release is een risicovolle operatie.
• Teamgrootte: meerdere teams werken aan dezelfde codebase en blokkeren elkaar continu bij merges en reviews.
• Schaalbehoefte: één component (bv. zoeken of rapportage) vraagt tien keer meer resources dan de rest, maar je kunt het niet onafhankelijk schalen.
• Technologieheterogeniteit: een deel van je systeem heeft fundamenteel andere requirements waarbij een andere taal of database beter past.
• Organisatiestructuur: Conway's Law werkt in je nadeel: je architectuur weerspiegelt een org-structuur die niet meer klopt.

Geen van deze signalen is op zichzelf voldoende. Het zijn aanwijzingen. Als er drie of meer gelden en ze je dagelijks raken, dan is de conversatie over migratie zinvol.

De kosten van microservices

Microservices brengen operationele complexiteit mee die vaak onderschat wordt. Wat je wint aan onafhankelijkheid per service, betaal je in overhead:

• Netwerkcommunicatie: een aanroep die in een monoliet een lokale functieaanroep is, wordt een HTTP- of gRPC-call met latency, timeouts en retry-logica
• Gedistribueerde transacties: een ACID-transactie over meerdere services bestaat niet. Je implementeert Saga-patterns of accepteert eventual consistency
• Observability: distributed tracing is complexer dan logging in een monoliet. Je hebt OpenTelemetry, een trace-backend en engineers die het begrijpen nodig
• Deployment-coördinatie: meerdere services betekent meerdere deployments, versioning en compatibiliteitscontracten
• Infrastructuurkosten: elke service heeft eigen compute, health checks en monitoring nodig. Bij twintig services telt dat op

Een onderzoek van Gartner uit 2023 constateerde dat organisaties die microservices migreerden zonder duidelijke probleemstelling in meer dan 60% van de gevallen niet de verwachte voordelen realiseerden binnen twee jaar. De architectuur werkte, het probleem was er gewoon niet.

Migratiestrategieën

Als je wel migreert, doe het dan stapsgewijs. Een big-bang-migratie waarbij je in zes maanden alles herschrijft is bijna altijd een ramp. De meest effectieve aanpak:

Strangler Fig Pattern: je bouwt nieuwe functionaliteit als aparte services en migreert bestaande functionaliteit geleidelijk. De monoliet "verstikt" langzaam terwijl nieuwe services groeien. Dit is de aanpak die Shopify, Netflix en Amazon succesvol hebben gevolgd.

Domein-gedreven decomposie: gebruik Domain-Driven Design om grenzen te identificeren. Bounded contexts in je domein worden kandidaat-services. Begin bij de grenzen die duidelijk zijn, niet bij de grenzen die interessant zijn.

Database-first: een gedeelde database tussen services is geen microservices-architectuur. Data-eigenaarschap per service is het fundament. Dit is ook de moeilijkste stap, want het vereist migratie van data en aanpassing van alles wat die data aanroept.

Hosting en infrastructuur bij microservices

Microservices en Kubernetes zijn geen synoniem, maar in de praktijk worden ze bijna altijd samen gebruikt. Kubernetes biedt de orkestratie die je nodig hebt om tientallen services te beheren: scheduling, health checks, scaling en rolling deployments.

Voor SaaS-bedrijven in Nederland betekent dit dat de infrastructuurkeuze voor microservices direct gekoppeld is aan de Kubernetes-keuze. Een managed Kubernetes-omgeving bij een Nederlandse provider biedt de basis zonder dat je een fulltime platform-engineer nodig hebt om de control plane draaiende te houden.

De nuchterste vraag

Voordat je een migratietraject start, één vraag: wat lost dit concreet op in de komende twaalf maanden? Als het antwoord vaag is ("het is beter schaalbaar", "het is moderner"), wacht dan. Migreer als het pijn kost om het niet te doen, niet omdat het interessant is om het wel te doen. De codebases die het langst meegaan zijn de codebases waarbij engineers op elk moment weten wat ze doen en waarom.