Są dwa sposoby, żeby pozwolić komuś innemu obsługiwać Twoją infrastrukturę. W pierwszym kupujesz od niego cloud: on trzyma konta u dostawcy, on dostaje fakturę, Ty dostajesz rachunek z narzutem i adres wsparcia. W drugim - bring your own cloud, zwykle skracane do BYOC - zachowujesz własne konta w Hetznerze, AWS czy OVHcloud, własną umowę, własną fakturę, i przyznajesz platformie zarządzającej poświadczenia ograniczone zakresem, żeby obsługiwała je w Twoim imieniu. Oba modele wyglądają podobnie na demo i zachowują się zupełnie inaczej w dniu, w którym chcesz odejść.
Model odsprzedaży to nie oszustwo; to legalny biznes z realnymi zaletami, głównie wokół jednej faktury i jednego miejsca do złożenia reklamacji. To, co oddajesz, jest mniej widoczne. Twoja relacja umowna jest z resellerem, nie z dostawcą, więc SLA, które faktycznie możesz wyegzekwować, jest jego. Zniżki za zobowiązanie użycia, kredyty startupowe i wynegocjowane ceny - wszystko przechodzi przez niego. A tożsamość zasobu, konto, w którym faktycznie żyją serwery, należy do kogoś innego, co oznacza, że odejście to migracja, a nie anulowanie.
Co zachowujesz, zachowując umowę
Przy BYOC relacja z dostawcą zostaje tam, gdzie spodziewałby się jej prawnik. Instancje są na Twoim koncie. Zgłoszenia do supportu otwierasz Ty. Faktura przychodzi w formacie, który Twój dział finansowy już umie uzgadniać, od firmy, którą już zweryfikowałeś, w jurysdykcji, którą już przemyślałeś. Jeśli Twoja postawa compliance zależy od tego, kto prawnie obsługuje usługę - co po Schrems II jest ciekawszym pytaniem niż to, gdzie fizycznie stoją serwery - nie dodałeś żadnego ogniwa do tego łańcucha, przyjmując control plane.
Test wyjścia uwidacznia różnicę. Co się dzieje, jeśli platforma zarządzająca zniknie z dnia na dzień? Przy odsprzedaży Twoje serwery są na koncie, którego nie kontrolujesz, a odpowiedź angażuje prawników. Przy BYOC serwery działają dalej dokładnie tak, jak działały; straciłeś konsolę, inwentarz i trochę automatyzacji, co jest irytujące, a nie egzystencjalne. Ta asymetria jest warta więcej niż każda lista funkcji, i to pierwsza rzecz do sprawdzenia, zanim cokolwiek podpiszesz.
Czego BYOC wymaga od platformy
Ceną tego modelu jest to, że platforma trzyma teraz prawdziwe produkcyjne poświadczenia do kont, których nie posiada. To zobowiązanie trzeba traktować dosłownie. Poświadczenia są szyfrowane w spoczynku AES-256-GCM, ograniczone zakresem do jednej organizacji, nigdy nie współdzielone między tenantami, i nigdy nie zwracane w odpowiedzi API - pola są prywatne na wyjściu tak samo, jak są zaszyfrowane na wejściu. Każdy z tych wymogów jest nudny, dopóki nie stanie się interesujący w momencie, gdy zwykły endpoint listujący zostanie poproszony o zserializowanie rekordu z poświadczeniem.
Potem jest tryb awarii, którego nikt nie planuje. Zadanie provisioningu przychodzi bez podpiętego poświadczenia: bug, wyścig, wiadomość ze starszej wersji usługi. Kuszącym zachowaniem jest spaść awaryjnie na własny token dostawcy platformy, żeby zadanie się powiodło. Wysłaliśmy kiedyś takie zachowanie na produkcję i zrobiło dokładnie to, co musiało zrobić - stworzyło prawdziwą maszynę na własnym koncie platformy, obciążoną kosztem po niewłaściwej stronie, niewidoczną w inwentarzu klienta. Domyślnym zachowaniem jest teraz fail-closed. Zadanie bez poświadczenia jest odrzucane, a włączenie fallbacku wymaga jawnej flagi środowiskowej.
Gdzie multi-provider BYOC robi się trudne
Jeden dostawca to integracja; jedenastu to problem taksonomii. Sencai obecnie steruje Hetznerem, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode od Akamai i Oracle Cloud, plus serwerami on-premise i bare-metal przez agenta hosta. Każdy z nich ma własny model uwierzytelniania, własny system limitów, własne słownictwo i własną opinię na temat tego, czy firewall należy do maszyny, sieci czy projektu. Znormalizowanie tego bez okłamywania samego siebie to większość tej inżynierii.
Linia, której staramy się trzymać, jest taka, że control plane obsługuje dostawcę, a nie jego kopię. Kiedy tworzysz sieć, regułę firewalla albo strefę DNS w Sencai, wywołanie idzie do API dostawcy i obiekt istnieje tam - widoczny w jego konsoli, usuwalny jego CLI, prawdziwy dla każdego, kto nigdy o nas nie słyszał. Platforma, która zapisuje tylko intencję we własnej bazie danych, produkuje bardzo przekonujący inwentarz rzeczy, które mogą w ogóle nie istnieć.
Rozliczenia idą za tą samą logiką. Ponieważ faktura zostaje u dostawcy, zadaniem platformy nie jest wystawianie Ci rachunków. Jest nim atrybucja i kontrola. Wydatki są śledzone per organizacja i projekt, u każdego podłączonego konta, z limitami, które ustawiasz Ty, więc pytanie „ile kosztował pipeline wsadowy w zeszłym miesiącu” ma jedną odpowiedź zamiast czterech eksportów w czterech formatach. To też część, w której BYOC jest naprawdę trudniejsze niż odsprzedaż, bo nie ma jednej księgi do odczytania; liczby trzeba pobrać i uzgodnić osobno dla każdego dostawcy.
Dla kogo jest bring your own cloud
BYOC pasuje zespołom z majątkiem, który już istnieje, i ograniczeniami, które są już realne: kilkaset maszyn zebranych przez trzy lata, wymóg jurysdykcyjny od działu zakupów klienta, mix dostawców, który się po prostu zdarzył, a nie został zaprojektowany. Pasuje gorzej, jeśli zaczynasz od zera, chcesz dokładnie jednej faktury i nie masz zdania, gdzie cokolwiek działa. Reseller albo pojedynczy hyperscaler będzie prostszy, i powinieneś wziąć to, co prostsze. Nikt nie potrzebuje multi-cloud control plane dla jednego konta i jedenastu serwerów.
Dwie rzeczy stają się ostrzejsze pod BYOC i zasługują na przemyślany projekt, a nie na dobre intencje. Pierwsza to izolacja: poświadczenia należą do organizacji, członkostwo dzieje się przez zaproszenie, a role decydują o tym, kto może wydawać pieniądze albo dotknąć firewalla - bo promień rażenia to tutaj prawdziwe konto produkcyjne, nie piaskownica. Druga to ślad audytowy. Każda akcja, którą platforma wykonuje w Twoim imieniu, powinna być zapisana append-only, z aktorem, zasobem i correlation ID, w formie, którą możesz wyeksportować. Delegujesz operacje, więc rekord tych operacji to jest to, co masz, zamiast tego, że zrobiłeś je sam.
Więc pytania warte zadania każdemu, kto sprzedaje Ci bring your own cloud. Czyje nazwisko widnieje na umowie z dostawcą? Co dokładnie może zrobić poświadczenie, które przekazałeś, i czy możesz zawęzić jego zakres? Co dzieje się z działającą infrastrukturą, jeśli przestaniesz im płacić jutro? Czy możesz wyeksportować log wszystkiego, co zrobili wewnątrz Twoich kont, i sprawdzić go niezależnie? Dobre odpowiedzi na te cztery pytania to jest to, co oddziela outsourcing operacji od outsourcingu infrastruktury - a tylko jedno z tych dwóch da się odwrócić we wtorek.