Monolit eller microservices?

Få tekniska val har blivit så laddade som monolit mot microservices. Microservices har i många kretsar setts som det moderna, självklara valet – och monoliten som något man ursäktar. Verkligheten är mer nykter. För de flesta organisationer är en välbyggd monolit inte bara tillräcklig, utan det klokare valet. Här är beslutet avdramatiserat, utan arkitekturmode.

Vad skillnaden faktiskt innebär

En monolit är ett system som byggs, testas och driftsätts som en enhet. All kod lever i samma bygge. Det gör den enkel att förstå, köra lokalt och felsöka – allt finns på ett ställe.

Microservices delar i stället upp systemet i många små, självständiga tjänster som körs var för sig och kommunicerar över nätverket. Varje tjänst kan utvecklas, driftsättas och skalas oberoende. Det låter befriande, och för rätt organisation är det det. Men oberoendet har ett pris som sällan nämns i entusiasmen.

Microservices verkliga pris

När microservices pitchas handlar det om skalbarhet, oberoende team och teknisk frihet. Det som utelämnas är driftnotan, och den är rejäl.

• Drift och övervakning. Varje tjänst behöver egen driftsättning, loggning och bevakning. Tio tjänster betyder tio saker som kan gå sönder var för sig, mitt i natten.
• Nätverket som felkälla. Anrop som i en monolit bara är ett funktionsanrop blir nu nätverkstrafik som kan vara långsam, misslyckas eller komma i oväntad ordning.
• Teamkoordinering. Detta är den största och mest underskattade kostnaden. Flera tjänster och team måste hålla ihop sina gränssnitt och versioner. Det som var ett samtal över skrivbordet blir ett kontrakt mellan system.

Poängen är inte att detta är omöjligt att hantera – stora organisationer gör det varje dag. Poängen är att det är verkligt arbete och verklig komplexitet, och att den kostnaden ska motiveras av ett faktiskt behov, inte av att arkitekturen är på modet.

Den moderna rekommendationen: modulär monolit först

Pendeln har svängt tillbaka, och rådet från erfaret håll är i dag tydligt: börja med en modulär monolit, och bryt ut tjänster när organisationen kräver det.

En modulär monolit ger dig det bästa av båda världar till att börja med. Du bygger tydliga interna moduler med rena gränser – samma ordning och separation som microservices lovar – men driftsätter allt som en enhet och slipper nätverket mellan delarna. Skulle en modul senare behöva stå på egna ben går den att bryta ut, just för att gränserna redan är dragna.

Skalningsmyten

Det starkaste argumentet för microservices är skalning – och samtidigt det mest missförstådda. Sanningen är att de allra flesta system aldrig når den trafik som skulle motivera uppdelningen.

Ett konkret exempel: ett bolag byggde tolv microservices från start “för att kunna skala”, för en produkt som ännu inte lanserat. De la månader på infrastruktur och koordinering i stället för på funktioner – och trafiken när den kom hade en enda monolit klarat utan att blinka. En monolit skalar nämligen långt genom att helt enkelt köras i flera kopior bakom en lastbalanserare.

När microservices faktiskt är rätt

Detta betyder inte att microservices är fel – bara att de löser ett organisatoriskt problem oftare än ett tekniskt. Den verkliga vinsten kommer när ni har många team som behöver kunna arbeta och driftsätta oberoende av varandra utan att trampa i varandras kod. Då är det värt priset att dela upp systemet, för alternativet är att alla väntar på alla.

Andra äkta skäl är delar med helt olika behov – en tung beräkning som måste skalas för sig, eller en komponent med krav som inte får smitta resten. Poängen är att beslutet ska drivas av ett behov ni faktiskt har, inte av en tänkt framtid. Och eftersom en modulär monolit går att bryta upp senare, förlorar ni sällan något på att vänta tills behovet är verkligt.

Låt problemet välja arkitekturen

Den nyktra hållningen är att arkitektur är ett medel, inte ett mål. Fråga vilket problem ni försöker lösa innan ni väljer form. Är svaret “vi kanske behöver skala en dag” räcker en välstrukturerad monolit gott. Är svaret “fem team snubblar över varandra dagligen” kan uppdelningen vara mödan värd.

Rätt arkitektur är den som passar er organisation och er faktiska belastning, inte den som ser mest modern ut på ett arkitekturdiagram. Vill ni ha ett neutralt par ögon på vad just ert system behöver, resonerar vi på Weapp gärna kring arkitekturen och kan gå igenom valen med er innan ni bygger.