Jak przygotować się do wejścia w chmurę?

Tematyka migracji do chmury jest jednym z najpopularniejszych tematów nie tylko podczas wielu prezentacji czy konferencji, ale także jest jednym z najpopularniejszych zapytań klientów zainteresowanych zwiększeniem elastyczności swojej infrastruktury oraz aplikacji. Z jednej strony nie ma się co temu dziwić – w dobie olbrzymiego wzrostu zainteresowania tematyką cloud, która napędzana jest dodatkowo sytuacją pandemiczną związaną z COVID-19, wiele firm musiało przyśpieszyć swoje plany adaptacji technologii chmurowych. Z drugiej strony chmura nadal jest wyzwaniem i pomimo jej szerokiego wykorzystania wciąż stanowi niebanalne wyzwanie, szczególnie dla tych wszystkich organizacji, dla których technologia nie jest źródłem dochodu (tutaj wystarczy, że wspomnimy niedawny pożar data centre firmy OVH w Strasburgu, który zniszczył jeden z budynków, uszkodził kolejny i naraził dwa pozostałe na uszkodzenia, pozostawiając wielu klientów na przysłowiowym lodzie). Pomijając jednak wszelkie za i przeciw jeśli chodzi o chmurę, w kontekście migracji zawsze pojawia się następujące pytanie - jak powinniśmy przygotować naszą organizację do migracji i na co zwrócić uwagę, aby popełnić jak najmniej błędów?

Zrozumienie swojego biznesu

Zanim podejmiemy jakąkolwiek decyzję co do chmury, musimy zrozumieć, czego my tak naprawdę oczekujemy i co chcemy zyskać, angażując środki na proces migracji do chmury. Istotne jest tutaj nie tylko przygotowanie odpowiedniej kalkulacji kosztów, ale także spodziewanej stopy zwrotu z takiej, a nie innej inwestycji. Spójrzmy na poniższy przykład:

W kalkulacji przyjęto średnie zużycie energii przez serwer na godzinę jako 500 W oraz 10 serwerów obsługujących wszystkie maszyny wirtualne. Dodatkowo przyjęto, że chłodzenie serwerowni zużywa 10% energii wykorzystanej przez fizyczne serwery. W przypadku obsługi technicznej przyjęto model 24/7 rozłożony na trzy etaty po 8h każdy przy zatrudnieniu UoP w wysokości 13 000 PLN brutto. Jeśli nie podano, inaczej prezentowane kwoty są kwotami netto.

W powyższej tabeli uwzględniliśmy tylko i wyłącznie wydatki, które nie amortyzują się w czasie – do pełnego obrazu potrzebowalibyśmy dodatkowo bazowego kosztu serwerowni (infrastruktura fizyczna w postaci pomieszczenia / budynku, koszt przyłącza energetycznego, zabezpieczenie przeciwpożarowe, zabezpieczenia antywłamaniowe, fizyczna ochrona), jednak dla uproszczenia rachunków ten koszt zostanie na ten moment pominięty. Istotne jest jednak to, że musimy zrozumieć który koszt w momencie pełnej migracji do chmury znika i dlaczego. Dla porównania przedstawmy teraz porównywalny przykład jednak z przełożeniem na dostawcę chmurowego:

W kalkulacji przyjęto maszynę wirtualną wyposażona w 8 vCPU, 32GB RAM, która przeznaczona jest do obsługi aplikacji bez wysokich wymagań co do wydajności procesora, pamięci oraz dysku.

Powyższy przykład od razu obrazuje nam poniższe wnioski:

• Wykorzystanie technologii chmurowej bez posiadania własnej infrastruktury skutkuje wyeliminowaniem z kalkulacji miesięcznych kosztów związanych z infrastrukturą przyłączeniową.
• Wykorzystanie maszyn wirtualnych w chmurze pozostawia na nas wymóg posiadania kadry odpowiedzialnej za utrzymanie tychże maszyn.
• Koszt maszyn wirtualnych w chmurze może przekroczyć koszt lokalnej infrastruktury, która jest szczególnie kosztowna w pierwszym roku korzystania z niej.

Zauważmy tutaj jeden istotny element – powyższe kalkulacje nie będą w 100% zgodne z rzeczywistością tak długo, jak nie uzupełnimy je o brakujące elementy i nałożymy faktyczny stan zgodny z naszą organizacją:

