Mikrotjänster har blivit synonymt med ”modern arkitektur”, och många team känner att de borde dela upp sitt system bara för att hänga med. För de flesta växande svenska bolag är svaret betydligt mer nyanserat. Efter att ha hjälpt en rad team genom just det här valet har jag landat i en tydlig hållning: börja enkelt och låt verkligheten – inte trenden – avgöra när det är dags att dela upp.
Vad mikrotjänster egentligen löser
Mikrotjänster löser i grunden ett organisatoriskt problem, inte ett tekniskt. De låter många team äga varsin tjänst och driftsätta oberoende av varandra, i sin egen takt, utan att trampa varandra på tårna i en gemensam kodbas. Det är en enorm fördel – när du faktiskt har många team.
Men den friheten kostar. Plötsligt måste du hantera nätverksanrop som kan fela och försvinna, data som lever i flera tjänster samtidigt, versionshantering mellan API:er, central loggning och spårning, samt ett helt driftslager med containrar och orkestrering som någon i teamet måste förstå på djupet.
Den dolda kostnaden för ett litet team
För ett team på fem till femton personer blir den komplexiteten oftast en ren förlust. Du betalar priset för en lösning på ett problem du ännu inte har. Energin går åt till infrastruktur i stället för till produkten dina kunder betalar för.
Några tydliga varningstecken på att man delat upp för tidigt:
- En enkel funktion kräver ändringar i tre tjänster samtidigt
- Mer tid läggs på pipelines och infrastruktur än på själva produkten
- Att starta hela systemet lokalt tar en halv förmiddag
- Buggar gömmer sig i glappet mellan tjänster och blir svåra att spåra
Den modulära monoliten
En välstrukturerad monolit ger dig det mesta av fördelarna utan den kostnaden. Koden delas in i tydliga moduler med väldefinierade gränser, men allt körs som en enda applikation och driftsätts i ett enda steg. Du får en gemensam loggning, enkel lokal utveckling och inga nätverksanrop mellan dina egna delar.
Tänk på modulerna som framtida tjänster. Varje modul äger sin egen data och exponerar ett tydligt internt gränssnitt. Andra moduler anropar det gränssnittet – aldrig databasen direkt. Den disciplinen är exakt det som gör en framtida utbrytning enkel.
Så håller du gränserna rena
Disciplin är hela poängen. Anropa aldrig en annan moduls tabeller direkt; gå alltid via dess publika gränssnitt. Då kan du senare flytta en modul till en egen tjänst utan att hela kodbasen rasar.
En enkel tumregel vi använder: om du inte kan rita en rak linje mellan två moduler utan att korsa fem andra, är gränserna fel dragna. Lägg tiden på att hitta rätt gränser – det är en mycket billigare investering än att bygga tjugo tjänster i förväg.
När det faktiskt är dags att dela upp
Det finns tydliga, ärliga signaler: flera team som ständigt krockar i samma kodbas, en del av systemet som måste skalas helt oberoende (som sök eller bildbehandling), eller en komponent med så annorlunda säkerhets- och driftskrav att den förtjänar att isoleras.
När den dagen kommer: bryt ut en tjänst i taget, av ett konkret skäl, och mät effekten. Det är en evolution – inte en revolution.
Sammanfattning
Välj den enklaste arkitektur som löser ditt faktiska problem idag. Bygg en modulär monolit med rena gränser, mät var smärtan faktiskt uppstår, och bryt ut tjänster först när verkligheten kräver det. Arkitektur är en resa – inte ett val du gör en gång på en whiteboard innan första raden kod är skriven.