Migracja do chmury: pytania do partnera przed umową

Jak partner ustali, co faktycznie działa w Państwa firmie

Plan migracji jest tak dobry, jak inwentaryzacja, na której się opiera. Warto zapytać partnera, jak ją przygotuje: na podstawie rozmów z właścicielami aplikacji, danych z infrastruktury, takich jak metryki serwerów i połączenia sieciowe, samego kodu czy wszystkich trzech źródeł. Istniejąca dokumentacja to punkt wyjścia, a nie dowód, bo z czasem rozmija się z tym, co naprawdę działa.

Trzeba też zapytać, co inwentaryzacja będzie zawierać i do kogo będzie potem należeć. Dobra odpowiedź wymienia pola i potwierdza, że inwentaryzacja zostaje u Państwa, niezależnie od dalszych decyzji.

• Każda aplikacja, jej właściciel biznesowy i stopień krytyczności
• Środowiska uruchomieniowe, frameworki i systemy operacyjne, z oznaczeniem wszystkiego, co straciło wsparcie
• Bazy danych, udziały plików, zadania cykliczne i kolejki, od których zależy każda aplikacja
• Integracje w obu kierunkach, łącznie z tymi, których nikt nie udokumentował
• Licencje powiązane ze sprzętem lub liczbą procesorów, które mogą nie przenieść się do chmury
• Akceptowalny przestój i kalendarz biznesowy: koniec miesiąca, szczyt sezonu, terminy regulacyjne

Strategia dla każdej aplikacji, a nie jedna dla całego portfela

Aplikacje przenosi się do chmury na różne sposoby. Typowe opcje to przeniesienie aplikacji bez zmian (lift and shift), przeniesienie z drobnymi zmianami, takimi jak zarządzana baza danych (replatforming), przebudowa pod usługi chmurowe (refaktoryzacja), zastąpienie produktem SaaS, pozostawienie jej na razie na miejscu albo wycofanie. Partner, który proponuje jedno podejście do wszystkiego, nie przyjrzał się wystarczająco uważnie.

Warto poprosić o kryteria wyboru i o pokazanie ich zastosowania do trzech lub czterech Państwa aplikacji przed podpisaniem umowy. Sposób rozumowania o prawdziwych systemach mówi więcej niż slajd z metodą. Szczególnie warto zapytać, jak partner traktuje aplikacje na środowiskach bez wsparcia, bo przeniesienie ich bez zmian przenosi stare ryzyka na nową platformę.

Kto projektuje i zabezpiecza landing zone

Landing zone to przygotowane środowisko docelowe: struktura kont, tożsamość i dostęp, sieć, logowanie, szyfrowanie i zabezpieczenia, które dziedziczy każda aplikacja. Błąd na tym etapie powtarza się w każdej aplikacji, która tam trafi. Warto zapytać, kto ją projektuje, czy jest zdefiniowana jako kod, na przykład w Terraform, i czy Państwa zespół bezpieczeństwa przegląda ją przed przeniesieniem pierwszej aplikacji.

Bezpieczeństwo w chmurze jest współdzielone. Dostawca zabezpiecza infrastrukturę bazową, a za to, jak się ją konfiguruje i używa, odpowiada klient. Warto zapytać partnera, które zabezpieczenia skonfiguruje, które zostaną po stronie Państwa zespołu oraz jak dostęp jego własnych inżynierów jest przyznawany, rejestrowany i na końcu odbierany.

• Osobne konta lub projekty dla każdego środowiska, z odizolowaną produkcją
• Single sign-on z imiennymi użytkownikami i rolami o minimalnych uprawnieniach, bez współdzielonych danych logowania administratora
• Centralne logowanie i ślady audytowe, których inżynierowie projektu nie mogą wyłączyć
• Domyślne szyfrowanie danych w spoczynku i w tranzycie, z sekretami trzymanymi poza kodem
• Regiony wybrane zgodnie z wymogami dotyczącymi lokalizacji danych i obowiązkami wynikającymi z RODO

