On kaksi tapaa antaa jonkun toisen operoida infrastruktuuriasi. Ensimmäisessä ostat pilven heiltä: he pitävät hallussaan palveluntarjoajatilit, he saavat laskun, sinä saat päällehinnoitellun laskun ja tukiosoitteen. Toisessa - bring your own cloud, yleensä lyhennettynä BYOC - pidät omat tilisi Hetznerillä tai AWS:llä tai OVHcloudilla, oman sopimuksesi, oman laskusi, ja myönnät hallinta-alustalle rajatut kredentiaalit operoidaksesi niitä puolestasi. Nämä kaksi mallia näyttävät samalta demossa eivätkä käyttäydy lainkaan samalla tavalla sinä päivänä, kun haluat lähteä.

Jälleenmyyntimalli ei ole huijaus; se on legitiimi liiketoiminta, jolla on todellisia etuja, lähinnä yhden laskun ja yhden valituspaikan ympärillä. Se, mistä luovut, on vähemmän näkyvää. Sopimussuhteesi on jälleenmyyjän kanssa, ei palveluntarjoajan, joten SLA, jota oikeasti voit valvoa, on heidän. Sitoumusalennukset, startup-krediitit ja neuvotellut hinnat kulkevat kaikki heidän kauttaan. Ja resurssi-identiteetti, se tili, jossa palvelimet oikeasti asuvat, kuuluu jollekulle muulle, mikä tarkoittaa, että lähteminen on migraatio eikä peruutus.

Mitä säilytät, kun säilytät sopimuksen

BYOC:n alla palveluntarjoajasuhde pysyy siellä, missä lakimies sen odottaisikin olevan. Instanssit ovat sinun tililläsi. Tukitiketit ovat sinun avattavissasi. Lasku saapuu formaatissa, jota talousosastosi jo täsmäyttää, yhtiöltä, jolle olet jo tehnyt due diligencen, lainkäyttöalueella, jota olet jo pohtinut. Jos compliance-asemasi riippuu siitä, kuka laillisesti operoi palvelua - mikä Schrems II:n jälkeen on se mielenkiintoinen kysymys, ei se, missä palvelimet fyysisesti sijaitsevat - et ole lisännyt uutta lenkkiä siihen ketjuun ottamalla käyttöön control planen.

Poistumistesti tekee erosta konkreettisen. Jos hallinta-alusta katoaisi yhdessä yössä, mitä tapahtuu? Jälleenmyynnin alla palvelimesi ovat tilillä, jota et hallitse, ja vastaus sisältää lakimiehiä. BYOC:n alla palvelimet jatkavat toimintaansa täsmälleen sellaisina kuin ne ovat; olet menettänyt konsolin, inventaarion ja hieman automaatiota, mikä on ärsyttävää muttei eksistentiaalista. Tuo epäsymmetria on enemmän arvoinen kuin mikään ominaisuuslista, ja se on ensimmäinen asia, joka kannattaa tarkistaa ennen minkään allekirjoittamista.

Mitä BYOC vaatii alustalta

Mallin hinta on se, että alusta pitää nyt hallussaan oikeita tuotantokredentiaaleja tileille, joita se ei omista. Tuo velvoite on otettava kirjaimellisesti. Kredentiaalit salataan levossa AES-256-GCM:llä, rajataan yhteen organisaatioon, niitä ei koskaan jaeta muiden vuokralaisten kesken, eikä niitä koskaan palauteta API-vastauksessa - kentät ovat private lähtiessä siinä missä salattuja tullessa. Jokainen näistä on tylsä vaatimus, josta tulee mielenkiintoinen ensimmäisellä kerralla, kun tavallista list-endpointia pyydetään serialisoimaan kredentiaalitietue.

Sitten on se vikatilanne, jota kukaan ei suunnittele. Provisiointityö saapuu ilman liitettyä kredentiaalia: bugi, race condition, viesti palvelun vanhemmasta versiosta. Houkutteleva käytös on pudota takaisin alustan omaan palveluntarjoajatokeniin, jotta työ onnistuu. Julkaisimme tuon käytöksen kerran, ja se teki tasan sen, minkä se aina oli tekevä - loi oikean koneen alustan omalle tilille, laskutettuna väärältä osapuolelta, näkymättömänä asiakkaan inventaariossa. Oletus on nyt fail-closed. Työ ilman kredentiaalia hylätään, ja fallbackin käyttöönotto vaatii eksplisiittisen ympäristölipun.

Missä moni-palveluntarjoaja-BYOC muuttuu vaikeaksi

