Musimy zrefaktoryzować — ale nie możemy sobie pozwolić na żaden downtime

Migracja Strangler Fig: nowy system rośnie obok starego, bez okna serwisowego.

Refaktoryzuj na produkcji bezpiecznie, kierując ruch kawałek po kawałku — użytkownicy widzą tylko to, że stało się szybciej.

Porozmawiajmy o tym Zobacz: Refaktoryzacja i wydajność

Sygnały, że to Twój problem

Rozpoznasz się w co najmniej jednym z poniższych

Wiesz, że system musi się zmienić, ale każdy plan zawiera okno serwisowe, na które biznes nie może sobie pozwolić.
Wcześniejsze próby migracji kończyły się rollbackami.
Krytyczne flow są zbyt ważne, żeby ryzykować je w cutoverze big-bang.
Stoisz w miejscu z powodu ryzyka, nie z powodu wysiłku.

Dlaczego tak się dzieje

Główna przyczyna, prostym językiem

Migracje big-bang są wyjątkowo ryzykowne, bo wszystko przełącza się naraz. Migracje Strangler Fig budują nowy system obok starego i kierują ruch kawałek po kawałku — ryzyko spada o rzędy wielkości.

Nasze podejście

Jak realnie to rozwiązujemy

1
Mapujemy krytyczną powierzchnię i identyfikujemy bezpieczne jednostki migracji.
2
Budujemy nowy, zoptymalizowany kod obok istniejącego systemu.
3
Kierujemy mały procent ruchu na nową ścieżkę i obserwujemy na produkcji.
4
Stopniowo poszerzamy nową ścieżkę, trzymając starą jako fallback aż do dekomisji.

Czego możesz się spodziewać