Kiedy warto migrować do chmury i jak nie wpakować się na minę? 

Od dłuższego czasu słyszymy, że migracja do chmury może przynieść oszczędności od dziesiątek tysięcy do nawet milionów dolarów, w zależności od skali projektu. Dostawcy usług w chmurze konkurują ze sobą, wprowadzając nowe usługi, które w coraz większym stopniu automatyzują proces migracji, pomagając tym samym obniżyć jego koszty. Ale czy zawsze warto migrować system do chmury? Czy w każdym przypadku jest to opłacalne? Kiedy lepiej zdecydować się na rozwiązanie hybrydowe, a kiedy w ogóle unikać chmury? Do czego odnosi się tytułowa "pułapka", w którą łatwo wpaść i jak się przed nią ustrzec?

Nie będzie to przewodnik w stylu "kiedy to się stanie..., musisz zrobić...". Niestety, to nie działa w ten sposób, ponieważ systemy są budowane przy użyciu różnych technologii, mają unikalne architektury i napotykają różne wymagania. Stworzenie uniwersalnego przewodnika dla wszystkich jest po prostu niemożliwe. Jednak w tym artykule podkreślę, co należy wziąć pod uwagę podczas migracja do chmury i kiedy warto zbadać alternatywy dla pełnej migracji, takie jak rozwiązania chmury hybrydowej.

Dlaczego potrzebujemy chmury? 

W zależności od tego, na jakim poziomie rozwoju znajduje się Twoja firma, a więc i Twój system, chmura może oferować Ci różne korzyści. Celowo używam słowa „oferować”, a nie „dawać”, ponieważ możliwości te muszą zostać odpowiednio wykorzystane, najlepiej w sposób optymalny.

Rozwiązania AI 

Obecnie trudno sobie wyobrazić rozwój bez użycia modeli AI, które w coraz lepszy sposób potrafią automatyzować wiele sfer działalności przedsiębiorstwa. Chmury publiczne dostarczają wiele rozwiązań z zakresu sztucznej inteligencji oraz uczenia maszynowego. Oferują także mechanizmy ułatwiające zarządzaniem cyklem życia modelu, tzw. MLOps.

Uruchomienie modeli w środowisku on-prem jest możliwe, ale wymaga bardzo dużych nakładów finansowych z uwagi na konieczności użycia kart graficznych.

Skalowalność 

Jest to jedna z głównych korzyści chmur publicznych, ponieważ z naszego punktu widzenia mamy możliwość korzystania z niemal nieograniczonych zasobów, które możemy dynamicznie dostosowywać zgodnie z naszymi aktualnymi potrzebami. W efekcie koszty operacyjne systemu są niższe, ponieważ nie ma potrzeby dokonywania zakupu sprzętu z wyprzedzeniem. 

Skalowalność okazuje się bardzo przydatna m.in. w poniższych przypadkach: 

• sezonowość, 
• szybkie wejście na rynek z nowym produktem/usługą, 
• optymalizacja kosztów poprzez skalowanie w dół.

Oszczędność 

Oprócz oszczędności wynikających z możliwości skalowania zgodnie z potrzebami można zyskać również oszczędności związane z licencjami na oprogramowanie, takimi jak licencje na bazy danych, platformy dla kontenerów, zapory sieciowe (ang. firewall) i inne. 

Podczas migracji do chmury, w przypadku relacyjnych baz danych, można zdecydować się na PostgreSQL. Nie jest to jednak typowa baza danych open-source, a implementacja dostawcy chmury oparta na specyfikacji open-source. Podobnie sytuacja ma się z platformami uruchomieniowymi kontenerów - w chmurach publicznych można zdecydować się na usługę Kubernetes, przy czym dostawca chmury zajmuje się całą płaszczyzną kontrolną i zarządzaniem workerami.

Zapewnienie ciągłości działania 

W zależności od rodzaju prowadzonego biznesu, awarie systemów informatycznych mogą prowadzić do mniejszych lub większych strat w kontekście skali utraconych korzyści. 

