Strategie migracji do chmury

Istnieje kilka sprawdzonych metod migracji do chmury. Firma Gartner zdefiniowała tzw. zasadę 5 R strategii migracji do chmury, którą można rozwinąć jako: Rehost, Refactor, Replatform, Rebuild i Replace.

Czym jest migracja do chmury?

Migracja do chmury to przeniesienie niektórych lub wszystkich Twoich procesów cyfrowych do dostawcy chmury. Migracja może dotyczyć przeniesienia procesów z Twojego centrum danych do chmury, od jednego dostawcy chmury do innego lub z chmury do Twojego centrum danych. W trakcie migracji do chmury możesz użyć jednej ze strategii 5 R:

Rehost – przeniesienie aplikacji bez zmiany architektury,
Refactor – modyfikacja aplikacji w celu lepszego dopasowania do specyfiki chmury,
Replatform – przeniesienie aplikacji bez istotnych zmian architektury, ale przy większym wykorzystaniu zalet chmury przez dostawcę chmury,
Rebuild – całkowita przebudowa i zmiana architektury,
Replace – rezygnacja z dotychczasowej aplikacji i jej zastąpienie gotową, która posiada podobne funkcjonalności.

Poniżej przedstawiam dokładniejszy opis trzech najpopularniejszych migracji do chmury wraz z wyszczególnieniem zalet i wad każdej z nich.

Rehost, czyli lift and shift

Strategia Rehost to jedna z najprostszych strategii migracji do chmury. Polega na przeniesieniu Twojej aplikacji / procesu do chmury bez jakiejkolwiek zmiany w jej architekturze. Przykładowo w przypadku migracji do chmury AWS serwery zastępujemy  usługą EC2, a strukturę sieci odtwarzamy za pomocą VPC.

Jednym z warunków powodzenia tego typu migracji jest zapewnienie przeniesionej aplikacji dostępu do tych samych danych w ten sam sposób, co dotychczas. AWS oferuje kilka serwisów storage, które mogą pomóc np. FSx for Windows File Server będzie właściwym wyborem przy przenoszeniu aplikacji hostowanej na Windows Server.

Zalety:

• brak zmian kodu i architektury,
• łatwiejsze zapewnienie wymagań zgodności i bezpieczeństwa,
• łatwa migracja kluczowych usług,
• niski koszt migracji, gotowe narzędzia do automatyzacji procesu.

Wady:

• brak wykorzystania wszystkich zalet chmury,
• możliwa gorsza wydajność przez niedostosowanie aplikacji do środowiska chmurowego,
• niepowodzenie migracji w przypadku niepełnego przeniesienia ustawień konfiguracyjnych,
• potencjalnie wyższe koszty eksploatacji przez brak dostosowania rozwiązania do specyfiki chmury.

Refactor

Strategia Refactor polega na przeniesieniu aplikacji do środowiska chmurowego, po uprzedniej zmianie architektury, tak, aby lepiej wykorzystywała zalety chmury. Tego typu  migracja wymaga modyfikacji kodu źródłowego w celu umożliwienia skorzystania z elastyczności chmury.

Strategia ta jest znacznie bardziej skomplikowana niż Rehost i niesie ze sobą wiele ryzyk, jeżeli będzie przeprowadzona nieprawidłowo. Potencjalnie zmiana w architekturze i kodzie aplikacji może doprowadzić do regresji lub nadmiernie zwiększonych kosztów eksploatacji.

Strategia Refactor pomimo wysokiej czasochłonności i wymienionych ryzyk umożliwia nam osiągnięcie dużych oszczędności w dłuższej perspektywie, a także osiągnięcie niezawodności niemożliwej do uzyskania we własnym centrum danych.

Zalety:

• długoterminowe oszczędności,
• zwiększona niezawodność i odporność na awarie,
• łatwiejsza rozszerzalność i dostosowanie do nowych wymagań.

Wady:

• większe koszty migracji,
• wymóg korzystania z pracy doświadczonych specjalistów chmurowych,
• ryzyko vendor lock-in, które może potencjalnie zwiększyć koszty migracji do innego dostawcy chmury lub z powrotem do własnego centrum danych.

Replatform

Strategia Replatform to swego rodzaju kompromis pomiędzy Rehost a Refactor. Jest podobna do strategii Rehost, ale wymaga już pewnych modyfikacji architektury i kodu w celu optymalnego wykorzystania chmury.

Przykładowe modyfikacje mogą polegać na użyciu usług zarządzanych np. Amazon RDS zamiast bazy danych na maszynie wirtualnej lub adaptację niektórych usług natywnych dla chmury np. AWS Lambda.

Zalety:

• efektywność kosztowa dzięki niższym kosztom migracji niż Refactor oraz niższym kosztom eksploatacji niż Rehost,
• możliwość stopniowej adaptacji większej liczby usług natywnych dla chmury.

Wady:

• zakres migracji może wzrosnąć, a wykorzystanie zbyt wielu serwisów natywnych dla chmury może doprowadzić do sytuacji, kiedy zakres modyfikacji w architekturze będzie tak istotny, że będzie wymagał pełnego przeprojektowania.

Rebuild

Strategia Rebuild polega na całkowitej przebudowie, zmianie architektury i konieczności wprowadzenia istotnych zmian w kodzie. Często wiąże się z koniecznością budowy aplikacji od podstaw.

Strategia ta jest szczególnie polecana dla mniej złożonych aplikacji, które nie są w dużym stopniu zależne od oprogramowania firm trzecich.

Zalety:

• możliwość skorzystania ze wszystkich innowacyjnych rozwiązań chmurowych,
• mniejszy stopień skomplikowania oraz mniejszy koszt wdrożenia w porównaniu do strategii Refactor,
• większe wykorzystanie usług natywnych chmury.

Wady:

• poziom funkcjonalności może być inny od oryginału,
• ryzyko sytuacji vendor lock-in, czyli uzależnienia się od jednego dostawcy usług chmurowych.

Replace

W tym podejściu nie dokonujemy żadnych zmian w kodzie aplikacji, zamiast tego wykorzystujemy gotowe rozwiązanie, które posiada podobne funkcjonalności oraz wykorzystuje zalety chmury.

Strategia Replace polega na zastąpieniu starej aplikacji nową dostępną w modelu SaaS – Software as a Service. Jest ona szczególnie wygodna, gdy chcemy skorzystać z potencjału chmury, ale jednocześnie nie chcemy ponosić kosztów migracji.

Zalety:

• niski koszt migracji,
• brak kosztów dalszego rozwoju systemu,
• zalety chmury w szczególności wysoka dostępność i skalowalność,
• przeniesienie odpowiedzialności na dostawcę systemu.

Wady:

• ryzyko uzależnienia się od jednego dostawcy,
• brak lub niski wpływ na kierunek rozwoju systemu,
• ryzyko długiego oczekiwania na zmiany,
• mniejsza kontrola nad własnymi danymi.

Podsumowanie

Decyzja o migracji do chmury to zaledwie pierwsza decyzja następująca przed szeregiem kolejnych, które będą miały istotny wpływ na koszt i powodzenie przedsięwzięcia. To olbrzymia szansa, ale również ryzyko niepowodzenia. Przed podjęciem tego typu decyzji powinniśmy przeanalizować dostępne zasoby oraz cele naszej firmy. Z pewnością warto skorzystać z konsultacji doświadczonych partnerów, którzy mają doświadczenie we wspieraniu procesu transformacji cyfrowej.