Architectuur

Microservices of monoliet: waarom het MKB bijna altijd beter af is met één applicatie

Leroy Steding·10 augustus 2026·2 min leestijd

Microservices zijn ontworpen om iets op te lossen wat weinig MKB-bedrijven hebben: tientallen ontwikkelaars die elkaar in de weg lopen. Wie die situatie niet heeft, koopt de kosten zonder de opbrengst.

Waar microservices vandaan komen

De architectuur is groot geworden bij bedrijven waar zoveel mensen aan één codebase werkten dat elke release een onderhandeling werd. Door de applicatie op te knippen in losse diensten met eigen databases kon elk team zelfstandig uitrollen. Dat is een organisatorische winst, geen technische.

Werk je met één, twee of vijf ontwikkelaars, dan bestaat dat probleem niet. Er is niemand die je in de weg loopt.

Wat het je kost

• Een aanroep die eerst een functie was, is nu een netwerkverzoek dat kan mislukken. Dat moet je overal afvangen.
• Transacties over twee diensten heen bestaan niet meer. Wat vroeger één database-transactie was, wordt handwerk met compensaties.
• Een fout opsporen betekent logs van vier diensten naast elkaar leggen. Zonder gedeelde tracing ben je uren kwijt aan wat lokaal één stacktrace was.
• Uitrollen wordt orkestratie: versies die bij elkaar passen, migraties in de juiste volgorde, en een omgeving die dat allemaal beheert.

Elk van die punten is oplosbaar. Bij elkaar zijn ze een dagtaak, en die dagtaak betaalt zichzelf pas terug bij een omvang die je waarschijnlijk niet hebt.

Wanneer het wél zin heeft

Er zijn goede redenen om één onderdeel apart te zetten, en die hebben zelden met teamgrootte te maken:

• Een onderdeel dat heel anders schaalt. Een importpipeline die af en toe zwaar draait, wil je niet in dezelfde processen als je webshop.
• Een onderdeel met andere eisen. Iets dat medische gegevens verwerkt heeft andere logging en bewaartermijnen nodig dan de rest.
• Een onderdeel in een andere taal. Als het rekenwerk in Python hoort, is dat een dienst - niet omdat het mode is maar omdat het moet.

Merk op dat dit steeds om één onderdeel gaat. Eén dienst naast een monoliet is een normale, gezonde architectuur. Dat is iets anders dan twaalf diensten omdat het zo hoort.

Hoe je nu begint

Bouw één applicatie, maar knip hem vanbinnen op in modules met duidelijke grenzen: aparte mappen, aparte tabellen, geen kriskras-aanroepen. Zolang die grenzen scherp zijn, is er later een module uit te trekken als daar aanleiding voor is. Wie dat vooraf doet, betaalt jaren voor een keuze die hij misschien nooit nodig heeft.

Lees verder

← Meer artikelen