Strategia migracji do chmury

Strategia migracji do chmury

W praktyce klienci najczęściej wybierają jedną z 6 różnych form strategii migracji (6R), która stanowi została rozwinięcie propozycji Gartnera z 2011 roku. Okazuje się jednak że w większości przypadków granice nie są sztywne i często na siebie zachodzą. Decyzja która strategia migracji do chmury powinna zostać zastosowana zazwyczaj podejmowana jest w drugim kroku migracji czyli w fazie odkrywania i planowania zasobów. W tej fazie odkrywa się portfolio zasobów i aplikacji oraz zależności pomiędzy nimi i dopiero uzbrojeni w taką wiedzę dobieramy najlepszą formę migracji dla każdej aplikacji.

W zależności od złożoności naszego obecnego rozwiązania i uwarunkowań licencyjnych, proces migracji do chmury oraz dobór strategii migracji może nie być oczywisty od razu, co najważniejsze może się zmienić już w trakcie samej migracji. Napewno dużo łatwiej jest zmigraować aplikację skonteneryzowaną niż dużą monolityczną aplikację z środowiska mainframe. Zazwyczaj tutaj pada pierwsze pytanie od czego zacząć? Sugerujemy zacząć od czegoś prostego, aplikacji, która nie ma dziesiątek zależności i integracji. W miarę nabywania wiedzy kolejne kroki będą łatwiejsze. Tak czy inaczej wsparcie merytoryczne w planowaniu, a później na etapie samej migracji się przyda.

Jeżeli już znamy portfolio zasobów i aplikacji, które chcemy przenieść możemy nakreślić plan i dobrać nejlepszą strategię migracji.

Najważniejsze: plan może podlegać zmianom w miarę postępu migracji

Ścieżki migracji

strategia 6r

1.Rehosting - inaczej „lift-and-shift”

Strategia najprostsza i najszybsza. Poprostu odwzorowujemy infrastrukturę z naszego centrum danych i uruchamiamy "kopię" środowiska. W przypadku dużej migracji, w którym organizacja chce szybko przeprowadzić migrację do chmury i zapewnić ciągłość działania jest uzasadniona biznesowo i technicznie. Nawet w takim wypadku bez optymalizacji chmury firma może zaoszczędzić nawet około 30 procent swoich kosztów dzięki tej strategii.

Strategia ta ma kolejną dużą zaletę, jest sporo narzędzi, które mogą zautomtyzować ten proces. Czasami dobrym podejściem może być ręczna alternatywa - nauczymy się jak skonfigurować aplikację w nowym środowisku chmurowym, szczególnie dotyczy to starszych systemów.

Nie należy traktować tej strategii jako końca historii migracji. Bardzo często aplikacje można zmigrować za pomocą strategii lift i shift, a następnie, po przejściu do chmury ponownie ją przeprojektować i wykorzystać usługi zarządzalne jak Amazon Elastic Kubernetes Service czy Amazon Relational Database Service (RDS).

2. Replatforming - Zmiana technologii (lift and reshape).

Strategia migracji do chmury replatforming to pierwsza optymalizacja środowiska. Przykładem może być wykorzystywany obecnie system bazodanowy. W podejściu lift and shift, dobieramy serwer (najczęściej instancję EC2), instalujemy odpowiednie oprogramowanie, aktualizujemy system operacyjny, instalujemy i konfigurujemy serwer baz danych, przygotowujemy plan backupów i prawie gotowe. Trzeba będzie jeszcze na bieżąco aktualizować zarówno system operacyjny jak i samo oprogramowanie bazodanowe.

Zalecamy jednak podejście replatforming polegające na skorzystaniu z zarządzanej przez dostawcę chmury np Amazon Web Services usługi RDS. To AWS zajmuje się za nas utrzymaniem i aktualizacją systemu operacyjnego, serwera baz danych i backupami. My wybieramy tylko parametry.