Yksi palveluntarjoaja on integraatio; yksitoista on taksonomiaongelma. Sencai ajaa tällä hetkellä Hetzneriä, OVHcloudia, Scalewayta, UpCloudia, AWS:ää, Azurea, Google Cloudia, DigitalOceania, Vultria, Akamain Linodea ja Oracle Cloudia, sekä on-premise- ja bare-metal-palvelimia host-agentin kautta. Jokaisella niistä on oma autentikointimallinsa, oma kiintiöjärjestelmänsä, oma sanastonsa, ja oma näkemyksensä siitä, kuuluuko palomuuri koneelle, verkolle vai projektille. Sen normalisointi valehtelematta siitä on suurin osa insinöörityötä.

Raja, jota yritämme pitää, on se, että control plane operoi palveluntarjoajaa, ei sen kopiota. Kun luot verkon, palomuurisäännön tai DNS-vyöhykkeen Sencaissa, kutsu menee palveluntarjoajan API:in ja objekti on olemassa siellä - näkyvissä heidän konsolissaan, poistettavissa heidän CLI:llään, todellinen kenelle tahansa, joka ei ole koskaan kuullut meistä. Alusta, joka tallentaa vain aikomuksen omaan tietokantaansa, tuottaa hyvin vakuuttavan inventaarion asioista, joita ei ehkä ole olemassa.

Laskutus noudattaa samaa logiikkaa. Koska lasku pysyy palveluntarjoajalla, alustan tehtävä ei ole laskuttaa sinua. Se on attribuutio ja kontrolli. Kulutusta seurataan organisaatio- ja projektikohtaisesti jokaisen yhdistetyn tilin yli, sinun asettamillasi katoilla, joten kysymyksellä "mitä eräajoputki maksoi viime kuussa" on yksi vastaus neljän formaatin neljän viennin sijaan. Tämä on myös se osa, jonka BYOC tekee aidosti vaikeammaksi kuin jälleenmyynti, koska yhtä pääkirjaa ei ole, josta lukea; luvut on haettava ja täsmäytettävä palveluntarjoajakohtaisesti.

Kenelle bring your own cloud on tarkoitettu

BYOC sopii tiimeille, joilla on jo olemassa oleva kalusto ja jo todellisia rajoitteita: muutama sata konetta, jotka ovat kertyneet kolmen vuoden aikana, lainkäyttöaluevaatimus asiakkaan hankintatiimiltä, palveluntarjoajayhdistelmä, joka syntyi eikä suunniteltu. Se sopii huonommin, jos olet greenfield, haluat tasan yhden laskun, eikä sinulla ole mielipidettä siitä, missä mikäkin ajetaan. Jälleenmyyjä tai yksi ainoa hyperscaler on yksinkertaisempi, ja sinun kannattaa ottaa se yksinkertaisempi vaihtoehto. Kukaan ei tarvitse multi-cloud-control planea yhdelle tilille ja yhdelletoista palvelimelle.

Kaksi asiaa terävöityy BYOC:n alla ja ansaitsevat tarkoituksellisen suunnittelun hyvien aikomusten sijaan. Ensimmäinen on eristys: kredentiaalit kuuluvat organisaatiolle, jäsenyys tapahtuu kutsulla, ja roolit päättävät, kuka voi käyttää rahaa tai koskea palomuuriin - koska blast radius tässä on oikea tuotantotili, ei hiekkalaatikko. Toinen on auditointiloki. Jokainen toiminto, jonka alusta tekee puolestasi, pitäisi tallentaa vain-lisäys-periaatteella, tekijän, resurssin ja correlation ID:n kanssa, muodossa, jonka voit viedä. Delegoit operaatioita, joten näiden operaatioiden tietue on se, mikä sinulla on sen sijaan, että olisit tehnyt ne itse.

Joten kysymykset, jotka kannattaa kysyä keneltä tahansa, joka myy sinulle bring your own cloudia. Kenen nimi on palveluntarjoajasopimuksessa? Mitä täsmälleen kredentiaali, jonka luovutit, voi tehdä, ja voitko rajata sitä pienemmäksi? Mitä käyvälle infrastruktuurille tapahtuu, jos lopetat maksamasta heille huomenna? Voitko viedä lokin kaikesta, mitä he tekivät tileilläsi, ja tarkistaa sen itsenäisesti? Hyvät vastaukset noihin neljään erottavat operaatioidesi ulkoistamisen infrastruktuurisi ulkoistamisesta - ja vain toinen niistä on peruutettavissa tiistaina.