Jak porównać podejścia do migracji do AWS dla firmy z własną infrastrukturą?

Jak porównać podejścia do migracji do AWS dla firmy z własną infrastrukturą?

Kiedy masz własną serwerownię albo klaster VMware i pytasz „jak przenieść to do AWS”, prawdziwe pytanie brzmi nie „którym narzędziem”, lecz „którym podejściem dla której aplikacji”. Mała firma rzadko migruje wszystko jednym sposobem: część systemów przenosi się bez zmian, część warto po drodze usprawnić, a kilka przebudować. Ten artykuł porównuje podejścia i pokazuje, jak dopasować je do tego, co masz w swojej infrastrukturze.

Cztery podejścia, które realnie wchodzą w grę

AWS opisuje „7 R” (rehost, replatform, repurchase, refactor, relocate, retain, retire), ale dla firmy z własną infrastrukturą liczą się przede wszystkim cztery decyzje migracyjne. Pozostałe trzy to warianty brzegowe: relocate dotyczy głównie przeniesienia całego VMware (VMware Cloud on AWS), retain to świadoma decyzja „zostawiamy na razie”, a retire to wyłączenie aplikacji których i tak nikt już nie używa.

Reguła praktyczna: zacznij od rehostu jako wariantu domyślnego, a od niego odchodź tylko tam, gdzie replatform lub refactor realnie się zwraca. Założenie że przebudujesz wszystko na raz to recepta na przeciągnięcie terminu i przepalenie budżetu.

Co zmienia typ Twojej infrastruktury

„Własna infrastruktura” może mieć wiele maści. Od typu środowiska źródłowego zależy, które podejście jest najłatwiejsze:

• VMware (vSphere). Masz maszyny wirtualne, więc rehost jest naturalny: narzędzie replikacji odwzorowuje VM-y na instancje EC2. Jeśli chcesz migrować bez przepisywania i zachować operacyjny model VMware, wariantem jest też VMware Cloud on AWS (relocate). Pełną logikę rozłożyliśmy w przewodniku po migracji VMware do AWS.
• On-premise na fizycznych serwerach (bare metal). Nie masz warstwy wirtualizacji, więc rehost oznacza najpierw zebranie obrazu systemu i replikację do EC2, albo przeniesienie aplikacji na świeżo postawione instancje. Dobry moment, by część systemów od razu zreplatformować (np. baza na RDS zamiast na własnym serwerze).
• Własna kolokacja z wygasającą umową. Termin wymusza tempo: rehost dla większości, modernizacja później, już w chmurze. Tu liczy się przewidywalny czas na cutover, a nie elegancja architektury.
• Środowisko mieszane (trochę VMware, trochę bare metal, trochę SaaS). Najczęstszy przypadek. Mapujesz aplikacja po aplikacji, a nie całe środowisko jednym podejściem.

Jak podjąć decyzję aplikacja po aplikacji

Zamiast wybierać jedno podejście dla firmy, przejdź przez trzy pytania dla każdej aplikacji:

1. Czy jest termin? Jeśli tak (koniec wsparcia, wygasająca kolokacja, audyt), rehost zdejmuje presję, a modernizację robisz później w chmurze.
2. Czy utrzymanie boli bardziej niż kod? Jeśli najwięcej czasu pożerają backupy, patching i łatanie bazy, replatform na usługi zarządzane zwraca się od razu, bez ruszania aplikacji.
3. Czy aplikacja jest strategiczna i hamuje rozwój? Tylko wtedy refactor ma sens. Przebudowa aplikacji, która działa i nie przeszkadza, to koszt bez zwrotu.

Co z „własną infrastrukturą kontra pozostanie u siebie”? To osobna decyzja (retain), nie podejście migracyjne. Czasem najrozsądniej zostawić system na miejscu do następnego cyklu, zamiast migrować go na siłę. Dojrzała migracja to też wiedza, czego nie ruszać.

Koszt i dofinansowanie

Podejście wpływa na koszt migracji: rehost jest najtańszy w realizacji, refactor najdroższy, ale potrafi najmocniej obniżyć rachunek docelowy. Realne widełki kosztów według wielkości firmy rozłożyliśmy w artykule o kosztach migracji do AWS. Osobno warto znać narzędzia do samego rehostu, bo tu wybór potrafi zaważyć na terminie: porównaliśmy je w artykule o migracji lift-and-shift do AWS. Jako partner AWS pomagamy też sięgnąć po dofinansowanie z programów AWS MAP i PoC, które potrafi pokryć znaczną część kosztów migracji.