• Koszt konserwacji lokalnej serwerowni (wymiana sprzętu, instalacja nowych maszyn, drobne awarie).
• Dokładne odzwierciedlenie wydajności lokalnych maszyn w wybranych maszynach wirtualnych (w zależności od modelu procesora, pamięci czy dysku koszt teoretycznie takiej samej maszyny wirtualnej może wzrosnąć nawet o kilkadziesiąt %).

Niezależnie jednak od powyższych założeń, przedstawione przykłady prezentują nam dość istotną tezę – w przypadku migracji do chmury, argument kosztów powinien być albo mniej istotnym elementem (pomimo tego, że często migracja do chmury pozwala na restrukturyzację i realne oszczędności), albo koszt w tym wypadku powinien być przedefiniowany i traktowany na równi z wydatkami typu prąd bądź licencje.

Dlaczego mówimy na samym początku o koszcie? Jest to związane ze zrozumieniem faktycznych potrzeb naszej firmy. Argument kosztowy w przypadku migracji rzadko kiedy jest sensownym argumentem, gdyż nie adresuje realnej potrzeby migracji, która przeprowadzana jest wszędzie tam, gdzie szukamy jednego z poniższych elementów:

• Zwiększonej elastyczności infrastruktury.
• Możliwości łatwego powiązania kosztów z konkretną aplikacją.
• Rozliczania swojego portfolio z faktycznie istniejących rozwiązań, a nie teoretycznych rozważań.
• Uniknięcia przewymiarowania infrastruktury.
• Realnej szansy na zmiany stosunku kosztów badań i rozwoju do utrzymania z zyskiem dla tego pierwszego.

Pomimo tego, że wiele z poniższych punktów zawiera słowo „koszt”, nie mówią jednak one o koszcie per se, który sprowadza się do standardowej optymalizacji kosztowej firmowych wydatków. Skupiają się one bardziej na większej granularności cyklicznych rozliczeń (co ułatwia w zarządzaniu budżetem) bądź powiązaniu realnie ponoszonego kosztu do stopnia rozwinięcia infrastruktury, co moglibyśmy zobrazować poniższym wykresem:

Jak widzimy powyżej, chmura obniża wyjściowy koszt, jaki należy ponieść w momencie przygotowywania infrastruktury nowego systemu, jest jednak daleka od zniwelowania go do zera, szczególnie jeśli nie mamy w zespołach specjalistów od tej technologii.

Z jakiego jeszcze powodu chcielibyśmy jako firma rozpocząć adaptację chmury? Jeśli pominiemy teraz aspekt kosztów oraz konieczności utrzymania własnej infrastruktury, pozostają nam jeszcze zagadnienia, którym bliżej jest do tematów biznesowo-technologicznych:

• Prostota przygotowywania środowisk testowych oraz przeznaczonych na prototypy, które są krótkożyjące (tzw. ephemeral environments).
• Prostota skalowania aplikacji wg realnego zapotrzebowania, co pozwala zaoszczędzić na przewymiarowanej infrastrukturze i adresuje problem dokładnie wtedy, kiedy tego potrzebujemy.
• Ułatwiona georeplikacja i wysoka dostępność naszej infrastruktury bez konieczności uruchamiania własnej serwerowni poza granicami kraju.
• Dostępność zaawansowanych technologii bez konieczności ich instalacji oraz konfiguracji na własnych maszynach.

Powyższe punkty przy odpowiedniej interpretacji także ostatecznie sprowadzą się do lepszego dysponowania wydatkami w naszej organizacji, zwiększając jednocześnie jej konkurencyjność oraz dynamikę. Większa dynamika to łatwiejsze dostosowywanie się do zmiennych warunków rynkowych i możliwość błyskawicznego reagowania na pojawiające się i znikające trendy. Są to dokładnie te wartości, które powinniśmy rozważać w pierwszej kolejności, jeśli chcemy uwzględnić chmurę w planie naszych inwestycji na nadchodzące lata.

Wybór dostawcy

Kolejnym punktem związanym z adaptacją cloud computingu jest dokładna analiza rynku wraz z dostawcami oraz ich ofertą. Ważne jest tutaj zbudowanie w głowie przekonania, że chmura nie kończy się na ofercie trzech największych dostawców (Amazon, Google, Microsoft) i wielu mniejszych graczy wychodzi coraz częściej z własną autorską ofertą, która w wielu aspektach może okazać się niezwykle kusząca. Niezależnie od naszych osobistych preferencji czy materiałów marketingowych, istotne jest zadanie każdemu z dostawców kilku pytań:

