Există două moduri de a lăsa pe altcineva să-ți opereze infrastructura. În primul, cumperi cloud de la ei: ei dețin conturile la furnizor, ei primesc factura, tu primești o factură cu adaos și o adresă de suport. În al doilea - bring your own cloud, de obicei prescurtat BYOC - îți păstrezi propriile conturi la Hetzner sau AWS sau OVHcloud, propriul contract, propria factură, și acorzi unei platforme de management credențiale limitate ca domeniu ca să le opereze în numele tău. Cele două modele arată similar într-un demo și se comportă complet diferit în ziua în care vrei să pleci.

Modelul de resell nu e o escrocherie; e o afacere legitimă cu avantaje reale, mai ales în jurul unei singure facturi și a unui singur loc unde te poți plânge. Ce cedezi e mai puțin vizibil. Relația ta contractuală e cu resellerul, nu cu furnizorul, deci SLA-ul pe care îl poți impune de fapt e al lor. Discounturile de committed-use, creditele de startup și prețurile negociate trec toate prin ei. Iar identitatea resursei, contul în care trăiesc de fapt serverele, aparține altcuiva, ceea ce înseamnă că plecarea e o migrare, nu o anulare.

Ce păstrezi când păstrezi contractul

Sub BYOC, relația cu furnizorul rămâne exact unde s-ar aștepta un avocat. Instanțele sunt în contul tău. Tichetele de suport sunt ale tale, de deschis. Factura sosește în formatul pe care echipa ta financiară deja îl reconciliază, de la o companie pentru care ai deja făcut diligence, sub o jurisdicție la care ai deja reflectat. Dacă postura ta de conformitate depinde de cine operează legal un serviciu - ceea ce, după Schrems II, e întrebarea interesantă, nu unde stau fizic serverele - n-ai adăugat o verigă la acel lanț adoptând un control plane.

Testul de ieșire face diferența concretă. Dacă platforma de management ar dispărea peste noapte, ce se întâmplă? Sub resell, serverele tale sunt într-un cont pe care nu-l controlezi, iar răspunsul implică avocați. Sub BYOC, serverele continuă să ruleze exact așa cum sunt; ai pierdut o consolă, un inventar și niște automatizare, ceea ce e enervant, nu existențial. Asimetria asta valorează mai mult decât orice listă de funcționalități, și e primul lucru de verificat înainte de a semna orice.

Ce cere BYOC de la platformă

Prețul modelului e că platforma deține acum credențiale reale de producție pentru conturi pe care nu le deține. Obligația asta trebuie luată literal. Credențialele sunt criptate la rest cu AES-256-GCM, limitate la o singură organizație, niciodată partajate între tenanți, și niciodată returnate într-un răspuns API - câmpurile sunt private la ieșire, la fel cum sunt criptate la intrare. Fiecare din astea e o cerință plictisitoare care devine interesantă prima dată când un endpoint obișnuit de listare e rugat să serializeze o înregistrare de credențiale.

Apoi există modul de eșec pe care nimeni nu-l planifică. Un job de provisioning sosește fără nicio credențială atașată: un bug, o race condition, un mesaj de la o versiune mai veche a unui serviciu. Comportamentul tentant e să cazi înapoi pe tokenul propriu al platformei ca jobul să reușească. Am livrat acel comportament o dată și a făcut exact ce urma mereu să facă - a creat o mașină reală pe contul propriu al platformei, facturată către partea greșită, invizibilă în inventarul clientului. Default-ul e acum fail-closed. Un job fără credențială e refuzat, iar activarea fallback-ului necesită un flag explicit de mediu.

Unde BYOC multi-provider devine dificil

Un furnizor e o integrare; unsprezece e o problemă de taxonomie. Sencai operează în prezent Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode de la Akamai și Oracle Cloud, plus servere on-premise și bare-metal printr-un agent gazdă. Fiecare dintre ele are propriul model de autentificare, propriul sistem de cote, propriul vocabular și propria opinie despre dacă un firewall aparține unei mașini, unei rețele sau unui proiect. Normalizarea asta fără să minți despre ea e cea mai mare parte a ingineriei.

Linia pe care încercăm s-o ținem e că control plane-ul operează furnizorul, nu o copie a lui. Când creezi o rețea, o regulă de firewall sau o zonă DNS în Sencai, apelul merge la API-ul furnizorului, iar obiectul există acolo - vizibil în consola lor, ștergibil cu CLI-ul lor, real pentru oricine n-a auzit niciodată de noi. O platformă care doar înregistrează intenția în propria bază de date produce un inventar foarte convingător de lucruri care poate nu există.

Facturarea urmează aceeași logică. Pentru că factura rămâne la furnizor, treaba platformei nu e să te factureze. E atribuire și control. Cheltuiala e urmărită per organizație și proiect, pe fiecare cont conectat, cu plafoane pe care le setezi tu, deci întrebarea „cât a costat pipeline-ul batch luna trecută” are un singur răspuns în loc de patru exporturi în patru formate. Asta e și partea în care BYOC face lucrurile genuin mai grele decât resell-ul, pentru că nu există un singur registru din care să citești; numerele trebuie extrase și reconciliate per furnizor.

Pentru cine e bring your own cloud

BYOC se potrivește echipelor cu o infrastructură care există deja și constrângeri deja reale: câteva sute de mașini acumulate în trei ani, o cerință de jurisdicție de la echipa de achiziții a unui client, un mix de furnizori care s-a întâmplat, nu a fost proiectat. Se potrivește mai prost dacă ești greenfield, vrei exact o factură și n-ai nicio opinie despre unde rulează orice. Un reseller sau un singur hyperscaler va fi mai simplu, și ar trebui să alegi lucrul mai simplu. Nimeni n-are nevoie de un control plane multi-cloud pentru un cont și unsprezece servere.

Două lucruri devin mai ascuțite sub BYOC și merită un design deliberat, nu bune intenții. Primul e izolarea: credențialele aparțin unei organizații, apartenența se întâmplă prin invitație, iar rolurile decid cine poate cheltui bani sau atinge un firewall - pentru că blast radius-ul aici e un cont real de producție, nu un sandbox. Al doilea e audit trail-ul. Fiecare acțiune pe care platforma o face în numele tău ar trebui înregistrată append-only, cu actorul, resursa și un ID de corelare, într-o formă pe care o poți exporta. Delegi operațiuni, deci înregistrarea acelor operațiuni e ce ai în loc să le fi făcut tu însuți.

Deci, întrebările care merită puse oricui îți vinde bring your own cloud. Al cui nume e pe contractul cu furnizorul? Ce poate face exact credențiala pe care ai predat-o, și o poți limita mai mult? Ce se întâmplă cu infrastructura care rulează dacă te oprești din plătit mâine? Poți exporta jurnalul a tot ce au făcut în interiorul conturilor tale, și-l poți verifica independent? Răspunsuri bune la aceste patru întrebări sunt ce separă externalizarea operațiunilor tale de externalizarea infrastructurii tale - și doar una dintre astea e reversibilă marțea viitoare.