Vad är microservices?

Microservices är ett av de mest omtalade orden i modern systemutveckling, och ett av de mest missförstådda. Det framställs ibland som det självklara sättet att bygga på i dag. Sanningen är mer nyanserad. Här är vad microservices faktiskt är, och när de är värda sin kostnad.

Definitionen

Microservices är en arkitektur där ett system delas upp i många små, självständiga tjänster. Varje tjänst har ett eget, avgränsat ansvar – en sköter betalningar, en annan användarkonton, en tredje notiser – och de driftsätts var för sig och kommunicerar med varandra över nätverket.

Nyckelordet är självständigt. Varje tjänst kan utvecklas, releasas och skalas oberoende av de andra. De är som ett lag av specialister som var och en gör sin sak och pratar ihop sig, i stället för en enda stor generalist som gör allt.

Det låter tilltalande, och för rätt sammanhang är det det. Men för att förstå när det passar behöver man se det mot alternativet.

Kontrasten mot monoliten

En monolit är motsatsen: ett system som byggs, testas och driftsätts som en enda enhet, där all kod lever i samma bygge. Där monoliten är ett sammanhållet helt, är microservices ett nätverk av delar.

Skillnaden är inte att den ena är modern och den andra föråldrad. Det är två sätt att organisera samma sak, med olika avvägningar: monoliten är enkel att bygga, köra och felsöka på ett ställe, medan microservices köper oberoende till priset av att helheten sprids ut över många rörliga delar.

Vad du vinner

Fördelarna med microservices är verkliga, och de kretsar kring oberoende.

• Oberoende releaser. En enskild tjänst kan uppdateras och släppas utan att hela systemet rörs. Ett litet fel i notistjänsten kräver inte att allt annat testas om och driftsätts på nytt.
• Skalning per del. Behöver bara en funktion mycket kraft kan just den tjänsten skalas för sig, medan resten lämnas i fred. Det kan vara mer resurseffektivt än att skala hela systemet.
• Parallellt arbete. Olika team kan äga varsin tjänst och arbeta samtidigt utan att ständigt trampa i varandras kod.

För en stor organisation med många team som ska röra sig oberoende är detta en betydande vinst – ofta det verkliga skälet att välja microservices över huvud taget.

Vad du betalar

Oberoendet är inte gratis, och priset betalas i komplexitet.

Tio tjänster är tio saker som kan gå sönder var för sig, alla med egen bevakning. Det som i en monolit bara var ett funktionsanrop blir nu nätverkstrafik som kan misslyckas eller dröja. Och när något går fel blir det svårare att se var, eftersom flödet slingrar sig genom flera delar. Det här är hanterbart – stora bolag gör det dagligen – men det är arbete och kunnande som måste finnas.

När du inte bör börja här

Den viktigaste insikten är att microservices löser ett organisatoriskt problem oftare än ett tekniskt. Har du inte det problemet, betalar du för en lösning du inte behöver.

Tumregeln är tydlig: små team och tidiga produkter ska sällan börja med microservices. Ett ungt system som ännu söker sin form, eller ett som drivs av några få personer, mår bäst av att hållas enkelt. Börja med en välstrukturerad (gärna modulär) monolit, och bryt ut tjänster först när ett verkligt behov – många team, delar med vitt skilda krav – tvingar fram det. Att dela upp för tidigt är ett av de vanligaste och dyraste arkitekturmisstagen.

Vill ni ha ett neutralt omdöme om vad just ert system behöver, resonerar vi på Weapp gärna kring arkitekturen tillsammans innan ni bygger.