Czym jest Strangler Fig Pattern?
Strangler Fig Pattern (wzorzec figowca dusiciela, znany też jako Strangler Pattern) to architektoniczna strategia migracji, a nie technologia ani framework. Opisuje sposób, w jaki organizacja może zastąpić stary, monolityczny system nową architekturą — funkcja po funkcji, domena po domenie — utrzymując przez cały czas ciągłość działania usługi.
Sedno wzorca jest proste. Zamiast pisać nowy system od zera i przełączać się na niego jednego dnia, wokół starej aplikacji buduje się nową implementację, która przejmuje kolejne fragmenty odpowiedzialności. Stary i nowy system działają równolegle, ukryte za wspólnym interfejsem zewnętrznym. Z perspektywy klienta końcowego nic się nie zmienia — nie wie on, że część żądań obsługuje już nowa architektura, a reszta wciąż stary kod. Proces trwa aż do momentu, gdy cała funkcjonalność zostaje przeniesiona, a monolit można bezpiecznie wyłączyć i usunąć.
Ważne, czym Strangler Fig nie jest. To nie jest narzędzie, które można zainstalować, ani biblioteka. To wzorzec projektowy — zestaw zasad i kolejność działań, które implementuje się przy użyciu istniejących komponentów infrastruktury, takich jak reverse proxy, API gateway czy brokery wiadomości.
Kto za tym stoi?
Pojęcie wprowadził do inżynierii oprogramowania Martin Fowler w 2004 roku. Inspiracją była obserwacja z wakacji w lasach deszczowych stanu Queensland w Australii w 2001 roku, gdzie Fowler zetknął się z figowcami dusicielami (ang. strangler figs).
Te rośliny mają nietypowy cykl życia. Nasiono kiełkuje wysoko w koronie drzewa żywiciela, a młody figowiec wypuszcza korzenie w dół, aż sięgną gleby, jednocześnie rozwijając gałęzie ku górze w stronę światła. Z czasem oplata żywiciela całkowicie. Pierwotne drzewo obumiera i ulega rozkładowi, a na jego miejscu zostaje samodzielny, pusty w środku figowiec o kształcie dawnego żywiciela.
Fowler dostrzegł w tym procesie trafną metaforę modernizacji systemów legacy — zamiast brutalnie wyciąć stare drzewo, można je stopniowo oplatać nowym, aż stanie się zbędne. Początkowo używał nazwy Strangler Application, jednak z czasem samo słowo "strangler" (dusiciel) zaczęło żyć własnym życiem i nabrało agresywnych konotacji. Dlatego Fowler oficjalnie zaktualizował terminologię na Strangler Fig Application, podkreślając powiązanie z naturą i powolnym, ewolucyjnym charakterem procesu. Dziś wzorzec jest promowany między innymi w oficjalnych wytycznych chmurowych Microsoft Azure oraz Amazon Web Services.
Jak to działa?
Cykl implementacji wzorca najczęściej opisuje się trzema czasownikami, których używa dokumentacja AWS: Transform, Coexist, Eliminate (Przekształć, Współistniej, Wyeliminuj).
Transform
Architekci analizują monolit i wydzielają fragment o wyraźnych granicach — na przykład proces kasowy w sklepie internetowym. Do identyfikacji tych granic często wykorzystuje się techniki Domain-Driven Design. Wydzielony komponent buduje się od nowa jako nowoczesną implementację, zwykle w architekturze mikroserwisowej, zachowując interfejs zgodny z oczekiwaniami klientów.
Coexist
Oba systemy działają równolegle. Ustanawia się fasadę — proxy lub bramę sieciową — która przyjmuje wszystkie żądania z zewnątrz. Początkowo fasada tylko przekazuje ruch do monolitu (tzw. pass-through). Następnie konfiguruje się logikę, która stopniowo kieruje ułamek ruchu do nowej implementacji, przy czym stary kod pozostaje w gotowości na wypadek problemów. To właśnie ta warstwa daje najważniejszą korzyść wzorca — jeśli nowy mikroserwis zawiedzie, powrót do poprzedniej wersji odbywa się niemal natychmiast (instant rollback).
Eliminate
Po udowodnieniu stabilności nowej funkcji w produkcji stara logika zostaje odcięta od żądań i, co kluczowe, fizycznie usunięta z repozytorium monolitu. Pominięcie tego usunięcia to jeden z najgroźniejszych błędów całego procesu.
Pętla ta powtarza się iteracyjnie dla kolejnych domen — obsługa użytkowników, katalog, płatności — aż monolit zostaje w 100% zastąpiony i można go wyłączyć.
Z jakich elementów się składa?
Warstwa przechwytująca
Centrum techniczne wzorca decyduje, dokąd trafi każde żądanie. Nazywa się je fasadą lub warstwą routingu. Najczęściej implementuje się ją jako reverse proxy?reverse proxy: serwer pośredniczący, który przyjmuje żądania z zewnątrz i przekazuje je do właściwej usługi w tle (na przykład NGINX lub HAProxy) albo API gateway (Amazon API Gateway, Azure API Management). Serwery proxy oferują bardzo szybki routing na podstawie URL lub nagłówków, a zarządzane bramy chmurowe dokładają deklaratywny routing, limitowanie ruchu i centralną autentykację.
Warstwa ta może rozdzielać ruch na kilka sposobów:
- Segmentacja według ścieżki URI — żądania do
/api/v2/ordersidą do nowego klastra, reszta trafia do legacy. - Flagi funkcji i canary deployments — początkowo 5–10% użytkowników trafia do nowej architektury, a zespół obserwuje błędy przed pełnym przełączeniem.
- Przechwytywanie zdarzeń (event interception) — brokery wiadomości, takie jak Apache Kafka czy AWS EventBridge, pozwalają staremu i nowemu systemowi komunikować się asynchronicznie przez magistralę zdarzeń.
Warstwa danych
Drugim, znacznie trudniejszym elementem jest warstwa danych. Monolit zwykle opiera się na jednej wielkiej bazie relacyjnej, a mikroserwisy wymagają modelu "baza na serwis" (database-per-service). Migrację danych realizuje się przyrostowo — od podwójnego zapisu (dual-write) do obu baz, przez proces backfill danych historycznych, aż po przejęcie roli systemu referencyjnego przez nową bazę. W bardziej zaawansowanych wdrożeniach stosuje się Change Data Capture?Change Data Capture: technika przechwytywania każdej zmiany w bazie źródłowej i przesyłania jej dalej w czasie zbliżonym do rzeczywistego z narzędziami takimi jak Debezium i strumieniowanie przez Kafkę.
Do czego może być używane?
Głównym zastosowaniem wzorca jest migracja monolitu do mikroserwisów oraz przenoszenie systemów On-Premises?On-Premises: infrastruktura IT zainstalowana i zarządzana fizycznie w siedzibie organizacji, w odróżnieniu od usług chmurowych do chmury (cloud migration). Giganci chmurowi aktywnie go promują. AWS traktuje Strangler Fig jako ścieżkę ku architekturze bezserwerowej i kontenerowej — funkcje eksportuje się do AWS Lambda lub klastrów ECS?ECS: Amazon Elastic Container Service — zarządzana platforma AWS do uruchamiania kontenerów Docker bez konieczności zarządzania własnym klastrem serwerów/EKS?EKS: Amazon Elastic Kubernetes Service — zarządzana usługa AWS uruchamiająca klastry Kubernetes bez konieczności instalowania i utrzymania warstwy sterującej, a na obrzeżach monolitu ustawia Amazon API Gateway wraz z load balancerem. Microsoft Azure kładzie nacisk na stopniowe wydzielanie zintegrowanej bazy danych z użyciem Azure SQL czy Cosmos DB oraz Azure API Management i Azure Kubernetes Service.
Istnieją też dedykowane narzędzia. AWS Migration Hub Refactor Spaces to środowisko przeznaczone niemal wyłącznie do orkiestracji wzorca Strangler Fig. Platformy takie jak vFunction automatyzują analizę splątanego kodu (zwłaszcza w Java Enterprise) i wykrywają optymalne granice subdomen, ograniczając ryzyko antywzorców.
Czym różni się od innych rozwiązań?
Naturalnym punktem odniesienia jest big-bang rewrite — przepisanie całego systemu od zera i przełączenie na nowy jednego dnia. Różnica sprowadza się do rozłożenia ryzyka. Big-bang gromadzi całe ryzyko na dzień cut-over i nie dostarcza żadnej wartości, dopóki projekt nie zostanie ukończony. Strangler Fig dzieli migrację na małe, odwracalne kroki i pozwala czerpać korzyści (early ROI?early ROI: zwrot z inwestycji osiągnięty zanim projekt zostanie w pełni ukończony — każdy zmigrowany fragment przynosi wartość produkcyjną jeszcze w trakcie migracji) już z pierwszych zmigrowanych fragmentów.
Wzorca nie stosuje się jednak samodzielnie. Anti-Corruption Layer (warstwa antykorupcyjna) chroni czysty model domenowy nowego mikroserwisu przed przenikaniem archaicznego modelu danych z monolitu, tłumacząc między nimi. Branch by Abstraction rozwiązuje przypadek, którego Strangler Fig nie obejmuje — Strangler Fig działa na krawędzi systemu, przechwytując żądania sieciowe, podczas gdy Branch by Abstraction operuje głęboko wewnątrz kodu, gdy logiki nie da się przechwycić przez proxy. Zespoły często łączą oba podejścia. Uzupełnieniem bywa też Parallel Run, w którym oba systemy przetwarzają to samo żądanie, a wynik nowego jest walidowany względem starego przed przełączeniem.
Najważniejsze ograniczenia i wyzwania
Wzorzec nie jest darmowy. Utrzymywanie dwóch systemów za pośrednictwem sieci proxy wymaga dojrzałych praktyk DevOps, CI/CD i monitoringu, a proces przejściowy generuje podwójne koszty operacyjne — nowa infrastruktura chmurowa działa obok starych maszyn.
Najtrudniejszym aspektem pozostaje synchronizacja danych. Jak trafnie ujmuje się w praktyce inżynierskiej, zaprojektowanie routingu jest łatwe, prawdziwym zderzeniem z rzeczywistością jest przeniesienie danych. Podwójny zapis wprowadza ostateczną spójność (eventual consistency) i ryzyko rozjazdu stanu między bazami.
Wdrożenia potrafią też wpaść w konkretne antywzorce:
- Pominięcie fazy Eliminate — pozostawienie starego kodu, a nawet dopisywanie nowych funkcji do obu baz kodu, co daje trwałe podwójne utrzymanie zamiast migracji.
- Migrowanie pojedynczych endpointów zamiast całych zdolności biznesowych — jeśli nowy mikroserwis wciąż zapisuje bezpośrednio do tabel legacy, to stary system nadal "posiada" dane i narzuca architekturę.
- Przeciążanie fasady logiką — fasada staje się wąskim gardłem i pojedynczym punktem awarii.
Wzorzec bywa też nieopłacalny dla małych aplikacji, gdzie narzut bram i synchronizacji przewyższa koszt zwykłego przepisania.
Strangler Fig w erze AI
Wzorzec powstał na długo przed obecną falą generatywnej sztucznej inteligencji, ale to właśnie ona nadaje mu nowy wymiar. AI wpływa na Strangler Fig dwutorowo — przyspiesza samą migrację, a jednocześnie sama staje się kolejnym systemem, który tą metodą trzeba oplatać.
AI jako akcelerator fazy Transform
Najbardziej pracochłonnym etapem wzorca jest zwykle Transform — ręczne przepisanie wydzielonego fragmentu monolitu. Tu do gry wchodzą agentowe asystenty programistyczne. Amazon Q Developer potrafi autonomicznie przeprowadzić aktualizację aplikacji Java z wersji 8 do 17 lub 21, a także przenieść aplikacje .NET z Windowsa na Linuksa, samodzielnie czytając i modyfikując pliki, generując różnice w kodzie i uruchamiając polecenia powłoki. Narzędzia analityczne w rodzaju vFunction wykorzystują AI do wykrywania granic domen w splątanym kodzie Java Enterprise — decyzji, która wcześniej pochłaniała tygodnie pracy architekta. Efekt jest taki, że faza historycznie dławiąca tempo migracji skraca się z miesięcy do dni.
Fasada dla ruchu AI
Druga zmiana dotyczy tego, co przepływa przez warstwę przechwytującą. Coraz częściej fasada kieruje ruch nie do mikroserwisów, lecz do modeli językowych. Powstała wręcz osobna kategoria — AI gateway. Kong AI Gateway?Kong AI Gateway: brama API zaprojektowana specjalnie pod ruch do modeli językowych — zarządza routingiem do wielu dostawców LLM, semantycznym cachowaniem odpowiedzi, limitami tokenów i monitoringiem kosztów pozwala z jednego punktu zarządzać ruchem do wielu dostawców modeli (multi-LLM), przełączać się między nimi w locie dla zachowania dostępności, buforować odpowiedzi semantycznie (semantic caching?semantic caching: technika buforowania odpowiedzi modelu językowego oparta na podobieństwie semantycznym zapytań — jeśli nowe pytanie jest wystarczająco bliskie wcześniejszemu, zwracana jest zapisana odpowiedź bez wysyłania zapytania do modelu) oraz nakładać limity zużycia tokenów. To dokładnie ta sama rola fasady co w klasycznym Strangler Fig, z tą różnicą, że dławionym systemem bywa jeden dostawca modelu zastępowany innym bez wiedzy aplikacji klienckiej.
Kiedy dusicielem jest sam model
Najciekawszy przypadek to sytuacja, w której nowa implementacja przejmująca odpowiedzialność od monolitu nie jest zwykłym mikroserwisem, lecz modelem uczenia maszynowego zastępującym logikę regułową — na przykład silnik reguł antyfraudowych ustępujący miejsca modelowi predykcyjnemu. Fasada Strangler Fig jest tu naturalnym środowiskiem dla wzorca Parallel Run, znanego w kontekście AI jako tryb cienia (shadow mode) — model ocenia produkcyjne żądania równolegle ze starym systemem, ale jego decyzje początkowo nie mają skutków. Pojawia się jednak nowe wyzwanie. Stara logika była deterministyczna?deterministyczna: system lub algorytm, który dla tych samych danych wejściowych zawsze produkuje identyczny wynik — bez elementu losowości, a model bywa probabilistyczny?probabilistyczny: system lub algorytm, którego wynik może się różnić między wywołaniami nawet przy identycznych danych wejściowych, ponieważ w jego działaniu występuje element losowości lub niepewności, więc kryterium "wynik nowego zgadza się ze starym" trzeba zastąpić progami statystycznymi i ciągłą ewaluacją jakości, w tym technikami w rodzaju LLM-as-judge, gdzie jeden model ocenia odpowiedzi drugiego.
Dlaczego to jest istotne?
Znaczenie wzorca najlepiej widać przez pryzmat kosztu jego braku. Podejście big-bang bywa katastrofalne. W kwietniu 2018 roku TSB Bank próbował jednorazowo zmigrować 5,2 miliona kont na nową platformę, odcinając 1,9 miliona osób od dostępu i ponosząc straty rzędu 330 milionów funtów (orientacyjnie ok. 1,7 mld zł) oraz karę regulacyjną blisko 48,65 mln funtów (ok. 250 mln zł). W 2012 roku błąd w skrypcie pojedynczego wdrożenia Knight Capital uaktywnił martwy kod z systemu legacy i kosztował firmę 440 milionów dolarów (ok. 1,6 mld zł) w ciągu 45 minut. Niezależne analizy wskazują, że projekty modernizacyjne typu big-bang zawodzą lub nie spełniają oczekiwań w 68–79% przypadków.
W tym kontekście Strangler Fig przestaje być akademicką ciekawostką, a staje się mechanizmem zarządzania ryzykiem. Dla systemów, których przestój uderza bezpośrednio w płynność finansową i wizerunek — bankowość, giełda, handel wielkoskalowy — możliwość natychmiastowego wycofania błędnej zmiany na poziomie fasady jest wartością trudną do przecenienia. Wzorzec pozwala też zespołom rozwijać produkt równolegle z modernizacją, zamiast zamrażać rozwój na czas przepisywania. To sprawia, że po dwóch dekadach od jego sformułowania pozostaje jednym z fundamentalnych narzędzi modernizacji systemów klasy enterprise.
Strangler Fig nie jest magiczną receptą — wymaga dyscypliny, zwłaszcza w konsekwentnym usuwaniu starego kodu i przenoszeniu własności danych, a nie tylko API. Ale w świadecie, w którym całkowite przepisanie systemu to zakład o wysokiej stawce i niskiej szansie powodzenia, oferuje coś rzadkiego: drogę modernizacji, którą można w każdej chwili zatrzymać, cofnąć i wznowić.