Migracja aplikacji do chmury - z głową!

Motywacja

Pierwszą, a zarazem podstawową kwestią, która wpłynie na dostępne dla nas opcje migracji jest precyzyjne określenie powodu, dla którego rozważamy krok w chmury. Czy zależy nam po prostu na szybkim rozwiązaniu palącego problemu biznesowego? Jeśli tak, może najlepszym rozwiązaniem będzie przyjrzenie się gotowym aplikacjom oferowanym w modelu abonamentowym (SaaS)? Ten coraz powszechniejszy model licencjonowania pozwala nie tylko istotnie zredukować czas i koszty wdrożenia, ale również zapewnić sobie odpowiednie warunki obsługi, zgodnie ze świadczonym przez dostawcę SLA. Jako subskrypcję nabyć możemy w tej chwili już nie tylko podstawowe oprogramowanie biurowe, ale także systemy CRM, ERP czy dedykowane rozwiązania branżowe.

Innym popularnym powodem rozważania migracji do chmury jest chęć zwiększenia niezawodności, dostępności lub skalowalności istniejących systemów. Ma to szczególne znaczenie dziś, kiedy okazało się, że wiele z istniejących środowisk jest nieprzygotowane do nowych wzorców użytkowania np. znacznie zwiększonej liczby pracowników zdalnych, wymagających interakcji z systemem centralnym.

Kolejnym argumentem za migracją może być redukcja kosztów ponoszonych na infrastrukturę sprzętową i oprogramowanie. Dobrze wykorzystana chmura może przyczynić się do redukcji wydatków. Należy mieć jednak świadomość specyfiki cenników usług chmurowych, które dla wielu początkujących użytkowników mogą okazać się istotną barierą wejścia.

Planowanie

Niezależnie od wskazanych powodów, migracja każdego ze środowisk powinna zostać starannie zaplanowana. Oto trzy pytania, które pozwolą nam ocenić ryzyko i prawdopodobieństwo sukcesu oraz wybrać najbardziej adekwatne podejście:

• Czy nasza aplikacja została już, lub da się ją łatwo zwirtualizować? Infrastruktura liczących się dostawców chmury publicznej oparta jest, w znacznej mierze, o wystandaryzowane środowiska wirtualne. Jeśli więc aktualnie korzystamy z jednego z popularnych wirtualizatorów (np. VMWare, Hyper-V, KVM) przesiadka do chmury powinna być stosunkowo bezproblemowa. Jeśli natomiast jesteśmy w tej chwili uzależnieni od konkretnej platformy sprzętowej, należy spodziewać się większych nakładów związanych z refaktoryzacją architektury.
• Czy wykorzystujemy w naszej aplikacji komercyjne oprogramowanie i - jeśli tak - czy posiadana przez nas licencja pozwala na bezproblemowe wykorzystanie u zewnętrznego dostawcy? Może się okazać, że poczynione do tej pory zakupy oprogramowania stanowić będą istotną przeszkodę w adopcji chmury. Część z producentów oprogramowania wciąż jeszcze nie pozwala na łatwe wykorzystanie nabytych licencji w środowiskach innych niż on-premise.
• Czy wiążą nas jakieś ograniczenia regulacyjne? Może dotyczyć to zarówno wewnętrznych polityk firmowych, jak i oficjalnych norm i praw (np. prawa bankowego). Im bardziej wrażliwe dane w naszej aplikacji, z tym większą uwagą powinniśmy podchodzić do zawartych w kontrakcie warunków świadczonych usług chmurowych.

Wybór podejścia

Choć ścieżek migracji do chmury jest wiele, można wyróżnić dwa główne podejścia:

• Lift & shift - jak najwierniejsze odzwierciedlenie już istniejącej infrastruktury sprzętowo-sieciowej. Ten typ migracji zwykle skupia się na wykorzystaniu usług typu IaaS, takich jak prekonfigurowane maszyny wirtualne wraz z podłączonymi do nich zasobami dyskowymi. Jego popularność wynika ze stosunkowo niskiej bariery wejścia oraz wyjścia z chmury. Zarówno dostawcy chmury jak i niezależni partnerzy oferują w tym zakresie gotowe narzędzia, które pozwalają na przeprowadzenie inwentaryzacji obecnych środowisk, zaplanowanie najbardziej optymalnych zasobów chmurowych oraz automatyzację samego procesu migracji.
• Cloud native - jeśli celem migracji do chmury jest zwiększenie elastyczności naszego zespołu programistycznego, istotne są dla nas kwestie skalowalności lub zoptymalizowania wydatków, alternatywą do klonowania maszyn wirtualnych jest modernizacja architektury obecnych środowisk. Nakład pracy z tym związany w dużej mierze zależy od obecnie stosowanych praktyk i technologii. Jeśli nasza architektura opiera się w tej chwili o mikroserwisy i kontenery, przesiadka do chmury może ograniczyć się jedynie do ponownego wdrożenia systemu na zarządzanym przez zewnętrznego dostawcę klastrze Kubernetes.

Niezależnie od wybranej ścieżki, powinniśmy zawsze upewnić się, że zachowane zostaną niezbędne standardy bezpieczeństwa. Dotyczy to choćby takich aspektów jak zagwarantowanie odpowiedniej jakości połączeń pomiędzy własną infrastrukturą, a chmurą (tunele VPN, dedykowane łącza), czy adekwatne mechanizmy szyfrowania danych.

Oczywiście przy okazji takiej przesiadki warto wykorzystać okazję, aby przyjrzeć się bliżej dostępnym w chmurze usługom zarządzalnym (np. silnikom baz danych, narzędziom analitycznym itp.). Może okazać się, że wymiana części z wykorzystywanych do tej pory komponentów na serwisy klasy PaaS (Platform-as-a-Service) zaoferuje nam poprawę wygody pracy, lepszą wydajność, skalowalność i dostępność.