Hva er en monolitt?
En monolitt er et system der all koden bygges, testes og produksjonssettes samlet, som én enhet. Det er verken bra eller dårlig i seg selv. For ett team, ett produkt og rask utvikling er det ofte det enkleste og mest effektive valget. En modulær monolitt er den moderne mellomveien.
Ordet monolitt har fått en ufortjent negativ klang. Det brukes noen ganger som skjellsord om alt som oppfattes som gammelt og tungrodd, som noe man burde ha lagt bak seg. Det bildet er misvisende. Her ser vi på hva en monolitt faktisk er, og hvorfor den er det riktige valget for mange systemer.
En nøytral definisjon
En monolitt er et system som bygges, testes og produksjonssettes som én enhet. All koden (grensesnitt, forretningslogikk, databasetilgang) bygges samlet og rulles ut sammen. Når du oppdaterer systemet, produksjonssetter du helheten, ikke en enkelt del.
Det er hele definisjonen, og den inneholder ingen vurdering. En monolitt er ikke automatisk rotete eller utdatert, like lite som et oppdelt system automatisk er godt bygget. Arkitekturen sier hvordan systemet pakkes og kjøres, ikke hvor godt koden er skrevet.
Myten om at monolitt betyr «stygt», kommer som regel fra møter med gamle systemer som tilfeldigvis er både monolittiske og dårlig strukturerte. Men de to tingene henger ikke sammen. En godt bygget monolitt kan være ryddig, oversiktlig og lett å jobbe i.
Når monolitten er det riktige valget
For svært mange systemer er monolitten ikke bare akseptabel, men det beste valget. Den kommer særlig til sin rett i tre situasjoner:
- Ett team. Når samme gruppe eier hele systemet, er det ikke behov for å dele det opp for å la ulike team jobbe uavhengig. Oppdeling løser et koordineringsproblem dere ikke har.
- Ett produkt. Et helhetlig system som gjør én tydelig ting, har godt av å holdes samlet. Delene hører naturlig sammen og tjener på å ligge på samme sted.
- Rask utvikling. Færre bevegelige deler betyr enklere drift, raskere feilsøking og mindre ekstraarbeid. Tidlige produkter trenger høyt tempo, og monolitten står sjelden i veien.
En monolitt har alt på ett sted: én enhet å produksjonssette, én logg å lese, én flyt å følge når noe går galt. Det er en styrke som er lett å undervurdere helt til man har mistet den.
Et konkret scenario
La oss si at en bedrift bygger en bookingtjeneste. Et team på fem personer, ett produkt, et tidlig marked. De velger å bygge den som en monolitt: kontoer, bookinger, betalinger og varsler i samme system.
Resultatet er at de kan bruke nesten all tiden på funksjoner i stedet for på infrastruktur. En ny utvikler setter seg inn i ett system, ikke ti. Når en feil dukker opp, ligger hele flyten på ett sted og kan feilsøkes der. Hadde de i stedet delt alt opp i småtjenester fra dag én, hadde de betalt drifts- og koordineringskostnader for et problem (mange uavhengige team) som de ennå ikke har. For tidlig oppdeling er en av de vanligste og dyreste arkitekturfeilene.
Den moderne mellomveien: modulær monolitt
Det finnes et tredje alternativ som har blitt populært nettopp fordi det tar det beste fra to verdener. Den modulære monolitten er ett system i drift, men internt delt opp i tydelig avgrensede moduler med rene grensesnitt mellom seg. Slik får du orden og struktur uten å spre systemet ut over nettverket.
Poenget er å skille mellom logisk og fysisk oppdeling. Du kan ha godt atskilte deler uten at hver del blir en egen tjeneste med egen drift. Det gir enkel drift nå og en tydelig linje å skjære langs hvis systemet en dag virkelig må deles opp.
En vanlig misforståelse er å tro at en monolitt ikke kan være godt strukturert, at orden krever at man deler systemet opp i tjenester. Slik er det ikke. Struktur handler om hvordan koden er organisert internt, ikke om hvordan den pakkes og produksjonssettes. En slurvete monolitt og en slurvete samling microservices er begge rotete; en gjennomtenkt modulær monolitt er ryddig uten å betale prisen for nettverket. Å skille de to spørsmålene fra hverandre sparer dere for mange dyre beslutninger tatt på feil grunnlag.
Slik tenker du om valget
Ta utgangspunkt i organisasjonen og produktet, ikke i hva som høres mest moderne ut. Har dere ett team, ett produkt og behov for fart, er en monolitt, gjerne modulær, som regel riktig. Skill ut tjenester først når et faktisk behov, for eksempel mange uavhengige team, tvinger det frem.
Vil dere ha en nøytral vurdering av hva akkurat systemet deres har best av, drøfter vi i Weapp gjerne arkitekturen sammen med dere før dere bygger.
Ofte stilte spørsmål
Er en monolitt noe dårlig?
Nei, det er en seiglivet myte. En monolitt er rett og slett et system som kjører som én enhet, og for mange produkter er det det klokeste valget. Den er enklere å bygge, drifte og feilsøke enn et distribuert system. Ryktet om at monolitter er stygge, kommer som regel fra gamle, dårlig strukturerte systemer, ikke fra arkitekturen i seg selv.
Når er en monolitt riktig valg?
Når dere har ett team og ett produkt og vil holde høyt tempo. En monolitt gir få bevegelige deler, enkel drift og rask feilsøking, og det er akkurat det tidlige produkter og mindre organisasjoner trenger. Så lenge kompleksiteten ikke tvinger frem en oppdeling, er en samlet løsning ofte både billigere og mer stabil.
Hva er forskjellen på en monolitt og microservices?
En monolitt kjører som én enhet, mens microservices deler systemet opp i mange små tjenester som produksjonssettes og skaleres hver for seg. Monolitten er enklere å bygge og drifte; microservices gir uavhengige deler, men prisen er betydelig mer kompleksitet i drift og feilsøking. Valget handler mer om organisasjon og størrelse enn om hva som er moderne.
Hva er en modulær monolitt?
En modulær monolitt er fortsatt ett system i drift, men internt delt opp i tydelig avgrensede moduler med rene grensesnitt mellom seg. Du får den enkle driften til en monolitt og de strukturelle fordelene som ellers forbindes med microservices, uten nettverkskompleksiteten. For mange er det den beste mellomveien.
Kan man gå fra monolitt til microservices senere?
Ja, og det er ofte den kloke rekkefølgen. Å begynne med en godt strukturert monolitt og skille ut tjenester først når et reelt behov oppstår, er mindre risikabelt enn å dele opp for tidlig. En modulær monolitt gjør overgangen enklere fordi modulene allerede har tydelige grenser å skjære langs.