Strangler Fig-patroon

Incrementeel een verouderd systeem migreren door geleidelijk specifieke onderdelen van functionaliteit te vervangen door nieuwe toepassingen en services. Wanneer u functies van het oude systeem vervangt, omvat het nieuwe systeem uiteindelijk alle functies van het oude systeem. Deze benadering onderdrukt het oude systeem, zodat u het uit bedrijf kunt nemen.

Context en probleem

Naarmate systemen ouder worden, kunnen de ontwikkelhulpprogramma's, hostingtechnologie en systeemarchitecturen waarop ze zijn gebouwd verouderd worden. Naarmate er nieuwe functies en functionaliteit worden toegevoegd, worden deze toepassingen complexer, waardoor ze moeilijker te onderhouden of uit te breiden zijn.

Het is moeilijk om een heel complex systeem te vervangen. In plaats daarvan kunt u geleidelijk migreren naar een nieuw systeem en het oude systeem gebruiken voor niet-gemigreerde functies. Als u echter parallelle versies van een toepassing uitvoert, moeten clients bijhouden welke versie elke functie bevat. Wanneer u een functie of service migreert, moet u clients doorsturen naar de nieuwe locatie. Om deze uitdagingen aan te pakken, moet u een benadering hanteren die incrementele migratie ondersteunt en onderbrekingen voor clients minimaliseert.

Oplossing

Nadat u nieuwe servicegrenzen hebt geïdentificeerd, gebruikt u een incrementeel proces om specifieke onderdelen van functionaliteit te vervangen door nieuwe toepassingen en services. Klanten blijven dezelfde interface gebruiken en weten niet dat er een migratie wordt uitgevoerd.

Een Visio-bestand van deze architectuur downloaden.

Het Strangler Fig-patroon biedt een gecontroleerde en gefaseerde benadering van modernisering. Hierdoor kan de bestaande toepassing blijven functioneren tijdens de modernisering. Een façade (proxy) onderschept aanvragen die naar het oude back-endsysteem gaan. De façade stuurt deze aanvragen naar de legacy applicatie of naar de nieuwe diensten.

Dit patroon vermindert de risico's in de migratie door uw teams in staat te stellen vooruit te gaan in een tempo dat past bij de complexiteit van het project. Wanneer u functionaliteit naar het nieuwe systeem migreert, wordt het verouderde systeem verouderd en wordt u het verouderde systeem buiten gebruik gesteld.

1. Het Strangler Fig-patroon begint met het introduceren van een gevel (proxy) tussen de client-app, het verouderde systeem en het nieuwe systeem. De gevel fungeert als intermediair. Hiermee kan de client-app communiceren met het verouderde systeem en het nieuwe systeem. In eerste instantie stuurt de gevel de meeste aanvragen naar het verouderde systeem.

2. Naarmate de migratie vordert, verschuift de façade stapsgewijs aanvragen van het oude systeem naar het nieuwe systeem. Met elke iteratie implementeert u meer onderdelen van functionaliteit in het nieuwe systeem.

   Deze incrementele benadering vermindert geleidelijk de verantwoordelijkheden van het oude systeem en breidt het bereik van het nieuwe systeem uit. Het proces is iteratief. Hiermee kan het team complexe aspecten en afhankelijkheden aanpakken in beheerbare fasen. Deze fasen helpen het systeem stabiel en functioneel te blijven.

3. Nadat u alle functionaliteit hebt gemigreerd en er geen afhankelijkheden zijn van het verouderde systeem, kunt u het verouderde systeem buiten gebruik stellen. De gevel stuurt alle aanvragen uitsluitend naar het nieuwe systeem.

4. U verwijdert de gevel en configureert de client-app opnieuw om rechtstreeks met het nieuwe systeem te communiceren. Deze stap markeert de voltooiing van de migratie.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

• Overweeg hoe u services en gegevensarchieven verwerkt die zowel het nieuwe systeem als het verouderde systeem kunnen gebruiken. Zorg ervoor dat beide systemen tegelijkertijd toegang hebben tot deze resources.

• Nieuwe toepassingen en services structureren zodat u deze eenvoudig kunt onderscheppen en vervangen tijdens toekomstige migraties volgens het strangler fig-principe. Probeer bijvoorbeeld duidelijke afbakeningen te hebben tussen delen van uw oplossing, zodat u elk onderdeel afzonderlijk kunt migreren.

• Nadat de migratie is voltooid, verwijdert u meestal de strangler fig façade. U kunt de façade ook behouden als adapter die door legacy-clients kan worden gebruikt terwijl u het kernsysteem bijwerkt voor nieuwe clients.

  Conceptualiseer dit als overgangsarchitectuur en balanceer de risicobeperkingsvoordelen van deze architectuur ten opzichte van de tijdelijke infrastructuurkosten.

• Zorg ervoor dat de gevel de migratie bijhoudt.

• Zorg ervoor dat de gevel geen single point of failure wordt of een prestatieknelpunt.