Zapewnienie wysokiej dostępności w środowisku on-prem jest kosztowne, ponieważ wiąże się z koniecznością dublowania sprzętu, systemów chłodzenia, zabezpieczeń energetycznych itp. W większych firmach koszty serwerowni mogą być rozłożone na wiele departamentów, jednak dla mniejszych firm budowanie takiego rozwiązania od podstaw jest bardzo drogie. 

W przypadku chmur publicznych wysoka dostępność jest niejako wbudowana w infrastrukturę oraz platformę chmurową.

Globalna ekspozycja 

Dostawcy chmur posiadają wiele centrów danych i jeszcze większą liczbę PoP (ang. Points of Presence). Uruchamiając system w chmurze, możemy wybrać, w jakim regionie będzie on fizycznie uruchomiony. Możemy uruchomić system regionalnie lub globalnie. Wybór rozwiązania wpływa na opóźnienia w dostarczaniu danych do klienta końcowego. 

W tym rozdziale celowo pominąłem aspekty bezpieczeństwa i zgodności z regulacjami, ponieważ powinny one być postrzegane bardziej jako obowiązek spełnienia wymagań nałożonych przez regulatorów na danym rynku lub w regionie, niż jako realne korzyści, które za sobą niosą.

Czym jest tytułowa mina i jak ją ominąć? 

Zanim napiszę o najlepszych powodach migracji do chmury i kiedy może się to opłacić, muszę najpierw nawiązać do tytułowej „miny” i wyjaśnić, co przez to rozumiem. 

Czytając poprzedni rozdział, można odnieść wrażenie, że chmura publiczna jest wręcz idealna i migracja systemu do chmury ma wyłącznie same zalety. Napisałem jednak na początku, że chmura publiczna oferuje różne korzyści, z których trzeba umieć skorzystać. 

Przez "pułapkę" rozumiem sytuację, w której nasze oczekiwania lub założenia odbiegają od rzeczywistości. Dzieje się tak, gdy migracja do chmury nie przynosi oczekiwanych rezultatów, a dostosowanie systemu do chmury okazuje się droższe niż przewidywano. 

Rozpoczynając migrację do chmury, musimy utworzyć tzw. „Landing Zone”. Obejmuje to przygotowanie zarysu przyszłej struktury organizacyjnej w chmurze – oddziałów/projektów, zdefiniowanie grup użytkowników, przypisanie im odpowiednich uprawnień oraz skonfigurowanie polityk automatyzujących i ograniczających, a także wiele innych elementów. Kiedy to zrobimy, szczególnie w przypadku dużych i złożonych organizacji, możemy odnieść wrażenie, że najgorsze za nami. Natomiast prawda jest inna – najwięcej pracy dopiero nas czeka.

Migracja do chmury - jasny cel biznesowy 

Ustalenie celów biznesowych, które chcemy osiągnąć dzięki migracji do chmury, jest podstawowym krokiem, który należy podjąć na samym początku. Te jasno zdefiniowane cele określą strategię i kierunek całego procesu migracji. 

Dla przykładu, jeśli celem biznesowym jest ekspansja na Amerykę Południową, to w pierwszej kolejności będą realizowane te prace, które spowodują, że system będzie dostępny na zakładanym kontynencie. Poprawa innych parametrów, takich jak wydajność, skalowalność czy optymalizacja kosztowa, będzie mniej priorytetowa. 

Inny przykład: jeśli celem biznesowym będzie obniżenie kosztów utrzymania o 20% w skali roku, zaczniemy od identyfikacji systemów generujących najwyższe koszty utrzymania, a następnie przeanalizujemy, co te koszty powoduje. Być może rozwiązaniem będzie lepsze wykorzystanie zasobów sprzętowych, poprawa procesów wytwarzania oprogramowania lub nawet zmiana architektury systemu z użyciem natywnych komponentów chmurowych. 

Migracja do chmury bez jasno określonych, mierzalnych celów biznesowych uniemożliwia ocenę, czy projekt zakończył się sukcesem, czy porażką.. W trakcie realizacji projektu nie będzie możliwości weryfikacji założeń i oceny, czy prace przebiegają zgodnie z planem. 