Innym przykładem jest instalacja aplikacji zamiast na ręcznie konfigurowanym serwerze (czy klastrze serwerów za load balancerem) w usłudze Amazon Elastic Beanstalk która za nas skonfiguruje całe środowisko dla naszej aplikacji.

Możemy również zmienić środowisko z komercyjnego kontenera Java Weblogic na opensourcowe rozwiązanie Tomcat. Taka migracja oznacza duże oszczędności na licencjach.

3. Repurchasing - zakup (replace - drop and shop)

Strategia ta polega na wycofaniu aplikacji z użycia i zastąpieniu jej wersją chmurową. W efekcie jest to zmiana licencji - zamiast tradycyjnej licencji lokalnej możesz zacząć korzystać z aplikacji w chmurze.

Najlepiej w trakcie procesu przeglądu portfolio aplikacji zidentyfikować starsze aplikacje, które nie spełniają już potrzeb biznesowych. Przejście do chmury daje możliwość wymiany tych aplikacji i przejścia do wersji chmurowej, która zazwyczaj oferuje nowoczesny zestaw funkcji oraz dostęp z dowolnego urządzenia jak smartfon czy tablet.

Podejście takie warto zastosować w przypadku starszych aplikacji niekompatybilnych z chmurą. Jeżeli istniejące aplikacje są przydatne, ale migracja przy użyciu metody migracji refactoring byłaby trudna, dobrym rozwiązaniem zastosować metodą „upuść i zrób zakupy”. Zapewni to ulepszony zestaw funkcji wraz z zaletami platformy chmurowej.

4. Refactoring - refaktoryzacja (re-writing / decoupling application)

To najbardziej wymagająca strategia migracji do chmury, która w perspektywie czasu daje najwięcej korzyści. Polega ona na dostosowaniu aplikacji do pracy w chmurze poprzez użycie funkcji natywnych dla chmury oraz wykorzystania szeregu usług pomocniczych do których można zaliczyć przypadku migracji do AWS:
- Lambda
- API Gateway
- SNS
- SQS
- SageMaker (sztuczna inteligencja)

Głównymi motywatorami takiego podejścia może być silna potrzeba biznesowa zmiany funkcjonalności, skalowania lub wydajności, które w innym przypadku byłyby trudne do osiągnięcia w istniejącym środowisku aplikacji.

Jeżeli chcesz przejść z architektury monolitycznej do architektury zorientowanej na usługi (lub bez serwera - serverless), aby zwiększyć sprawność lub poprawić ciągłość biznesową. Strategia ta jest najdroższa, ale jeżeli produkt ma być używany przez miliony użytkowników na całym świecie to najlepszy wybór.

Przykład architektury serverless:

serverless diagram

5. Retire / decommission - wycofanie

Podczas dokładnej analizy środowiska on-premise (własna serwerownią / centrum danych) okazuje się często że mamy aplikacje, których albo nie używamy, albo nie są one już przydatne biznesowo. W takim wypadku zalecamy po prostu zakończyć cykl życia takiej aplikacji i nie przenosić jej do chmury.

W takim wypadku aplikacje które są refaktoryzowane mogą zostać uzupełnione o funkcje tej aplikacji, ale tylko jeżeli będą one używane.

6. Retain - zachowaj

Migracja musi mieć sens i uzasadnienie biznesowe. W niektórych przypadkach aplikacje wręcz nie powinna być migrowana do chmury.

Jeżeli firma podjęła niedawno duże inwestycje w aplikację lokalną i zasoby sprzętowe dla niej, to wydatki się nie zamortyzowały i ponoszenie kosztów migracji w danym momencie nie jest dobry wyborem. Może się też zdarzyć że aplikacja jest w technologi, która nie jest dostępna w chmurze. Zdarza się że aplikacja podlega restrykcyjnym regulacjom prawnym których spełnienie jest albo nie możliwe, albo bardzo kosztowne.