• Czy ich oferta odzwierciedla nasz stack technologiczny – czy będąc firmą skupioną np. na Javie, będziemy w stanie bez problemu uruchomić tam wszystkie nasze systemy?
• Czy oferują data centre w interesujących nas położeniach geograficznych – prędzej czy później pojawią się regulacje, które będą wymuszać na nas przetwarzanie danych w regionach, gdzie zostały one zebrane. Jeśli nasz dostawca nie będzie w stanie zaoferować nam interesującej nas lokalizacji, może nas to przyblokowac jeśli chodzi o ekspansję na kolejny rynek.
• Jakie modele wsparcia są oferowane przez dostawcę – jeśli przenosimy naszą infrastrukturę na zarządzane komponenty, będziemy potrzebować wydajnego supportu, który jest w stanie reagować na nasze zapytania wg odpowiednio zdefiniowanego SLA.
• Jak stabilna jest ich oferta – najgorsze co możemy wybrać to dostawca, który dopiero co stabilizuje dostępne produkty i nie daje gwarancji co do ich dalszego rozwoju.
• Jak wydajna oraz elastyczna jest infrastruktura naszego dostawcy. Pamiętajmy, że w każdym data centre działać będą aplikacje różnych klientów, gdzie każdy z nich ma inne oczekiwania co do dostępności oraz inną charakterystykę hostowanych aplikacji. W momencie zwiększonego ruchu w naszej aplikacji (a co za tym idzie – zwiększonego zapotrzebowania na moc obliczeniową) chcemy mieć pewność co do stabilności nie tylko naszego rozwiązania, ale także infrastruktury chmurowej.

Ponieważ technologie chmurowe mają mnóstwo składowych bardzo pomocne na etapie analizy oferty może być zatrudnienie konsultanta, który może nas wspomóc w inwentaryzacji naszych zasobów oraz jej ewaluacji. Jeśli to szczególnie istotne jeśli osobiście nie mamy doświadczenia z tą tematyką i nie mamy intuicji, jak faktycznie rozkładają się poszczególne koszty oraz jakie trudności napotkamy w zależności od naszego wyboru.

Inwentaryzacja naszych zasobów

Migracja do chmury nie mogłaby się odbyć bez zrozumienia, co właściwie chcemy przenieść z naszego lokalnego środowiska do zewnętrznego data centre. Aby tego dokonać, będziemy potrzebować współpracy nie tylko z zespołami deweloperskimi, ale także osobami odpowiedzialnymi za utrzymanie serwisów typu legacy, administratorów naszej sieci czy inżynierów bezpieczeństwa. Niezwykle ważne będzie nie tylko zrozumienie stanu obecnego, ale także zaplanowanie tzw. landing zone. Landing zone to nic innego jak punkt wyjścia, który służy zarówno jako docelowe miejsce początkowych operacji związanych z migracją, ale także miejsce eksploracji dalszych możliwości. Aby dopełnić obrazu migracji, musimy zdecydować się na chmurowy model, który jest dla nas szczególnie interesujący:

• Model publiczny, w którym cała nasza infrastruktura jest hostowana w ramach chmurowej infrastruktury naszego dostawcy, która jest ogólnodostępna i współdzielona z innymi użytkownikami.
• Model prywatny, w którym otrzymujemy dedykowane rozwiązania sieciowe dostarczane tylko dla wybranych klientów a cała infrastruktura jest odseparowana od współdzielonej części.
• Model hybrydowy, w którym łączymy wiele różnych modeli chmurowych (bądź uwzględniamy połączenie z istniejącym środowiskiem on-premises).

Wybór modelu jest często ściśle uzależniony od charakterystyki naszej firmy (inne wymagania ma sektor medyczny, inny e-commerce, jeszcze inny retail), naszych możliwości finansowych (rozwiązania prywatne są zdecydowanie bardziej bezpieczne, choć jednocześnie kilkukrotnie droższe) czy ogólnych wewnętrznych wymagań oraz audytów. Wielu klientów decyduje się na metodę małych kroków kiedy w pierwszej kolejności do chmury migrujemy proste aplikacje o niewygórowanych wymaganiach, dzięki którym budujemy fundamenty przyszłej infrastruktury chmurowej.

