Rozważając przeniesienie części zasobów i procesów IT do chmury publicznej, musimy znaleźć odpowiedzi na wiele nurtujących nas pytań. Który dostawca zapewni najwyższy poziom bezpieczeństwa, gdzie zlokalizowane są centra danych, jakie usługi są dostępne w warstwie PaaS, wreszcie jaka jest dostępność rynkowa specjalistów w zakresie danej chmury – te pytania potrafią spędzić sen z powiek niejednemu CIO.
Coraz częściej jednak zadawane jest jeszcze jedno pytanie – ilu chmur potrzebuję?
Powody skłaniające organizacje do zastosowania tzw. multi-cloud mogą być bardzo różne.
W niektórych scenariuszach kluczowym argumentem będzie zapewnienie wysokiej dostępności aplikacji z wykorzystaniem infrastruktury dwóch lub więcej chmur. W innych – mniejsze uzależnienie od konkretnego dostawcy (tzw. vendor lock-in) oraz mocniejsza pozycja negocjacyjna, wynikająca m.in. z rzeczywistej możliwości przeniesienia części zasobów do konkurencyjnej chmury. Wreszcie w części zastosowań istotna będzie możliwość wykorzystania konkretnych, unikalnych dla danej platformy usług warstwy Platform-as-a-Service.
Aby lepiej zrozumieć korzyści i wyzwania związane z multi-cloud, rozpatrzmy dwa najczęściej spotykane scenariusze.
Scenariusz 1 – IaaS
W pierwszym scenariuszu (nazwijmy go roboczo „zrównoleglony IaaS”) aplikacje są migrowane do dwóch lub więcej chmur, w których działają w sposób niezależny. Przykładowo, jeśli są to aplikacje przetwarzające strumieniowo dane wejściowe, mogą one zostać skonfigurowane w taki sposób aby każde zdarzenie źródłowe było równolegle przetwarzane przez każdą instancję aplikacji w poszczególnych chmurach. W ten sposób uzyskujemy możliwość load balancingu, ale przede wszystkim zwiększoną odporność na awarie infrastruktury poszczególnych dostawców. Jeśli w chmurze A następuje awaria, przełączenie ruchu na instancje aplikacji w chmurze B jest łatwe, ponieważ działają one na tych samych danych.
Dodatkową korzyścią może być przeniesienie aplikacji możliwie blisko klienta końcowego. Poszczególne chmury w dalszym ciągu różnią się pod kątem swojej dostępności geograficznej – chociaż różnica ta będzie maleć wraz z rozbudową infrastruktury i dodawaniem do niej nowych regionów. Dobrym przykładem będzie tu rynek chiński – gdzie dominującą pozycję i najbardziej rozbudowaną sieć centrów danych posiada Alibaba Cloud. Obecność pozostałych chmur publicznych na tym rynku jest raczej marginalna.
Patrząc na taką architekturę od strony biznesowej, pozwala ona w dużej mierze rozwiązać problem uzależnienia od pojedynczego dostawcy. Niestety, ceną za to jest konieczność utrzymywania w organizacji kompetencji technicznych w zakresie wszystkich wykorzystywanych chmur – co w dobie notorycznego braku na rynku doświadczonych specjalistów może być problematyczne. Jeśli z tego lub innego powodu nie chcemy więc samodzielnie zarządzać naszym środowiskiem multi-cloud, warto rozważyć model usługi zarządzanej (tzw. managed service), w którym będzie ono utrzymywane przez wyspecjalizowanego Managed Service Providera.
Niezależnie od przyjętego modelu rozliczeniowego, architektura oparta o działające niezależnie zduplikowane instancje aplikacji wiąże się z odpowiednio zwielokrotnionymi kosztami – stąd takie podejście będzie uzasadnione przede wszystkim w aplikacjach krytycznych biznesowo, Po rozwiązania tego typu sięgną więc zapewne w pierwszej kolejności banki i inne instytucje finansowe, dla których nawet najmniejszy przestój w kluczowych systemach transakcyjnych oznacza ogromne straty operacyjne i reputacyjne.
Scenariusz 2 – IaaS/PaaS
Rozważana powyżej architektura oparta jest o czysty model IaaS, gdzie oferta poszczególnych chmur jest względnie zunifikowana, a dodatkowe narzędzia takie jak Terraform pozwalają dodatkowo przykryć część szczegółów implementacyjnych związanych z konkretną platformą. Jednak opieranie się o „najmniejszy wspólny mianownik” w postaci podstawowego IaaS oznacza brak możliwości skorzystania z unikalnych funkcjonalności i usług wyróżniających poszczególne chmury.
W drugim scenariuszu dokonujemy wyboru najlepszej chmury dla każdej aplikacji osobno. Być może w trakcie ewaluacji dojdziemy do wniosku, że najlepszym wyborem dla naszego systemu transakcyjnego będzie AWS, klasyczny BI chcemy umieścić w Azure (np. z uwagi na już wdrożony w organizacji Office 365) – zaś przetwarzanie Big Data i modele predykcyjne chcemy realizować za pomocą BigQuery i modeli TensorFlow / CloudML w chmurze Google. W rozwiązaniu o takiej architekturze korzyścią jest możliwość głębokiej integracji poszczególnych aplikacji z usługami PaaS oferowanymi przez konkretną platformę. Z drugiej strony, o wysoką dostępność musimy zadbać samodzielnie w ramach mechanizmów dostępnych w danej chmurze publicznej (np. availability zones) – co może oznaczać konieczność modyfikacji kodu aplikacji.
W rozważanej architekturze mamy jeszcze jedno wyzwanie, które nie występowało w pierwszym podejściu IaaS-owym. Musimy bowiem zadbać o szybkie i niezawodne połączenie sieciowe pomiędzy poszczególnymi chmurami – a w zasadzie pomiędzy aplikacjami tam wdrożonymi. O ile każdy dostawca chmurowy umożliwia zestawienie wydajnego Site-to-Site VPN z naszą infrastrukturą on-premises oraz w razie potrzeby skorzystanie z dedykowanego połączenia o wysokiej prędkości (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect), o tyle zestawienie VPN pomiędzy zasobami w różnych chmurach będzie wymagało pewnego nakładu pracy po obu stronach połączenia. W przypadku bardziej zaawansowanej topologii sieci (np. więcej niż 2 chmury, wiele regionów) warto rozważyć skorzystanie z dedykowanego narzędzia, takiego jak Aviatrix.
Podobnie jak w pierwszym scenariuszu, dalej musimy utrzymywać w organizacji zaawansowaną wiedzę o wszystkich wykorzystywanych platformach – zwłaszcza biorąc pod uwagę fakt, że będziemy chcieli skorzystać z unikalnych, niedostępnych u konkurencji, usług PaaS których nasz zespół musi się nauczyć. Musimy też zarządzać kontraktami i relacjami z dostawcami chmur – a ponieważ wynikowe rozwiązanie składa się z aplikacji i komponentów uruchamianych na różnych platformach, problemem może być uzyskanie wsparcia technicznego i SLA w przypadku problemów „na styku” dwóch chmur. Dlatego również i w tym scenariuszu warto rozważyć przekazanie operacyjnego zarządzania środowiskiem w ręce zaufanego dostawcy managed service, który przejmie na siebie część z opisanych wyżej ryzyk i będzie w stanie zaoferować SLA na całość rozwiązania.
Narzędzia
Niezależnie od wybranego scenariusza migracji do multi-cloud, w przypadku projektów klasy Enterprise są to dosyć wymagające przedsięwzięcia zarówno od strony technicznej jak i organizacyjnej. Warto więc skorzystać z wyspecjalizowanych narzędzi, które mogą pomóc w automatyzacji tworzenia infrastruktury oraz jej monitorowaniu i optymalizacji na późniejszych etapach projektu.
Projektując docelową sieć, składającą się z zasobów w kilku chmurach publicznych oraz rozproszoną pomiędzy regionami, staniemy przed koniecznością zdefiniowania połączeń VPN, których konfiguracja może być czasochłonna – a monitoring, w przypadku ich większej liczby, utrudniony. Tę część prac możemy uprościć korzystając z komercyjnego rozwiązania Aviatrix. Umożliwia ono szybkie zestawiania połączeń między największymi chmurami (AWS, Azure, GCP) za pomocą interfejsu graficznego, wspiera kluczowe architektury takie jak hub and spoke, oraz dostarcza rozbudowane opcje monitoringu stanu sieci.
W zakresie definiowania i wdrażania samej infrastruktury, niezastąpiony będzie Terraform – posiadający ponad 50 konektorów zarówno do wszystkich liczących się chmur publicznych jak i dostawców lokalnych oraz zewnętrznych narzędzi. Ciekawostką jest fakt, że część z dostawców chmury, np. Microsoft, Oracle oraz Google, bardzo ściśle współpracuje z Terraform, inwestując czas inżynierów i rozbudowując konektory do swoich produktów.
Z punktu widzenia zarządzania i monitoringu wdrożonego już rozwiązania, warto sięgnąć po jedną z Cloud Management Platform. Z reguły platformy te, takie jak np. RightScale, są dosyć rozbudowane i dostarczają szeroki wachlarz usług od definiowania infrastruktury poprzez jej wdrażanie i monitoring – ale często posiadają też osobne produkty do zarządzania kosztami (np. RightScale Optima). Jeśli korzystamy już z Microsoft Azure, to bez dodatkowych kosztów mamy możliwość skorzystania z usługi Azure Cost Management – czyli de facto produktu firmy Cloudyn, która w wersji komercyjnej wspiera również analizę kosztów w chmurach AWS i GCP.
Czytaj także: Uniwersalna chmura – czy istnieje?
