Strangler Fig-mönstret

Grundidén är att införa ett nytt, tunt programlager som fungerar som en fasad eller proxy framför den befintliga monoliten. Alla inkommande anrop går först till denna proxy.

Proxyn avgör sedan om anropet ska dirigeras till det gamla monolitiska programmet eller till en ny, modern mikrotjänst.

Det första steget är att identifiera en liten, fristående funktion eller en ”bounded context” i monoliten som ni vill extrahera.

Leta efter:

• Funktioner med tydliga gränser
• Funktionalitet som ändras ofta
• Områden som orsakar skalningsproblem

Börja i liten skala för att minimera risken och lära er processen.

När ni har valt en funktion bygger ni en helt ny mikrotjänst som hanterar just den funktionaliteten. Den nya tjänsten utvecklas med modern teknik och beprövade arkitekturprinciper.

Det är viktigt att den nya tjänsten körs fristående, utanför monolitens kodbas.

När den nya mikrotjänsten är klar uppdaterar ni er proxy. I stället för att skicka alla anrop för funktionen till monoliten dirigerar proxyn dem nu till den nya mikrotjänsten.

Den gamla monolitiska koden för funktionen används inte längre och har i praktiken ”strypits” av den nya tjänsten.

Anta att monoliten hanterar användarprofiler. Ni bestämmer er för att extrahera ”Update User Email”.

1. Bygg en ny UserProfileService.
2. Proxyn kontrollerar inkommande anrop mot /api/users/{id}/email.
3. Om det gäller en e-postuppdatering skickar proxyn anropet till UserProfileService.
4. Övriga profilanrop (till exempel namnändringar) går fortfarande till monoliten.

Så småningom flyttas alla profilfunktioner och den gamla monolitiska koden kan tas bort.

Det fina med Strangler Fig-mönstret är att omvandlingen sker stegvis. Ni skriver inte om allt på en gång.

• Extrahera en funktion.
• Testa den noggrant.
• Bygg upp förtroende.
• Upprepa processen för nästa funktion.

Detta gör att systemet kan fortsätta vara i drift och minimerar risken med en total omskrivning.

Det här mönstret ger betydande fördelar för utvecklingen av SaaS:

• Minskad risk: Migrerar en del i taget.
• Kontinuerlig drift: Ingen långvarig nedtid.
• Modernisering: Nya tjänster använder modern teknik.
• Förbättrad skalbarhet: Mikrotjänster kan skalas oberoende av varandra.
• Snabbare utveckling: Mindre, fokuserade team arbetar med de nya tjänsterna.

Även om mönstret är kraftfullt behöver ni vara medvetna om möjliga utmaningar:

• Komplex proxy: Routningslagret kan bli komplext.
• Datamigrering: Det kan vara svårt att avgöra hur data ska migreras för de nya tjänsterna.
• Distribuerad monolit: Utan noggrann design kan resultatet bli tätt kopplade mikrotjänster.

Planering och tydliga gränser är avgörande!

I dag utforskade vi Strangler Fig-mönstret, ett strategiskt sätt att modernisera äldre monoliter till mikrotjänster.

• Det använder en proxy för att omdirigera trafik.
• Funktioner extraheras och byggs om som nya tjänster.
• Processen sker stegvis, vilket minskar risken.
• Viktiga fördelar är kontinuerlig drift och modernisering.

Det här mönstret är ovärderligt när befintliga SaaS-plattformar ska utvecklas utan större störningar. Fortsätt bygga!