Multicloud w praktyce, czyli integracja wielu chmur w jednym środowisku

Firmy – poszukując najlepszych w swojej kategorii rozwiązań albo aby uniknąć tzw. Vendor Lock-in – coraz częściej wybierają strategię multicloud. Polega ona na wykorzystywaniu usług chmurowych różnych producentów. Tak powstaje model Chmury 2.0, czyli zastosowanie tych usług, które do danych zadań nadają się najlepiej.

Podstawowe powody, dla których organizacje decydują się na wdrożenie strategii wielu chmur, to: odporność na awarie i łatwość odtwarzania systemów IT po ich wystąpieniu; unikanie uzależnienia się od konkretnego dostawcy, minimalizacja opóźnień w przypadku obsługi klientów lub ośrodków rozproszonych geograficznie, elastyczność zarządzania danymi oraz optymalizacja kosztów. O ile minimalizację opóźnień da się zrealizować w jednej chmurze udostępnianej z kilku centrów przetwarzania danych, o tyle do uniknięcia zjawiska Vendor Lock-in oraz poprawy elastyczności zarządzania danymi najlepiej nadają się chmury różnych dostawców. Strategia multicloud daje wybór tych narzędzi i usług, które połączą funkcjonalność, efektywność kosztową i bezpieczeństwo.

Zastosowanie najkorzystniejszych na rynku narzędzi

Mimo podobieństw, oferty różnych dostawców dość znacząco się różnią. Każdy dostawca ma właściwy dla siebie zestaw usług, z którymi wiąże się określony model kosztowy. Niewłaściwy dobór usług i dostawców wymusza większe koszty. Dobrze przygotowana strategia multicloud umożliwia zaś optymalizację kosztów utrzymania, a także kosztów migracji, w obie strony. Jednocześnie, każdy dostawca usług chmury obliczeniowej – obok typowych usług i zasobów, takich jak storage, moc obliczeniowa, platformy, usługi serverless oraz aplikacje – oferuje natywne narzędzia bezpieczeństwa. Model multicloud umożliwia użycie tych narzędzi, które będą najkorzystniejsze dla każdego zastosowania z osobna, zachowując przy tym spójność w firmie.

Stworzona w tym modelu infrastruktura będzie pozbawiona pojedynczego punktu awarii i odporniejsza nawet na duże problemy spowodowane rozległymi awariami technicznymi. Ponadto, szczególnie istotne dane nadal będzie można składować w firmowej infrastrukturze – w modelu on-premise – wykorzystując przy tym istniejące rozwiązania uwierzytelnienia, serwery bazodanowe i inne zasoby. Co ważne, usługi po stronie chmury należy dobrać w taki sposób, aby minimalizować utrzymywanie niezależnych systemów uwierzytelnienia, automatyzacji, zarządzania, monitoringu i innych podobnych komponentów. Dobór usług i miejsca, gdzie poszczególne usługi się znajdują, będzie najważniejszym i najtrudniejszym zadaniem dla firmowego IT.

Strategie migracji do wielu chmur

Wykorzystanie koncepcji multicloud zazwyczaj zaczyna się od prostego przenoszenia istniejących aplikacji, tak aby można było je uruchomić w docelowym środowisku. Taka sama maszyna wirtualna może pracować w każdym z tych środowisk, odzwierciedlając środowisko on-premise. Nie wszystkie aplikacje można wprost przenieść w ten sposób. Mogą pojawić się też problemy związane z licencjonowaniem serwerów i baz danych, co sprawia, że nie zawsze jest to wariant najkorzystniejszy kosztowo. Przenoszenie jest jednak najprostsze i z powodzeniem umożliwia uniknięcie Vendor Lock-in.

Nieco dalej idzie proces nazywany uchmurowieniem, który polega na oddzielnej migracji obciążeń CPU i storage do ich odpowiedników w obu chmurach. Możliwy jest nawet scenariusz cross-cloud, w którym maszyny wirtualne mogą pracować w środowisku Azure, ale składowanie danych może odbywać się np. w ramach platformy AWS (lub odwrotnie). Organizacje decydują się na taki model, gdy chcą w prosty sposób uzyskać wysoką dostępność środowiska i odporność na awarie. W kolejnych krokach podobnej migracji łączy się usługi różnych dostawców, otwierając składniki aplikacji na nowe możliwości.

Rozdzielona migracja komponentów o różnej charakterystyce pracy

Aby odnieść większe korzyści, firma może przygotować aplikacje do migracji, dzieląc je na odpowiednie komponenty o różnej charakterystyce pracy, które następnie będą stopniowo przenoszone do właściwych dla nich środowisk. Proces podziału i dostosowania nazywany jest rozdzieloną migracją lub refaktoringiem. Jest to dość duża zmiana z punktu widzenia architektury, ale umożliwia lepszy dobór usług, co daje korzyści z punktu widzenia wydajności, dostępności i kosztów. Jeśli aplikacja jest na to gotowa, można będzie użyć automatycznej skalowalności, właściwej dla środowisk chmurowych. Wzrost obciążenia będzie skutkował powoływaniem w miarę potrzeb nowych maszyn, a spadek ich wyłączaniem. Wadą tego modelu będzie złożoność migracji. Aplikacja to nie tylko aplikacje i systemy, lecz także sieć i polityki bezpieczeństwa oraz inny sposób utrzymania aplikacji pracującej w docelowych środowiskach.

Model chmury obliczeniowej charakteryzuje się bardzo wysoką skalowalnością oraz dostępnością, z czego organizacje skwapliwie korzystają. Jeśli możliwy będzie podział aplikacji na komponenty, część składników można będzie przenieść do dwóch chmur i uruchomić w środowiskach np. AWS i Azure równocześnie, uzyskując nadzwyczaj dobrą skalowalność i odporność na awarie. W ten sposób można migrować niemal cały Front-end webowy wielu obciążonych aplikacji, zachowując ich responsywność i dostępność.

Wadą takiego rozwiązania jest opóźnienie w przypadku poważnych awarii. Nie ma natychmiastowego przełączenia, co można nieco poprawić po przeprowadzeniu zmian architektonicznych i wykorzystaniu usług brokera chmurowego. Broker spowoduje szybkie przełączenie obsługi obciążenia, ale nadal będzie odczuwalna przerwa w dostępności usługi spowodowana awarią usług chmurowych jednego dostawcy. Uzyskana tą drogą odporność na awarie jest jednak nieporównywalnie lepsza od tego, co zazwyczaj uzyskuje się w środowiskach on-premise.