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.