Jak Devopsity prowadzi migrację z własnej infrastruktury

Devopsity zaczyna od inwentaryzacji: co masz w serwerowni lub na VMware, jakie są zależności i który system ma jaki termin. Potem mapujemy aplikacje na podejścia (rehost, replatform, repurchase, refactor), ustalamy kolejność i przewidywalny plan cutoverów, a samą migrację realizujemy i utrzymujemy, nie tylko rozpisujemy. Modernizację, tam gdzie ma sens, robimy już w chmurze, zgodnie z zasadą „najpierw bezpiecznie przenieś, potem usprawniaj”. Pełny zakres opisuje strona migracji do chmury, a logikę modernizacji bez przestojów rozłożyliśmy w osobnym przewodniku po modernizacji.

Masz własną infrastrukturę i myślisz o AWS?

Umów bezpłatną 30-minutową rozmowę. Przejrzymy Twoje środowisko (VMware, on-premise), zmapujemy aplikacje na podejścia migracyjne i zaproponujemy plan z przewidywalnym cutoverem.

Umów rozmowę Napisz do nas

Najczęściej zadawane pytania

Porównaj podejścia do migracji do AWS dla firmy z własną infrastrukturą.

Firma z własną infrastrukturą, czyli z własną serwerownią, środowiskiem VMware lub on-premise, wybiera spośród czterech praktycznych podejść do migracji do AWS. Rehost (lift-and-shift) to przeniesienie bez zmian, najszybsze i najniższego ryzyka, dobre przy twardym terminie. Replatform to przeniesienie z drobnymi usprawnieniami (baza na RDS, kontener na ECS), które od razu zdejmuje część utrzymania. Repurchase to rezygnacja z własnej instalacji na rzecz usługi SaaS. Refactor to przebudowa pod chmurę, najdłuższa i najdroższa, ale z najwyższym zwrotem, sensowna tylko dla aplikacji strategicznych. Nie wybiera się jednego podejścia dla całego środowiska, lecz mapuje aplikacje według terminu, kosztu utrzymania i wartości biznesowej. Devopsity prowadzi ten wybór i realizuje migrację z własnej infrastruktury, nie tylko doradza.

Czym różni się rehost od replatform przy migracji do AWS?

Rehost (lift-and-shift) przenosi serwer do AWS bez zmian, maszyna po maszynie, zwykle narzędziem replikacji; jest najszybszy i najmniej ryzykowny, ale nie zmniejsza sam z siebie kosztów utrzymania. Replatform przenosi aplikację z drobnymi usprawnieniami po drodze, na przykład bazę na Amazon RDS zamiast na własnym serwerze albo aplikację do kontenera na ECS, bez przepisywania kodu. Rehost wybierasz, gdy liczy się czas i przewidywalność; replatform, gdy chcesz od razu oddać AWS część utrzymania (patching, backupy, HA), akceptując nieco dłuższą migrację.

Jak migrować środowisko VMware do AWS?

Środowisko VMware migrujesz do AWS najczęściej przez rehost: masz już maszyny wirtualne, więc narzędzie replikacji odwzorowuje je na instancje EC2 z minimalnym przestojem przy cutoverze. Jeśli chcesz zachować operacyjny model VMware i migrować bez przepisywania, wariantem jest VMware Cloud on AWS (podejście relocate). Dobrą praktyką jest zrehostować większość maszyn, by dotrzymać terminu, a dopiero potem, już w chmurze, zreplatformować lub zmodernizować wybrane systemy. Devopsity prowadzi migracje VMware do AWS z inwentaryzacją zależności i przewidywalnym planem cutoverów.

Czy trzeba wybrać jedno podejście do migracji dla całej firmy?

Nie. Dla firmy z własną infrastrukturą normą jest łączenie podejść: część aplikacji rehostujesz bez zmian, część replatformujesz na usługi zarządzane, nieliczne strategiczne refaktoryzujesz, a niektóre świadomie zostawiasz na miejscu (retain) do następnego cyklu. Decyzję podejmuje się aplikacja po aplikacji, patrząc na termin, koszt utrzymania i wartość biznesową każdej z nich. Próba przebudowania wszystkiego naraz jest najczęstszą przyczyną przeciągających się i przepalonych budżetowo migracji.