Monolit eller mikrotjänster? Så här bestämmer du dig faktiskt

Om du startar ett nytt projekt dyker denna fråga upp tidigt: ska du bygga en enda stor applikation eller dela upp den i flera mindre, oberoende delar? Det är den klassiska debatten om monolit kontra mikrotjänster (monolith vs. microservices), och ärligt talat hamnar nästan alla utvecklingsteam vid denna skiljeväg förr eller senare.

Här är den obekväma sanningen: det finns inget universellt svar. Vad som fungerar bäst beror på storleken på ditt team, var din produkt befinner sig just nu och vart ni är på väg under det närmaste året eller två. Låt oss bryta ner båda tillvägagångssätten så att du faktiskt kan lista ut vilket som passar er bäst, och inte bara vilket som låter mest imponerande på en presentation.

Monoliter: En kodbas, en driftsättning

En monolit är precis vad det låter som; allt lever i en och samma kodbas och levereras som en enda enhet. Föreställ dig en kontorsbyggnad där försäljning, HR, utveckling och support alla arbetar under samma tak istället för i separata byggnader utspridda över stan.

Gränssnittet, affärslogiken och databaslagret är sammankopplade. Om du ändrar en del måste du driftsätta om hela applikationen.

Ta en nystartad e-handelsapp som exempel. Produktsortiment, kassa, inloggning och orderhistorik — allt ligger i en kodbas och driftsätts tillsammans.

Varför väljer utvecklare fortfarande detta tillvägagångssätt? Här är några av de främsta anledningarna:

• Det går snabbt att konfigurera och börja leverera.
• Felsökning är enklare eftersom allt finns på ett ställe och inte är utspritt över olika tjänster.
• Inga nätverksanrop krävs mellan komponenterna, så allt bara fungerar.
• Driftsättningar är enkla, åtminstone i början.
• Du slipper hantera en hel hög med extra infrastruktur.

Mikrotjänster: Små, oberoende delar

Mikrotjänster vänder på den modellen. Istället för en stor applikation delar du upp funktionaliteten i mindre tjänster som var och en gör sitt jobb väl, körs oberoende av varandra och kommunicerar via API:er eller meddelandeköer.

Gå tillbaka till samma e-handelsexempel, men dela upp det denna gång: produkter, lager, betalningar, användare, aviseringar och beställningar är alla egna tjänster som byggs och skalas separat.

Detta är den väg som företag som Netflix, Amazon och Uber tog när deras trafik och team växte ur vad en enskild kodbas kunde hantera.

Vad är fördelarna med detta?

• Tjänster kan skalas oberoende; det finns inget behov av att överdimensionera hela applikationen bara för att en viss del är under hög belastning.
• Olika team kan driftsätta ändringar utan att störa varandras kod.
• Olika tjänster kan använda olika teknikstackar om det är mest lämpligt.
• Om en tjänst kraschar innebär det inte nödvändigtvis att hela systemet går ner.
• Att släppa uppdateringar för en enskild del kräver inte att hela systemet driftsätts om.

Snabb jämförelse

Vad ingen nämner: De dolda kostnaderna

Mikrotjänster presenteras ofta som den självklara uppgraderingen — mer flexibilitet, högre skalbarhet och större feltolerans på pappret. Men de kostnader som faktiskt följer med tenderar att sopas under mattan.

För det första smyger sig komplexiteten på snabbt. Service discovery, lastbalansering (load balancing), distribuerad spårning (distributed tracing), API-gateways och kommunikation mellan tjänster blir plötsligt saker du måste hantera. En bugg som förr var ett enkelt funktionsanrop är nu en misslyckad nätverksbegäran som studsar mellan två tjänster, och lycka till med att spåra det klockan 02:00 på natten.

Sedan har vi DevOps. Om du kör tio eller tjugo tjänster behöver du riktiga CI/CD-pipelines, container-orkestrering (troligen Kubernetes), centraliserad loggning och övervakning för varje enskild tjänst. Om ditt team inte har gjort detta tidigare kan den operativa arbetsbördan få allt annat att stanna av.

Å andra sidan är inte monoliter smärtfria heller. När kodbasen växer blir saker lätt röriga, flera utvecklare krockar i samma filer, byggtiderna ökar och en enda dålig driftsättning kan sänka hela applikationen.

När en monolit är det bästa valet

