In deze blogreeks vertelt Solution Architect Sjoerd je alles over migratiepatronen. Dit keer komt The Strangler pattern aan bod. Wat is het en met welke aspecten moet je rekening houden.
Elke applicatie zal vrijwel zeker een keer het stempel legacy krijgen. Wat de reden ook is, als je besloten hebt de applicatie te vervangen zal er ook een moment komen waarop een migratie plaatsvindt. Als er weinig documentatie voorhanden is, tests niet de volledige codebase dekken en/of je te maken krijgt met een complexe monolith, dan is dit het moment waar je het meest tegenop kijkt. Het is voor veel bedrijven zelfs een reden alles bij het oude te laten en het probleem van morgen vooral niet vandaag aan te pakken.
Elke migratie is anders en vraagt een unieke aanpak die vaak een combinatie is van meerdere migratiepatronen. Deze blogpost gaat over The Strangler Pattern, een migratiepatroon dat veel toegepast wordt bij het migreren van legacy maatwerkapplicaties naar bijvoorbeeld Azure of AWS.
Dit migratiepatroon is vernoemd naar een klimplant. Deze klimplant komt overal ter wereld in tropische oerwouden voor en heeft de bijzondere eigenschap dat ze om een bestaande boom heen groeit en deze langzaam maar zeker ‘wurgt’. Uiteindelijk sterft deze en valt de boom uit elkaar en blijft enkel de klimplant achter. Alleen de contouren van de stam van de originele boom laten zien dat deze ooit bestaan heeft.
Zo gaat het in dit migratiepatroon ook met de oude applicatie. Beetje bij beetje worden meer en meer gebruikers via een zogenaamde Stangler Facade naar een nieuwe omgeving doorgestuurd. Deze façade kan bijvoorbeeld een load balancer of een (serverless) API Gateway zijn. Er worden geleidelijk functionaliteiten uit oude applicatie naar de nieuwe overgeheveld totdat deze leeg is en uitgezet kan worden. Geen big bang, maar een geleidelijke transitie. Ideaal voor een situatie waarin je met complexe legacy te maken hebt. Alles wat onbekend en/of verborgen bleef kan beetje bij beetje worden opgespoord en opgepakt.
Daarnaast kan je tijdens de migratie in de nieuwe omgeving al aan de slag met nieuwe features. Zo worden de voordelen van de migratie snel tastbaar. Dit zal sterk bijdragen aan het succes van de migratie en de adoptie van de nieuwe omgeving.
Heeft dit patroon ook nadelen? Zeker.
En dan is er nog iets om goed bij stil te staan. Vaak zal je in de nieuwe applicatie (of set microservices) data nodig hebben die (nog) uit de oude applicatie komt. Ook moet je bedenken hoe je data van de nieuwe omgeving naar de oude synchroniseert zodat deze kan blijven functioneren. Dit kan je goed met een asynchrone anti-corruption layer bewerkstelligen (waarover later meer). Kortom, bij zo’n migratie komt een hoop vindingrijkheid en ervaring kijken.
Dit blog is geschreven door Sjoerd Santema.
Neem contact met ons op! We vertellen je het je graag.