Struktura migracji 6-R

Model migracji 6-R to ustrukturyzowane podejście do kategoryzowania sposobu przenoszenia poszczególnych obciążeń lokalnych do chmury. Microsoft i cała branża używają tych sześciu strategii — nazywanych również wzorcami migracji — aby podejmować decyzje dotyczące portfela sprawnie i konsekwentnie. Zamiast stosować jedno podejście do wszystkich przypadków, architekci oceniają każdą aplikację indywidualnie i przypisują jej najbardziej odpowiednią strategię R.

Rehost (Lift and Shift) oznacza przeniesienie obciążenia do Azure bez zmian w kodzie. Istniejący obraz VM lub plik binarny aplikacji jest uruchamiany w usłudze Azure IaaS. To najszybsza strategia, zwykle stosowana w przypadku starszych aplikacji, które trudno zmodyfikować, albo organizacji z napiętymi terminami migracji. Aparat replikacji Azure Migrate automatyzuje rehosting większości maszyn wirtualnych Windows i Linux.

Replatform (nazywany również Lift, Tinker, and Shift) obejmuje niewielkie optymalizacje podczas migracji bez zmieniania podstawowej architektury. Przykłady to przeniesienie samodzielnie zarządzanej bazy danych MySQL z maszyny VM do Azure Database for MySQL albo zastąpienie samodzielnie hostowanego przekaźnika SMTP usługą Azure Communication Services. Zyskujesz korzyści usług zarządzanych — poprawki, kopie zapasowe, skalowanie — bez przepisywania logiki aplikacji.

Rearchitect (lub Refactor) oznacza znaczącą zmianę architektury aplikacji, aby wykorzystać możliwości natywne dla chmury. Monolityczna aplikacja .NET może zostać podzielona na mikrousługi wdrożone w Azure Container Apps, a system wsadowy oparty na zadaniach cron może zostać zaimplementowany jako Azure Functions. Rearchitect zapewnia największe długoterminowe korzyści pod względem skalowalności i kosztów, ale wymaga największych inwestycji.

Rebuild oznacza całkowite porzucenie istniejącej aplikacji i zbudowanie nowego rozwiązania natywnego dla chmury. Strategię tę wybiera się, gdy utrzymanie starszej aplikacji jest zbyt kosztowne, korzysta ona ze stosu technologicznego wycofanego z obsługi lub po prostu nie może spełnić wymagań biznesowych nawet po migracji. Rebuild zapewnia maksymalne korzyści środowiska chmurowego, ale najdłuższy czas do uzyskania wartości. Typowymi celami są usługi Azure PaaS i serverless, takie jak Azure App Service, Azure Functions i Cosmos DB.

Replace oznacza zastąpienie istniejącej aplikacji lokalnej dostępnym komercyjnie produktem SaaS, który zapewnia równoważną lub lepszą funkcjonalność. Przykładowo można zastąpić lokalny system CRM usługą Dynamics 365 albo starszy serwer plików usługą SharePoint Online. Replace całkowicie eliminuje zarządzanie infrastrukturą. Kompromisem jest mniejszy zakres dostosowywania oraz potencjalnie znaczny nakład pracy związany z migracją danych i zarządzaniem zmianą.

Retire to najprostsza strategia — identyfikujesz aplikacje, które nie są już używane, są redundantne lub zostały zastąpione, i wycofujesz je zamiast migrować. Dane inwentaryzacyjne zbierane przez Azure Migrate często pokazują, że znaczny odsetek (czasem 20–30%) serwerów lokalnych ma bardzo niskie wykorzystanie lub nie ma aktywnych użytkowników. Wycofanie tych aplikacji zmniejsza zakres migracji, koszty licencji i złożoność operacyjną.

Wybór odpowiedniej strategii R wymaga przeanalizowania czterech czynników dla każdej aplikacji: krytyczności biznesowej, złożoności technicznej, harmonogramu migracji i całkowitego kosztu posiadania. Prosty front-end internetowy bez zależności integracyjnych jest dobrym kandydatem do Rehost. Aplikacja z setkami procedur składowanych i niestandardowymi funkcjami bazy danych może wymagać Rearchitect lub Rebuild. Wewnętrzne narzędzia o niskiej wartości są dobrymi kandydatami do Retire lub Replace.

Azure Migrate udostępnia funkcję Business Case, która automatycznie sugeruje strategię migracji dla wykrytych serwerów na podstawie danych o wykorzystaniu, licencjonowaniu i cenach Azure. Grupuje obciążenia w kategorie Rehost, Replatform i End-of-Support, co ułatwia rozpoczęcie klasyfikacji według modelu 6-R. Przed sfinalizowaniem planu migracji możesz zastąpić dowolną rekomendację własną i dodać własny kontekst biznesowy.

Po przypisaniu strategii R do każdej aplikacji grupujesz je w fale migracji. Kandydaci do Rehost o niskim ryzyku zwykle tworzą pierwszą falę, aby budować pewność zespołu i znajomość narzędzi. Projekty Rearchitect i Rebuild są realizowane równolegle w strumieniach prac o dłuższych harmonogramach. Należy uwzględnić zależności między aplikacjami — na przykład warstwę internetową wywołującą współdzieloną bazę danych — aby powiązane aplikacje migrowały razem lub we właściwej kolejności.

Model 6-R jest zgodny z fazą Adopt w Cloud Adoption Framework firmy Microsoft. CAF udostępnia szablony planowania fal, macierze RACI i kwestionariusze oceny obciążeń, które pozwalają stosować model 6-R w skali przedsiębiorstwa. Mechanizmy kontroli ładu ustanowione w fazie Ready — landing zones, zasady, tożsamość — muszą być wdrożone przed rozpoczęciem fal migracji, aby migrowane obciążenia od pierwszego dnia trafiały do zgodnego środowiska.

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) z tej lekcji.

W tej lekcji nauczono się, że: model 6-R (Rehost, Replatform, Rearchitect, Rebuild, Replace, Retire) zapewnia słownictwo do podejmowania decyzji migracyjnych, każda strategia R wiąże się z innym kompromisem między kosztem a szybkością, a funkcja Business Case usługi Azure Migrate może automatycznie sugerować strategie na podstawie danych o wykorzystaniu. Następnie omówiono, jak Azure Migrate wykrywa i ocenia serwery lokalne.