Vijf jaar geleden was de boodschap helder: monolieten zijn slecht, microservices zijn goed. Inmiddels weten we beter. Een eerlijke stand van zaken in 2026 — wat hebben we geleerd, en wanneer wint elk model?
Wat de hype ons vertelde
Microservices beloofden:
- Onafhankelijke deploys per service
- Onafhankelijk schalen waar nodig
- Polyglot ontwikkeling — elke service in de beste taal
- Teams die elkaar niet meer hoeven blokkeren
- Failure isolation — één service down betekent niet alles down
De realiteit is gemengder.
Wat we hebben geleerd
1. De distributed systems tax is groter dan verwacht
Een monolithic functie-aanroep is gratis en nooit kapot. Een netwerk-call tussen services kan timeout, vertraagd, of gedeeltelijk slagen. Je moet timeouts, retries, circuit breakers, en error handling overal toevoegen.
Wat in monoliet 100 regels code is, wordt in microservices 800 regels — verspreid over services.
2. Conway's Law slaat altijd terug
Microservices werken alleen als je organisatie structuur erbij past. Eén team per service, met duidelijke ownership. Heb je niet die structuur? Dan worden services politieke lijnen — niemand voelt zich verantwoordelijk voor de "tussenstukken".
3. Debugging is exponentieel moeilijker
Een bug in monoliet: stack trace, je weet waar. Een bug in microservices: het loopt door 8 services, queues, externe APIs. Zonder distributed tracing (Jaeger, Honeycomb) ben je verloren.
4. De data-grenzen zijn de echte bottleneck
"Elke service eigen database" klinkt netjes. In de praktijk: data dat ooit in één query bij elkaar kwam, vereist nu 5 services aanroepen + samenvoegen + cachen. Performance lijdt, complexity explodeert.
5. Operational overhead is enorm
Monitoring 1 service: simpel. 50 services: een fulltime team. Alerting, log aggregation, deployment pipelines, secrets management — alles ×50.
Wanneer wint monoliet?
Monolieten zijn de juiste keuze in deze situaties:
- Team < 20 developers — coördinatie in monoliet is goedkoper dan netwerk-overhead
- Domein nog niet stabiel — boundaries verschuiven, dan zijn services premature optimization
- Performance kritisch — in-process calls zijn 1000x sneller dan netwerk
- Geen DevOps capacity — monoliet kun je deployen, microservices vereisen platform
De moderne "modular monolith" is vaak het beste startpunt: monolithic deploy, maar met strakke module-boundaries. Je kunt later modules uithalen als microservices als de business case er is.
Wanneer wint microservices?
Microservices zijn de juiste keuze als:
- Team > 50 developers — coördinatie wordt het bottleneck
- Domein-grenzen zijn stabiel en duidelijk
- Echt verschillende schaal-eisen per onderdeel — checkout pakt 100x meer load dan admin
- Polyglot maakt verschil — bijv. ML in Python, video in Go, frontend in Node
- Compliance-isolatie — payment in eigen service met aparte access control
Het migratie-pad dat werkt
Heb je nu een monoliet en denk je "wij moeten naar microservices"? Doe het zo niet:
Niet: "Big bang" rewrite naar 30 services. Dat duurt 2 jaar, raakt scope, je weet niet meer welke service waarom bestaat.
Wel: Strangler fig pattern. Identificeer één duidelijk afgegrensd domein (bijv. "notifications"). Bouw die als aparte service. Migreer functionaliteit uit monoliet erheen. Herhaal voor volgend domein. Na 18 maanden heb je 5-8 services en de monoliet is gekrompen — natuurlijk evolutionair pad.
De vergeten optie: serverless functies
Voor sommige use cases (event processing, scheduled tasks, lichte APIs) zijn serverless functies (AWS Lambda, Azure Functions) een tussenoplossing. Geen volledige microservice-overhead, wel onafhankelijk deploybaar.
Concrete checklist
Begin met monoliet als:
- Team < 20 mensen
- Product < 3 jaar oud
- Geen specifieke schaal-issues per component
- Je hebt geen platform-team (DevOps, SRE)
Beweeg naar microservices als:
- Lead time stijgt door coördinatie tussen teams
- Eén component overschaduwd andere in load
- Compliance/security eist isolatie
- Je hebt een platform-team beschikbaar
Worstel je met deze keuze of zit je in een microservices-architectuur die meer pijn doet dan oplost? Plan een gesprek — we hebben veel migraties begeleid en weten waar het mis gaat.
Verder lezen: Technical debt herkennen en Kubernetes — overkill of zinvol.