usługi

Sześć typów migracji a spokojny sen

Sześć lat minęło odkąd zaczęliśmy migrować klientów do chmury obliczeniowej. Sześć typów migracji najczęściej wymieniam w codziennych rozmowach z klientami. Sześć etapów można wyłonić w większości procesów migracyjnych. Trzy szóstki, które kojarzą się jednoznacznie, skłoniły mnie do refleksji. Zastanawiam się, czy migracja do chmury jest bardziej jak dzieło sił nieczystych, czy spokojna przejażdżka na rowerze wzdłuż najpiękniejszych plaż Miami?

Dobry początek

Świadomość możliwości chmury obliczeniowej przez ostatnie lata diametralnie się zmieniła, a co za tym idzie, zmieniły się również metody migracji jak i ich przedmiot. Mimo upływu lat, często z łezką w oku wracam do naszej pierwszej migracji.

Patrząc z perspektywy czasu zmigrowanie bloga do chmury (a od tego właśnie zacząłem) nie było żadnym „rocket science”. Ale sprawa się skomplikowała, gdy od klienta otrzymaliśmy jedynie dostęp FTP do ówczesnego hostingu. Blog istniał na rynku już kilka lat, posiadał sporą bazę danych, miał opublikowanych wiele artykułów, a co za tym idzie tonę zdjęć. My mieliśmy jedynie dostęp do hostingu via FTP, gdzie notorycznie zrywane było połączenie, występowały ograniczenia transferu, a przez to zachowanie ciągłości działania usługi w czasie migracji stało pod wielkim znakiem zapytania.

Czy się udało? Jasne, że tak. Czy było łatwo? Dziś powiedziałbym "piece of cake", ale chcąc być zupełnie szczerym, wtedy nie było to takie oczywiste, gdy o 4 rano gdy byliśmy w połowie drogi z przeniesieniem danych. Finalnie, migrację wykonaliśmy, przerwy w działaniu usługi nie było, ale media do artykułów archiwalnych “zaciągane” były jeszcze przez kilka kolejnych godzin.

Niezależnie od tego, co my jako zespół migracyjny tamtej nocy czuliśmy, nasz klient spał spokojnie. Nie, to nie jest chwyt marketingowy. Tak było. Rolą klienta w tej migracji było udostępnienie nam konta FTP (jak to dobrze, że mogliśmy wykorzystać php-shella, gdyż serwer nie był odpowiednio dobrze zabezpieczony). A następnie, w godzinach porannych, zweryfikowanie poprawności dodawania wpisów i redagowania artykułów. Czy tak jest zawsze? Oczywiście, że nie! W zależności od złożoności projektu zaangażowanie po stronie klienta jest różne. Najważniejsza staje się współpraca, komunikacja i jasno zdefiniowany plan migracji.

Typy migracji do chmury

We wstępie wspomniałem o sześciu typach migracji, które powoli stawały się standardem na rynku usług. Ze względu na dany typ migracji i skalę zaangażowania, przebieg procesu przejścia do chmury jest różny. Skupię się więc na trzech najczęściej spotykanych typach migracji.

Lift and shift

Lift-and-shift jest typem migracji pozwalającym na przeniesienie usług (serwerów) do chmury, bez konieczności dokonywania większych zmian po stronie aplikacji. Często określamy go mianem przeniesienia 1:1.

Z założenia jest to najszybszy i najłatwiejszy typ migracji, w którym możemy zacząć korzystać z dobrodziejstw chmury. Migracja, szczególnie gdy klient posiada już własne środowisko zwirtualizowane może odbyć się za przysłowiowym jednym kliknięciem (eksport obrazu maszyny wirtualnej do chmury, import i uruchomienie u nowego dostawcy). Dodatkowo istnieją również narzędzia pozwalające na zwirtualizowanie dowolnego serwera fizycznego i dalej procedura jest równie prosta. W ten sposób otrzymujemy identyczną kopię naszego serwera w chmurze.