Wracamy tutaj do pojęcia landing zone w chmurze, które w większości przypadków sprowadza się do wdrożenia kilku aplikacji w sposób, który od razu zwaliduje nasze założenia na poziomie sieciowym oraz koncepcyjnym. Jeśli w tym momencie wykryjemy braki u naszego dostawcy, mamy jeszcze szansę albo przeprojektować obecne rozwiązania, albo zmienić dostawcę na takiego, który spełni nasze oczekiwania. Wbrew pozorom poziom skomplikowania operacji migracji nawet niewielkich aplikacji do chmury nie może być pominięty. Wiele systemów tworzonych z myślą o działaniu na środowiskach on-premises nie musiało mierzyć się z takimi problemami jak nieustanne migracje pomiędzy maszynami, multi-tenancy, ciągłe zmiany adresów IP, wyższe wymagania co do skalowalności. Mając z tyłu głowy jedną z głównych założeń architektury chmurowej, tj. „chmura to stan permanentnej awarii”, musimy liczyć się z tym, że proste migracje typu lift & shift sprawdzają się bardzo rzadko i raczej tylko w przypadku aplikacji hostowanych bezpośrednio na wirtualnych maszynach. Jakiekolwiek odstępstwo od tej reguły (jak np. migracje do modelu PaaS bądź zarządzanego klastra Kubernetes) zwielokrotnia ryzyko i bez uwzględnienia go wcześniej powoduje nieoszacowanie kosztów migracji.

Gotowe frameworki

Dostawcy chmurowi są świadomi, że adaptacja chmury w organizacji to kosztowny i długotrwały proces, który wymaga skrupulatnego planowania i analizy zysków oraz strat. Na szczęście w sieci możemy znaleźć gotowe frameworki nazwane CAF od Cloud Adoption Framework, które dzielą proces migracji na kilka elementarnych składowych:

• Definicja strategii
• Planowanie
• Osiągnięcie gotowości
• Adaptacja
• Kontrola
• Zarządzanie

W zależności od wybranego dostawcy chmurowego CAF może się nieco różnić od innych, mimo to u podstaw służą one temu samemu celowi – ułatwienie organizacjom przejścia procesu migracji poprzez „wymuszenie” na nich spisania strategii migracji i ewaluację obecnych ryzyk jak, chociażby istniejący know-how w firmie, inwentaryzację zasobów czy zaplanowany landing zone. Niektóre frameworki posiadają gotowe benchmarki, które pozwalają nam ocenę poszczególnych obszarów i skupienie się na miejscach, które wymagają zdecydowanej poprawy. Często wspominanym elementem jest także zatrudnienie odpowiedniego partnera, który ma doświadczenie w migracjach do chmury i jest w stanie wesprzeć nas nie tylko w zakresie technicznym, ale także ewentualnych zawiłości prawnych, które mogą się pojawić, jeśli chcemy przenieść naszą infrastrukturę oraz dane poza granice kraju.

Podsumowanie

Migracja do chmury jest zagadnieniem, do którego każda firma powinna się przygotować bez pośpiechu i unikać podejmowania decyzji pod wpływem emocji. W przeciwieństwie do wielu technologicznych nowinek cloud nie jest przejściową modą i dyktuje kierunek rozwoju wielu systemów IT oraz produktów na najbliższe lata. Olbrzymia elastyczność, ułatwiona kontrola kosztów, ułatwiony development czy baza gotowych elementów, z których można składać swoją aplikację, to rzeczy, które ciężko zignorować przy tak dużej konkurencyjności obecnych rynków. Z drugiej strony chmura to też ryzyka – brak pełnej kontroli nad infrastrukturą, zależność od dostawcy, a także często skomplikowane procedury związane z dostarczaniem oprogramowania na zarządzaną infrastrukturę to rzeczy, które trzeba wziąć pod uwagę, rezygnując z tradycyjnej infrastruktury lokalnej. Niezależnie jednak od naszego wyboru odsetek firm, które z powodzeniem zakończyły proces migracji, rośnie z dnia na dzień, a wspomniana na samym początku pandemia tylko przyspieszyła ten trend. Wskazuje to jednoznacznie na coraz większe zaufanie do tej technologii i pokazuje, że cały proces można przejść nawet w tak ekstremalnych warunkach.