Hvad er microservices?
Microservices er en arkitektur hvor systemet deles op i små tjenester der idriftsættes hver for sig, har hvert sit ansvar og kommunikerer over netværket. Du vinder uafhængige releases og skalering af hver enkelt del, men betaler med kompleksitet i drift og fejlsøgning. Små teams og tidlige produkter bør sjældent starte her.
Microservices er et af de mest omtalte ord i moderne systemudvikling og et af de mest misforståede. Det bliver nogle gange fremstillet som den selvfølgelige måde at bygge på i dag. Sandheden er mere nuanceret. Her er hvad microservices faktisk er, og hvornår de er prisen værd.
Definitionen
Microservices er en arkitektur hvor et system deles op i mange små, selvstændige tjenester. Hver tjeneste har sit eget, afgrænsede ansvar (én tager sig af betalinger, en anden af brugerkonti, en tredje af notifikationer), og de idriftsættes hver for sig og kommunikerer med hinanden over netværket.
Nøgleordet er selvstændig. Hver tjeneste kan udvikles, rulles ud og skaleres uafhængigt af de andre. De er som et hold af specialister der hver især gør deres del og taler sammen, i stedet for én stor generalist der gør det hele.
Det lyder tiltalende, og i den rette sammenhæng er det også det. Men for at forstå hvornår det passer, skal man se det i forhold til alternativet.
Kontrasten til monolitten
En monolit er det modsatte: et system der bygges, testes og idriftsættes som én samlet enhed, hvor al koden lever i samme build. Hvor monolitten er et sammenhængende hele, er microservices et netværk af dele.
Forskellen er ikke at det ene er moderne og det andet forældet. Det er to måder at organisere det samme på, med forskellige afvejninger: Monolitten er enkel at bygge, køre og fejlsøge ét sted mens microservices køber uafhængighed mod at helheden spredes ud over mange bevægelige dele.
Hvad du vinder
Fordelene ved microservices er reelle, og de handler om uafhængighed.
- Uafhængige releases. En enkelt tjeneste kan opdateres og rulles ud uden at hele systemet berøres. En lille fejl i notifikationstjenesten kræver ikke at alt andet testes igen og idriftsættes på ny.
- Skalering af hver del. Har kun én funktion brug for meget kraft, kan netop den tjeneste skaleres for sig mens resten får lov at være i fred. Det kan være mere ressourceeffektivt end at skalere hele systemet.
- Parallelt arbejde. Forskellige teams kan eje hver sin tjeneste og arbejde samtidig uden hele tiden at træde hinanden over tæerne i koden.
For en stor organisation med mange teams der skal kunne bevæge sig uafhængigt, er det en betydelig gevinst, ofte den egentlige grund til overhovedet at vælge microservices.
Hvad du betaler
Uafhængigheden er ikke gratis, og prisen betales i kompleksitet.
| Omkostning | Betydning |
|---|---|
| Drift | Hver tjeneste skal have sin egen idriftsættelse, overvågning og logning |
| Netværket | Kald mellem tjenester bliver en ny fejlkilde, langsommere og mindre pålidelige end interne kald |
| Fejlsøgning | Sværere at følge et flow der passerer mange tjenester |
Ti tjenester er ti ting der kan gå i stykker hver for sig, alle med deres egen overvågning. Det der i en monolit bare var et funktionskald, bliver nu netværkstrafik der kan fejle eller blive forsinket. Og når noget går galt, bliver det sværere at lokalisere fejlen fordi flowet snor sig gennem flere dele. Det er til at håndtere (store virksomheder gør det dagligt), men det er arbejde og viden der skal være på plads.
Hvornår du ikke bør starte her
Den vigtigste indsigt er at microservices oftere løser et organisatorisk problem end et teknisk. Har du ikke det problem, betaler du for en løsning du ikke har brug for.
Tommelfingerreglen er klar: Små teams og tidlige produkter bør sjældent starte med microservices. Et ungt system der stadig søger sin form, eller et der drives af nogle få personer, har det bedst med at blive holdt enkelt. Start med en velstruktureret (gerne modulær) monolit, og bryd først tjenester ud når et reelt behov (mange teams, dele med vidt forskellige krav) tvinger det frem. At dele op for tidligt er en af de mest almindelige og dyreste arkitekturfejl.
Vil I have en neutral vurdering af hvad netop jeres system har brug for, drøfter vi hos Weapp gerne arkitekturen sammen med jer før I bygger.
Ofte stillede spørgsmål
Hvad er forskellen til en monolit?
En monolit bygges og idriftsættes som én samlet enhed, hvor al koden lever sammen. Microservices deler i stedet systemet op i mange små tjenester som køres og rulles ud hver for sig og taler sammen over netværket. Monolitten er enklere at bygge og drive, microservices giver uafhængige dele til gengæld for betydeligt mere kompleksitet.
Hvad vinder man ved microservices?
Først og fremmest uafhængighed. Hver tjeneste kan rulles ud for sig uden at hele systemet berøres, og dele kan skaleres individuelt: Den tunge funktion får mere kraft uden at resten påvirkes. Forskellige teams kan eje hver sin tjeneste og arbejde parallelt. For store organisationer med mange teams er det en reel fordel.
Hvad betaler man for den fordel?
Kompleksitet i drift og fejlsøgning. Hver tjeneste skal have sin egen idriftsættelse, overvågning og logning, og netværket mellem dem bliver en ny fejlkilde. Det bliver sværere at forstå hvorfor noget er gået galt når flowet passerer mange tjenester. Det er reelt arbejde som ofte overskygger de tekniske gevinster for mindre systemer.
Hvornår skal man ikke bruge microservices?
Når teamet er lille, eller produktet er ungt. At dele et system op som endnu ikke har fundet sin form, eller som drives af nogle få personer, lægger omkostninger til drift og koordinering oveni uden tilsvarende nytte. Tommelfingerreglen er at starte enklere og først bryde tjenester ud når et faktisk behov tvinger det frem.
Har alle moderne systemer brug for microservices?
Nej, det er en udbredt misforståelse. Microservices løser oftere et organisatorisk problem (mange teams der skal arbejde uafhængigt) end et rent teknisk. De fleste systemer er bedre tjent med en velstruktureret monolit og kan brydes op senere hvis og når behovet virkelig opstår.