Valg af softwarearkitektur: monolit eller microservices?

Du vælger den rigtige softwarearkitektur ved at starte med det enkleste, der kan virke, som regel en modulær monolit, og først flytte en del af systemet ud i en selvstændig tjeneste, når et målt behov kræver det. Behovet kan være et andet belastningsmønster, en fejl, der skal isoleres, teams, der blokerer hinanden, eller en compliance-grænse. Sikkerhed, overvågning og sporbarhed indbygges fra dag ét, fordi de er dyre at eftermontere.

Artiklen er til stiftere, produktejere og CTO’er, der skal træffe eller godkende valget. Den bygger på det, vi ser hos bon.do, når vi bygger backends til medicinsk udstyr, sundhedsapps og SaaS-produkter, og når vi overtager systemer, som andre leverandører har startet.

Hvad er softwarearkitektur, og hvorfor er det en forretningsbeslutning?

Softwarearkitektur er systemets opbygning: hvordan systemet er delt op, hvordan delene taler sammen, og hvor dataene ligger. Den afgør, hvor hurtigt du kan ændre produktet, hvad det koster at drive, hvordan det fejler, og hvor let det er at bestå en audit.

Forretningen mærker arkitekturen fire steder:

• Ændringshastighed. Kan et nyt krav leveres i et sprint, eller rammer det fem moduler?
• Driftsomkostninger. Hosting, overvågning og de folk, der skal drive systemet.
• Risiko. Hvad der sker, når en komponent eller en cloud-region går ned.
• Compliance. Om du kan vise en revisor, hvem der ændrede hvad, hvornår og hvorfor.

Derfor bør arkitekturen ikke bestemmes af én udviklers foretrukne teknologistak. Den skal følge produktets udviklingsplan, teamets størrelse og de regler, produktet skal overholde. Et system, der håndterer kliniske data, har andre behov end en intern rapportportal.

Monolit, modulær monolit eller microservices: hvad skal du vælge?

For de fleste nye produkter er en modulær monolit det rigtige udgangspunkt: én applikation og én database, delt i moduler med skarpe grænser. Microservices betaler sig, når flere teams skal kunne udrulle uafhængigt, eller når dele af systemet har tydeligt forskellige krav til belastning, fejlisolering eller compliance.

Microservices er et godt valg, når:

• flere teams skal kunne udvikle og udrulle uden at vente på hinanden;
• en del af systemet har et markant andet belastningsmønster, fx sensordata eller batchkørsler;
• en del af systemet har andre krav til compliance eller isolation.

Microservices er et dårligt valg, når:

• teamet er lille, og driftsbyrden er større end gevinsten;
• grænserne mellem domænerne endnu ikke er forstået;
• overvågning, automatisk udrulning og fejlhåndtering ikke er på plads.

En velopdelt modulær monolit holder døren åben. Skal et modul senere ud som selvstændig tjeneste, er det en flytning, ikke en genopbygning. Serverless-funktioner følger samme logik: de er nyttige til ujævne, hændelsesdrevne opgaver, men kold start, platformens grænser og leverandørbinding gør dem til et dårligt standardvalg for kernen i et reguleret produkt.

Sådan vælger du arkitektur: syv trin

Vælg arkitekturen ud fra produktet, domænet og de ikke-funktionelle krav, ikke ud fra en foretrukken teknologi, og skriv hver beslutning ned, så den kan tages op igen:

1. Forstå produktet. Hvem bruger det, hvilke data behandler det, og hvilke regler gælder (GDPR, MDR, IEC 62304, kundens sikkerhedskrav)?
2. Tegn domænet. Del det i afgrænsede områder, før du vælger teknologi.
3. Skriv de ikke-funktionelle krav ned. Svartider, mål for oppetid, datamængder, opbevaringstid og genetableringstid. De styrer arkitekturen mere, end funktionerne gør.
4. Vælg det enkleste, der kan virke. Du kommer langt med en modulær monolit og en relationsdatabase.
5. Beslut, hvad der skal skalere eller fejle for sig. Kun de dele, der faktisk har et andet behov.
6. Byg sikkerhed, overvågning og sporbarhed ind fra starten. Det er billigere end at eftermontere.
7. Dokumentér beslutningerne. Korte beskrivelser af arkitekturbeslutninger (ADR’er) med kontekst, valg og konsekvens, som I tager op igen, når produktet vokser.

Hvordan påvirker arkitekturen omkostningerne?

