{"id":338,"date":"2019-09-09T09:56:00","date_gmt":"2019-09-09T09:56:00","guid":{"rendered":"https:\/\/oktawave.com\/blog\/?p=338"},"modified":"2022-11-14T14:56:23","modified_gmt":"2022-11-14T14:56:23","slug":"szesc-typow-migracji-a-spokojny-sen","status":"publish","type":"post","link":"https:\/\/oktawave.com\/pl\/blog\/uslugi\/szesc-typow-migracji-a-spokojny-sen\/","title":{"rendered":"Sze\u015b\u0107 typ\u00f3w migracji a spokojny sen"},"content":{"rendered":"\n

Sze\u015b\u0107 lat min\u0119\u0142o odk\u0105d zacz\u0119li\u015bmy migrowa\u0107 klient\u00f3w do chmury obliczeniowej. Sze\u015b\u0107 typ\u00f3w migracji najcz\u0119\u015bciej wymieniam w codziennych rozmowach z klientami. Sze\u015b\u0107 etap\u00f3w mo\u017cna wy\u0142oni\u0107 w wi\u0119kszo\u015bci proces\u00f3w migracyjnych. Trzy sz\u00f3stki, kt\u00f3re kojarz\u0105 si\u0119 jednoznacznie, sk\u0142oni\u0142y mnie do refleksji. Zastanawiam si\u0119, czy migracja do chmury jest bardziej jak dzie\u0142o si\u0142 nieczystych, czy spokojna przeja\u017cd\u017cka na rowerze wzd\u0142u\u017c najpi\u0119kniejszych pla\u017c Miami?<\/strong><\/p>\n\n\n\n\n\n\n\n

DOBRY POCZ\u0104TEK<\/h2>\n\n\n\n

\u015awiadomo\u015b\u0107 mo\u017cliwo\u015bci chmury obliczeniowej przez ostatnie lata diametralnie si\u0119 zmieni\u0142a, a co za tym idzie, zmieni\u0142y si\u0119 r\u00f3wnie\u017c metody migracji jak i ich przedmiot. Mimo up\u0142ywu lat, cz\u0119sto z \u0142ezk\u0105 w oku wracam do naszej pierwszej migracji.<\/p>\n\n\n\n

Patrz\u0105c z perspektywy czasu zmigrowanie bloga do chmury (a od tego w\u0142a\u015bnie zacz\u0105\u0142em) nie by\u0142o \u017cadnym \u201erocket science\u201d. Ale sprawa si\u0119 skomplikowa\u0142a, gdy od klienta otrzymali\u015bmy jedynie dost\u0119p FTP do \u00f3wczesnego hostingu. Blog istnia\u0142 na rynku ju\u017c kilka lat, posiada\u0142 spor\u0105 baz\u0119 danych, mia\u0142 opublikowanych wiele artyku\u0142\u00f3w, a co za tym idzie ton\u0119 zdj\u0119\u0107. My mieli\u015bmy jedynie dost\u0119p do hostingu via FTP, gdzie notorycznie zrywane by\u0142o po\u0142\u0105czenie, wyst\u0119powa\u0142y ograniczenia transferu, a przez to zachowanie ci\u0105g\u0142o\u015bci dzia\u0142ania us\u0142ugi w czasie migracji sta\u0142o pod wielkim znakiem zapytania.<\/p>\n\n\n\n

Czy si\u0119 uda\u0142o? Jasne, \u017ce tak. Czy by\u0142o \u0142atwo? Dzi\u015b powiedzia\u0142bym „piece of cake”, ale chc\u0105c by\u0107 zupe\u0142nie szczerym, wtedy nie by\u0142o to takie oczywiste, gdy o 4 rano gdy byli\u015bmy w po\u0142owie drogi z przeniesieniem danych. Finalnie, migracj\u0119 wykonali\u015bmy, przerwy w dzia\u0142aniu us\u0142ugi nie by\u0142o, ale media do artyku\u0142\u00f3w archiwalnych \u201czaci\u0105gane\u201d by\u0142y jeszcze przez kilka kolejnych godzin.<\/p>\n\n\n\n

Niezale\u017cnie od tego, co my jako zesp\u00f3\u0142 migracyjny tamtej nocy czuli\u015bmy, nasz klient spa\u0142 spokojnie. Nie, to nie jest chwyt marketingowy. Tak by\u0142o. Rol\u0105 klienta w tej migracji by\u0142o udost\u0119pnienie nam konta FTP (jak to dobrze, \u017ce mogli\u015bmy wykorzysta\u0107 php-shella, gdy\u017c serwer nie by\u0142 odpowiednio dobrze zabezpieczony). A nast\u0119pnie, w godzinach porannych, zweryfikowanie poprawno\u015bci dodawania wpis\u00f3w i redagowania artyku\u0142\u00f3w. Czy tak jest zawsze? Oczywi\u015bcie, \u017ce nie! W zale\u017cno\u015bci od z\u0142o\u017cono\u015bci projektu zaanga\u017cowanie po stronie klienta jest r\u00f3\u017cne. Najwa\u017cniejsza staje si\u0119 wsp\u00f3\u0142praca, komunikacja i jasno zdefiniowany plan migracji.<\/p>\n\n\n\n

TYPY MIGRACJI DO CHMURY<\/h2>\n\n\n\n

We wst\u0119pie wspomnia\u0142em o sze\u015bciu typach migracji, kt\u00f3re powoli stawa\u0142y si\u0119 standardem na rynku us\u0142ug. Ze wzgl\u0119du na dany typ migracji i skal\u0119 zaanga\u017cowania, przebieg procesu przej\u015bcia do chmury jest r\u00f3\u017cny. Skupi\u0119 si\u0119 wi\u0119c na trzech najcz\u0119\u015bciej spotykanych typach migracji.<\/p>\n\n\n\n

LIFT AND SHIFT<\/h3>\n\n\n\n

Lift-and-shift jest typem migracji pozwalaj\u0105cym na przeniesienie us\u0142ug (serwer\u00f3w) do chmury, bez konieczno\u015bci dokonywania wi\u0119kszych zmian po stronie aplikacji. Cz\u0119sto okre\u015blamy go mianem przeniesienia 1:1.<\/p>\n\n\n\n

Z za\u0142o\u017cenia jest to najszybszy i naj\u0142atwiejszy typ migracji, w kt\u00f3rym mo\u017cemy zacz\u0105\u0107 korzysta\u0107 z dobrodziejstw chmury. Migracja, szczeg\u00f3lnie gdy klient posiada ju\u017c w\u0142asne \u015brodowisko zwirtualizowane mo\u017ce odby\u0107 si\u0119 za przys\u0142owiowym jednym klikni\u0119ciem (eksport obrazu maszyny wirtualnej do chmury, import i uruchomienie u nowego dostawcy). Dodatkowo istniej\u0105 r\u00f3wnie\u017c narz\u0119dzia pozwalaj\u0105ce na zwirtualizowanie dowolnego serwera fizycznego i dalej procedura jest r\u00f3wnie prosta. W ten spos\u00f3b otrzymujemy identyczn\u0105 kopi\u0119 naszego serwera w chmurze.<\/p>\n\n\n\n

Czy to trudne? Absolutnie nie. Czy warto? Oczywi\u015bcie, \u017ce tak. Pomimo faktu, \u017ce klient nie wprowadzi\u0142 \u017cadnych zmian w konfiguracji swoich us\u0142ug, to z automatu korzysta z g\u0142\u00f3wnych korzy\u015bci, jakie przynosi chmura: p\u0142atno\u015b\u0107 za realne zu\u017cycie, mo\u017cliwo\u015b\u0107 skalowania serwera\/serwer\u00f3w (procesory, pami\u0119\u0107 RAM), zmiana pr\u0119dko\u015bci dysk\u00f3w itp.<\/p>\n\n\n\n

Klient zyskuje jeszcze co\u015b, co ci\u0119\u017cko prze\u0142o\u017cy\u0107 na finanse, ale jest nies\u0142ychanie wa\u017cne, a mianowicie spok\u00f3j o ca\u0142\u0105 warstw\u0119 fizyczn\u0105 swojego \u015brodowiska. Od tego momentu nie martwimy si\u0119 ju\u017c, czy nasz sprz\u0119t si\u0119 psuje czy nie, czy macierze s\u0105 wydajne, czy mamy wystarczaj\u0105cy zapas mocy, przestrzeni. Wszystkie te troski znikaj\u0105. Dzi\u0119ki temu zyskujemy czas pozwalaj\u0105cy na koncentracje w innych obszarach naszego biznesu, a wszystko to bez du\u017cego nak\u0142adu czasu i du\u017cego stopnia skomplikowania samego procesu migracji.<\/p>\n\n\n\n

LIFT-TINKER-AND-SHIFT<\/h3>\n\n\n\n

Lift-tinker-and-shift to spos\u00f3b migracji, kt\u00f3ry w realizacji nie jest trudny, ale wymaga pewnego zaanga\u017cowania ze strony klienta. Cz\u0119sto polecam go firmom, kt\u00f3re poza samym przeniesieniem us\u0142ug do chmury staraj\u0105 si\u0119 zadba\u0107 o lepsz\u0105 wydajno\u015b\u0107 swoich aplikacji, szukaj\u0105 optymalizacji kosztowej czy te\u017c oczekuj\u0105 wi\u0119kszej odporno\u015bci na sytuacje wcze\u015bniej nieprzewidziane.<\/p>\n\n\n\n

Migruj\u0105c us\u0142ugi z wyborem w\u0142a\u015bnie tego typu si\u0119gamy po mo\u017cliwie \u0142atwe do zaimplementowania mechanizmy, jakie daje nam chmura. Najcz\u0119\u015bciej spotykane optymalizacje jakie wykonujemy w ramach takich migracji to wykorzystanie us\u0142ug storage\u2019u obiektowego do tre\u015bci statycznych czy przeniesienia us\u0142ug baz danych z w\u0142asnych serwer\u00f3w do us\u0142ug chmurowych. Cz\u0119sto rozdzielamy te\u017c role poszczeg\u00f3lnych serwer\u00f3w na mniejsze cz\u0119\u015bci, co pozwala na dalsze optymalizacje infrastruktury.<\/p>\n\n\n\n

RE-ARCHITECT<\/h3>\n\n\n\n

Kiedy pr\u00f3buj\u0119 przybli\u017cy\u0107 ten typ migracji, to si\u0119gam po s\u0142owo transformacja. W ramach takiej migracji dokonujemy transformacji i zmieniamy podej\u015bcie do proces\u00f3w zwi\u0105zanych nawet z samym wytwarzaniem aplikacji, a ju\u017c na pewno z \u201cdostarczaniem\u201d jej do chmury. Nak\u0142ad pracy jest w tym przypadku najwi\u0119kszy,ale proporcjonalnie do korzy\u015bci.<\/p>\n\n\n\n

Po przeprowadzeniu takich migracji klient zdecydowanie najwi\u0119cej dostaje w zamian, zar\u00f3wno pod wzgl\u0119dem finansowym jak r\u00f3wnie\u017c technologicznym. Migracja tego typu to r\u00f3wnie\u017c poszerzenie kompetencji pracownik\u00f3w, \u201ewlanie w nich nowego paliwa\u2019 i spokojny sen ka\u017cdego dnia.<\/p>\n\n\n\n

POZOSTA\u0141E TRZY TYPY<\/h2>\n\n\n\n

Pozosta\u0142e trzy typy migracji zwi\u0105zane s\u0105 ze zmian\u0105 np. dotychczas u\u017cywanego oprogramowania na rzecz gotowego rozwi\u0105zania innego producenta, kt\u00f3ry udost\u0119pnia je w modelu SaaS (Software-as-a-Service) <\/a>czy te\u017c wys\u0142aniem dawno niewykorzystywanego produktu na tzw. emerytur\u0119. Czasem, i to jest w\u0142a\u015bnie ostatni z typ\u00f3w migracji, okazuje si\u0119, \u017ce niestety ale obecnie posiadane oprogramowanie nie mo\u017ce zosta\u0107 zmigrowane do chmury np. ze wzgl\u0119du na ograniczenia licencyjne jakie narzuca producent. To r\u00f3wnie\u017c korzy\u015bci z migracji do chmury, gdy\u017c koniec ko\u0144c\u00f3w robimy to wszystko z kilku powod\u00f3w: by oszcz\u0119dzi\u0107, by nie martwi\u0107 si\u0119 o sprz\u0119t, by m\u00f3c obs\u0142u\u017cy\u0107 stale rosn\u0105ca liczb\u0119 u\u017cytkownik\u00f3w, by spa\u0107 spokojnie.<\/p>\n\n\n\n

STA\u0141A OPTYMALIZACJA<\/h2>\n\n\n\n

Wracaj\u0105c do wymienionej wcze\u015bniej mojej pierwszej migracji, min\u0119\u0142o od niej ju\u017c sze\u015b\u0107 lat, ale czy prace nad migrowanym wtedy \u015brodowiskiem si\u0119 zako\u0144czy\u0142y? Nie, to \u015brodowisko \u201e\u017cyje\u201d. Jednak obecnie nie ma nic wsp\u00f3lnego z tym, jak wygl\u0105da\u0142o kilka lat wstecz. Jest ono \u015brodowiskiem wieloserwerowym, podzielonym na projekty obs\u0142uguj\u0105ce \u0142\u0105cznie kilkana\u015bcie milion\u00f3w u\u017cytkownik\u00f3w miesi\u0119cznie.<\/p>\n\n\n\n

Z dum\u0105 mog\u0119 stwierdzi\u0107, \u017ce nasz zesp\u00f3\u0142 i migracja do chmury pomog\u0142a klientowi rozwin\u0105\u0107 skrzyd\u0142a. Migracja i jej trudno\u015b\u0107 w realizacji bywa r\u00f3\u017cna. Jednak ze swojej strony, jeste\u015bmy gotowi do jej skutecznego wykonania, w ramach kompetencji zespo\u0142\u00f3w\u00a0Oktawave Cloud Masters i Premium Support<\/a>.<\/p>\n\n\n