Architektura Multi-Cloud

Są jednak sytuacje, w których nie jest. Regulator może wymagać, żeby określone dane pozostały w jurysdykcji, w której Twój główny dostawca nie ma regionu. Zobowiązanie co do dostępności może przekraczać to, co obejmuje SLA jednej platformy. Konkretna usługa (określona baza zarządzana, sieć brzegowa, usługa uczenia maszynowego) bywa wyraźnie lepsza w jednym miejscu, podczas gdy reszta systemu spokojnie działa gdzie indziej. A firma wydająca duże kwoty u jednego dostawcy ma zauważalnie inną pozycję negocjacyjną, gdy istnieje wiarygodna alternatywa.

Każdy z tych powodów jest konkretny. Gdy któryś z nich występuje, projekt multi-cloud jest wart swojego kosztu. Gdy nie występuje żaden, zwykle nie jest.

Dwie platformy oznaczają dwa modele tożsamości i uprawnień, dwa zestawy pojęć sieciowych, dwie struktury rozliczeń, dwa procesy przeglądu bezpieczeństwa i dwa zbiory osobliwości, które ujawniają się dopiero o trzeciej nad ranem. Twoi inżynierowie muszą sprawnie poruszać się w obu, co wpływa na rekrutację i utrudnia obsadzenie dyżurów. Narzędzia, które u jednego dostawcy działają bezproblemowo, często wymagają warstwy abstrakcji, żeby działać u obu, a ta warstwa to kod, który ktoś musi utrzymywać.

Nic z tego nie jest argumentem przeciwko multi-cloud. To argument za tym, żeby mieć jasny powód przed podjęciem takiej decyzji, bo narzut jest stały, a korzyść bywa sporadyczna.

Warto też rozważyć najpierw wersję lżejszą. Trzymanie DNS, warstwy cache na brzegu sieci albo magazynu obiektowego u dostawcy innego niż ten, który obsługuje główne moce obliczeniowe, daje pewien stopień niezależności przy ułamku kosztu operacyjnego. Te usługi są w dużej mierze wymienne i rzadko wplecione głęboko w resztę systemu. Dla wielu firm to wystarczający zakres tej dyskusji.

Środowisko postawione w innej chmurze, ale nigdy nieobsługujące ruchu produkcyjnego, nie jest realnym miejscem przełączenia awaryjnego. Konfiguracja się rozjeżdża. Replikacja danych zaczyna się opóźniać albo po cichu przestaje działać. Certyfikaty wygasają. Wpisy DNS wskazują na coś, co się zmieniło. Awaria u głównego dostawcy to zły moment, żeby którąkolwiek z tych rzeczy odkryć.

Jeśli powodem takiej architektury jest odporność, to przełączenie trzeba ćwiczyć cyklicznie, mierząc czas odtworzenia i ewentualną utratę danych oraz zapisując te wartości. Ta liczba jest faktyczną odpornością systemu. Cała reszta to intencja.

Ćwiczenie warto zaplanować tak, żeby obejmowało również ludzi, a nie tylko technikę. W trakcie realnej awarii pytania o to, kto podejmuje decyzję o przełączeniu, na jakiej podstawie i kogo trzeba poinformować, zabierają zwykle więcej czasu niż same operacje techniczne.

Użyteczna wersja tego celu jest skromniejsza. Dla każdej istotnej zależności warto wiedzieć, co oznaczałaby jej wymiana i mniej więcej ile by zajęła. Część odpowiedzi jest uspokajająca. Magazyn obiektowy i uruchamianie kontenerów wyglądają wszędzie podobnie. Część nie jest, a wyjście z zamkniętej usługi zarządzanej, wplecionej głęboko w aplikację, jest drogie.

Wiedza o tym, co jest czym, pozwala świadomie zawrzeć ten kompromis. Możesz zaakceptować głęboką zależność tam, gdzie usługa jest tego warta, i zostawić sobie drogę wyjścia tam, gdzie nie jest. To znacznie praktyczniejsze podejście niż ignorowanie lock-inu albo próba całkowitego wyeliminowania go.