For en lille SaaS er svaret næsten altid en monolit, gerne en velopdelt en. En monolit er ét samlet system, der udgives som én enhed. Microservices er mange små, selvstændige tjenester, der taler sammen over netværket. Microservices er en løsning på et organisatorisk problem: at mange teams skal kunne arbejde uden at stå i vejen for hinanden. Har I et lille team, har I ikke det problem, og så får I regningen for løsningen uden gevinsten. Den modulære monolit, hvor koden er delt i klare dele inden for ét system, er den mellemvej, de fleste virksomheder i jeres størrelse har bedst af.
Forskellen forklaret for en direktør
Forestil jer et firma, der arbejder i ét stort kontor. Alle kan råbe til hinanden, og en ændring kan laves på et øjeblik. Det er monolitten. Med tiden bliver det larmende, og folk står i vejen.
Microservices svarer til at flytte hvert team ind i sit eget hus. Holdene kan arbejde i ro, og til gengæld skal al kommunikation foregå med post, og postvæsenet skal fungere. Hvis et brev bliver væk, skal nogen finde ud af hvor. Netværket mellem tjenesterne bliver en del af produktet, og det kan fejle, være langsomt eller levere tingene i forkert rækkefølge.
Det, microservices koster
Det er let at sælge fordelene: tjenester kan skaleres hver for sig, udgives uafhængigt og skrives i forskellige sprog. Ulemperne står sjældnere i præsentationen.
- Drift. I skal køre, overvåge og opdatere mange ting i stedet for én. Det kræver værktøjer og folk.
- Fejlfinding. En fejl hos brugeren kan gå gennem flere tjenester. Der skal ekstra udstyr til at følge sporet.
- Sammenhæng i data. I en monolit kan én handling gemme flere ting på én gang. Går handlingen på tværs af tjenester, skal I selv håndtere, at noget lykkes, og noget fejler.
- Langsommere ændringer på tværs. En ændring, der rører tre tjenester, kræver tre udgivelser i den rigtige rækkefølge.
- Test. Det bliver sværere at afprøve hele produktet samlet.
For et team på få udviklere kan den slags arbejde sluge den tid, der skulle være gået til produktet. Der er også en menneskelig side. Med fem udviklere og et dusin tjenester ender hver tjeneste med at være én persons viden.
Hvornår microservices giver mening
Opdeling kan være det rigtige, når I ser konkrete tegn:
- Teamet er vokset, så flere selvstændige hold konstant venter på hinanden.
- Én del af produktet har en helt anden belastning end resten, og det er målt.
- En del har andre krav til sikkerhed eller placering af data, fx hos bestemte kunder.
- Udgivelser er ofte blokeret af en anden gruppes arbejde, selv om koden allerede er godt opdelt.
Selv da behøver I sjældent at gå hele vejen. Ofte er det nok at trække én eller to dele ud af monolitten, resten kan blive. Tænk i små skridt, og mål, om det hjalp. Hvornår teamet når den størrelse, handler fra fem til tyve udviklere om.
Den modulære monolit
I en modulær monolit er koden delt i selvstændige områder med klare grænser, fx fakturering, brugere og rapporter. Områderne taler sammen gennem aftalte indgange og pilles ikke fra hinanden. Det hele udgives stadig som ét system.
Det giver to gevinster. I får det meste af overblikket fra microservices uden omkostningerne ved netværket. Og I holder døren åben: en del med klare grænser kan flyttes ud, den dag der er en god grund. Omvendt kan et system af dårligt opdelte microservices være det værste af begge verdener, hvor alt alligevel afhænger af alt.
Prisen er disciplin. Grænserne skal holdes, ellers vokser monolitten sammen til det, udviklere kalder en stor mudderkugle. Automatiske kontroller kan hjælpe, og beslutningerne skal være skrevet ned, se skriv de tekniske beslutninger ned.
Når en udvikler eller leverandør foreslår microservices
Forslaget kommer ofte i god tro, og nogle gange er det rigtigt. Som ledelse kan I stille disse spørgsmål:
- Hvilket konkret problem løser det, som vi har i dag?
- Hvordan har vi målt problemet?
- Hvem skal drive og overvåge de ekstra dele, og hvad kræver det?
- Hvad kan vi prøve først, som er mindre?
- Hvad sker der med hastigheden i de første måneder?
Er svaret en henvisning til, hvad store internationale virksomheder gør, så husk forskellen i størrelse. Læg også mærke til, om leverandøren tjener på den ekstra kompleksitet. Står I omvendt med et gammelt, sammenfiltret system, er spørgsmålet et andet, og det handler mere om vejen videre, se skal produktet skrives om.
Sådan træffer I beslutningen
Beslutningen hører til dem, der er dyre at ændre, så giv den en ejer. Skriv det valgte ned sammen med de omstændigheder, der ville få jer til at ændre mening. For de fleste små SaaS-virksomheder lyder notatet nogenlunde sådan: vi bygger en modulær monolit, vi holder grænserne mellem områderne, og vi tager spørgsmålet op igen, når teamet er blevet til flere hold, eller når en måling viser en del, der ikke kan følge med.
Det skal I lade være med
· At vælge microservices, fordi det lyder modent. Modenhed viser sig i, at valget passer til jer.
· At dele systemet op for at løse rod i koden. Roden følger med og bliver nu fordelt over netværket.
· At undervurdere driften. Hver ny tjeneste er noget, der kan gå ned om natten.
· At bruge en omlægning som erstatning for at prioritere. Kunderne får intet ud af den alene.
Det skal I kræve af den eksterne
- ☐ En anbefaling begrundet i teamets størrelse og produktets faktiske belastning.
- ☐ En forklaring, der kan følges af en direktør uden teknisk baggrund.
- ☐ Klare tegn på, hvornår beslutningen skal tages op igen.
- ☐ En plan for, hvordan grænserne i koden holdes.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Når kunderne bliver flere · Hvem ejer driften?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