Omówienie jednego przełączenia i jednego wycofania krok po kroku

Przełączenie to moment, w którym ruch i dane przechodzą do nowego środowiska, i to wtedy migracja jest dla biznesu najbardziej widoczna. Warto poprosić partnera, by krok po kroku omówił przełączenie jednej z Państwa aplikacji: jak synchronizowane są dane, jak przełączany jest ruch, jakie kontrole są potem wykonywane i kto decyduje, że się udało.

Następnie trzeba zapytać, jak partner by się wycofał. Wiarygodny plan wskazuje warunki, które uruchamiają wycofanie, osobę podejmującą decyzję i czas, przez jaki stare środowisko pozostaje dostępne. Jeśli od przełączenia użytkownicy zapisali dane w nowym środowisku, trzeba zapytać, jak te dane wrócą do starego. Słabe plany pomijają to pytanie.

Nasz artykuł o migracji setek starszych aplikacji do AWS pokazuje, jak te kroki zamieniają się w runbooki w dużym portfelu aplikacji.

Koszty widoczne, zanim przyjdzie pierwszy rachunek

Koszty chmury zachowują się inaczej niż w centrum danych. Płaci się za to, co działa, łącznie ze środowiskami testowymi, których nikt nie wyłączył, stale rosnącą przestrzenią dyskową i danymi przesyłanymi poza sieć dostawcy. Warto poprosić o szacunek kosztów dla każdej aplikacji ze spisanymi założeniami i zapytać, jak partner porówna go z rzeczywistym użyciem w pierwszych miesiącach.

Przejrzystość kosztów to decyzja projektowa, a nie miesięczny raport. Warto poprosić o reguły tagowania, które wiążą każdy zasób z aplikacją i właścicielem, budżety i alerty od pierwszego dnia oraz przegląd rozmiarów instancji, gdy aplikacje popracują pod prawdziwym obciążeniem. Dobieranie serwerów w chmurze do starego sprzętu to pewny sposób, by płacić za moc, z której nikt nie korzysta.

Sygnały ostrzegawcze, że oferta migracji nie jest gotowa

Każdy z tych sygnałów może mieć wyjaśnienie. Kilka w tej samej ofercie zwykle oznacza, że ryzyko zostawiono Państwu do odkrycia.

• Sztywny harmonogram, zanim ktokolwiek zobaczył inwentaryzację
• Jedna strategia migracji zastosowana do każdej aplikacji
• Brak pisemnego planu wycofania albo wycofanie oparte na odtwarzaniu kopii zapasowych pod presją
• Konta chmurowe, kod infrastruktury lub pipeline'y należące do partnera, a nie do Państwa
• Szacunki kosztów bez założeń i bez planu tagowania czy budżetów
• Przekazanie wiedzy zaplanowane na ostatni tydzień

Przekazanie wiedzy planowane od pierwszego tygodnia, a nie ostatniego

Migracja się kończy, utrzymanie platformy już nie. Warto zapytać, jak Państwa zespół nauczy się obsługiwać to, co powstanie: praca w parach nad prawdziwymi zadaniami w trakcie migracji, runbooki do powtarzalnych operacji i omówienie monitoringu oraz alertów z osobami, które będą pełnić dyżury.

Wszystko powinno od początku znajdować się na Państwa kontach i w Państwa repozytoriach: kod infrastruktury, pipeline'y, runbooki i diagramy. Następnie należy uzgodnić, jak odbywa się odbiór przekazania, na przykład Państwa zespół wdraża i wycofuje aplikację bez pomocy partnera.

Pracowaliśmy w zespole, który przeniósł 600+ wewnętrznych aplikacji Crédit Agricole ze starych maszyn wirtualnych do AWS, i sami zrealizowaliśmy 50+ z tych migracji. Jeśli potrzebują Państwo drugiej opinii o ofercie migracji albo zespołu do realizacji części prac, nasi inżynierowie infrastruktury chmurowej mogą przejść z Państwem przez te pytania.

FAQ