Från monolit till moduler: en pragmatisk migrationsguide

Att skriva om monoliten från grunden är nästan alltid fel svar. De framgångsrika migrationerna vi ser följer i stället strangler fig-mönstret: ny funktionalitet byggs utanför, gammal flyttas gradvis.

Första steget är alltid detsamma: kartlägg domängränserna. Verktyg som kan analysera beroendegrafer och ändringsmönster i versionshistoriken avslöjar var de naturliga sömmarna finns.

Sätt mätbara mål för varje etapp och fira delsegrar. En migration utan synliga framsteg tappar både budget och entusiasm inom ett halvår.

Databasen är nästan alltid den svåraste delen. Kod kan flyttas modul för modul, men ett delat schema binder ihop allt – två tjänster som skriver till samma tabeller är i praktiken fortfarande en monolit. Börja därför med läsvägar: låt den nya modulen läsa via ett API i stället för direkt ur databasen, och flytta skrivägarskapet först när gränsen bevisat sig.

Expand-and-contract är arbetshästen i varje etapp: bygg det nya parallellt, dubbelskriv under övergången, verifiera med skuggtrafik och riv det gamla först när siffrorna visar noll anrop. Det låter omständligt, och det är poängen – varje steg är reversibelt, vilket är skillnaden mot omskrivningen som måste lyckas på första försöket.

Räkna också med att organisationen migrerar långsammare än koden. Team som ägt “hela systemet” ska plötsligt äga avgränsade domäner, jourscheman och deploy-rättigheter ska ritas om, och någon måste äga det som blir kvar av monoliten – ofta den viktigaste och minst glamorösa rollen av alla.

Och våga avsluta. Alla monoliter förtjänar inte att styckas; målet är leveransförmåga, inte arkitekturdiagram. När de mest föränderliga domänerna är utbrutna och resten är stabilt kan “tillräckligt modulärt” vara exakt rätt slutstation.