Migracje inkrementacyjne

Problem polega na tym, że całe ryzyko ląduje w jednym dniu, a żadna korzyść nie pojawia się wcześniej. Jeśli przełączenie się przesunie, przesuwa się wszystko. Jeśli jeden komponent okaże się znacznie trudniejszy, niż zakładano, blokuje elementy gotowe od miesięcy. A przez cały ten czas zespół utrzymuje dwa środowiska i nie dowozi niczego nowego.

Migracja inkrementacyjna odwraca ten układ. Przenosisz jedną rzecz, potwierdzasz, że działa, i ta poprawa już zostaje. Potem bierzesz następną.

Zwykle jest to jeden z kilku wariantów. Aplikacja, która przewraca się przy ruchu, jaki powinna spokojnie obsłużyć. Serwer, którego rachunek rośnie rok po roku, bo nikt nie renegocjował warunków. Komponent na tyle kruchy, że nikt nie chce w nim niczego wdrażać, przez co po cichu spowalnia każdy projekt dotykający tego obszaru.

Każdy z tych przypadków daje czytelne porównanie przed i po. To ma większe znaczenie, niż się wydaje, bo drugi etap migracji uzasadnia się znacznie łatwiej, gdy pierwszy przyniósł konkretną liczbę, którą można pokazać.

Niemal każda migracja wyciąga na wierzch tę samą kategorię niespodzianek. Wartość konfiguracyjna wpisana na sztywno w miejscu, którego nikt nie pamięta. Zadanie cykliczne działające na maszynie, której nie ma w żadnym spisie. Integracja uwierzytelniająca się adresem IP, która przestaje działać w momencie zmiany tego adresu. Zależność od wersji biblioteki, której nowa platforma już nie udostępnia.

Znalezienie tego na jednym ograniczonym systemie jest niewygodne. Znalezienie wszystkiego naraz, w trakcie jednego weekendowego przełączenia, to sposób, w jaki migracje trafiają do opowieści powtarzanych latami. Pierwszy etap to moment, w którym płacisz ten koszt tanio.

Kilka rzeczy trzeba więc rozwiązać na początku, a nie przy każdym komponencie osobno. Uwierzytelnianie musi działać po obu stronach, żeby użytkownik nie został wylogowany przy przekroczeniu niewidocznej granicy. Usługi muszą mieć między sobą bezpieczne i przewidywalnie szybkie ścieżki sieciowe. Współdzielone dane muszą mieć jednego właściciela. Najczęstsza awaria w tym miejscu to dwa systemy zapisujące do czegoś, co każdy z nich uważa za własną kopię.

Zbudowanie tego porządnie w pierwszym etapie sprawia wrażenie nadmiarowej pracy. I to właśnie ono decyduje o tym, że każdy kolejny etap jest rutyną. Zespoły, które ten krok pominęły, zwykle wracają do niego po trzecim czy czwartym komponencie, tyle że przy znacznie większej liczbie działających już połączeń do poprawienia.

Po kilku etapach zostają zwykle systemy stabilne. Działają na sprzęcie, który jest już zapłacony, rzadko się psują, a nikt nie musiał ich zmieniać od dwóch lat. Ich przeniesienie kosztowałoby realne pieniądze i dałoby niewiele. Co jakiś czas przeglądamy, co pozostało, i jeśli uczciwa odpowiedź brzmi, że reszta powinna zostać na miejscu, to właśnie rekomendujemy.

Celem nigdy nie było znalezienie się w całości w chmurze. Celem było to, żeby infrastruktura przestała przeszkadzać.