Migracja do AWS rzadko oznacza „przenieś wszystko w weekend”. To proces rozłożony na etapy, zaprojektowany tak, żeby firma nie odczuła przestoju, a błędy wyszły na jaw w środowisku testowym, nie na produkcji.
1. Audyt obecnej infrastruktury
Jakie aplikacje, jakie zależności między nimi, jakie dane, jakie wymagania co do dostępności. Bez tego etapu nie da się dobrać sensownej strategii migracji ani wycenić projektu.
2. Wybór strategii migracji
- Lift-and-shift. Przeniesienie istniejących serwerów bez większych zmian — szybsze i tańsze na start.
- Replatforming. Drobne zmiany, np. przejście na zarządzaną bazę danych (RDS) zamiast własnego serwera bazodanowego.
- Przeprojektowanie architektury. Pełne wykorzystanie możliwości chmury — więcej pracy na start, większe korzyści docelowo.
3. Projekt architektury docelowej
Sieć (VPC), uprawnienia (IAM), wybór regionu, strategia backupu — zaprojektowane zgodnie z zasadami Well-Architected Framework, dopasowane do tego, co dla danej firmy ma największe znaczenie.
4. Migracja danych i testy
Dane i aplikacje trafiają do nowego środowiska równolegle do działającej produkcji. Testy funkcjonalne i wydajnościowe odbywają się przed jakimkolwiek przełączeniem realnego ruchu.
5. Przełączenie produkcyjne
Zmiana DNS albo routingu ruchu na nowe środowisko, zaplanowana w oknie serwisowym poza godzinami szczytu. Stare środowisko zostaje jeszcze przez jakiś czas jako zabezpieczenie na wypadek nieprzewidzianych problemów.
6. Opieka powdrożeniowa
Monitoring kosztów, przegląd uprawnień, optymalizacja wydajności — infrastruktura w chmurze wymaga ciągłej uwagi, nie jednorazowego uruchomienia i zapomnienia o niej.
Migracja kończy się nie wtedy, gdy aplikacja działa w chmurze, tylko gdy ktoś sprawdził, że działa tam poprawnie, bezpiecznie i w rozsądnej cenie.
Zastanawiasz się, jak to wygląda konkretnie w Twojej firmie? Najprościej to po prostu omówić.