Det finnes to måter å la noen andre drifte infrastrukturen din. I den første kjøper du sky fra dem: de eier leverandørkontoene, de får fakturaen, du får en påslagsfaktura og en support-adresse. I den andre - bring your own cloud, som regel forkortet BYOC - beholder du dine egne kontoer hos Hetzner eller AWS eller OVHcloud, din egen kontrakt, din egen faktura, og gir en administrasjonsplattform avgrensede credentials til å drifte dem på dine vegne. De to modellene ser like ut i en demo og oppfører seg helt forskjellig den dagen du vil ut.

Videresalgsmodellen er ikke svindel; det er en legitim forretningsmodell med reelle fordeler, hovedsakelig rundt én samlet faktura og ett sted å klage. Det du gir opp er mindre synlig. Det kontraktsmessige forholdet ditt er med videreselgeren, ikke leverandøren, så den SLA-en du faktisk kan håndheve er deres. Committed-use-rabatter, oppstartskreditter og forhandlet prising ruter alt sammen gjennom dem. Og ressursidentiteten, kontoen serverne faktisk bor i, tilhører noen andre, noe som betyr at det å forlate er en migrering fremfor en oppsigelse.

Hva du beholder når du beholder kontrakten

Under BYOC forblir leverandørforholdet der en advokat ville forvente det. Instansene er i din konto. Support-sakene er dine å åpne. Fakturaen kommer i formatet regnskapsteamet ditt allerede avstemmer, fra et selskap du allerede har gjort due diligence på, under en jurisdiksjon du allerede har vurdert. Hvis compliance-posisjonen din avhenger av hvem som juridisk drifter en tjeneste - som, etter Schrems II, er det interessante spørsmålet fremfor hvor serverne fysisk står - har du ikke lagt til et ledd i den kjeden ved å ta i bruk en kontrollplan.

Exit-testen gjør forskjellen konkret. Hvis administrasjonsplattformen forsvant over natten, hva skjer? Under videresalg er serverne dine i en konto du ikke kontrollerer, og svaret involverer advokater. Under BYOC fortsetter serverne å kjøre nøyaktig som de er; du har mistet en konsoll, et inventar og noe automatisering, som er irriterende fremfor eksistensielt. Den asymmetrien er verdt mer enn noen funksjonsliste, og det er det første å sjekke før du signerer noe som helst.

Hva BYOC krever av plattformen

Prisen for modellen er at plattformen nå har reelle produksjons-credentials for kontoer den ikke eier. Den forpliktelsen må tas bokstavelig. Credentials krypteres i hvile med AES-256-GCM, avgrenset til én enkelt organisasjon, aldri delt på tvers av tenants, og aldri returnert i et API-svar - feltene er private på vei ut like mye som de er krypterte på vei inn. Hvert av disse er et kjedelig krav som blir interessant første gang et vanlig liste-endepunkt blir bedt om å serialisere en credential-post.

Så er det feilmodusen ingen planlegger for. En provisjoneringsjobb kommer inn uten noen tilknyttet credential: en bug, en race, en melding fra en eldre versjon av en tjeneste. Den fristende oppførselen er å falle tilbake på plattformens egen leverandørtoken slik at jobben lykkes. Vi shippet den oppførselen én gang, og den gjorde nøyaktig det den alltid kom til å gjøre - opprettet en reell maskin på plattformens egen konto, fakturert til feil part, usynlig i kundens inventar. Standarden er nå fail-closed. En jobb uten credential avvises, og å slå på fallback-en krever et eksplisitt miljøflagg.

Hvor BYOC med flere leverandører blir vanskelig

Én leverandør er en integrasjon; elleve er et taksonomiproblem. Sencai driver i dag Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamais Linode og Oracle Cloud, pluss on-premise- og bare-metal-servere gjennom en host-agent. Hver av disse har sin egen autentiseringsmodell, sitt eget kvotesystem, sitt eget vokabular, og sin egen oppfatning om hvorvidt en brannmur tilhører en maskin, et nettverk eller et prosjekt. Å normalisere det uten å lyve om det er mesteparten av ingeniørarbeidet.

Linjen vi prøver å holde er at kontrollplanen drifter leverandøren fremfor en kopi av den. Når du oppretter et nettverk, en brannmurregel eller en DNS-sone i Sencai, går kallet til leverandørens API, og objektet finnes der - synlig i konsollen deres, slettbart med CLI-en deres, reelt for alle som aldri har hørt om oss. En plattform som bare journalfører intensjon i sin egen database, produserer et svært overbevisende inventar av ting som kanskje ikke finnes.

Fakturering følger samme logikk. Fordi fakturaen blir hos leverandøren, er ikke plattformens jobb å fakturere deg. Det er attribusjon og kontroll. Forbruk spores per organisasjon og prosjekt på tvers av hver tilkoblet konto, med tak du setter, slik at spørsmålet «hva kostet batch-pipelinen forrige måned» har ett svar i stedet for fire eksporter i fire formater. Dette er også delen BYOC gjør genuint vanskeligere enn videresalg, fordi det ikke finnes én samlet hovedbok å lese fra; tallene må hentes og avstemmes per leverandør.

Hvem bring your own cloud passer for

BYOC passer team med en infrastruktur som allerede finnes og begrensninger som allerede er reelle: noen hundre maskiner samlet opp over tre år, et jurisdiksjonskrav fra en kundes innkjøpsavdeling, en leverandørmiks som oppsto fremfor ble designet. Det passer dårligere hvis du starter fra scratch, ønsker nøyaktig én faktura, og ikke har noen mening om hvor noe kjører. En videreselger eller en enkelt hyperscaler vil være enklere, og du bør velge det enklere. Ingen trenger en multi-cloud-kontrollplan for én konto og elleve servere.

To ting blir skarpere under BYOC og fortjener bevisst design fremfor gode intensjoner. Det første er isolasjon: credentials tilhører en organisasjon, medlemskap skjer ved invitasjon, og roller avgjør hvem som kan bruke penger eller røre en brannmur - fordi eksplosjonsradiusen her er en reell produksjonskonto, ikke en sandkasse. Det andre er revisjonssporet. Hver handling plattformen tar på dine vegne bør journalføres append-only, med aktøren, ressursen og en korrelasjons-ID, i en form du kan eksportere. Du delegerer drift, så journalen over den driften er det du har i stedet for å ha gjort det selv.

Så, spørsmålene verdt å stille alle som selger deg bring your own cloud. Hvem sitt navn står på leverandørkontrakten? Hva kan credential-en du ga fra deg egentlig gjøre, og kan du avgrense den? Hva skjer med den kjørende infrastrukturen hvis du slutter å betale dem i morgen? Kan du eksportere loggen over alt de gjorde inne i kontoene dine, og sjekke den uavhengig? Gode svar på de fire er det som skiller å sette ut driften fra å sette ut infrastrukturen - og bare én av dem er reversibel på en tirsdag.