Badania pokazują, że stworzenie strategii migracji to w opinii dyrektorów IT największe wyzwanie w drodze do chmury. Migracja przedsiębiorstwa, które posiada zasoby on-premise, to temat wymagający głębszego zastanowienia. To ambitny projekt, do którego trzeba podejść w sposób usystematyzowany. Dlatego na początku wypada określić motywy i cele - co chcemy osiągnąć dzięki chmurze? Dobrą okazją i katalizatorem migracji mogą być zmiany organizacyjne firmy - gdy zmieni się właściciel, dojdzie do fuzji dwóch firm, pojawi się potrzeba integracji albo stworzenia nowego data center. Dobrze, gdy zdefiniowane cele dają się skwantyfikować - to pierwszy krok do tego, by powstał business case dla migracji do chmury.
Jeśli będziemy w stanie porównać oczekiwane korzyści z nakładami, jakie musimy ponieść, i te pierwsze przeważają, warto zabrać się do pracy. Powinniśmy zdawać sobie jednak sprawę, że wyliczenia zysków nie będą proste i oczywiste (zwłaszcza w początkowych fazach projektu). W jakiejś mierze będziemy musieli zdać się na nasze przeczucia związane z wyznaczonym celem i mieć świadomość tego, że koszty chmury wcale nie muszą być niższe od lokalnie uruchomionej infrastruktury. Z drugiej strony pamiętajmy, że cloud oferuje wiele niewymiernych korzyści, jak brak angażowania kapitału własnego, wysoka skalowalność i dostęp do zasobów na żądanie, krótszy time-to-market czy wyższy poziom bezpieczeństwa. Wreszcie z trzeciej strony, nie można zapomnieć o ryzykach związanych z przejściem do chmury wynikających chociażby z ograniczeń prawnych, konieczności wprowadzenia zmian organizacyjnych czy związania się na dobre i na złe z określonym dostawcą (vendor lock-in).
To, jak przygotujemy się do migracji na starcie, będzie mieć ogromne znaczenie dla finalnego efektu. Powinniśmy zdać sobie sprawę, że droga do chmury najczęściej nie będzie ani szybka, ani prosta i składa się na nią klika etapów. Na wszystkich etapach musimy dobrze odrobić nasze lekcje. Jak tłumaczył uczestnikom warsztatów Paweł Pętlicki z Atende, przeprowadzając migracje w różnych organizacjach jego firma wyróżnia cztery fazy.
Pierwszą jest eksperyment - na początku warto po prostu przetestować chmurę i zrobić PoC. Dobrze na początek wybrać aplikacje, które nie mają krytycznego znaczenia dla działania organizacji. Aplikacje webowe, archiwa cyfrowe czy testowe środowiska developerskie to potencjalnie najlepsi kandydaci. Przez kilka tygodni albo miesięcy możemy sprawdzać, czym chmura jest w rzeczywistości.
Gdy okaże się, że to dobry kierunek, można zacząć budować fundamenty, określić jak przeprowadzić migrację i kto się powinien tym zająć. Fundamenty to przede wszystkim ludzie, osoby o różnych specjalizacjach - od developmentu, systemów, bezpieczeństwa, sieci – ci wszyscy, którzy stworzą zespół osób zaangażowanych we wszystkie tematy cloudowe. Tak tworzymy nasze pierwsze Cloud Center of Excellence. Na tym etapie ważne będzie gromadzenie wiedzy i kompetencji chmurowych oraz stworzenie konfiguracji bazowych - dzięki nim nie będziemy musieli wszystkiego zaczynać od początku, gdy coś pójdzie nie tak. Konfiguracje będą dotyczyć takich kwestii, jak: zarządzanie tożsamością, topologia sieci i łączność, organizacja zasobów, governance, bezpieczeństwo czy zarządzanie kosztami. W przypadku firm, które mają już swoje zasoby IT i po migracji one nie znikną, szczególnie ważne będą dwie pierwsze, umożliwiające zachowanie płynnego działania, ale już w modelu hybrydowym.
Dopiero po tym następuje migracja, która składa się z kilku podetapów, takich jak inwentaryzacja i analiza środowiska do zmigrowania, przygotowanie strategii migracji dla konkretnych aplikacji i sama migracja. Zadanie na tym etapie ułatwiają gotowe narzędzia, ale ostatecznie migracja będzie tak dobra, jak dobra będzie przygotowana dla niej strategia. To w tej fazie ważny jest wybór określonego dostawcy chmury. Wcześniej konkretna technologia nie miała większego znaczenia.
Tomasz Płoński z Omnilogy zwrócił uwagę, że zasadniczo strategię migracji możemy sprowadzić do wyboru swojego „R" spośród 7 dostępnych sposobów postępowania. Relocate i Rehost to przeniesienie infrastruktury lokalnej do chmurowego DC; Repurchase - zmiana aplikacji on-premise na jej wersję chmurową lub jej odpowiednik; Replatform to przeniesienie aplikacji do zarządzanych usług chmury; Refactor - takie przepisanie aplikacji, by można ją było uruchomić w chmurze (często ze zmianą architektury na cloud-native); wreszcie Retain i Retire oznaczają brak migracji aplikacji - pozostawienie jej on-premise albo wygaszenie.
Dochodzimy w końcu do ostatniej fazy - zarządzania i obsługi stworzonego środowiska, w której będziemy je optymalizować i dbać o nie. Tak jak o każde inne środowisko IT - różnić się mogą tylko metody i narzędzia. O tym, jak ważne jest tutaj posiadanie właściwego narzędzia, mówił Michał Naleziński z Dynatrace. By zachować kontrolę nad zmigrowaną aplikacją, niezbędny staje się system, który zagwarantuje jej prawidłowe działanie, jednocześnie zapewniając optymalne zarządzanie wydajnością.
Po przejściu wszystkich etapów trudno jednak uznać migrację za proces, który można w którymś momencie zakończyć. Zawsze pojawiają się nowe zasoby do migracji, nowe projekty, nowe sposoby działania. Tak mniej więcej wygląda proces migracji do chmury, ale dla każdego CIO liczy się praktyka. Na drugim wirtualnym spotkaniu z cyklu CLOUD SIG nie zabrakło szczegółowo omówionych przez Jarosława Zielińskiego przykładów wdrożeń oraz prezentacji „use case'ów", a także analizy i porównania kosztów.