Migracja setek starszych aplikacji z maszyn wirtualnych (VM) do AWS się udaje, gdy prowadzi się ją jak linię produkcyjną, a nie jak setki osobnych projektów: inwentaryzacja i klasyfikacja każdej aplikacji, decyzja o aktualizacji lub przebudowie dla każdej z osobna i podział portfela na bloki, za które odpowiadają małe zespoły. Wspólny szkielet aplikacji, przetestowane kroki przełączenia i wycofania oraz runbooki, z których może korzystać każdy zespół, utrzymują stałą jakość w miarę wzrostu skali.
Najpierw inwentaryzacja, która pokazuje, czego naprawdę potrzebuje każda aplikacja
Zanim ktokolwiek dotknie AWS, trzeba spisać każdą aplikację działającą na starych maszynach wirtualnych i zanotować fakty, od których zależy nakład pracy przy migracji. Na początek wystarczy wspólny arkusz kalkulacyjny. Ważne, by każda aplikacja miała swój wiersz, właściciela i te same kolumny.
Następnie każdą aplikację przypisuje się do jednej z kilku ścieżek, takich jak aktualizacja, przebudowa i wycofanie. Zespoły mogą wtedy planować według ścieżek, zamiast rozważać każdą aplikację od zera.
- Wersja środowiska uruchomieniowego i frameworka, z oznaczeniem wszystkiego, co straciło wsparcie
- Bazy danych, udziały plików i zadania cykliczne, od których zależy aplikacja
- Integracje przychodzące i wychodzące, łącznie z zapisanymi na sztywno nazwami hostów i adresami IP
- Metoda uwierzytelniania i wszelkie sekrety przechowywane na maszynie wirtualnej
- Właściciel biznesowy, poziom użycia i akceptowalne okno przestoju
Aktualizacja czy przebudowa: decyzja dla każdej aplikacji, a nie raz dla całego programu
Żadna pojedyncza strategia nie pasuje do setek aplikacji. Niektóre wymagają tylko aktualizacji frameworka, wyniesienia konfiguracji na zewnątrz i nowego środowiska wdrożeniowego. Inne mają tyle martwego kodu lub splątanej struktury, że przebudowa na czystej bazie jest szybsza niż ich naprawa.
Decyzję podejmuje się według spisanych kryteriów, aby różne zespoły dochodziły do tej samej odpowiedzi. Przydatna reguła: jeśli przeniesienie aplikacji na standardowy szkielet i tak oznacza przepisanie większości kontrolerów i warstwy dostępu do danych, lepiej ją przebudować. Jeśli logika biznesowa przenosi się w większości bez zmian, wystarczy aktualizacja.
Program w Crédit Agricole, w ramach którego przeniesiono 600+ wewnętrznych aplikacji ze starych maszyn wirtualnych do AWS, korzystał z obu ścieżek. Aplikacje odbudowywano na wewnętrznym szkielecie CodeIgniter banku: część zaktualizowano, a część przebudowano od zera.
- Aktualizacja, gdy kod jest czytelny, jego działanie jasne, a różnica wersji frameworka niewielka
- Przebudowa, gdy logika biznesowa jest wszędzie wymieszana z warstwą prezentacji lub aplikacja zależy od usuniętych funkcji języka
- Wycofanie, gdy użycie jest bliskie zeru, a właściciel biznesowy się zgadza, bo najtańsza migracja to ta, której się nie przeprowadza
Podział portfela na bloki, każdy blok dla jednego zespołu
Przy tej skali pojedynczy centralny zespół staje się wąskim gardłem. Model podziału na bloki przydziela partię powiązanych aplikacji jednemu małemu zespołowi, który odpowiada za nie od analizy do przełączenia.
Bloki grupuje się według wspólnych zależności, a nie alfabetycznie. Aplikacje, które korzystają z tej samej bazy danych lub wywołują się nawzajem, powinny przechodzić razem, inaczej ta sama praca integracyjna powtarza się w kilku zespołach.
Bloki sprawiają też, że postęp da się mierzyć. Każdy zespół raportuje te same stany dla każdej aplikacji, na przykład przeanalizowana, zmigrowana, przetestowana, przełączona i wyłączona, a tablica programu jest sumą tych stanów. Tak prowadzono program w Crédit Agricole, a SDK Enterprises zrealizowało 50+ migracji aplikacji jako część zespołu programu.
Jeden standardowy szkielet, na który trafia każda aplikacja
Standardowy szkielet aplikacji zamienia setki migracji w powtarzalny proces. Ustala decyzje, których nie należy podejmować od nowa dla każdej aplikacji: strukturę katalogów, konfigurację ze zmiennych środowiskowych, format logów, health checki, punkty podpięcia uwierzytelniania i pipeline wdrożeniowy.
Każda zmigrowana aplikacja różni się wtedy tylko logiką biznesową. Osoby przeglądające kod wiedzą, gdzie szukać, zespoły utrzymania dostają spójne logi i alarmy, a poprawka w szkielecie trafia do każdej aplikacji na nim zbudowanej.
Szkielet powinien być mały i wersjonowany. Jeśli rozrośnie się we własny framework, zespoły zaczną go omijać.
Przełączenie i wycofanie zaplanowane przed pierwszą migracją
Każda aplikacja potrzebuje planu przełączenia, który określa, jak przenosi się ruch, jak przenoszą się dane i jak wrócić. Trzeba to ustalić, zanim przeniesie się pierwszą aplikację. Improwizowanie wycofania w trakcie incydentu to najprostszy sposób, by program migracji stracił zaufanie biznesu.
- Okno zamrożenia: uzgodnienie z właścicielem biznesowym, od kiedy wstrzymuje się zmiany na starej maszynie wirtualnej
- Synchronizacja danych: migracja danych z wyprzedzeniem, a potem końcowa synchronizacja przyrostowa w oknie przełączenia
- Przełączenie ruchu: zmiana DNS lub reguł load balancera, z niskimi wartościami TTL w DNS ustawionymi kilka dni wcześniej
- Smoke testy: krótki skryptowy test logowania, kluczowych ekranów i integracji zaraz po przełączeniu
- Warunek wycofania: wskazana osoba i spisane warunki powrotu do starej wersji
- Zachowanie starej maszyny: zatrzymanie jej bez usuwania, dopóki aplikacja nie przepracuje bezproblemowo w AWS uzgodnionego okresu
Runbooki, z których każdy zespół skorzysta od pierwszego dnia
Runbook to lista kontrolna jednej powtarzalnej operacji: przygotowania aplikacji, jej przełączenia, wycofania, wyłączenia maszyny wirtualnej. Każdy pisze się raz, testuje na kilku pierwszych aplikacjach i aktualizuje za każdym razem, gdy coś zaskoczy zespół.
Dobre runbooki podają polecenia, osoby odpowiedzialne i oczekiwane wyniki, a nie zamiary. „Sprawdzić, czy aplikacja działa” to nie jest krok. „Zalogować się jako użytkownik testowy i potwierdzić, że pulpit wczytuje dane konta” to jest krok.
Runbooki pozwalają też inżynierom, którzy dołączają w trakcie programu, szybko stać się produktywnymi. Specjalista, który przychodzi w szóstym tygodniu, powinien po jednej sesji w parze móc przełączyć aplikację, postępując według dokumentów.
Gdzie w dużej migracji sprawdza się zespół z zewnątrz
Duże programy często potrzebują dodatkowych mocy przerobowych na określony czas, bez oddawania kontroli. Przejmujemy bloki migracji w ramach większych programów, pracując na szkielecie, runbookach i narzędziach klienta, z naszymi inżynierami i sprawdzonymi specjalistami freelancerami w ramach jednej umowy.
Najważniejsze wnioski
- Każdą aplikację trzeba zinwentaryzować i sklasyfikować przed migracją którejkolwiek z nich, aby planować pracę według ścieżek.
- Aktualizację, przebudowę lub wycofanie wybiera się dla każdej aplikacji według spisanych kryteriów, które każdy zespół stosuje tak samo.
- Portfel dzieli się na bloki powiązanych aplikacji, za które od początku do końca odpowiada jeden mały zespół.
- Mały, wersjonowany szkielet aplikacji sprawia, że setki migracji są spójne i łatwe do przeglądu.
- Żadnej aplikacji nie przełącza się bez przetestowanej ścieżki wycofania i nadal dostępnej starej maszyny wirtualnej.
FAQ
Ile trwa migracja setek aplikacji do AWS?
To zależy od liczby aplikacji, odsetka tych, które wymagają przebudowy, liczby równoległych zespołów i okien przełączenia akceptowanych przez biznes. Szacunek warto zrobić po klasyfikacji: zmierzyć czas kilku aplikacji z każdej ścieżki, pomnożyć przez liczebność ścieżki i podzielić przez przepustowość zespołów.
Czy najpierw przenieść aplikacje metodą lift and shift, a zmodernizować później?
Lift and shift jest najszybszy, gdy aplikacja działa już na wspieranym środowisku uruchomieniowym, a celem jest opuszczenie centrum danych. W przypadku aplikacji na środowiskach bez wsparcia przeniesienie ich bez zmian przenosi stare ryzyka na nową platformę, więc aktualizacja lub przebudowa w trakcie migracji jest często łącznie tańsza.
Czym jest migracja z podziałem na bloki?
Migracja z podziałem na bloki dzieli duży portfel aplikacji na partie powiązanych aplikacji i przydziela każdą partię jednemu zespołowi, który odpowiada za nią od analizy do przełączenia. Usuwa to centralne wąskie gardło i ułatwia śledzenie postępów wielu zespołów.