Kolejnym aspektem jest upewnienie się, że zarówno inwestor, jak i wykonawca tak samo rozumieją zdefiniowane cele biznesowe. Pomocne w tym jest określenie miar sukcesu.

Mierzalność realizacji 

Aby ocena realizacji celów biznesowych była obiektywna, muszą być zdefiniowane metryki, na podstawie których w sposób wymierny będzie można określić efekt realizacji. 

W przypadku optymalizacji kosztowej metryką może być wysokość miesięcznej faktury za działanie systemu w chmurze. Z kolei dla wydajności kluczową miarą będzie na przykład maksymalne możliwe do obsłużenia natężenie ruchu.

Plan migracji do chmury

Mając zdefiniowany cel biznesowy oraz metryki, za pomocą których będzie można stwierdzić, czy cel biznesowy został osiągnięty, pora na plan migracji.

To jest zdecydowanie najtrudniejsze zadanie i bardzo często taki plan nie powstaje lub jest bardzo powierzchowny. Aby powstał plan migracji, musi być wcześniej przeprowadzona analiza, która da odpowiedzi na pytania:

• Które systemy będą migrowane i w jakiej kolejności?
• Jaki wpływ na prowadzony biznes będzie miała migracja?
• Jak będzie wyglądał sam proces tranzycji?
• Którą strategię migracji wybrać?
• Czy zostaną użyte usługi natywne w chmurze?
• Jak będzie wyglądał proces SDLC (ang. Software Development Lifecycle)?
• Czy obecna architektura systemu nadaje się do efektywnego działania w chmurze, czy może wymaga refaktoryzacji lub zmiany architektury?
• Jakie będą koszty zmian architektonicznych?
• Jakie będą całkowite koszty migracji?
• Jakie będą prognozowane koszty działania systemu w chmurze?
• Czy moja organizacja posiada potrzebne kompetencji do przeprowadzenia migracji, a później do utrzymania systemu w chmurze?
• Czy istnieją jakieś prawne/regulacyjne ograniczenia do migracji danego systemu do chmury?

Brak precyzyjnego plan migracji prawdopodobnie wskazuje na brak analizy i zdefiniowanej architektury dla docelowego rozwiązania.

Kiedy warto migrować do chmury? 

Znając już możliwości, jakie daje chmura, oraz ryzyka i zagrożenia, możemy przejść do sedna tego artykułu, odpowiadając na postawione w tytule pytanie: kiedy warto skorzystać z możliwości chmury. 

Podzielę ten wątek na dwie części i omówię, jakie kryteria należy brać pod uwagę przy migracji całego systemu do chmury, a także w sytuacji, gdy taka opcja nie jest dostępna, przedstawię inne sposoby wykorzystania chmury.

Przeniesienie całego systemu 

Istnieje wiele strategii migracji systemu do chmury, lecz wszystkie można sprowadzić do trzech kluczowych podejść: 

• lift & shift, 
• replatform, 
• rearchitektura. 

Koszt migracji i działania na chmurze są uzależnione od obecnej architektury systemu oraz wybranej strategii migracyjnej.

Najtańszą strategią będzie lift & shift, ponieważ dosłownie system zostanie w takim stanie, w jakim jest obecnie uruchomiony w chmurze. Z drugiej strony najdroższą opcją będzie zmiana architektury systemu, ponieważ będzie wiązało się to z przepisaniem prawdopodobnie wielu jego funkcjonalności. 

Wydawać by się mogło, że w takim razie najlepszą opcją jest wykonanie lift & shift, ale nie jest to takie proste, biorąc pod uwagę koszty działania w chmurze. Tutaj sytuacja wygląda następująco:

Jak widać na powyższym rysunku, najtańszy w utrzymaniu jest system bazujący na architekturze cloud native. Wynika to między innymi z następujących faktów:

• Architektura cloud native składa się bardzo często z wielu małych serwisów (mikroserwisów), dzięki czemu łatwiej jest efektywniej dobrać wielkość potrzebnych zasobów. Dodatkowo, w przypadku potrzeby skalowania w górę, dotyczy to mniejszej liczby serwisów niż w systemach monolitycznych. Tym sposobem zasoby są efektywniej wykorzystywane.
• Im bliżej architektury cloud native, tym większa odpowiedzialność za szeroko pojętą infrastrukturę przechodzi na stronę dostawcy chmury.
• Zarządzanie cyklem życia systemu o architekturze cloud native oraz cały proces CI/CD są tańsze w utrzymaniu niż w przypadku systemów monolitycznych.

Ogólnie rzecz biorąc, przy podejmowaniu decyzji o migracji ważne jest, aby rozważyć, jaki poziom usług w chmurze będziemy w stanie wykorzystać. Jak pokazano na powyższej ilustracji, im dalej w prawo, tym potencjalnie większe oszczędności i elastyczność. 

Kiedy pełna migracja systemu do chmury jest opłacalna? 

1. Dla nowych systemów, które powstają w technologii cloud native. Koszt ich przeniesienia jest niski, a korzyści liczne. 

2. Dla rozwiązań, których przyjęcie się na rynku nie jest pewne. Brak konieczności inwestycji w sprzęt. 

3. Dla starych systemów, dla których istnieje i jest realizowany plan modernizacji stosu technologicznego, tak aby wykorzystać usługi PaaS/SaaS.

Migracja częściowa – chmura hybrydowa (ang. hybrid cloud) 

Migracja do chmury nie musi oznaczać konieczności przenoszenia całego systemu, co czasami może być bardzo kosztowne. Dobrym rozwiązaniem jest wyodrębnienie pojedynczych potrzeb, które mogą zostać zaspokojone z wykorzystaniem usług chmurowych.

Archiwizacja danych i przechowywanie kopii zapasowych 

Przechowywanie danych w chmurze może być bardzo ekonomicznym rozwiązaniem. Dodatkowo, nie wymaga ciągłego planowania rozbudowy naszej infrastruktury. 

Odpowiednim rozwiązaniem do tych zastosowań jest magazyn obiektowy, który jest teoretycznie nieskończenie skalowalny. Ponadto, posiada kilka warstw, różniących się pod względem kosztów przechowywania danych oraz kosztów dostępu do nich. W przypadku archiwizacji danych, idealnym rozwiązaniem jest użycie poziomu archiwalnego, którego koszt składowania jest najniższy, a potrzeba dostępu do danych bardzo rzadka.

Planu przywrócenia gotowości (ang. disaster recovery) 

Chmura publiczna może być dobrym wyborem jako zabezpieczenie na wypadek katastrofy. W razie jej wystąpienia, w chmurze mogą zostać tymczasowo uruchomione wszystkie lub najbardziej kluczowe usługi danego systemu. 

Choć przygotowanie instalacji w chmurze wymaga oczywiście inwestycji i przeprowadzenia testowego uruchomienia systemu, koszty jej utrzymania ograniczają się głównie do opłat związanych z synchronizacją danych i obsługą niewielkiej liczby serwisów. 

Rozszerzenie możliwości DC w ramach sezonowości i nieprzewidzianego zwiększenia natężenia ruchu 

Chmura jest dobrym rozwiązaniem, aby rozszerzyć możliwości centrum danych i zabezpieczyć się przed sezonowym wzrostem ruchu lub wynikającym z planowanych kampanii marketingowych. Do tego celu można użyć bardzo tanich maszyn wirtualnych typu spot (ang. Spot Virtual Machines). Ich zaletą jest znacznie niższa cena, nawet o ponad 80%. Niestety, istnieje ryzyko, że dostawca chmury może je odebrać w dowolnym momencie, gdyż są one częścią jego zapasu.

Potrzebujesz wsparcia we wdrożeniu i zrealizowaniu strategii migracji do chmury?

Marcin Korda Cloud Architect

Doświadczony architekt rozwiązań chmurowych, specjalizujący się w prowadzeniu migracji z architektury monolitycznej na cloud-native, ulepszaniu procesów projektowania i wytwarzania oprogramowania, tworzeniu kluczowych komponentów systemu oraz weryfikacji koncepcji w celu oceny produktu.