Det finns två sätt att låta någon annan driva din infrastruktur. I det första köper du moln av dem: de innehar leverantörskontona, de får fakturan, du får en påslagen räkning och en supportadress. I det andra - bring your own cloud, oftast förkortat BYOC - behåller du dina egna konton hos Hetzner eller AWS eller OVHcloud, ditt eget avtal, din egen faktura, och du beviljar en hanteringsplattform avgränsade autentiseringsuppgifter för att driva dem å dina vägnar. De två modellerna ser lika ut i en demo och beter sig inte alls likadant den dag du vill ur.
Återförsäljarmodellen är inte en bluff; det är en legitim affärsmodell med verkliga fördelar, mest kring en enda faktura och ett enda ställe att klaga hos. Det du ger upp är mindre synligt. Din avtalsrelation är med återförsäljaren, inte leverantören, så det SLA du faktiskt kan hävda är deras. Rabatter för bunden användning, startup-krediter och förhandlade priser går alla via dem. Och resursidentiteten, kontot servrarna faktiskt bor i, tillhör någon annan, vilket betyder att att lämna blir en migrering snarare än en uppsägning.
Vad du behåller när du behåller avtalet
Under BYOC förblir leverantörsrelationen precis där en jurist skulle förvänta sig den. Instanserna finns i ditt konto. Supportärendena är dina att öppna. Fakturan kommer i det format din ekonomiavdelning redan avstämmer, från ett bolag du redan har granskat, under en jurisdiktion du redan har resonerat kring. Om din efterlevnadsposition beror på vem som juridiskt driver en tjänst - vilket, efter Schrems II, är den intressanta frågan snarare än var servrarna fysiskt står - har du inte lagt till en länk i den kedjan genom att anta ett control plane.
Exit-testet gör skillnaden konkret. Om hanteringsplattformen försvann över en natt, vad händer? Under återförsäljning finns dina servrar i ett konto du inte kontrollerar, och svaret involverar jurister. Under BYOC fortsätter servrarna köra precis som förut; du har förlorat en konsol, en inventering och en del automatisering, vilket är irriterande snarare än existentiellt. Den asymmetrin är värd mer än vilken funktionslista som helst, och det är det första du bör kontrollera innan du skriver under något.
Vad BYOC kräver av plattformen
Priset för modellen är att plattformen nu förvarar riktiga produktionsautentiseringsuppgifter för konton den inte äger. Den skyldigheten måste tas bokstavligt. Autentiseringsuppgifter krypteras i vila med AES-256-GCM, avgränsas till en enda organisation, delas aldrig mellan tenants, och returneras aldrig i ett API-svar - fälten är privata på väg ut precis lika mycket som de är krypterade på väg in. Vart och ett av de här är ett trist krav som blir intressant första gången en vanlig list-endpoint ombeds serialisera en autentiseringspost.
Sedan finns felläget ingen planerar för. Ett provisioneringsjobb dyker upp utan autentiseringsuppgift bifogad: en bugg, en kapplöpning, ett meddelande från en äldre version av en tjänst. Den lockande lösningen är att falla tillbaka på plattformens egen leverantörstoken så att jobbet lyckas. Vi levererade det beteendet en gång, och det gjorde precis vad det alltid skulle göra - skapade en riktig maskin på plattformens eget konto, fakturerad till fel part, osynlig i kundens inventering. Standarden är nu fail-closed. Ett jobb utan autentiseringsuppgift avvisas, och att aktivera fallbacken kräver en uttrycklig miljöflagga.
Där BYOC med flera leverantörer blir svårt
En leverantör är en integration; elva är ett taxonomiproblem. Sencai driver för närvarande Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamais Linode och Oracle Cloud, plus on-prem- och bare-metal-servrar via en värdagent. Var och en av dem har sin egen autentiseringsmodell, sitt eget kvotsystem, sitt eget vokabulär, och sin egen uppfattning om huruvida en brandvägg tillhör en maskin, ett nätverk eller ett projekt. Att normalisera det utan att ljuga om det är merparten av ingenjörsarbetet.
Gränsen vi försöker hålla är att control plane driver leverantören snarare än en kopia av den. När du skapar ett nätverk, en brandväggsregel eller en DNS-zon i Sencai går anropet till leverantörens API och objektet finns där - synligt i deras konsol, raderbart med deras CLI, verkligt för vem som helst som aldrig hört talas om oss. En plattform som bara registrerar avsikt i sin egen databas producerar en mycket övertygande inventering av saker som kanske inte existerar.
Fakturering följer samma logik. Eftersom fakturan stannar hos leverantören är plattformens jobb inte att fakturera dig. Det är attribuering och kontroll. Kostnader spåras per organisation och projekt över varje anslutet konto, med tak du själv sätter, så frågan "vad kostade batch-pipelinen förra månaden" har ett svar istället för fyra exporter i fyra format. Det här är också den del BYOC gör genuint svårare än återförsäljning, eftersom det inte finns en enda huvudbok att läsa ur; siffrorna måste hämtas och stämmas av per leverantör.
Vem bring your own cloud passar för
BYOC passar team med ett bestånd som redan finns och begränsningar som redan är verkliga: några hundra maskiner som samlats på tre år, ett jurisdiktionskrav från en kunds inköpsavdelning, en leverantörsmix som bara blev till snarare än designades. Det passar sämre om du startar från noll, vill ha exakt en faktura, och inte har någon uppfattning om var något ska köras. En återförsäljare eller en enda hyperscaler blir enklare, och du bör välja det enklare. Ingen behöver ett multi-cloud control plane för ett konto och elva servrar.
Två saker blir skarpare under BYOC och förtjänar medveten design snarare än goda avsikter. Den första är isolering: autentiseringsuppgifter tillhör en organisation, medlemskap sker genom inbjudan, och roller avgör vem som kan spendera pengar eller röra vid en brandvägg - för blast radius här är ett riktigt produktionskonto, inte en sandlåda. Den andra är granskningsspåret. Varje åtgärd plattformen utför å dina vägnar bör registreras append-only, med aktören, resursen och ett korrelations-ID, i ett format du kan exportera. Du delegerar drift, så journalen över den driften är det du har istället för att ha gjort den själv.
Så, frågorna värda att ställa till vem som helst som säljer dig bring your own cloud. Vems namn står på leverantörsavtalet? Vad exakt kan autentiseringsuppgiften du lämnade över göra, och kan du avgränsa den ytterligare? Vad händer med den körande infrastrukturen om du slutar betala dem imorgon? Kan du exportera loggen över allt de gjorde inuti dina konton, och kontrollera den oberoende? Bra svar på de här fyra är det som skiljer att lägga ut din drift från att lägga ut din infrastruktur - och bara en av de två går att ångra en tisdag.