• Plan voor afhankelijkheden tussen systemen. Tijdens de migratie moeten beide systemen naast elkaar bestaan en communiceren. Het nieuwe systeem moet bijvoorbeeld mogelijk niet-gemigreerde functionaliteit aanroepen van het verouderde systeem en niet-gemigreerde verouderde onderdelen moeten mogelijk gemigreerde functionaliteit aanroepen van het nieuwe systeem. Gebruik het Anti-corruptielaagpatroon om deze aanroepen te beheren. Een anti-corruptielaag fungeert als een adapter die aanvragen tussen de twee systemen vertaalt. Deze laag beveiligt het ontwerp van het nieuwe systeem tegen verouderde semantiek, zodat het verouderde systeem nieuwe services kan bereiken zonder belangrijke codewijzigingen. Zonder deze adapter kunnen afhankelijkheden tussen systemen onderdelen breken of het nieuwe systeem dwingen verouderde conventies te gebruiken.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• U migreert geleidelijk een back-endtoepassing naar een nieuwe architectuur, met name wanneer u grote systemen, belangrijke onderdelen of complexe functies vervangt, brengt risico's met zich mee.

• Het oorspronkelijke systeem kan gedurende langere tijd blijven bestaan tijdens de migratie.

Dit patroon is mogelijk niet geschikt wanneer:

• Aanvragen voor het back-endsysteem kunnen niet worden onderschept.

• U hebt geen toegang tot de broncode van het verouderde systeem. Als u gemigreerde functies wilt uitschakelen en interne aanroepen wilt omleiden, moet u de broncode van het verouderde systeem kunnen wijzigen.

• Je migreert een klein systeem, en het vervangen van het hele systeem is eenvoudig.

• U moet de oorspronkelijke oplossing snel uit bedrijf nemen.

Werklastontwerp

Evalueer hoe u het Strangler Fig-patroon gebruikt in workloadontwerp om de doelen en principes van de pijlers van het Azure Well-Architected Framework te adresseren. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Houd rekening met eventuele afwegingen ten opzichte van de doelstellingen van de andere pijlers die dit patroon kan introduceren.

Voorbeeld

Verouderde systemen zijn doorgaans afhankelijk van een gecentraliseerde monolithische database die meerdere domeinen dient. Na verloop van tijd wordt deze gedeelde database moeilijk te beheren en te verbeteren vanwege de afhankelijkheden tussen domeinen. Om deze uitdaging aan te pakken, extraheert het Strangler Fig-patroon stapsgewijs domeinspecifieke tabellen, opgeslagen procedures en gerelateerde gegevens uit de monolithische database in geïsoleerde domeindatabases. Elke database bevat slechts één domein. Herhaal het extractieproces totdat de monolithische database volledig is uitgevouwen.

1. Introduceer een nieuwe systeemservice, die begint met het beheren van aanvragen voor het domein. De nieuwe systeemservice leest nog steeds van en schrijft naar de monolithische database voor de domeintabellen. Het verouderde systeem blijft alle andere domeinen bedienen.

2. Introduceer een geïsoleerde domeindatabase voor het nieuwe systeem. Migreer de relevante domeintabellen en de bijbehorende historische gegevens naar de nieuwe database met behulp van een ETL-proces (extract, transform en load). Een CDC-proces (Change Data Capture) synchroniseert de domeingegevens van de monolithische database naar de nieuwe domeindatabase. Tijdens deze fase blijft het verouderde systeem lezen van en schrijven naar de monolithische database en schrijft het nieuwe systeem naar de nieuwe domeindatabase. Valideer de consistentie tussen beide databases vóór cutover.

3. Na validatie is de nieuwe domeindatabase het recordsysteem voor dat domein. Het nieuwe systeem voert alle lees- en schrijfbewerkingen uit op de domeindatabase. Verwijder de bijbehorende domeintabellen, opgeslagen procedures en afhankelijkheden uit de monolithische database. Herhaal dit proces voor elk domein totdat de monolithische database volledig is uitgevouwen.

   U kunt tijdens fase 2 en aan het begin van fase 3 terugkeren naar de monolithische database wanneer de domeintabellen en synchronisatieprocessen nog steeds aanwezig zijn in de monolithische database. Als u wilt terugkeren naar de monolithische database nadat u de domeintabellen, opgeslagen procedures en synchronisatieprocessen uit de monolithische database hebt verwijderd, moet u deze objecten herstellen en gegevenswijzigingen opnieuw afspelen. Dit proces verhoogt echter de inspanning en het risico aanzienlijk. Behandel het verwijderen van verouderde objecten als een opzettelijke laatste stap voor elk domein. Verwijder verouderde objecten pas nadat het nieuwe systeem is gevalideerd.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteurs:

• Adnan Khan | Senior Cloud Solutions Architect
• Ovais Mehboob Ahmed Khan | Senior Cloud Solution Architect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stap

• Lees het blogbericht van Martin Fowler over strangler Fig-patroontoepassing

Gerelateerde bronnen

• Berichtbrugpatroon
• Plan uw workloadmigratie van Amazon Web Services naar Azure