Monolit eller microservices? Svaret afhænger af din organisation

Microservices var svaret – men på hvad?

Microservices opstod som et svar på reelle problemer: store, tunge kodebaser, langsomme releases og teams, der konstant blokerede hinanden. Ved at splitte systemer op i mindre, selvstændige services kunne man i teorien opnå hurtigere udvikling, bedre skalerbarhed og mere autonome teams. 

Og i mange organisationer virkede det – i hvert fald i starten. 

Problemet er, at microservices ofte blev adopteret som arkitektonisk standard, snarere end som et situationsbestemt valg. Resultatet er, at mange i dag sidder med systemer, der er teknisk avancerede, men organisatorisk skrøbelige. 

Når microservices bliver en distribueret monolit

Et velkendt antipattern er den såkaldte distributed monolith: Et system, der på papiret består af mange services – men i praksis opfører sig som én stor klump. 

Typiske symptomer er: 

• ændringer kræver deploy af flere services samtidigt
• services deler databaser eller tætte synkrone afhængigheder
• releases koordineres centralt
• fejl ét sted forplanter sig hurtigt gennem systemet

Det er her, begrebet “distribueret monolit” giver mening: Du har fået al kompleksiteten fra et distribueret system – men uden fleksibiliteten. Systemet er blevet sværere at forstå, sværere at teste og sværere at drifte, uden at udviklingshastigheden reelt er steget. 

Monolitten er ikke død – den har fået bedre værktøjer

Samtidig er synet på monolitter blevet mere nuanceret. I dag taler man oftere om modulære monolitter: systemer, der stadig deployes samlet, men som internt er opdelt i klare domæner og moduler. 

En sådan monolit kan være overraskende behagelig at arbejde med. Den er nem at debugge, nem at teste og nem at få overblik over. For mange teams betyder det færre overraskelser i produktion og mindre tid brugt på at forstå, hvorfor noget gik galt et helt andet sted i systemet. 

Det betyder ikke, at monolitter er løsningen på alt – men de er langt fra den forældede arkitektur, de nogle gange bliver fremstillet som. 

Arkitektur følger organisation – ikke omvendt

Et af de vigtigste – og mest oversete – principper i arkitektur er Conway’s Law: Systemers struktur afspejler organisationens kommunikationsmønstre. 

Arkitektur kan med andre ord ikke adskilles fra organisationen. Systemer ender med at afspejle, hvordan teams kommunikerer, træffer beslutninger og tager ansvar. 

Microservices fungerer derfor bedst i organisationer, hvor teams har reelt ejerskab, kan deploye selv og også tage ansvar, når noget går i stykker. Hvis beslutninger stadig skal forbi flere led, eller hvis drift er noget “andre” tager sig af, kan microservices hurtigt blive en kilde til frustration. 

Hvis organisationen ikke er gearet til det, vil arkitekturen ikke redde situationen. Tværtimod kan den forstærke friktion, misforståelser og teknisk gæld. 

DevOps, platforme og den skjulte kompleksitet

Noget af det, der ofte undervurderes, er den driftsmæssige omkostning ved microservices. Microservices stiller høje krav til DevOps-modenhed. CI/CD, observability, logning, tracing, incident-håndtering og sikkerhed bliver ikke nemmere – de bliver flere. 

Mange organisationer opdager for sent, at: 

• hver service kræver pipeline, monitorering og support
• fejl bliver sværere at lokalisere
• driftsansvaret fragmenteres
• platform engineering bliver en forudsætning, ikke et valg

Microservices fjerner med andre ord ikke kompleksitet – de flytter den. Derfor er det vigtigt, at organisationen er klar til at håndtere den dér, hvor den ender. 

Så… hvornår giver hvad mening?

Microservices giver god mening, når der er klare domæner, autonome teams og et reelt behov for uafhængige releases og skaleringsprofiler. Her kan arkitekturen understøtte både tempo og robusthed. 

En monolit – gerne modulær – giver ofte bedre mening, når teamet er mindre, domænet stadig er under udvikling, og overblik og stabilitet er vigtigere end maksimal fleksibilitet. Det er ikke et kompromis, men et bevidst valg.