De vraag komt vroeg of laat in bijna elk project: moeten we niet naar microservices? Meestal wordt die vraag gesteld voordat er een concreet probleem is dat erom vraagt. Het antwoord begint dan al vast te liggen voordat iemand heeft gekeken wat het kost.
Microservices lossen een reëel probleem op: ze maken het mogelijk om onderdelen onafhankelijk te ontwikkelen, uit te rollen en te schalen. Maar het is geen gratis voordeel. Je ruilt interne complexiteit in voor netwerkcomplexiteit, en die laatste is in de praktijk moeilijker te beheersen.
Kort antwoord
- Splits alleen naar microservices wanneer je concrete drijfveren kunt aanwijzen: meetbaar andere schaalbehoeften, teams die elkaar blokkeren, een duidelijke datagrens of een echte behoefte aan onafhankelijke uitrol.
- Kun je er geen twee of drie aanwijzen, overweeg dan een modulaire monoliet in plaats van microservices.
- Een modulaire monoliet is één uitrolbaar systeem met strikte interne grenzen en duidelijke interfaces.
- Het verschil tussen de twee is niet de structuur maar of er een netwerk tussen de onderdelen zit.
- Een slecht afgebakende microservices-architectuur wordt een gedistribueerde monoliet: al het nadeel van beide, zonder het voordeel.
- Grote systemen draaien succesvol als één uitrolbare applicatie. Grote bedrijven doen dit met strikte interne scheiding en tooling die overtredingen van grenzen laat falen.
Het verschil zit niet in de structuur
Dezelfde modules kun je op twee manieren tekenen. Als interne grenzen binnen één applicatie, of als losse diensten met een netwerk ertussen. De domeinen zijn identiek: bestellingen, facturatie, catalogus. Wat verandert is of er een netwerk tussen die onderdelen ligt, en wat dat netwerk je oplevert tegen welke prijs.
Dat is de kern van de keuze. Een netwerk tussen modules geeft je onafhankelijke uitrol en schaling. In ruil daarvoor krijg je alles wat distributed systemen met zich meebrengen: netwerkstoringen, latency, gegevens die niet meer in één transactie passen en de noodzaak om te observeren wat er tussen diensten gebeurt.
Een modulaire monoliet probeert het beste van beide te pakken. Het is één ding om uit te rollen, met de structuur en de grenzen die mensen normaal bij microservices zoeken. Je krijgt de discipline van duidelijke modules zonder de operationele rekening van een netwerk.
Wat een echte modulegrens is
Een modulegrens is meer dan een map. Bestanden groeperen in bestellingen/, facturatie/ en catalogus/ maakt nog geen modulair systeem. De grens betekent dat een module van buitenaf alleen via een gedefinieerde interface te benaderen is, en dat de interne onderdelen niet van buitenaf worden aangeroepen.
In de praktijk is dat het lastige deel. Zonder handhaving verdwijnt de grens binnen een paar maanden, omdat het altijd makkelijker is om even direct bij de interne code van een andere module te komen dan om de interface uit te breiden. Daarom heeft een goede modulaire monoliet ook tooling: de build faalt wanneer de ene module in de interne onderdelen van een andere grijpt.
Dat is precies wat een groot bedrijf deed dat zijn omvangrijke applicatie niet opsplitste. In plaats van het systeem uit elkaar te trekken, trok men harde grenzen binnen het systeem, groepeerde de code in componenten met vaste interfaces en bouwde tooling die de build liet falen bij een overtreding. De applicatie bleef één ding om uit te rollen en kreeg toch de structuur die mensen normaal met microservices bereiken.
Waarom afbakenen in een modulith makkelijker is
De grenzen bepalen is in microservices het moeilijkste onderdeel, en het is een van de belangrijkste redenen waarom veel microservices-architecturen vastlopen. Zodra een grens verkeerd is getrokken en er een netwerk tussen de onderdelen zit, is het verplaatsen van die grens een kostbaar project.
In een modulaire monoliet kun je die afweging nog maken. Modules die te klein zijn of te veel met elkaar praten, kun je samenvoegen. Modules die te groot zijn geworden of te veel afhankelijkheden hebben, kun je opsplitsen. Die flexibiliteit is precies wat je in de beginfase nodig hebt, wanneer je domein nog niet volledig begrepen is.
Wanneer microservices wel de juiste keuze zijn
Dit is geen pleidooi tegen microservices. Het is een pleidooi voor een concreet argument. Er zijn situaties waarin de voordelen opwegen tegen de kosten. Wanneer één onderdeel van je systeem een heel andere schaalbehoefte heeft dan de rest, is onafhankelijke schaling echt winst. Wanneer meerdere teams elkaar blokkeren in één releaseproces, kan een grens dat oplossen. Wanneer je een datagrens helder kunt trekken of echt onafhankelijke uitrol nodig hebt, wordt het netwerk zijn geld waard.
Het patroon dat werkt: verdeel je systeem in logische modules, maar houd de fysieke uitrol één geheel. Pas wanneer je concrete problemen ervaart die alleen een echte scheiding oplost, verplaats je een module naar een eigen dienst. Die volgorde is veiliger dan de omgekeerde.
De gedistribueerde monoliet
De duurste uitkomst is wanneer je splitst zonder de grenzen echt te trekken. Je krijgt dan hetzelfde nauw verbonden systeem, maar nu over een netwerk verdeeld. Elke wijziging raakt nog steeds meerdere diensten, de uitrol is complexer en de fouten zijn moeilijker te vinden, zonder dat je er iets voor terugkrijgt.
Dit gebeurt vaak wanneer de behoefte om te splitsen uit een trend komt in plaats van uit een probleem. Het systeem wordt verdeeld in de vorm van microservices, maar de afhankelijkheden blijven zoals ze waren. Dan heb je al het nadeel van beide werelden.
Conclusie
De vraag is niet of je microservices wilt, maar of je de grenzen wilt en bereid bent de operationele rekening te betalen. Voor de meeste teams is het antwoord: de grenzen wel, de rekening nog niet. Begin met een modulaire monoliet, trek de grenzen echt en handhaaf ze met tooling. Splits pas wanneer een concreet probleem erom vraagt.
Wil je weten of je architectuur klaar is om te splitsen, of hoe je de grenzen binnen je systeem goed trekt? GitCity kijkt graag met je mee naar de opzet en de keuzes erachter. Neem contact op voor een eerste gesprek zonder verplichtingen.