BYOC (Bring Your Own Cloud)
BYOC (Bring Your Own Cloud) er en modell der kunden kobler til sin eksisterende skyleverandørkonto i stedet for å migrere til en leverandørs egen infrastruktur eller en forhandlers konto. Kontoen, kontrakten og faktureringsforholdet forblir hos kunden og leverandøren hele veien; leverandøren administrerer ressurser inne i den fremfor å eie dem.
BYOC beskriver hvem som juridisk eier skykontoen en gitt infrastruktur kjører i, ikke hvem som drifter den fra dag til dag. I en BYOC-ordning beholder organisasjonen sin egen konto hos en skyleverandør — Amazon Web Services, Google Cloud, Hetzner eller en annen — sammen med kontrakten og fakturaen som følger med. En separat leverandør, for eksempel en administrasjonsplattform, et overvåkingsverktøy eller en managed-service-leverandør, får avgrenset tilgang til å operere inne i den kontoen: provisjonere ressurser, sette opp konfigurasjon eller samle inn telemetri. Ingenting ved den underliggende regnekraften, lagringen eller nettverket flyttes. Begrepet oppstod i sammenhenger knyttet til administrerte databaser og SaaS, der «bring your own cloud» skiller en driftssetting som kjører inne i kundens egen konto, fra en som er vertet utelukkende på leverandørens egen infrastruktur.
Alternativet er en fullt administrert modell eller en forhandlermodell, der leverandøren har sin egen konto hos den underliggende leverandøren og enten videreselger kapasitet til kundene eller migrerer arbeidsbelastningene deres over til infrastruktur den selv eier fullt ut. Den modellen kan forenkle fakturering — én leverandør, én faktura — men den betyr også at kundens infrastruktur befinner seg inne i en annens konto. Å bytte leverandør, forhandle leverandørpriser direkte, eller overfor en revisor bevise nøyaktig hvilken enhet som innehar den underliggende kontrakten, blir alt sammen vanskeligere. BYOC holder det skillet intakt: kunden kan når som helst tilbakekalle leverandørens tilgang på leverandørnivå, og den underliggende kontoen, dens faktureringshistorikk og dens compliance-status skifter aldri eier.
I praksis gis BYOC-tilgang gjennom API-legitimasjon eller en rolle leverandøren tildeles inne i kundens konto, avgrenset til det den faktisk trenger og som kan tilbakekalles uavhengig av selve leverandørforholdet. Avveiningen er operasjonell: det er kunden, ikke leverandøren, som forblir den kontraherende parten overfor hver skyleverandør, så flere leverandører betyr flere kontrakter og fakturaer med mindre noe over kontonivået konsoliderer dem. Leverandører som støtter BYOC, støtter som regel også den motsatte modellen — å provisjonere og fakturere kapasitet under sin egen konto på vegne av kunden — slik at en organisasjon kan blande begge deler, avhengig av hvilke ressurser den vil holde under direkte leverandørkontrakt og hvilke den er komfortabel med å delegere fullstendig.
Hvorfor BYOC er viktig
Lock-in er den sentrale risikoen BYOC adresserer. Når infrastrukturen ligger inne i en leverandørs egen konto, betyr det å forlate den leverandøren å migrere arbeidsbelastninger — et prosjekt som måles i uker eller måneder, ikke en supportsak. BYOC gjør en exit til en tilgangsendring: tilbakekall leverandørens legitimasjon, og infrastrukturen står nøyaktig der den sto, under samme kontrakt. Dette betyr mest der den underliggende kontoen, ikke bare dataene, har compliance-vekt — regulerte bransjer der en bestemt juridisk enhet må forbli den behandlingsansvarliges direkte kontraktspart med infrastrukturleverandøren, eller anskaffelsesregler i offentlig sektor som krever at den kjøpende organisasjonen har sin egen skykontrakt fremfor en underleverandørkontrakt. Det bevarer også eventuell volumprising eller enterprise-avtale organisasjonen allerede har forhandlet direkte frem med sin skyleverandør.
Hvordan Sencai håndterer BYOC
Sencai støtter BYOC som en av to modeller som eksisterer side om side i samme organisasjon. Koble til en eksisterende konto, og ingenting flyttes: legitimasjon er kryptert i hvile, du kan tilbakekalle tilgangen hos leverandøren når som helst, og i det øyeblikket kontoen kobles til, kartlegger Sencai det som allerede kjører — instanser, nettverk, lagring, DNS — på tvers av alle tilkoblede leverandører, med ressurs-for-ressurs-innmelding til aktiv administrasjon. Kontoen, kontrakten og fakturaen forblir hos leverandøren din hele veien. Hvis du heller ikke vil ha en direkte leverandørkontrakt, kan Sencai i stedet provisjonere og fakturere kapasitet under sin egen konto — én faktura, leverandørkostnad pluss en margin på 2 % vist separat på fakturaen — og du kan blande begge modellene etter hvert som behovene endrer seg.
Se hvordan inventar og provisjonering fungerer →