Vad är en monolit?
En monolit är ett system som byggs, testas och driftsätts som en enda sammanhållen enhet, där all kod lever i samma bygge. Det är varken bra eller dåligt i sig – för ett team, en produkt och snabb utveckling är det ofta det enklaste och mest effektiva valet. En modulär monolit är den moderna medelvägen.
Ordet monolit har fått en oförtjänt negativ klang. Det används ibland som skällsord för allt som anses gammalt och tungrott, som något man borde ha lämnat bakom sig. Den bilden är missvisande. Här är vad en monolit faktiskt är, och varför den för många system är rätt val.
Definitionen, utan värdering
En monolit är ett system som byggs, testas och driftsätts som en enda enhet. All kod – gränssnitt, affärslogik, databasåtkomst – lever i samma bygge och släpps tillsammans. När du uppdaterar systemet driftsätter du helheten, inte en enskild del.
Det är hela definitionen, och den bär ingen värdering. En monolit är inte per automatik rörig eller föråldrad, lika lite som ett uppdelat system automatiskt är välbyggt. Arkitekturen säger hur systemet paketeras och körs, inte hur välskrivet det är.
Myten att monolit betyder “fult” kommer oftast från möten med gamla system som råkar vara både monolitiska och dåligt strukturerade. Men de två sakerna hänger inte ihop. En välbyggd monolit kan vara ren, tydlig och lätt att arbeta i.
När monoliten är rätt
För en stor mängd system är monoliten inte bara acceptabel, utan det bästa valet. Den lyser särskilt i tre situationer:
- Ett team. När samma grupp äger hela systemet finns inget behov av att dela upp det för att låta olika team arbeta oberoende. Uppdelning löser ett koordineringsproblem ni inte har.
- En produkt. Ett sammanhållet system som gör en tydlig sak mår bra av att hållas ihop. Delarna hör naturligt samman och vinner på att bo tillsammans.
- Snabb utveckling. Färre rörliga delar betyder enklare drift, snabbare felsökning och mindre kringarbete. Tidiga produkter behöver röra sig fort, och monoliten står sällan i vägen.
En monolit har allt på ett ställe: ett bygge att driftsätta, en logg att läsa, ett flöde att följa när något går fel. Det är en styrka som är lätt att underskatta tills man mist den.
Ett konkret scenario
Säg att ett bolag bygger en bokningstjänst. Ett team på fem personer, en produkt, tidig marknad. De väljer att bygga den som en monolit: konton, bokningar, betalningar och notiser i samma system.
Resultatet är att de kan lägga nästan all tid på funktioner i stället för på infrastruktur. En ny utvecklare sätter sig in i ett system, inte tio. När en bugg dyker upp finns hela flödet på ett ställe att felsöka. Hade de i stället delat upp allt i småtjänster från dag ett, hade de betalat drift- och samordningskostnad för ett problem – många oberoende team – som de ännu inte har. Uppdelning för tidigt är ett av de vanligaste och dyraste arkitekturmisstagen.
Den moderna medelvägen: modulär monolit
Det finns ett tredje alternativ som blivit populärt just för att det tar det bästa av två världar: den modulära monoliten är ett enda system i drift, men internt uppdelat i tydligt avgränsade moduler med rena gränssnitt mellan sig – så du får ordning och struktur utan att sprida ut systemet över nätverket.
Poängen är att skilja på logisk och fysisk uppdelning. Du kan ha välseparerade delar utan att varje del blir en egen tjänst med egen drift. Det ger enkel drift nu och en tydlig linje att skära längs om systemet en dag verkligen behöver brytas upp.
Ett vanligt misstag är att tro att en monolit inte kan vara välstrukturerad – att ordning kräver att man delar upp systemet i tjänster. Så är det inte. Struktur är en fråga om hur koden organiseras internt, inte om hur den paketeras och driftsätts. En slarvig monolit och en slarvig samling microservices är båda röriga; en genomtänkt modulär monolit är ordnad utan att betala nätverkspriset. Att skilja de två frågorna åt sparar många dyra beslut fattade på fel grund.
Så tänker du kring valet
Utgå från organisationen och produkten, inte från vad som låter mest modernt. Har ni ett team, en produkt och behov av fart, är en monolit – gärna modulär – oftast rätt. Bryt ut tjänster först när ett faktiskt behov, som många oberoende team, tvingar fram det.
Vill ni ha ett neutralt omdöme om vad just ert system mår bäst av, resonerar vi på Weapp gärna kring arkitekturen tillsammans innan ni bygger.
Vanliga frågor
Är en monolit något dåligt?
Nej, det är en seglivad myt. En monolit är helt enkelt ett system som körs som en enhet, och för många produkter är det det klokaste valet. Den är enklare att bygga, driva och felsöka än ett utspritt system. Ryktet om att monoliter är fula kommer oftast från gamla, dåligt strukturerade system – inte från arkitekturen i sig.
När är en monolit rätt val?
När ni har ett team, en produkt och vill röra er snabbt. En monolit ger få rörliga delar, enkel drift och snabb felsökning, vilket är precis vad tidiga produkter och mindre organisationer behöver. Så länge komplexiteten inte tvingar fram en uppdelning är den sammanhållna lösningen ofta både billigare och stabilare.
Vad är skillnaden mot microservices?
En monolit körs som en enda enhet, medan microservices delar upp systemet i många små tjänster som släpps och skalas var för sig. Monoliten är enklare att bygga och driva; microservices ger oberoende delar mot betydligt mer drift- och felsökningskomplexitet. Valet handlar mer om organisation och storlek än om vad som är modernt.
Vad är en modulär monolit?
En modulär monolit är fortfarande ett enda system i drift, men internt uppdelat i tydligt avgränsade moduler med rena gränssnitt mellan sig. Du får monolitens enkla drift och de strukturella fördelar som annars förknippas med microservices, utan nätverkskomplexiteten. För många är det den bästa medelvägen.
Kan man gå från monolit till microservices senare?
Ja, och det är ofta den kloka ordningen. Att börja med en välstrukturerad monolit och bryta ut tjänster först när ett verkligt behov uppstår är mindre riskabelt än att dela upp för tidigt. En modulär monolit gör den övergången enklare, eftersom modulerna redan har tydliga gränser att skära längs.