Microservices hebben een sterke reputatie: knip je software op in losse services en je kunt elk onderdeel apart aanpassen, schalen en vervangen. Die voordelen bestaan. Maar er hangt een prijskaartje aan dat in de meeste voordelenlijstjes ontbreekt, en voor veel organisaties is een goed opgebouwde monoliet de verstandiger keuze.
De vraag is dus niet of microservices voordelen bieden, maar of die voordelen in jouw situatie opwegen tegen de extra complexiteit. Die afweging kun je maken zonder zelf te programmeren. Je hebt er vooral kennis van je eigen organisatie voor nodig.
Eén systeem of een verzameling losse services
Bij een monolithische architectuur vormt je applicatie één geheel: één codebase, één deployment. Wil je iets wijzigen, dan zet je het complete systeem opnieuw live. Microservices knippen datzelfde systeem op in zelfstandige onderdelen, bijvoorbeeld een aparte service voor gebruikersbeheer, een voor betalingen en een voor rapportages. Elke service wordt apart ontwikkeld, getest en uitgerold.
Dat klinkt als een detail voor ontwikkelaars, maar het bepaalt hoe je organisatie met de software kan werken: wie waaraan kan werken, wat er stilligt bij een storing en waar je capaciteit bijzet als het druk wordt.
Waar de winst zit
Neem een klantenserviceapplicatie waarin de chatfunctie de hele dag zwaar wordt gebruikt, terwijl de rapportagemodule vooral rond de maandafsluiting draait. Met microservices geef je alleen de chatservice extra capaciteit; de rest van het systeem blijft ongemoeid. In een monoliet schaal je noodgedwongen alles tegelijk op, ook de delen die dat niet nodig hebben.
Hetzelfde geldt voor storingen. Valt in die opzet de rapportageservice uit, dan werken chat en orderverwerking door. En werken er meerdere teams aan het systeem, dan kan elk team zijn eigen service uitrollen zonder op de anderen te wachten. Hoe software mee kan groeien met je organisatie beschrijven we breder in hoe maatwerksoftware meeschaalt met bedrijfsgroei.
De prijs die je ervoor betaalt
Elke service die je toevoegt is er ook een die je moet draaien. Hij heeft zijn eigen deployment, zijn eigen monitoring en zijn eigen storingen. Wat in een monoliet een interne functieaanroep was, wordt tussen services netwerkverkeer dat kan haperen. Gegevens raken verspreid over meerdere services en moeten toch consistent blijven. En een fout opsporen betekent zoeken door meerdere systemen in plaats van één logboek.
Die overhead vraagt om een team dat thuis is in gedistribueerde systemen en om een organisatie die dat beheer kan dragen. Is die er niet, dan gaan de voordelen op papier verloren aan de complexiteit in de praktijk.
Vier vragen die de afweging scherp maken
Of microservices voor jouw maatwerksoftware lonen, hangt vooral af van vier dingen:
- Werken er meerdere teams aan het systeem die elkaar bij releases in de weg zitten?
- Verschilt de belasting zo sterk per onderdeel dat apart schalen merkbaar prestaties of kosten scheelt?
- Moeten onderdelen blijven draaien wanneer een ander deel uitvalt?
- Verandert het ene deel van het systeem veel sneller dan het andere?
Beantwoord je de meeste van deze vragen met ja, dan is de architectuur het onderzoeken waard. Beantwoord je ze met nee, dan koop je met microservices vooral beheerlast.
Wanneer je er beter vanaf blijft
Een interne planningstool voor één afdeling, onderhouden door één team, met een voorspelbare belasting: zo’n systeem wordt niet beter van opknippen. Daar past een modulaire monoliet, één applicatie die intern strak is opgedeeld in modules met duidelijke grenzen. Die geeft je veel van dezelfde overzichtelijkheid, zonder dat elk onderdeel zijn eigen infrastructuur nodig heeft.
Zo’n opzet houdt bovendien de deur open. Groeit het systeem en wordt de behoefte aan losse services later alsnog reëel, dan liggen de grenzen waarlangs je kunt knippen er al. Beginnen met een monoliet is dan geen achterstand, maar een besparing.
Sta je zelf voor deze keuze, dan is ons belangrijkste advies: laat de architectuur volgen uit je organisatie, niet andersom. Bij het ontwikkelen van maatwerkapplicaties beginnen we daarom bij die vier vragen, en kiezen we pas daarna de techniek die het antwoord waarmaakt.