Arkitekturen styrer tre omkostninger: prisen for at bygge, prisen for at drive og prisen for at ændre. Den sidste er som regel den største, fordi et system, hvor hvert nyt krav rammer mange moduler, bliver dyrere for hver udgivelse, uanset hvad det kostede at bygge.

Byggeprisen stiger med hver ekstra tjeneste, database og integration, der skal udvikles, testes og udrulles. Microservices er ikke gratis: de kræver netværk, overvågning, pipelines og folk, der kan drive dem.

Driftsprisen afhænger af, hvordan systemet bruger cloud-ressourcer. De vigtigste greb:

• Dimensionér efter målinger, ikke gætværk, og sluk test- og udviklingsmiljøer uden for arbejdstid.
• Bind stabile workloads til reserveret kapacitet eller savings plans, og brug on demand-priser til uforudsigelig belastning.
• Brug managed services til databaser, køer og lagring, hvor det sparede driftsarbejde opvejer den højere enhedspris.
• Hold øje med dataoverførsel, som ofte koster, når trafikken forlader skyen eller krydser regioner.
• Sæt budgetalarmer, fordi forbrugsafregning og autoskalering kan gøre en trafiktop til en stor regning.

Vi har set effekten selv. Da vi genopbyggede appen og backenden til MindPlus, faldt den månedlige hosting- og serviceomkostning med 98%. Produktet havde været gennem flere leverandører og et dyrt hosting-setup; den nye backend blev designet til at kunne køre uden et stort driftsbudget.

Hvordan skalerer du uden at bygge mere end nødvendigt?

Skalér, når målinger viser, at det er nødvendigt, ikke før. Hold applikationen statsløs, så den kan køre i flere instanser bag en load balancer, og giv kun en del af systemet sin egen skalering, når dens belastningsmønster adskiller sig fra resten.

• Vertikal skalering betyder en større maskine. Det er enkelt, men der er et loft, det kræver ofte en genstart, og de største maskiner bliver dyre.
• Horisontal skalering betyder flere instanser. Det kræver statsløs applikationskode, hvor sessioner og tilstand ligger i en database, en cache eller en kø.

På Kubernetes tilføjer eller fjerner Horizontal Pod Autoscaler instanser ud fra CPU, hukommelse eller egne målinger som kølængde. Ifølge Kubernetes-dokumentationen anbefaler eller anvender Vertical Pod Autoscaler nye CPU- og hukommelsesgrænser, enten ved at genskabe pods eller, hvor klyngen understøtter det, ved at ændre dem uden genstart. En genskabt pod er en genstart, så vær forsigtig med den til databaser og andre tilstandsfulde workloads, hvor en genstart betyder et failover.

En månedlig kapacitetsgennemgang er mere værd end en arkitektur, der er bygget til en belastning, som aldrig kommer.

Hvilke sikkerhedsbeslutninger hører til i arkitekturen?

Security by design betyder, at arkitekturen selv begrænser, hvad en angriber kan nå, og hvad en fejl kan ødelægge. Kerneprincipperne er mindst mulige rettigheder, forsvar i dybden, sikre standardindstillinger, en lille angrebsflade og at fejle sikkert.

I praksis:

• Mindst mulige rettigheder. Hver bruger, tjeneste og integration får kun den adgang, den har brug for, styret af rollebaseret adgangskontrol.
• Forsvar i dybden. Netværk, applikation, data og identitet beskyttes hver for sig, så svigt i én kontrol ikke får hele beskyttelsen til at svigte.
• Kryptering af data under overførsel og ved lagring. TLS hele vejen og krypteret lagring af følsomme data.
• Hemmeligheder ud af koden. En secret manager som Azure Key Vault, ikke .env-filer i Git.
• En sikker forsyningskæde. Fastlåste og scannede afhængigheder og en build-pipeline, du kan stole på.

OWASP Top 10:2025 bekræfter, at mange af de største risici på nettet starter i designet: mangelfuld adgangskontrol ligger stadig først, fejlkonfiguration er nummer to, kategorien fejl i softwareforsyningskæden er ny på tredjepladsen, og usikkert design samt mangelfuld logning og alarmering er også på listen. Arbejder I mod ISO/IEC 27001, beder kontrol 8.27 i bilag A jer om at fastlægge og anvende principper for sikker systemarkitektur, og kontrol 8.25 om at bygge sikkerhed ind i udviklingsforløbet. Zero trust er én måde at leve op til det på, ikke et navngivet krav.

Hvordan designer du for driftssikkerhed og overvågning?

