# Monoliet of microservices: kies op teamgrootte en domein

URL: https://brainpowergroup.eu/nl/blog/monoliet-of-microservices
Datum: 2026-01-21
Door: Erik Schoorl, Brainpower Group

Met één team van tot ongeveer acht developers is een modulaire monoliet de betere keuze. Microservices lonen pas als meerdere teams los van elkaar willen releasen.

Voor de meeste producten met één developmentteam is een goed opgedeelde monoliet de betere keuze. Microservices lossen vooral een organisatieprobleem op: meerdere teams die zelfstandig willen bouwen en releasen. Heb je dat probleem niet, dan betaal je de kosten van microservices zonder dat je er iets voor terugkrijgt.

## Microservices lossen een teamprobleem op

In 1967 schreef Melvin Conway dat een organisatie systemen ontwerpt waarvan de structuur een kopie is van haar eigen communicatiestructuur. Dat stuk werd in 1968 gepubliceerd en staat nu bekend als de wet van Conway.

Microservices maken daar gebruik van. Elk team krijgt een of meer services, met een eigen codebase, een eigen database en een eigen release, zodat teams niet op elkaar hoeven te wachten.

Werkt er één team aan het product, dan valt dat voordeel weg. Iedereen praat al met iedereen, er is één backlog en één release, en de grenzen tussen services worden vooral plekken waar je werk dubbel doet.

## Wat microservices kosten

Wat binnen een monoliet een functieaanroep is, wordt een netwerkaanroep die kan falen, traag kan zijn of een oude versie van een contract kan verwachten. Daar komt meer bij:

- Geen gewone databasetransacties meer over services heen, dus werken met eventual consistency, retries en idempotentie.
- Tracing en centrale logging, anders vind je een fout niet terug.
- Een eigen pipeline, monitoring en alerting per service.
- Afspraken over versies van API's en events.
- Een lokale ontwikkelomgeving waarin tien services samen moeten draaien.

Martin Fowler noemde die extra last in 2015 de "microservice premium". In zijn stuk "Monolith First" schreef hij dat bijna alle succesvolle microservice-verhalen begonnen met een monoliet die te groot werd en is opgesplitst. Hij raadt daarom af om een nieuw project met microservices te beginnen.

## Vuistregels per situatie

Een harde grens is er niet. Dit zijn de vuistregels die ik aanhoud:

| Situatie | Keuze |
|---|---|
| Eén team, tot ongeveer acht developers, domein nog in beweging | Modulaire monoliet |
| Twee of drie teams, duidelijke domeinen, wel één releaseritme | Modulaire monoliet met eigenaarschap per module |
| Meerdere teams die los van elkaar willen releasen, stabiele domeingrenzen | Microservices langs die grenzen |
| Eén onderdeel met heel andere belasting of techniek | Alleen dat onderdeel als aparte service |

Die laatste optie kiezen teams volgens mij te weinig. Denk aan beeld- of videoverwerking, een zware import of een AI-onderdeel in Python naast een .NET-backend. Dan haal je dat ene stuk eruit en laat je de rest als monoliet staan.

## Het domein bepaalt waar je knipt

Een service moet een stuk van het domein volledig bezitten: de logica en de data. Kun je die grenzen nog niet goed tekenen, dan kun je ook nog niet goed knippen.

Knip je op de verkeerde plek, dan krijg je een gedistribueerde monoliet. Die herken je hieraan:

- Services moeten samen worden uitgerold.
- Services lezen in elkaars tabellen.
- Een kleine wijziging raakt drie of vier services tegelijk.

Ik vind dat de duurste vorm die er is: je hebt het netwerk en de pipelines van microservices, en de koppeling van een monoliet.

## De modulaire monoliet als middenweg

Een modulaire monoliet is één applicatie die je als geheel uitrolt, intern opgedeeld in modules per domein. Elke module heeft een publieke interface en eigen tabellen, en tooling in de CI bewaakt de grenzen. Je krijgt zo de duidelijke grenzen die je bij microservices zoekt, zonder het netwerk ertussen.

Wil je later toch een module afsplitsen, dan is het grootste werk al gedaan. Aleksa beschrijft hoe je dat opzet in [de modulaire monoliet](/nl/blog/de-modulaire-monoliet).

## Wanneer splitsen wel loont

Er zijn goede redenen om een monoliet op te knippen: teams staan in de rij voor dezelfde release, één onderdeel moet los kunnen schalen, een deel van het systeem valt onder strengere beveiligingseisen dan de rest, of de oude code zit zo in elkaar vast dat elke wijziging iets anders breekt.

Bij ViaLuxury was dat laatste het geval. Betalingen, beschikbaarheid en onboarding waren aan elkaar geknoopt en niet meer te onderhouden. Daar hebben we het platform [opnieuw opgezet rond losse .NET-microservices](/nl/cases/vialuxury), met Stripe voor betalingen en Elasticsearch voor de beschikbaarheid.

Kies je voor microservices, kijk dan ook kritisch naar de infrastructuur. Een handvol services vraagt nog niet om Kubernetes. Aleksa zet de opties op een rij in [heb je Kubernetes nodig](/nl/blog/heb-je-kubernetes-nodig).

## Eigenaarschap weegt zwaarder dan architectuur

Met developers op verschillende locaties is duidelijk eigenaarschap belangrijker dan de architectuur zelf. Wie is eigenaar van welke module, wie reviewt wijzigingen daarin, en waar staan de afspraken? Dat regel je in een modulaire monoliet net zo goed als in microservices.

Microservices verhelpen geen slechte communicatie tussen locaties. Ze maken die eerder zichtbaar, omdat elke onduidelijke afspraak een kapotte integratie oplevert. Begin dus met één codebase en duidelijke modules, en splits pas als daar een concrete reden voor is, zoals teams die op dezelfde release wachten of een onderdeel dat los moet schalen.

## Bronnen

- [Martin Fowler: Monolith First (2015)](https://martinfowler.com/bliki/MonolithFirst.html)
- [Mel Conway: Conway's Law](https://www.melconway.com/Home/Conways_Law.html)

## Veelgestelde vragen

**Vanaf welke teamgrootte zijn microservices zinvol?**

Er is geen harde grens. Mijn vuistregel: zolang één team van ongeveer acht developers het hele product bouwt, is een modulaire monoliet beter. Microservices worden interessant als meerdere teams los van elkaar willen releasen.

**Wat is een gedistribueerde monoliet?**

Een systeem dat uit losse services bestaat, maar waarvan de services toch samen moeten worden uitgerold of dezelfde database delen. Je hebt dan de kosten van microservices zonder de onafhankelijkheid.

**Kun je later van een monoliet naar microservices?**

Ja, en dat is vaak de beste route. Als de monoliet al in modules met duidelijke grenzen is opgedeeld, haal je een module eruit zodra daar een concrete reden voor is, zoals los schalen of een eigen team.

---

Bron: https://brainpowergroup.eu/nl/blog/monoliet-of-microservices
Brainpower Group, contact: https://brainpowergroup.eu/nl/contact, hello@brainpowergroup.eu