Monolit eller microservices?
Start med en modulær monolit, og bryd først microservices ud når organisationen virkelig kræver det. Den reelle pris for microservices ligger i drift, overvågning og koordinering mellem teams, omkostninger der sjældent ses i pitchen. Skaleringsargumentet gælder de få systemer der når virkelig høj trafik. De fleste gør det aldrig og er bedst tjent med en velstruktureret monolit.
Få tekniske valg er blevet så ladede som monolit over for microservices. Microservices er i mange kredse blevet set som det moderne, selvfølgelige valg, og monolitten som noget man undskylder. Virkeligheden er mere nøgtern. For de fleste organisationer er en velbygget monolit ikke bare tilstrækkelig, men det klogere valg. Her er beslutningen afdramatiseret, uden arkitekturmode.
Hvad forskellen faktisk betyder
En monolit er et system der bygges, testes og idriftsættes som én enhed. Al koden lever i samme build. Det gør den enkel at forstå, køre lokalt og fejlsøge: Alt ligger ét sted.
Microservices deler i stedet systemet op i mange små, selvstændige services der køres hver for sig og kommunikerer over netværket. Hver service kan udvikles, idriftsættes og skaleres uafhængigt. Det lyder befriende, og for den rigtige organisation er det det. Men uafhængigheden har en pris der sjældent nævnes i begejstringen.
Den reelle pris for microservices
Når microservices bliver pitchet, handler det om skalerbarhed, uafhængige teams og teknisk frihed. Det der udelades, er regningen for driften, og den er betragtelig.
- Drift og overvågning. Hver service skal have sin egen idriftsættelse, logning og overvågning. Ti services betyder ti ting der kan gå i stykker hver for sig, midt om natten.
- Netværket som fejlkilde. Kald der i en monolit bare er et funktionskald, bliver nu netværkstrafik som kan være langsom, fejle eller ankomme i uventet rækkefølge.
- Koordinering mellem teams. Det er den største og mest undervurderede omkostning. Flere services og teams skal holde deres grænseflader og versioner i trit med hinanden. Det der var en snak hen over skrivebordet, bliver en kontrakt mellem systemer.
Pointen er ikke at det er umuligt at håndtere. Store organisationer gør det hver dag. Pointen er at det er reelt arbejde og reel kompleksitet, og at den omkostning skal begrundes i et faktisk behov, ikke i at arkitekturen er på mode.
Den moderne anbefaling: modulær monolit først
Pendulet er svinget tilbage, og rådet fra erfarne folk er i dag klart: Start med en modulær monolit, og bryd services ud når organisationen kræver det.
En modulær monolit giver dig det bedste fra begge verdener til at begynde med. Du bygger tydelige interne moduler med rene grænser (den samme orden og adskillelse som microservices lover), men idriftsætter det hele som én enhed og slipper for netværket mellem delene. Skulle et modul senere få brug for at stå på egne ben, kan det brydes ud netop fordi grænserne allerede er trukket.
| Aspekt | Modulær monolit |
|---|---|
| Drift | Én enhed at køre og overvåge |
| Kodestruktur | Tydelige moduler med rene grænser |
| Ydeevne mellem dele | Hurtige kald i hukommelsen, intet netværk |
| Vejen frem | Enkelte moduler kan brydes ud efter behov |
Myten om skalering
Det stærkeste argument for microservices er skalering, og samtidig det mest misforståede. Sandheden er at langt de fleste systemer aldrig når den trafik der ville begrunde opdelingen.
Et konkret eksempel: En virksomhed byggede tolv microservices fra start “for at kunne skalere”, til et produkt der endnu ikke var lanceret. De brugte måneder på infrastruktur og koordinering i stedet for på funktioner, og den trafik der kom, ville en enkelt monolit have klaret uden at blinke. En monolit skalerer nemlig langt ved simpelthen at køre i flere kopier bag en load balancer.
Når microservices faktisk er det rigtige
Det betyder ikke at microservices er forkert, kun at de oftere løser et organisatorisk problem end et teknisk. Den reelle gevinst kommer når I har mange teams der skal kunne arbejde og idriftsætte uafhængigt af hinanden uden at træde ind i hinandens kode. Så er det prisen værd at dele systemet op, for alternativet er at alle venter på alle.
Andre ægte grunde er dele med helt forskellige behov: en tung beregning der skal skaleres for sig, eller en komponent med krav der ikke må smitte af på resten. Pointen er at beslutningen skal drives af et behov I faktisk har, ikke af en tænkt fremtid. Og fordi en modulær monolit kan brydes op senere, mister I sjældent noget ved at vente til behovet er reelt.
Lad problemet vælge arkitekturen
Den nøgterne holdning er at arkitektur er et middel, ikke et mål. Spørg hvilket problem I prøver at løse før I vælger form. Er svaret “vi får måske brug for at skalere en dag”, er en velstruktureret monolit rigeligt. Er svaret “fem teams falder over hinanden hver dag”, kan opdelingen være umagen værd.
Den rigtige arkitektur er den der passer til jeres organisation og jeres faktiske belastning, ikke den der ser mest moderne ud på et arkitekturdiagram. Vil I have et neutralt sæt øjne på hvad netop jeres system har brug for, tager vi hos Weapp gerne en snak om arkitekturen og kan gennemgå valgene med jer før I bygger.
Ofte stillede spørgsmål
Hvad er forskellen på en monolit og microservices?
En monolit er et system der bygges og idriftsættes som én enhed. Microservices deler systemet op i mange små services der køres og idriftsættes 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 koster microservices egentlig?
Mere end pitchen antyder. Hver service skal have sin egen drift, overvågning, logning og idriftsættelse, og netværket mellem dem bliver en ny fejlkilde. Størst er koordineringsomkostningen: Flere teams og services skal hænge sammen. Det er en reel udgift i tid og kompleksitet som ofte overskygger de tekniske fordele.
Hvad er en modulær monolit?
En monolit med tydelige interne moduler og grænser, bygget og idriftsat som én enhed. Du får den orden og adskillelse i koden som microservices lover, men slipper for netværket og driftskompleksiteten mellem services. Det er den moderne anbefaling at starte med, og den kan brydes op senere hvis behovet opstår.
Har vi brug for microservices for at kunne skalere?
Sjældent. Skaleringsargumentet gælder systemer med meget høj og ujævn trafik, og de fleste systemer når aldrig dertil. En velbygget monolit skalerer langt ved at køre i flere kopier bag en load balancer. At indføre microservices for en skala I ikke har, er at betale for et problem I ikke har fået endnu.
Hvornår er microservices det rigtige valg?
Når organisationen kræver det, ikke kun teknikken. Mange teams der skal kunne arbejde og idriftsætte uafhængigt, dele med helt forskellige behov for skalering eller teknologi, eller et system der er blevet for stort til én enhed. Så kan opdelingen tjene sin kompleksitet ind. Før da er den som regel for tidlig.