Neem contact met ons op:
Type something to search...
to navigateto selectESC to close

Technical leadership

Engineering
Je hebt geen microservices nodig
Door Lumia Labs/ Op 09 Feb, 2026

Je hebt geen microservices nodig

Segment bouwde meer dan 140 microservices voor hun event routing. Drie ontwikkelaars besteedden uiteindelijk het grootste deel van hun tijd aan onderhoud in plaats van features bouwen. Ze stapten terug naar een monoliet. In plaats van sneller te werken, schreef Alexandra Noonan, verdronk het kleine team in complexiteit. We zien dit patroon ook bij klanten. Amazon's Prime Video-team stapte over van serverless microservices naar een monoliet en verlaagde de infrastructuurkosten met 90%. Zelfs het bedrijf dat service-oriented architecture uitvond, kwam erachter dat het niet altijd het juiste antwoord is. Amazon's architectuur is niet de jouwe De microservices-beweging begon omdat monolithische applicaties onhandelbaar werden naarmate teams groeiden. Conway's Law speelde zich af: grote codebases dwongen ontwikkelaars tot eindeloos afstemmen. Jeff Bezos stuurde rond 2002 zijn beroemde API-mandaat waarin hij alle Amazon-teams verplichtte om via service-interfaces te communiceren. Die architectuurkeuze maakte AWS mogelijk. Het patroon werkte voor Amazon, dus iedereen kopieerde dat. In 2020 vond O'Reilly dat 77% van de organisaties microservices had overgenomen. Maar de meeste van die organisaties zijn Amazon niet. Ze hebben geen duizenden ontwikkelaars, geen decennia aan infrastructuurtooling, en niet het budget om honderden onafhankelijke services te beheren. Martin Fowler zag het al in 2015, hij schreef: bijna alle succesvolle microservices-verhalen begonnen met een monoliet die te groot werd en werd opgesplitst. Bijna alle gevallen waarbij een systeem vanaf het begin als microservices werd gebouwd, liepen vast. De meeste microservices zijn verkapte monolieten De meeste microservice-architecturen waar we mee werken doen niet wat ze beloven. Fouten die we zien:Meerdere services delen een database, waardoor migraties van het schema lastig worden Lastig om één wijziging in één service te deployen, door lekkende abstracties en verborgen afhankelijkheden Moeilijk om leveringen over teams te coördineren, omdat services niet onafhankelijk zijn Slecht API-ontwerp, waardoor services hun interne werking blootleggen (dit is ook slecht in monolieten, maar daar zit het nog in één delivery) Een storing in één service rolt door het hele systeemTaibi, Lenarduzzi en Pahl catalogiseerden 20 van dit soort antipatronen via gesprekken met ontwikkelaars. De meeste herkennen we. Het heeft een naam: de distributed monolith. Je betaalt de volledige operationele kosten van microservices, maar krijgt niets van de onafhankelijkheid. Elke service-hop voegt latency toe, en debuggen over servicegrenzen duurt zo'n 35% langer dan in één proces. Kelsey Hightower, destijds Distinguished Engineer bij Google Cloud, was er duidelijk over: monolieten zijn de toekomst, want microservices lossen een probleem op dat er niet is. Je gaat van slechte code naar slechte infrastructuur waar je diezelfde slechte code bovenop draait. Wat ons betreft wordt de complexiteit voor teams te vaak over het hoofd gezien. Team Topologies-onderzoek van Matthew Skelton en Manuel Pais bevestigt dit: niet de architectuurkeuze doet ertoe, maar of je team die architectuur aankan. Microservices verveelvoudigen wat een team moet begrijpen: networking, service discovery, distributed tracing, container orchestration. Method calls, niet netwerkcalls Er is een andere optie: de modulaire monoliet. Eén deployment met strikte interne grenzen tussen domeinmodules, waar communicatie via method calls gaat in plaats van netwerkcalls. Eén testpipeline, één deployment, maar mét de structuur die spaghetti voorkomt. Shopify draait een van de grootste Ruby on Rails-applicaties ter wereld: 2,8 miljoen regels code, meer dan 500.000 commits, honderden actieve ontwikkelaars. Ze evalueerden microservices en wezen ze bewust af. Kirsten Westeinde van Shopify's engineeringteam schreef dat ze een oplossing wilden die modulariteit bood zonder het aantal deployments te vergroten. Dat leverde 37 componenten op met duidelijke grenzen, afgedwongen door tools als Packwerk voor statische analyse. Ontwikkelaars werken binnen heldere grenzen zonder de overhead van gedistribueerde systemen. DHH van Basecamp beschreef hun aanpak in 2016: 12 programmeurs die miljoenen gebruikers bedienen op zes platformen, met een monoliet van 200 controllers en 190 modelklassen. In 2023 schreef hij "How to Recover from Microservices", met Gall's Law als uitgangspunt: een complex systeem dat werkt, is altijd ontstaan uit een simpel systeem dat werkte. Zelfs Google erkende het patroon. Hun Service Weaver-framework laat je een applicatie schrijven als modulaire monoliet en pas als microservices deployen wanneer dat nodig is. De architectuur begint simpel en wordt alleen complexer waar het systeem erom vraagt. De meeste teams zijn te klein voor microservices Microservices lossen problemen op die eenvoudigere architecturen niet aankunnen. Honderden ontwikkelaars die onafhankelijk moeten deployen. Componenten met fundamenteel andere schaaleisen. Op die schaal verdienen microservices hun complexiteit terug. Stefan Tilkov stelt dat een monoliet leidt tot koppeling die je er later moeilijk uit krijgt. Daar heeft hij gelijk in, als je geen modulegrenzen afdwingt. Maar hij nuanceert het zelf: de aanpak vereist diepe domeinkennis en past alleen bij grotere systemen. Het onderzoek achter Accelerate (Forsgren, Humble, Kim) laat zien dat topteams architectuur hebben waarmee teams onafhankelijk kunnen deployen. Dat kan met microservices, maar net zo goed met een modulaire monoliet. Teamautonomie bepaalt het resultaat, niet het architectuurpatroon. Als je engineeringteam kleiner is dan 50 ontwikkelaars, heb je vrijwel zeker geen microservices nodig. Begin met modules en stap over op microservices als dat nut heeft. Eerst modules, dan pas services Als we teams helpen met hun software-architectuur, gebruiken we deze principes: Trek eerst domeingrenzen. Snap je bedrijfsdomeinen voor je een architectuur kiest. Goede domeinkennis is de basis voor een goede architectuur. Dwing grenzen af in code. Modulegrenzen zonder handhaving vervagen binnen een paar maanden. Gebruik tooling als SonarQube om schendingen zichtbaar te maken. Meet de belasting op je team. Besteedt je team meer tijd aan infrastructuur dan aan features? Dan is je architectuur te complex. Plan vooruit. Een goed gemodulariseerde monoliet kan doorgroeien naar microservices wanneer nodig. Ontwerp modules alsof ze services kunnen worden.Lumia Labs helpt organisaties met architectuurkeuzes. Heroverweeg je je architectuur? We horen graag van je.

