Nechat si infrastrukturu provozovat někým jiným jde dvěma způsoby. V prvním od něj cloud kupujete: účty u providerů drží on, faktura chodí jemu, vy dostanete přeprodanou fakturu a kontakt na podporu. Ve druhém - bring your own cloud, zkráceně BYOC - si držíte vlastní účty u Hetzneru, AWS nebo OVHcloudu, vlastní smlouvu, vlastní fakturu, a management platformě dáte omezené credentials, aby je za vás obsluhovala. V demu vypadají oba modely podobně a v den, kdy budete chtít pryč, se chovají úplně jinak.

Přeprodej není podvod; je to legitimní byznys s reálnými výhodami, hlavně kolem jedné faktury a jednoho místa, kam si stěžovat. Co ztrácíte, je hůř vidět. Smluvní vztah máte s přeprodejcem, ne s providerem, takže SLA, které reálně vymáháte, je jeho. Committed-use slevy, startupové kredity i vyjednané ceny jdou přes něj. A identita zdrojů - účet, ve kterém ty servery skutečně žijí - patří někomu jinému, což znamená, že odchod není výpověď, ale migrace.

Co vám zůstane, když si necháte smlouvu

Pod BYOC zůstává vztah s providerem tam, kde by ho právník čekal. Instance jsou ve vašem účtu. Tikety na podporu otevíráte vy. Faktura chodí ve formátu, který vaše finanční oddělení už umí spárovat, od firmy, na kterou už jste udělali due diligence, pod jurisdikcí, kterou už jste si promysleli. Pokud váš compliance postoj závisí na tom, kdo službu právně provozuje - což je po Schrems II ta zajímavá otázka, ne kde fyzicky stojí servery - nasazením control plane jste do toho řetězce nepřidali další článek.

Rozdíl zkonkrétní test odchodu. Co se stane, když management platforma přes noc zmizí? U přeprodeje jsou vaše servery v účtu, který neovládáte, a v odpovědi figurují právníci. U BYOC servery běží dál přesně tak, jak běžely; přišli jste o konzoli, inventář a kus automatizace, což je otravné, ne existenční. Ta asymetrie má větší cenu než jakýkoliv seznam funkcí a je to první věc, kterou stojí za to ověřit, než cokoliv podepíšete.

Co BYOC vyžaduje od platformy

Cenou toho modelu je, že platforma teď drží reálné produkční credentials k účtům, které nevlastní. Ten závazek se musí brát doslova. Credentials jsou at-rest šifrované AES-256-GCM, vázané na jednu organizaci, nikdy sdílené mezi tenanty a nikdy nevracené v API odpovědi - ta pole jsou private na cestě ven stejně jako šifrovaná na cestě dovnitř. Každý z těch bodů je nudný požadavek, který se stane zajímavým v okamžiku, kdy má úplně obyčejný list endpoint serializovat záznam s credentialem.

A pak je tu selhání, se kterým nikdo nepočítá. Přijde provisioning job bez připojeného credentialu - chyba, race, zpráva ze starší verze služby. Lákavé chování je sáhnout po vlastním providerském tokenu platformy, aby job prošel. Tohle jsme jednou nasadili a udělalo to přesně to, co udělat mělo: vytvořilo reálný stroj na vlastním účtu platformy, účtovaný špatné straně, neviditelný v zákazníkově inventáři. Výchozí chování je dnes fail-closed. Job bez credentialu se odmítne a zapnutí fallbacku vyžaduje explicitní proměnnou prostředí.

Kde je vícecloudové BYOC těžké

Jeden provider je integrace; jedenáct je taxonomický problém. Sencai dnes řídí Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode od Akamai a Oracle Cloud, plus on-premise a bare-metal servery přes host agenta. Každý z nich má vlastní autentizační model, vlastní kvóty, vlastní slovník a vlastní názor na to, jestli firewall patří ke stroji, k síti, nebo k projektu. Sjednotit to, aniž byste o tom lhali, je většina té inženýrské práce.

Hranice, kterou se snažíme držet, je, že control plane obsluhuje providera, ne jeho kopii. Když v Sencai vytvoříte síť, pravidlo firewallu nebo DNS zónu, volání jde do API providera a ten objekt tam skutečně vznikne - je vidět v jeho konzoli, smazatelný jeho CLI, reálný pro každého, kdo o nás nikdy neslyšel. Platforma, která si jen zapíše záměr do vlastní databáze, vyrobí velmi přesvědčivý inventář věcí, které nemusí existovat.

Billing jde stejnou logikou. Protože faktura zůstává u providera, úkolem platformy není fakturovat vám. Je to atribuce a kontrola. Útrata se sleduje po organizacích a projektech napříč všemi připojenými účty, se stropy, které si nastavíte, takže otázka „kolik nás minulý měsíc stála batch pipeline“ má jednu odpověď, ne čtyři exporty ve čtyřech formátech. Tohle je zároveň část, kterou BYOC dělá reálně těžší než přeprodej, protože neexistuje jedna účetní kniha ke čtení; čísla se musí tahat a párovat per provider.

Pro koho je bring your own cloud

BYOC sedí týmům, které už mají estate a už mají reálná omezení: pár stovek strojů nahromaděných za tři roky, jurisdikční požadavek od procurementu zákazníka, mix providerů, který spíš vznikl, než byl navržen. Sedí hůř, pokud stavíte na zelené louce, chcete přesně jednu fakturu a nemáte názor na to, kde co běží. Přeprodejce nebo jeden hyperscaler bude jednodušší a měli byste vzít to jednodušší. Nikdo nepotřebuje multicloudový control plane na jeden účet a jedenáct serverů.

Dvě věci se pod BYOC zostřují a zaslouží si vědomý návrh, ne dobré úmysly. První je izolace: credentials patří organizaci, členství vzniká pozvánkou a role rozhodují, kdo smí utrácet peníze nebo sahat na firewall - protože blast radius je tady reálný produkční účet, ne sandbox. Druhá je audit trail. Každá akce, kterou platforma za vás udělá, má být zaznamenaná append-only, s actorem, zdrojem a correlation ID, ve formě, kterou si vyexportujete. Delegujete provoz, takže záznam o tom provozu je to, co máte místo toho, že jste to udělali sami.

Takže otázky, které stojí za to položit každému, kdo vám prodává bring your own cloud. Čí jméno je na smlouvě s providerem? Co přesně umí credential, který jste jim předali, a jde zúžit? Co se stane s běžící infrastrukturou, když jim zítra přestanete platit? Jde vyexportovat záznam všeho, co ve vašich účtech udělali, a nezávisle si ho ověřit? Dobré odpovědi na tyhle čtyři jsou to, co odděluje outsourcing provozu od outsourcingu infrastruktury - a vratná je jen jedna z těch dvou věcí.