Hvad er en monolit?
En monolit er et system der bygges, testes og idriftsættes som én samlet enhed, hvor al koden lever i det samme build. Det er hverken godt eller dårligt i sig selv: For ét team, ét produkt og hurtig udvikling er det ofte det enkleste og mest effektive valg. En modulær monolit er den moderne mellemvej.
Ordet monolit har fået en ufortjent negativ klang. Det bruges nogle gange som skældsord for alt der anses for gammelt og tungt, som noget man burde have lagt bag sig. Det billede er misvisende. Her er hvad en monolit faktisk er, og hvorfor den er det rigtige valg for mange systemer.
Definitionen, uden værdidomme
En monolit er et system der bygges, testes og idriftsættes som én enhed. Al koden (brugerflade, forretningslogik, databaseadgang) lever i det samme build og udgives samlet. Når du opdaterer systemet, idriftsætter du helheden, ikke en enkelt del.
Det er hele definitionen, og den rummer ingen værdidom. En monolit er ikke automatisk rodet eller forældet, lige så lidt som et opdelt system automatisk er velbygget. Arkitekturen siger noget om hvordan systemet pakkes og køres, ikke om hvor velskrevet det er.
Myten om at monolit betyder “grimt”, kommer som regel fra mødet med gamle systemer der tilfældigvis er både monolitiske og dårligt strukturerede. Men de to ting hænger ikke sammen. En velbygget monolit kan være ren, overskuelig og nem at arbejde i.
Hvornår monolitten er det rigtige valg
For rigtig mange systemer er monolitten ikke bare acceptabel, men det bedste valg. Den kommer især til sin ret i tre situationer:
- Ét team. Når den samme gruppe ejer hele systemet, er der ikke noget behov for at dele det op for at lade forskellige teams arbejde uafhængigt. En opdeling løser et koordineringsproblem I ikke har.
- Ét produkt. Et samlet system der gør én tydelig ting, har godt af at blive holdt sammen. Delene hører naturligt sammen og vinder ved at bo sammen.
- Hurtig udvikling. Færre bevægelige dele betyder enklere drift, hurtigere fejlsøgning og mindre overhead. Tidlige produkter skal bevæge sig hurtigt, og monolitten står sjældent i vejen.
En monolit har alt ét sted: ét build at idriftsætte, én log at læse, ét flow at følge når noget går galt. Det er en styrke der er let at undervurdere indtil man har mistet den.
Et konkret scenarie
Lad os sige at en virksomhed bygger en bookingtjeneste. Et team på fem personer, ét produkt, et tidligt marked. De vælger at bygge den som en monolit: konti, bookinger, betalinger og notifikationer i det samme system.
Resultatet er at de kan bruge næsten al deres tid på funktioner i stedet for på infrastruktur. En ny udvikler skal sætte sig ind i ét system, ikke ti. Når der dukker en fejl op, ligger hele flowet ét sted og kan fejlsøges. Havde de i stedet delt det hele op i små services fra dag ét, ville de have betalt drifts- og koordineringsomkostninger for et problem (mange uafhængige teams) som de endnu ikke har. For tidlig opdeling er en af de mest almindelige og dyreste arkitekturfejl.
Den moderne mellemvej: modulær monolit
Der findes et tredje alternativ der er blevet populært netop fordi det tager det bedste fra to verdener: Den modulære monolit er ét system i drift, men internt opdelt i tydeligt afgrænsede moduler med rene grænseflader imellem. Så får du orden og struktur uden at sprede systemet ud over netværket.
Pointen er at skelne mellem logisk og fysisk opdeling. Du kan have veladskilte dele uden at hver del bliver en selvstændig service med sin egen drift. Det giver enkel drift nu og en tydelig linje at skære langs hvis systemet en dag virkelig skal brydes op.
En almindelig fejl er at tro at en monolit ikke kan være velstruktureret, at orden kræver at man deler systemet op i services. Sådan er det ikke. Struktur er et spørgsmål om hvordan koden er organiseret internt, ikke om hvordan den pakkes og idriftsættes. En sjusket monolit og en sjusket samling microservices er begge rodede; en gennemtænkt modulær monolit er velordnet uden at betale netværksprisen. At holde de to spørgsmål adskilt sparer mange dyre beslutninger truffet på et forkert grundlag.
Sådan tænker du om valget
Tag udgangspunkt i organisationen og produktet, ikke i hvad der lyder mest moderne. Har I ét team, ét produkt og brug for fart, er en monolit, gerne modulær, som regel det rigtige. Bryd først services ud når et reelt behov, f.eks. mange uafhængige teams, tvinger det frem.
Vil I have en neutral vurdering af hvad netop jeres system har bedst af, drøfter vi hos Weapp gerne arkitekturen sammen med jer inden I bygger.
Ofte stillede spørgsmål
Er en monolit noget dårligt?
Nej, det er en sejlivet myte. En monolit er ganske enkelt et system der kører som én enhed, og for mange produkter er det det klogeste valg. Den er enklere at bygge, drive og fejlsøge end et distribueret system. Forestillingen om at monolitter er grimme, kommer som regel fra gamle, dårligt strukturerede systemer, ikke fra arkitekturen i sig selv.
Hvornår er en monolit det rigtige valg?
Når I har ét team, ét produkt og vil bevæge jer hurtigt. En monolit giver få bevægelige dele, enkel drift og hurtig fejlsøgning, og det er præcis hvad tidlige produkter og mindre organisationer har brug for. Så længe kompleksiteten ikke tvinger en opdeling frem, er den samlede løsning ofte både billigere og mere stabil.
Hvad er forskellen på en monolit og microservices?
En monolit kører som én enhed mens microservices deler systemet op i mange små services der udgives og skaleres hver for sig. Monolitten er enklere at bygge og drive; microservices giver uafhængige dele til gengæld for betydeligt mere kompleksitet i drift og fejlsøgning. Valget handler mere om organisation og størrelse end om hvad der er moderne.
Hvad er en modulær monolit?
En modulær monolit er stadig ét system i drift, men internt opdelt i tydeligt afgrænsede moduler med rene grænseflader imellem. Du får monolittens enkle drift og de strukturelle fordele der ellers forbindes med microservices, uden netværkskompleksiteten. For mange er det den bedste mellemvej.
Kan man gå fra monolit til microservices senere?
Ja, og det er ofte den kloge rækkefølge. At starte med en velstruktureret monolit og først bryde services ud når der opstår et reelt behov, er mindre risikabelt end at dele op for tidligt. En modulær monolit gør den overgang enklere fordi modulerne allerede har tydelige grænser at skære langs.