Engineering
De Architectuur Review Checklist
Door Lumia Labs/ Op 16 Jan, 2026

De Architectuur Review Checklist

Een software systeem overnemen is een uitdaging. Misschien ben je net begonnen als CTO of nieuwe developer. Misschien heeft je bedrijf software overgenomen. Misschien zijn de oprichters of het oude team vertrokken en is het nu aan jou. De documentatie is karig. De git-historie vertelt verhalen waar je niet bij was. Het systeem draait, meestal, maar je weet niet precies waarom. Laat staan wanneer het gaat omvallen. Dit artikel geeft je vragen. Vragen die problemen blootleggen voordat ze zichzelf aankondigen. Je leert meer van de vragen die je niet kunt beantwoorden dan van de vragen die je wel kunt beantwoorden. Elke keer dat je "geen idee" moet zeggen, weet je waar je op kunt focussen. Drie gebieden zijn belangrijk: beveiliging, operations en aanpasbaarheid. Elk gebied legt andere risico's bloot, en samen vertellen ze je wat voor software je in huis hebt. Beveiliging Beveiliging in dit soort systemen is speurwerk. Beslissingen genomen door mensen die er niet meer zijn, gebaseerd op aannames die misschien niet meer kloppen. Jouw taak: uitpluizen. Kun je het volledige pad volgen van gebruikersinvoer naar de database? Authenticatie zit in de ene service, autorisatie ergens anders, inputvalidatie verspreid over drie microservices. Waar componenten elkaar raken, daar vind je de zwakke plekken. Wat is de schade als één component wordt gehackt? Kijk naar gedeelde database-credentials, service accounts met onbeperkte toegang, secrets in environment variables die elke service kan lezen. Dit was logisch toen het systeem nog klein was met 3 ontwikkelaars met één server. Nu betekent het dat één hack overal doorwerkt. De Target-hack van 2013 begon met de credentials van een airco-leverancier en eindigde met 40 miljoen gestolen creditcards. Eenmaal binnen konden aanvallers overal bij. Wat als authenticatie niet meer werkt? Als de authenticatieservice down gaat, falen requests dan of gaan ze door? Onder druk falen veel systemen open: de "tijdelijke bypass" die nooit is verwijderd, de fallback die validatie overslaat of minder goed beveiligd is. Dit zit in bijna elke codebase. Vind het voordat een aanvaller het vindt. Welke beveiligingskeuzes passen niet meer bij hoe het systeem nu wordt gebruikt? Het single-tenant systeem dat multi-tenant werd, de interne tool die naar klanten ging. Beveiligingsfouten kunnen meerdere productreleases overleven, vooral als ze uit dependencies komen. Vraag wanneer de laatste security review was. Vraag dan wat er sindsdien is veranderd. Beveiligingslekken kunnen kostbaar worden. Probeer een goed beeld te vinden van waar de risico's zich bevinden. Operationele Paraatheid Je ontdekt hoe software faalt door ernaar te kijken, niet door te wachten tot het daadwerkelijk gebeurt. Operationele paraatheid betekent dat je bugs kunt oplossen voordat je klanten erover beginnen te posten op social media. Wat gebeurt er als het systeem 's nachts down gaat? Als er iets faalt, wordt dan de juiste persoon genotificeert, en heeft deze genoeg informatie om het probleem te kunnen oplossen? Veel van dit soort systemen sturen alerts naar Slack-kanalen die niemand bekijkt, en zeker niet na kantooruren. Dat is schijnveiligheid, geen werkende monitoring. Check wie er echt on-call is, welke informatie ze krijgen, en of ze er iets mee kunnen. Op welke manier heeft dit systeem nog nooit gefaald? Als het systeem nooit een database-failover heeft meegemaakt, of een externe service die wegviel, nooit echte productiebelasting heeft doorstaan, dan weet je niet hoe het zich gedraagt in die scenario's. Geen incidenten kan betekenen dat het systeem robuust is, maar het kan ook betekenen dat dit nog kan komen. Welke alerts worden door iedereen genegeerd? Te veel valse meldingen creëren een gevaarlijk patroon: teams leren alerts negeren, waardoor echte problemen onzichtbaar worden. Analyseer: hoeveel alerts kwamen binnen en hoeveel waren terecht? Minder dan de helft bruikbaar? Dan verstoort je monitoring meer dan het beschermt. Hoe lang duurt herstel echt, en heb je het ooit getest? De meeste van dit soort systemen hebben backups die nooit zijn teruggezet, failover-procedures die nooit zijn uitgevoerd, en runbooks van mensen die jaren geleden vertrokken. Je 'theoretische' hersteltijd betekent niets tot je het onder druk hebt doorlopen. GitLab leerde dit op de harde manier in 2017 toen ze tijdens een incident ontdekten dat hun backups niet werkten. Ter referentie: DORA-onderzoek laat zien dat topteams binnen een uur herstellen. Zwakke teams doen er een week tot een maand over. Wie weet echt hoe het systeem werkt? Als het antwoord 'één persoon' is, heb je een single point of failure. Onderzoekers noemen dit de "busfactor," het aantal mensen dat kan vertrekken voordat een project vastloopt. Een studie bij JetBrains toonde aan dat bestanden die niet meer door hun oorspronkelijke ontwikkelaars worden aangeraakt, verlaten blijven. Permanente blinde vlekken in de codebase. Als 'het vertrokken team' je antwoord is, vertrouw je op kennis die al begint te verdwijnen. Aanpasbaarheid Als ontwikkelaars niet durven te refactoren, worden kleine aanpassingen opgespaard tot gevaarlijke mega-releases. Bugfixes blijven liggen uit angst voor onverwachte bijwerkingen. De technische schuld groeit omdat iedereen de risicovolle modules mijdt. Enquêteonderzoek in de software-industrie toont aan dat teams 23% van hun ontwikkeltijd verspillen aan technical debt. Tijdsdruk is de belangrijkste oorzaak. Angst is een valide maatstaf voor architectuurkwaliteit. Waar weigeren developers aan te werken in het systeem? Elk systeem heeft dit soort black boxez: de facturatiecode die niemand helemaal snapt, de koppeling met dat legacy-systeem bij elkaar gehouden door WD-40 en duct tape. Dit worden permanente blinde vlekken en zijn risicovol. Wat is het ergste dat kan gebeuren door een typfout? Kan één verkeerd teken productie platleggen? Een gezond systeem kan omgaan met kleine fouten, terwijl een gevoelig systeem kleine fouten keihard afstraft. Vinden je tests echt bugs? Een groene testsuite die niet alles test zorgt voor vals vertrouwen. Teams deployen omdat de tests slaagden, terwijl de tests niet testten wat belangrijk was. Kijk naar de laatste bugs die productie bereikten. Hadden de tests die bugs moeten voorkomen? Hoe lang duurt het voor een nieuwe engineer code kan deployen? Dit is een productiviteitsmetric die wrijving meet. Als het maanden kost om het systeem goed genoeg te begrijpen om veilig code bij te dragen, zal ontwikkeling aan het systeem altijd traag zijn. De codebase werkt tegen. Bij Etsy deployen nieuwe engineers op hun eerste dag. Kun je een foute deploy binnen minuten terugdraaien? De snelheid waarmee je kunt herstellen bepaalt je bereidheid om te deployen. Als rollback een nachtmerrie is, durf je niet meer te deployen. Teams nemen geen risico's meer en productiviteit en innovatie stopt. Wat Nu Met Deze Antwoorden Begin met de vragen die je niet kon beantwoorden. Dat zijn je blinde vlekken, en blinde vlekken blijven niet voor altijd verborgen. De antwoorden die je zorgen baren: schrijf ze nu op. Volgende week is de urgentie weg, en het systeem blijft draaien terwijl je jezelf vertelt dat het waarschijnlijk wel goed zit. Leg de zorgen vast en pak dit aan. Deze vragen geven je geen compleet beeld, het is een beginpunt. Ze vertellen je waar de gaten kunnen zitten, en daar begin je met oplossen.Lumia Labs werkt samen met organisaties met legacy systemen. Heb je behoefte aan een frisse blik op je systeem? Laten we praten.