Migracja do Google Cloud bez nerwowego weekendu

Z serwerów on-prem, z PaaS-a albo z innej chmury: etapami, z próbą generalną i z drogą powrotu aż do ostatniego kroku.

Brzmi znajomo?

Kończy się umowa na serwerownię albo rachunek za PaaS rośnie szybciej niż firma.
Nikt do końca nie wie, co działa na starych serwerach.
Poprzednia migracja utknęła w połowie i teraz utrzymujecie oba środowiska.
Przestój nie wchodzi w grę, półroczne zamrożenie nowych funkcji też nie.

Co naprawdę działa, co od czego zależy i co można po prostu wyłączyć.

Każdy etap z drogą powrotu, żeby żaden krok nie był nieodwracalny, zanim naprawdę musi.

Sieć, IAM, GKE albo Cloud Run i Cloud SQL, gotowe, zanim przeniesie się jakikolwiek ruch.

Replikacja tam, gdzie to ważne, żeby przełączenie było przełącznikiem, a nie długim eksportem.

Runbook przećwiczony wcześniej i zwykle wykonany po godzinach.

Przegląd
Pokazujesz, co działa i gdzie boli. Patrzę na rzeczywistą konfigurację, a nie na slajdy.
Plan
Krótki pisemny plan: co się zmienia, w jakiej kolejności i ile to zajmie.
Wdrożenie
Małe kroki, które da się przejrzeć i cofnąć, najpierw dev, potem prod.
Przekazanie
Dokumentacja i runbook, żeby Twój zespół sam to utrzymał, a jeśli chcesz, zostaję na dyżurze.

Przeniosłem startup B2B SaaS z Heroku na GKE i Cloudflare, a w ramach tej samej, pięciomiesięcznej współpracy dodałem drugi region poza Google Cloud.
Drugi region w szczegółach (artykuł po angielsku) →
Przeniosłem stare aplikacje banku z on-prem do GCP, przeprojektowane pod chmurę, przy około 35% niższych kosztach infrastruktury (HSBC).
W InPost migrowałem aplikacje on-prem do rozwiązań cloud-native.