En monolit är oftast det bästa valet när:

• Du fortfarande håller på att lista ut vad du faktiskt bygger och kraven ständigt förändras.
• Ditt team är litet, under 5 till 10 utvecklare.
• Snabbhet är viktigare än arkitektonisk elegans just nu.
• Ni inte har en mogen DevOps-struktur på plats ännu.
• Olika delar av applikationen inte har radikalt olika skalningsbehov.

Det är värt att komma ihåg att många av dagens jättar började som monoliter. Shopify, Stack Overflow och GitHub körde monolitiska system i åratal innan något annat blev nödvändigt. Att starta enkelt är inte en kompromiss, det är ofta det helt rätta valet.

Det finns ett gammalt talesätt som ofta upprepas i utvecklingskretsar: börja med en monolit och dela upp den först när smärtan blir påtaglig. Det stämmer. Att optimera sin arkitektur innan det faktiskt behövs kan tyst bränna månader av utvecklingstid som ni aldrig får tillbaka.

När mikrotjänster faktiskt lönar sig

Mikrotjänster börjar bli vettiga först när:

• Delar av systemet har genuint olika skalningsbehov (t.ex. om din videotjänst får tio gånger mer trafik än din inställningssida).
• Flera team behöver kunna arbeta självständigt utan att ständigt blockera varandra.
• Ni behöver hög tillgänglighet och det inte är acceptabelt att en felande komponent sänker hela systemet.
• En driftsättning har blivit långsam, riskabel och något som hela teamet fasar för.
• Olika delar av systemet på allvar skulle tjäna på att använda olika teknikstackar.

Om ni är en startup på fem personer med några hundra användare kommer mikrotjänster förmodligen att sinka er mer än de hjälper. Men om ni är ett växande företag med ökande trafik och flera produktteam som arbetar parallellt, är det oftast där som mikrotjänster börjar betala sig.

Medelvägen: Modulär monolit

Det finns ett alternativ som det inte talas alls tillräckligt om: den modulära monoliten.

Det är fortfarande en enda driftsättningsbar enhet, men koden inuti är organiserad i tydligt separerade moduler med skarpa gränser. Tänk på det som att bygga applikationen så att det inte blir en mardröm att lyfta ut delar till separata tjänster senare, även om ni inte gör det idag.

Du får monolitens enkelhet idag, samtidigt som du håller dörren öppen för en migrering till mikrotjänster längre fram. För team som växer men ännu inte nått nivån där fullskaliga mikrotjänster behövs, är detta ofta den mest förnuftiga medelvägen.

Så, hur bestämmer du dig?

Här är en enkel tumregel att tänka efter:

Välj en monolit om din produkt är ny, ditt team är litet eller om ni fortfarande försöker definiera exakt vad ni bygger. Snabbhet och enkelhet är viktigast just nu.

Gå mot mikrotjänster om ni har stött på verkliga skalnings- eller koordinationsproblem som en monolit genuint inte kan lösa. Låt smärtan styra beslutet, inte hypen.

Överväg en modulär monolit om ni vill ha renare kodgränser idag utan att behöva ta på er den operativa overhead som det innebär att köra flera tjänster.

Och en sak till som tål att sägas högt: att flytta från en monolit till mikrotjänster i efterhand är absolut möjligt, och massor av företag har gjort just det. Du behöver inte ha rätt arkitektur på dag ett. Att få ut produkten till verkliga användare och lära av dem slår nästan alltid att spendera månader på att designa den "perfekta" arkitekturen innan du ens har driftsatt något.

Sammanfattning

Varken monoliter eller mikrotjänster är i sig själva bättre; de är bara verktyg anpassade för olika skeden av ett företags liv. En monolit låter er röra er snabbt när ni är små och fortfarande letar efter fotfästet. Mikrotjänster ger utrymme att skala när teamet och trafiken faktiskt kräver det.

Om ni är i ett tidigt skede, håll det enkelt. Bygg en ren monolit, driftsätt den och låt den faktiska användningen tala om för er vad nästa steg är. När skalning och teamstorlek blir reella problem kommer ni att ha mycket bättre information att fatta det beslutet på än vad ni har just nu.

Den bästa arkitekturen är inte den som låter mest imponerande i en anställningsintervju — det är den som låter ditt team leverera pålitlig programvara i den takt som er verksamhet faktiskt kräver.