Zapytaj dziesięć zespołów infrastrukturalnych, czy mają strategię wyjścia z cloud, a dziewięć odpowie „tak”. Zapytaj, z czego się ona składa, a zwykle dostaniesz stronę wiki napisaną podczas przeglądu dostawcy, wyliczającą, które usługi są własnościowe, a które przenośne. To inwentarz, nie strategia. Prawdziwy test jest mniej wygodny: gdyby Twój dostawca podwoił ceny, zmienił jurysdykcję albo zawiesił Twoje konto we wtorkowy poranek, ile tygodni zajęłoby Ci obsługiwanie ruchu gdzie indziej - i kto w Twoim zespole odpowie na to bez otwierania arkusza kalkulacyjnego?
Presja regulacyjna jest tu realna, ale to nie ta ciekawa część. Data Act usuwa opłaty za zmianę dostawcy, co odbiera działowi finansowemu wymówkę. Schrems II i CLOUD Act odebrały tę prawną już lata temu. To, co zostaje, to rzeczywistość inżynierska, i żadna dyrektywa jej nie naprawi. Regulator może sprawić, że odejście będzie tańsze na papierze; nie sprawi, że Twój pipeline deploymentu, model tożsamości, rekordy DNS i ścieżka przywracania zadziałają u drugiego dostawcy. Ta praca jest Twoja i to jest cały koszt.
Czym naprawdę jest strategia wyjścia z cloud
Strategia wyjścia to mierzalna właściwość Twojej architektury, nie dokument. Pomiar jest bezlitosny: jaki odsetek Twojego działającego majątku mógłbyś postawić u innego dostawcy, używając narzędzi, którymi już się posługujesz, bez pisania nowego kodu? Dla większości zespołów uczciwa odpowiedź mieści się gdzieś między czterdziestoma a siedemdziesięcioma procentami, a luka nigdy nie jest tam, gdzie się jej spodziewali. Rzadko jest to aplikacja. To zarządzana baza danych, kolejka, semantyka object storage i jedenaście drobnych nawyków operacyjnych, których nikt nigdy nie spisał.
Trybem awarii jest tu wiara, że posiadanie dwóch dostawców cokolwiek dowodzi. Mnóstwo firm prowadzi produkcję u jednego hyperscalera i zapomniany projekt testowy gdzie indziej, a potem nazywa to multi-cloud. Opcjonalność to nie posiadanie drugiego konta; to zdolność, żeby z niej skorzystać. Dopóki jeden prawdziwy workload - z monitoringiem, backupami, dyżurami on-call i przywracaniem, które faktycznie przeprowadziłeś - nie działa gdzie indziej niż u Twojego głównego dostawcy, masz drugą fakturę, nie drugą opcję.
Trzy rzeczy, które utrudniają odejście
Po pierwsze, grawitacja danych, która jest nudna i decydująca. Bajty są tanie do skopiowania i drogie do przeniesienia spójnie, gdy system działa na żywo. W chwili, gdy Twoje dane siedzą wewnątrz własnościowej usługi zarządzanej, wyjście przestaje być kopiowaniem, a staje się przepisaniem wszystkiego, co się z nimi komunikuje. Dlatego zespoły, które trzymają swój stan w czymś, co mogłyby same uruchomić - nawet jeśli dziś wybierają, żeby tego nie robić - zachowują opcje, które zespoły na w pełni zarządzanych stackach po cichu tracą po kilku latach.
Po drugie, pamięć mięśniowa operacyjna. Twój zespół zna model tożsamości jednego dostawcy, jedną abstrakcję firewalla, jeden sposób nazywania sieci, jeden układ konsoli o trzeciej nad ranem. Przenieś się do drugiego dostawcy, a każde z tych, pod presją, staje się obce. Kosztem nie jest weekend migracji; to następne sześć miesięcy incydentów obsługiwanych trochę wolniej przez ludzi, którzy zgadują. Nikt tego nie wpisuje do estymacji migracji, a to zwykle jej największa pozycja.
Po trzecie, atrybucja kosztów. Większość zespołów nie potrafi Ci powiedzieć, ile dziś kosztuje pojedynczy workload, co z zasady czyni porównywanie dostawców niemożliwym. Jeśli Twoja faktura to jedna liczba na dostawcę, a Twoja architektura to czterdzieści usług, rozmowa o wyjściu degeneruje się do przeczuć. Zanim wycenisz wyjście, potrzebujesz wydatków rozbitych na usługę, projekt i środowisko, u każdego dostawcy, którego używasz, łącznie z tymi małymi, o których zapomniałeś. To niewdzięczna praca u podstaw, i jest warunkiem koniecznym dla każdej innej decyzji w tym temacie.
Jak uniknąć uzależnienia od dostawcy cloud (vendor lock-in) w UE
Jeśli chcesz uniknąć uzależnienia od jednego dostawcy cloud (vendor lock-in), rynek UE jest w lepszej kondycji, niż zakłada większość zespołów. Stosunek ceny do wydajności Hetznera sprawia, że faktury od hyperscalerów wyglądają jak zaokrąglenie w złą stronę. OVHcloud prowadzi własne centra danych i światłowody w całej Europie. Scaleway oferuje naprawdę nowoczesne doświadczenie deweloperskie z Francji. UpCloud dostarcza niezawodny compute z Finlandii. Żaden z nich nie zastępuje każdej usługi hyperscalera - ale w zakresie compute, block storage i sieci, gdzie realnie idzie większość pieniędzy na infrastrukturę, są wiarygodni i odpowiadają wyłącznie przed prawem UE.
Uczciwym ograniczeniem są usługi zarządzane. Jeśli Twój produkt jest zbudowany na zastrzeżonej, serverlessowej bazie danych, konkretnej szynie zdarzeń albo platformie machine learning, dla której nie ma odpowiednika gdzie indziej, żaden entuzjazm dla Europy nie zmieni tego w ciągu jednego kwartału. Sensowny ruch to nie heroiczna migracja na zasadzie wszystko-albo-nic. To dokładne rozeznanie, które workloady są dziś przenośne, uruchomienie części z nich tam, gdzie odpowiada Ci jurysdykcja i cena, oraz potraktowanie reszty jako świadomej, udokumentowanej decyzji, a nie przypadku historii.
Na czym naprawdę polega próba wyjścia
Potraktuj to jak ćwiczenie przywracania z backupu, bo dokładnie tym to jest. Wybierz prawdziwy workload - nie stronę marketingową, tylko coś ze stanem i runbookiem. Postaw go u drugiego dostawcy. Skieruj na niego ułamek prawdziwego ruchu. Celowo go zepsuj i sprawdź, czy Twój monitoring, model dostępu i grafik dyżurów też tam działają. Potem zapisz rzeczywisty czas trwania i wszystko, co Cię zaskoczyło. Próba, która nie przynosi żadnych niespodzianek, zwykle oznacza, że wybrałeś coś zbyt łatwego.
Powód, dla którego większość zespołów nigdy nie robi takiej próby, to nie lenistwo, tylko narzędzia. Każdy dodatkowy dostawca oznacza kolejną konsolę, kolejny model poświadczeń, kolejny eksport rozliczeń, kolejny zestaw dziwactw do nauczenia się - a mały zespół platformowy nie jest w stanie wchłonąć tego przy każdym kolejnym cloudzie. To operacyjny podatek, który po cichu zamienia rozmowę o suwerenności w problem na przyszły rok - co roku. To także dokładnie ten problem, który control plane ma zdjąć z Twojego biurka.
Dokładnie do tego zbudowaliśmy Sencai. Jeden control plane obejmujący jedenastu dostawców - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode od Akamai i Oracle Cloud - plus Twoje własne serwery przez agenta hosta. Sieci, firewalle i DNS są zarządzane tam, gdzie faktycznie żyją, czyli u dostawcy, więc drugi dostawca staje się kafelkiem w tym samym interfejsie, a nie drugim zespołem platformowym. Wydatki są śledzone per organizacja, z limitami, więc rozmowa o wyjściu ma w sobie konkretne liczby.
Możesz uruchomić to na własnych kontach u dostawców albo kupić pojemność przez nas i mieć jedną fakturę - obsługujemy oba warianty, a wybór możesz później zmienić. Tak czy inaczej wynik jest ten sam i to jedyna liczba, którą warto raportować wyżej: ile czasu zajęłoby Ci działanie gdzie indziej. Zmierz to raz, a przestanie to być strachem. Mierz to co kwartał, a stanie się to atutem - w negocjacjach, w przeglądzie zakupowym i w dniu, w którym coś wymusi to pytanie.