Migratiepatroon voor legacy applicaties: The Strangler pattern

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.

De wurgende klimplant

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.

Het Strangler Façade migratiepatroon

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.

Zijn er ook nadelen?

Heeft dit patroon ook nadelen? Zeker.

1. Je zult je voor moeten bereiden op een project waarin je niet alleen tijd en geld in de nieuwe applicatie investeert, maar ook in het ontleden van de oude applicatie.
2. Ook een overweging is dat niet alle legacy applicaties zich lenen voor deze aanpak. Als je applicatie zich niet leent voor het routeren van verkeer via een Strangler Facade valt dit migratiepatroon af.
3. Je kan met meer latency tussen beide omgevingen te maken krijgen. Vooral als de legacy applicatie zich nog on-premises bevindt.

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.