{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/microservices","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/microservices/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/microservices/"},"term":{"en":"Microservices","da":"Microservices"},"aka":{"en":["microservice architecture"],"da":["microservice-arkitektur"]},"domain":["platform","cs"],"cluster":"containers","layer":"application","status":"current","era":2014,"summary":{"en":"A way of building an application as many small, separate services that each do one job and talk to each other over an API.","da":"En måde at bygge et system på som mange små, selvstændige tjenester, der hver løser én opgave og taler sammen via et API."},"body":{"formal":{"en":"A design style in which an application is split into small services, each with its own code, data and release cycle, that run as separate processes and work together only through calls over the network.","da":"En designstil, hvor et system deles op i små tjenester med hver deres kode, data og egen takt for nye versioner, som kører som separate processer og kun arbejder sammen via kald over netværket."},"plain":{"en":"Like a food court instead of one big kitchen - each stall cooks one thing, can close for repairs on its own, and customers order from several at once.","da":"Som en food court i stedet for ét stort køkken - hver bod laver én ting, kan lukke for reparation uden de andre, og kunderne bestiller fra flere på én gang."},"inPractice":{"en":"A municipality's citizen portal is split into separate services for bookings, payments and messages; the payments team can ship a fix on Tuesday without touching or restarting the rest.","da":"En kommunes borgerportal er delt op i separate tjenester til bookinger, betalinger og beskeder; betalingsteamet kan sende en rettelse ud om tirsdagen uden at røre ved eller genstarte resten."},"whyItMatters":{"en":"Small services let teams move and grow parts on their own, but every service and every call between them is one more door to lock, so the attack surface grows.","da":"Små tjenester lader teams udvikle og skalere dele hver for sig, men hver tjeneste og hvert kald imellem dem er endnu en dør, der skal låses, så angrebsfladen vokser."}},"deepDive":{"en":"The term was consolidated by James Lewis and Martin Fowler's March 2014 article, which described characteristics rather than a specification: componentisation via services rather than in-process libraries, organisation around business capabilities, products not projects, smart endpoints and dumb pipes, decentralised governance and data management, infrastructure automation, design for failure and evolutionary design. Service boundaries are usually drawn along bounded contexts from domain-driven design, and Conway's law (1968) predicts that they will mirror team structure - which is why the style is as much an organisational choice as a technical one.\n\nOwning data per service is the defining and hardest constraint. Without a shared database there are no cross-service ACID transactions, so consistency is achieved with sagas (a chain of local transactions with compensating actions), the transactional outbox pattern to publish events atomically with state changes, idempotent consumers and eventual consistency. Communication is either synchronous (REST over HTTP, gRPC) or asynchronous (Kafka, AMQP brokers); synchronous chains multiply latency and failure probability, because availability of a call path is roughly the product of the availabilities of its hops. Resilience patterns - timeouts, retries with exponential backoff and jitter, circuit breakers, bulkheads - and distributed tracing with W3C Trace Context propagation, typically via OpenTelemetry, are therefore mandatory rather than optional. A system that must be deployed in lockstep or shares a schema across services is a \"distributed monolith\": it pays the network cost without the independence.\n\nSecurity changes shape rather than simply growing. Perimeter controls at an API gateway handle north-south traffic, but east-west calls between services need their own authentication and authorisation. NIST SP 800-204 (2019) sets out security strategies for microservices, and its companions SP 800-204A and 800-204B cover service-mesh deployment and attribute-based access control within a mesh. A service mesh such as Istio or Linkerd gives every workload a cryptographic identity (often in SPIFFE format), enforces mutual TLS and applies per-route policy through sidecar or node-level proxies. End-user identity is propagated with signed tokens (JWT access tokens, OAuth 2.0 token exchange per RFC 8693) so that each service can enforce object-level authorisation itself; failing to do so produces Broken Object Level Authorization, API1:2023 in the OWASP API Security Top 10.\n\nMicroservices are an architecture style and are independent of containers or Kubernetes, though they are commonly deployed that way. They contrast with a modular monolith, which enforces module boundaries inside one deployable and avoids network failure modes; for small teams that is often the better trade-off, and several well-publicised migrations have gone back from microservices to fewer, larger services.","da":"Begrebet blev samlet i James Lewis og Martin Fowlers artikel fra marts 2014, der beskrev kendetegn frem for en specifikation: opdeling i komponenter via tjenester frem for biblioteker i samme proces, organisering efter forretningsevner, produkter frem for projekter, smarte endepunkter og dumme rør, decentral styring og datahåndtering, automatiseret infrastruktur, design for fejl og evolutionært design. Grænserne mellem tjenester trækkes normalt efter bounded contexts fra domænedrevet design, og Conways lov (1968) forudsiger, at de vil afspejle teamstrukturen - derfor er stilen lige så meget et organisatorisk valg som et teknisk.\n\nAt hver tjeneste ejer sine egne data er den definerende og sværeste begrænsning. Uden en fælles database findes der ingen ACID-transaktioner på tværs af tjenester, så konsistens opnås med sagaer (en kæde af lokale transaktioner med kompenserende handlinger), transactional outbox-mønstret til at udgive hændelser atomisk sammen med tilstandsændringer, idempotente modtagere og eventuel konsistens. Kommunikationen er enten synkron (REST over HTTP, gRPC) eller asynkron (Kafka, AMQP-brokere); synkrone kæder ganger forsinkelse og fejlsandsynlighed op, fordi tilgængeligheden af en kaldsti groft sagt er produktet af tilgængeligheden for hvert led. Robusthedsmønstre - timeouts, genforsøg med eksponentiel backoff og jitter, circuit breakers, bulkheads - og distribueret sporing med W3C Trace Context, typisk via OpenTelemetry, er derfor obligatoriske og ikke valgfrie. Et system, der skal udrulles i takt, eller som deler et skema på tværs af tjenester, er en \"distribueret monolit\": det betaler netværkets pris uden at få uafhængigheden.\n\nSikkerheden skifter form i stedet for blot at vokse. Perimeterkontroller i en API-gateway håndterer nord-syd-trafikken, men øst-vest-kald mellem tjenester kræver deres egen autentificering og autorisation. NIST SP 800-204 (2019) beskriver sikkerhedsstrategier for microservices, og ledsagerne SP 800-204A og 800-204B dækker udrulning af service mesh og attributbaseret adgangskontrol i et mesh. Et service mesh som Istio eller Linkerd giver hver workload en kryptografisk identitet (ofte i SPIFFE-format), håndhæver gensidig TLS og anvender politik per rute via sidecar- eller node-proxyer. Slutbrugerens identitet videregives med signerede tokens (JWT-adgangstokens, OAuth 2.0 token exchange efter RFC 8693), så hver tjeneste selv kan håndhæve autorisation på objektniveau; gøres det ikke, opstår Broken Object Level Authorization, API1:2023 i OWASP API Security Top 10.\n\nMicroservices er en arkitekturstil og uafhængig af containere eller Kubernetes, selvom de ofte udrulles sådan. Stilen står i kontrast til en modulær monolit, der håndhæver modulgrænser inden for én udrulningsenhed og undgår netværkets fejltyper; for små teams er det ofte det bedre kompromis, og flere omtalte migreringer er gået tilbage fra microservices til færre, større tjenester."},"edges":[{"type":"requires","to":"cs/api","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/network","confidence":"high","strength":"normal"},{"type":"causes","to":"security/attack-surface","why":{"en":"Each extra service and each call between services over the network is another place an attacker can try to get in.","da":"Hver ekstra tjeneste og hvert kald mellem tjenester over netværket er endnu et sted, hvor en angriber kan forsøge at komme ind."},"confidence":"medium","strength":"normal"}],"depth":5,"sources":[{"title":"Microservices - Martin Fowler & James Lewis","url":"https://martinfowler.com/articles/microservices.html","tier":"reference","publisher":"martinfowler.com"},{"title":"NIST SP 800-204 - Security Strategies for Microservices-based Application Systems","url":"https://csrc.nist.gov/pubs/sp/800/204/final","tier":"standard","publisher":"NIST"}],"draft":true}