Antag, at hver komponent vil fejle, og design efter det. Fjern punkter, hvor en enkelt fejl kan sætte hele systemet ud af drift, hvor forretningen kan bære prisen, og sørg for at kunne se, hvad systemet gør, før brugerne fortæller dig det.

Sørg for:

• Målinger: svartid, fejlrate, kølængde og de forretningstal, der betyder noget.
• Strukturerede logs med et korrelations-id, så én forespørgsel kan følges på tværs af komponenter.
• Distribueret tracing, så snart der er mere end én tjeneste.
• Alarmer kun for det, nogen skal handle på. For mange alarmer, og ingen reagerer.
• Testet backup og gendannelse. En backup, der aldrig er blevet gendannet, er ikke en backup.

Sæt målet for oppetid bevidst. 99,9% tillader omkring 8,8 timers nedetid om året, 99,99% omkring 53 minutter. Hvert ekstra ni-tal kræver mere redundans og automatisering, så vej prisen op mod, hvad nedetid faktisk koster jer. For et medicinsk produkt skal I også designe, hvad brugeren ser, når en tjeneste ikke svarer: kan klinikeren arbejde videre, og hvem får besked?

Hvad ændrer sig, når softwaren er reguleret?

I life science, medtech og sundhed er arkitekturen en del af dokumentationen. Revisorer og bemyndigede organer forventer at se en dokumenteret struktur, sporede krav, styrede ændringer og et revisionsspor, så det hører hjemme i designet fra starten.

• IEC 62304. For softwaresikkerhedsklasse B og C kræver afsnit 5.3 i IEC 62304:2006+A1:2015 en dokumenteret arkitektur, der identificerer softwareenhederne og deres grænseflader, og at arkitekturen verificeres. For klasse C skal den adskillelse, der er nødvendig for risikokontrol, identificeres. En ny udgave af standarden er undervejs; byg efter den, der gælder.
• Sporbarhed. Hvert krav skal kunne følges til et designelement, en test og en udgivelse. Vores guide til ISO 13485 dækker kvalitetssystemet omkring det.
• Revisionsspor. Ifølge 21 CFR 11.10(e) kræver FDA’s Part 11 sikre, systemgenererede og tidsstemplede revisionsspor for elektroniske registreringer, og GxP-kunder vil bede om det samme. Hvem der ændrede hvad, hvornår og hvorfor, skal ligge i datamodellen, ikke i et regneark.
• Logning og GDPR. Logs indeholder ofte personoplysninger. Log det, I har brug for, pseudonymisér id’er, fastsæt slettefrister efter princippet om opbevaringsbegrænsning i GDPR artikel 5, stk. 1, litra e, og beskyt adgangen. ISO/IEC 27001-kontrollerne 8.15 (logning) og 8.16 (overvågning) beskriver forventningerne.

En klar domænemodel med dokumenterede grænseflader er lettere at validere end et system, hvor alt afhænger af alt. To af vores projekter viser, hvordan behovet og ikke moden afgør formen. Backenden, vi byggede til et CE-mærket medicinsk udstyr, er ét .NET-API med SQL Server på Azure, hvor enhedshåndtering, optagelser og kvalitetskontrol er en del af samme backend. Platformen til Wear & Care modtager løbende sensordata og sender alarmer via push, SMS og SignalR, så den bruger beskedkøer og kører i Kubernetes.

Hvornår skal du refaktorere eller dele systemet op?

Refaktorer, når en ændring, der burde være lille, rammer mange dele af systemet. Skil et modul ud som tjeneste, når det skal kunne skalere, udrulles eller fejle for sig selv, eller når flere teams står i vejen for hinanden i samme kodebase. Gør det før den næste funktion, ikke efter.

Advarselstegn, vi kigger efter, når vi overtager et system:

• Små ændringer kræver koordinerede udgivelser af flere dele.
• Ingen kan sige, hvilket modul der ejer et givet stykke data.
• Fejl bliver fundet af kunderne, ikke af overvågningen.
• Spørgsmål fra en audit tager uger at besvare, fordi dokumentationen ligger uden for systemet.

Hvad er næste skridt?

Vælg en arkitektur, der lader dig opfylde det næste krav uden at ødelægge eksisterende funktioner, og som du kan forklare for både en udvikler, en CTO og en revisor. Den behøver ikke være den mest avancerede. Start enkelt, mål, og flyt grænserne, når der er en grund.

Skal du i gang med et nyt produkt, eller sidder du med et system, der er blevet svært at ændre, så book en samtale. Vi ser på jeres krav og giver jer en gratis projektvurdering med et forslag til, hvordan systemet bør opdeles.