Mikrotjenester og arkitektur – en guide

Mikrotjenester: fra hype til realitet

For omtrent ti år siden var mikrotjenestearkitektur den hete nye tingen — et konsept popularisert av Netflix, Amazon og Uber som beskrev hvordan store monolitter ble delt opp i hundrevis av uavhengige, deployerbare tjenester. Norske teknologibedrifter kastet seg på bølgen, og snart ble mikrotjenester nesten synonymt med 'moderne arkitektur'.

I 2025 er bildet mer nyansert. Mange av pionerene har offentlig anerkjent at mikrotjenester ble tatt for langt — og flere prominente norske teknologiselskaper har gjennomført det som kalles 're-monolittisering': sammenslåing av tjenester som ble splittet for tidlig. Dette betyr ikke at mikrotjenester er feil, men at den riktige arkitekturbeslutningen avhenger av kontekst, teamstørrelse og modenhetsnivå.

Ekte fordeler med mikrotjenester

Mikrotjenestearkitektur gir reelle fordeler når premissene er oppfylt:

• Uavhengig deploy: Hvert team kan deploye sin tjeneste uten å koordinere med andre team. Kritisk for store organisasjoner med mange parallelle utviklingsteam.
• Teknologifrihet: Ulike tjenester kan bruke ulike programmeringsspråk og databaser basert på hva som er best egnet for oppgaven.
• Feilisolasjon: En tjeneste som krasjer tar ikke ned hele systemet. Resilience patterns som circuit breaker og bulkhead kan isolere feil.
• Skalerbarhet per komponent: Den komponenten som er under høy last kan skaleres uavhengig fremfor å skalere hele applikasjonen.
• Organisatorisk skalerbarhet: Conway's Law — systemer speiler organisasjonens kommunikasjonsstruktur. Mikrotjenester gjør det mulig å skalere antall team uten at koordineringskostnadene vokser eksponentielt.

Kostnadene ved mikrotjenester

Fordelene har en pris. Mikrotjenestearkitektur introduserer operasjonell kompleksitet som mange team undervurderer:

Kommunikasjonsmønstre mellom tjenester

Valget mellom synkron og asynkron kommunikasjon er en av de viktigste arkitekturavgjørelsene i et mikrotjenestesystem. Synkrone REST/gRPC-anrop er enkle å forstå og debugge, men skaper tett kopling og kan forsterke feil i en tjenestekjede. Asynkron kommunikasjon via meldingsbrokere som Apache Kafka, RabbitMQ eller AWS SQS gir løsere kopling og bedre feilisolasjon, men gjør flytforståelse og debugging vesentlig mer kompleks.

Event-driven arkitektur (EDA) med Kafka er blitt standard for data-intensive mikrotjenestesystemer. Norske selskaper som Vipps, Aker BP og Visma bruker Kafka for å transportere hundrevis av millioner hendelser per dag mellom tjenester. Kafka garanterer bestilte meldinger, replay-mulighet og høy gjennomstrømmning — men introduserer et nytt lag av infrastruktur og kompetansebehov.

"Vi gikk for langt med mikrotjenester tidlig. Vi hadde 60 tjenester med 5 utviklere. Det er en oppskrift på kaos. I dag har vi 12 velveldefinerte tjenester og er mye mer produktive."

Monolitten er ikke død – modular monolit som strategi

Martin Fowler og Sam Newman — de mest innflytelsesrike stemmene innen mikrotjenestearkitektur — anbefaler begge at de fleste team bør starte med en godt strukturert monolit og ekstrahere tjenester kun når det er et konkret behov. Praksisen med en 'modular monolit' — en enkelt deployerbar enhet med klare interne modulgrenser — gir mange av fordelene ved mikrotjenester (separasjon av ansvarsområder, tydelige grenser) uten den operasjonelle kostnaden.

Stack Overflow, en av verdens mest besøkte nettsider, kjøres til dags dato primært som en monolit. Shopify gjennomgikk en stor 'modulizeringsinitiativ' der de delte monolittens kodebase inn i 'components' med tydelige grenser uten å dele opp deploymentet. For norske startups og SMB-er er dette eksemplet verdt å ta innover seg.

Anbefaling for norske team

Ikke start med mikrotjenester med mindre du har et eksplisitt behov: uavhengige team-deploy-sykler, ekstremt ulike skalerbarhetskrav per komponent, eller tydelige domene-grenser definert gjennom Domain-Driven Design (DDD).

Bygg i stedet en 'monolit-first'-arkitektur med klare domene-grenser innad i kodebasen. Når smerten av en enkelt deploysyklus blir reell — når to team faktisk venter på hverandre regelmessig — er det tid for å ekstrahere den første tjenesten. Gjort i riktig rekkefølge, med god domenekunnskap og riktig infrastrukturgrunnlag (Kubernetes, CI/CD, observability), er mikrotjenester et kraftig virkemiddel. Gjort for tidlig er det en kognitiv og operasjonell byrde som senker hastigheten.