Czym różni się migracja big-bang od modernizacji przyrostowej?
Migracja big-bang zastępuje cały system legacy w jednym przełączeniu. Jej zaletą jest prostota: jeden termin uruchomienia, jedno czyste cięcie. Ryzyko polega na tym, że każda awaria uderza jednocześnie w całą platformę, a powrót do poprzedniego stanu jest często niemożliwy bez utraty tygodni pracy.
Modernizacja przyrostowa przesuwa jednorazowo jeden ograniczony fragment systemu. Każda zmiana jest na tyle mała, że można ją dokładnie przetestować, a system legacy obsługuje ruch produkcyjny aż do momentu, gdy jego zamiennik sprawdzi się na produkcji. Łączny czas realizacji może być dłuższy, ale ryzyko w każdym pojedynczym punkcie jest znacznie niższe, a Twój biznes działa przez cały czas.
Jak długo trwa typowe wdrożenie modernizacji aplikacji?
To zależy od rozmiaru i stanu systemu, liczby punktów integracji oraz tego, ile pracy Twój wewnętrzny zespół może przejąć równolegle. Skoncentrowana faza oceny i roadmapy trwa zazwyczaj od czterech do sześciu tygodni. Fazy realizacji dla średniego monolitu przy modernizacji przyrostowej trwają zwykle od sześciu do osiemnastu miesięcy.
Każde zaangażowanie wyceniamy po fazie oceny, otrzymujesz harmonogram oparty na Twojej rzeczywistej bazie kodu, a nie ogólne szacunki. Faza roadmapy istnieje właśnie po to, żeby usunąć tę niepewność, zanim zdecydujesz się na większy program.
Jak wzorzec strangler-fig utrzymuje produkcję podczas modernizacji?
Wzorzec strangler-fig działa poprzez umieszczenie warstwy routingu przed systemem legacy. Nowe żądania dotyczące konkretnych funkcji są kierowane do serwisu zastępczego, podczas gdy wszystko inne trafia do starej aplikacji jak dotychczas. System legacy nie jest wyłączany, jest stopniowo otaczany i zastępowany.
Gdy kolejny nowy serwis sprawdza się na produkcji, reguły routingu kierują do niego coraz więcej ruchu. Stara ścieżka kodu dla danej funkcji jest wycofywana dopiero wtedy, gdy nowa ścieżka jest stabilna. W żadnym momencie cały system nie zależy od niesprawdzonego zamiennika, awaria jednego nowego serwisu dotyka tylko tej funkcji, nie całej platformy.
Co jest tańsze, modernizacja istniejącego systemu czy przebudowa od zera?
Pełna przebudowa ma przewidywalną atrakcyjność: czysta baza kodu, brak ograniczeń legacy i szansa na zastosowanie wszystkiego, czego nauczył się Twój zespół. Praktyczny problem polega na tym, że przebudowy nagminnie trwają dłużej niż zaplanowano, a w tym czasie utrzymujesz stary system równolegle, płacąc za budowanie nowego.
Modernizacja zachowuje logikę biznesową, która już działa, reguły, przepływy pracy i integracje, które Twoja organizacja dopracowywała przez lata. Płacisz za zmianę tych elementów strukturalnych, które powodują problemy, nie za odtwarzanie tego, co już jest poprawne. W przypadku większości platform enterprise jest to znacznie tańsze i szybsze niż przebudowa od zera.
Właściwa odpowiedź zależy od stanu istniejącej bazy kodu. Faza oceny, którą przeprowadzamy, daje Ci rzetelne porównanie obu ścieżek, zanim zdecydujesz się na którąkolwiek z nich.
Jak ograniczone konteksty pomagają w podziale monolitu na mikroserwisy?
Ograniczony kontekst to wyraźnie zdefiniowana część domeny biznesowej, w której obowiązuje określony model i konkretny zespół odpowiada za jego zasady. W monolicie te konteksty istnieją w sposób dorozumiany, są ze sobą splątane poprzez współdzielone bazy danych i kod, dlatego zmiana w jednym obszarze psuje coś w innym.
Domain-driven design sprawia, że granice te stają się jawne. Gdy wiesz, gdzie kończy się jeden kontekst, a zaczyna kolejny, masz naturalną linię podziału, wzdłuż której możesz wyodrębnić serwis. Wyodrębniony serwis zarządza własnymi danymi i komunikuje się z resztą systemu przez zdefiniowany interfejs, a nie przez bezpośredni dostęp do bazy danych. Usuwa to powiązania, które czynią monolity kruche, i daje każdemu zespołowi jasno określony obszar odpowiedzialności.
Co dzieje się po zakończeniu prac modernizacyjnych?
Nie uważamy wdrożenia modernizacji za zakończone w momencie technicznego dostarczenia. Ostatnia faza naszego modelu zaangażowania to Operate: tworzymy runbooki, dokumentujemy decyzje architektoniczne i prowadzimy ustrukturyzowane sesje transferu wiedzy z Twoim zespołem.
Dla zespołów potrzebujących wsparcia wykraczającego poza przekazanie systemu oferujemy bieżącą warstwę obsługi platformy. Obejmuje ona monitoring, reagowanie na incydenty i prace nad ciągłym ulepszaniem nowej platformy. Celem jest, żeby Twój wewnętrzny zespół przejął system, który rozumie i może samodzielnie rozwijać, a nie uzależnienie od nas.