Czy to trudne? Absolutnie nie. Czy warto? Oczywiście, że tak. Pomimo faktu, że klient nie wprowadził żadnych zmian w konfiguracji swoich usług, to z automatu korzysta z głównych korzyści, jakie przynosi chmura: płatność za realne zużycie, możliwość skalowania serwera/serwerów (procesory, pamięć RAM), zmiana prędkości dysków itp.

Klient zyskuje jeszcze coś, co ciężko przełożyć na finanse, ale jest niesłychanie ważne, a mianowicie spokój o całą warstwę fizyczną swojego środowiska. Od tego momentu nie martwimy się już, czy nasz sprzęt się psuje czy nie, czy macierze są wydajne, czy mamy wystarczający zapas mocy, przestrzeni. Wszystkie te troski znikają. Dzięki temu zyskujemy czas pozwalający na koncentracje w innych obszarach naszego biznesu, a wszystko to bez dużego nakładu czasu i dużego stopnia skomplikowania samego procesu migracji.

Lift-tinker-and-shift

Lift-tinker-and-shift to sposób migracji, który w realizacji nie jest trudny, ale wymaga pewnego zaangażowania ze strony klienta. Często polecam go firmom, które poza samym przeniesieniem usług do chmury starają się zadbać o lepszą wydajność swoich aplikacji, szukają optymalizacji kosztowej czy też oczekują większej odporności na sytuacje wcześniej nieprzewidziane.

Migrując usługi z wyborem właśnie tego typu sięgamy po możliwie łatwe do zaimplementowania mechanizmy, jakie daje nam chmura. Najczęściej spotykane optymalizacje jakie wykonujemy w ramach takich migracji to wykorzystanie usług storage’u obiektowego do treści statycznych czy przeniesienia usług baz danych z własnych serwerów do usług chmurowych. Często rozdzielamy też role poszczególnych serwerów na mniejsze części, co pozwala na dalsze optymalizacje infrastruktury.

Re-architect

Kiedy próbuję przybliżyć ten typ migracji, to sięgam po słowo transformacja. W ramach takiej migracji dokonujemy transformacji i zmieniamy podejście do procesów związanych nawet z samym wytwarzaniem aplikacji, a już na pewno z “dostarczaniem” jej do chmury. Nakład pracy jest w tym przypadku największy,ale proporcjonalnie do korzyści.

Po przeprowadzeniu takich migracji klient zdecydowanie najwięcej dostaje w zamian, zarówno pod względem finansowym jak również technologicznym. Migracja tego typu to również poszerzenie kompetencji pracowników, „wlanie w nich nowego paliwa’ i spokojny sen każdego dnia.

Pozostałe trzy typy

Pozostałe trzy typy migracji związane są ze zmianą np. dotychczas używanego oprogramowania na rzecz gotowego rozwiązania innego producenta, który udostępnia je w modelu SaaS (Software-as-a-Service) czy też wysłaniem dawno niewykorzystywanego produktu na tzw. emeryturę. Czasem, i to jest właśnie ostatni z typów migracji, okazuje się, że niestety ale obecnie posiadane oprogramowanie nie może zostać zmigrowane do chmury np. ze względu na ograniczenia licencyjne jakie narzuca producent. To również korzyści z migracji do chmury, gdyż koniec końców robimy to wszystko z kilku powodów: by oszczędzić, by nie martwić się o sprzęt, by móc obsłużyć stale rosnąca liczbę użytkowników, by spać spokojnie.

Stała optymalizacja

Wracając do wymienionej wcześniej mojej pierwszej migracji, minęło od niej już sześć lat, ale czy prace nad migrowanym wtedy środowiskiem się zakończyły? Nie, to środowisko „żyje”. Jednak obecnie nie ma nic wspólnego z tym, jak wyglądało kilka lat wstecz. Jest ono środowiskiem wieloserwerowym, podzielonym na projekty obsługujące łącznie kilkanaście milionów użytkowników miesięcznie.

Z dumą mogę stwierdzić, że nasz zespół i migracja do chmury pomogła klientowi rozwinąć skrzydła. Migracja i jej trudność w realizacji bywa różna. Jednak ze swojej strony, jesteśmy gotowi do jej skutecznego wykonania, w ramach kompetencji zespołów Oktawave Cloud Masters i Premium Support.