Zarządzanie multi-cloud

"Multi-cloud" jest często używane jako termin strategiczny — powód, by zdywersyfikować się poza jednego dostawcę, wynegocjować lepsze ceny lub spełnić wymóg dotyczący rezydencji danych. Zarządzanie multi-cloud to węższa, operacyjna warstwa leżąca pod tą strategią: narzędzia i procesy, które pozwalają zespołowi infrastruktury faktycznie uruchamiać obciążenia u kilku dostawców, nie traktując każdego z nich jak osobne zadanie. Bez niej "multi-cloud" w praktyce oznacza osobną konsolę, zestaw danych uwierzytelniających i terminologię dla każdego dostawcy — i brak jednego miejsca, w którym można odpowiedzieć na podstawowe pytanie: jaka infrastruktura istnieje w tej chwili i kto ostatnio ją zmienił.

Każdy dostawca ma własną konsolę, CLI, model IAM i słownictwo dla tych samych, leżących u podstaw prymitywów — maszyny wirtualnej, grupy bezpieczeństwa, strefy DNS, wolumenu magazynu. To rozdrobnienie jest właściwym problemem, który rozwiązuje zarządzanie multi-cloud. Zaczyna się od discovery: podłączenia konta u dostawcy i natychmiastowego zobaczenia inwentarza tego, co już tam działa, zanim cokolwiek zostanie zmigrowane lub zmienione. Stamtąd stosuje jeden spójny workflow do typowych działań w cyklu życia zasobu — provisioningu, uruchamiania, zatrzymywania, zmiany rozmiaru, niszczenia — niezależnie od tego, u którego dostawcy dany zasób się znajduje. Silniejsze implementacje zarządzają konfiguracją na żywo i synchronicznie bezpośrednio u dostawcy, zamiast przez zbuforowaną kopię we własnej bazie danych, więc zmiana wprowadzona przez narzędzie to ta sama zmiana, którą zobaczysz, logując się do konsoli samego dostawcy.

Zarządzanie multi-cloud wykracza poza cykl życia mocy obliczeniowej i obejmuje te obszary operacji, które faktycznie generują ryzyko, gdy są niespójne u różnych dostawców. Kontrola dostępu musi działać wszędzie tak samo — pojedyncze logowanie (SSO), uprawnienia oparte na rolach oraz podwyższanie uprawnień do wrażliwych działań wymagające zatwierdzenia, zamiast innego modelu tożsamości u każdego dostawcy. Każda zmiana musi dać się przypisać do konkretnej osoby, dlatego ścieżka audytu obejmująca wszystkich podłączonych dostawców ma tu większe znaczenie niż w konfiguracji z jedną chmurą — to różnica między pytaniem, na które można odpowiedzieć, a dochodzeniem. A ponieważ koszt infrastruktury jest jedną z pierwszych rzeczy, które stają się nieczytelne przy wielu dostawcach, widoczność kosztów i wykrywanie anomalii powinny znajdować się w tym samym miejscu co provisioning, a nie w osobnym arkuszu uzgadnianym raz w miesiącu. Wiele zespołów utrzymuje też infrastrukturę, która w ogóle nie jest chmurą — serwery on-premise lub bare-metal — i oczekuje, że ta sama dyscyplina monitorowania i łatania obejmie także ją.