Ci sono due modi per far gestire la tua infrastruttura a qualcun altro. Nel primo, compri cloud da loro: loro detengono gli account provider, loro ricevono la fattura, tu ottieni una bolletta con ricarico e un indirizzo di supporto. Nel secondo - bring your own cloud, di solito abbreviato in BYOC - mantieni i tuoi account con Hetzner o AWS o OVHcloud, il tuo contratto, la tua fattura, e concedi a una piattaforma di gestione credenziali scoped per operarli per tuo conto. I due modelli sembrano simili in una demo e si comportano in modo completamente diverso il giorno in cui vuoi uscire.
Il modello di rivendita non è una truffa; è un business legittimo con vantaggi reali, soprattutto attorno a un'unica fattura e un unico posto dove lamentarsi. Ciò a cui rinunci è meno visibile. Il tuo rapporto contrattuale è con il rivenditore, non con il provider, quindi lo SLA che puoi effettivamente far valere è il loro. Sconti per uso impegnato, crediti startup e pricing negoziato passano tutti attraverso di loro. E l'identità della risorsa, l'account in cui i server risiedono realmente, appartiene a qualcun altro, il che significa che andarsene è una migrazione, non una cancellazione.
Cosa mantieni quando mantieni il contratto
Con BYOC il rapporto col provider resta dove un avvocato se lo aspetterebbe. Le istanze sono nel tuo account. I ticket di supporto li apri tu. La fattura arriva nel formato che il tuo team finance già riconcilia, da un'azienda su cui hai già fatto due diligence, sotto una giurisdizione su cui hai già ragionato. Se la tua postura di compliance dipende da chi opera legalmente un servizio - che, dopo Schrems II, è la domanda interessante, non dove si trovano fisicamente i server - non hai aggiunto un anello a quella catena adottando un control plane.
Il test dell'uscita rende la differenza concreta. Se la piattaforma di gestione sparisse dall'oggi al domani, cosa succede? Con la rivendita, i tuoi server sono in un account che non controlli e la risposta coinvolge degli avvocati. Con BYOC, i server continuano a girare esattamente come prima; hai perso una console, un inventario e un po' di automazione, il che è fastidioso ma non esistenziale. Quell'asimmetria vale più di qualsiasi elenco di funzionalità, ed è la prima cosa da verificare prima di firmare qualunque cosa.
Cosa richiede BYOC alla piattaforma
Il prezzo del modello è che la piattaforma ora detiene credenziali di produzione reali per account che non possiede. Quell'obbligo va preso alla lettera. Le credenziali sono cifrate a riposo con AES-256-GCM, scoped a una singola organizzazione, mai condivise tra tenant, e mai restituite in una risposta API - i campi sono privati in uscita quanto cifrati in entrata. Ognuno di questi è un requisito noioso che diventa interessante la prima volta che a un normale endpoint di lista viene chiesto di serializzare un record di credenziali.
Poi c'è la modalità di guasto che nessuno pianifica. Un job di provisioning arriva senza alcuna credenziale allegata: un bug, una race condition, un messaggio da una versione più vecchia di un servizio. Il comportamento allettante è ricadere sul token provider della piattaforma stessa così il job va a buon fine. Abbiamo rilasciato quel comportamento una volta e ha fatto esattamente ciò che era destinato a fare - ha creato una macchina reale sull'account della piattaforma stessa, fatturata alla parte sbagliata, invisibile nell'inventario del cliente. Il default ora è fail-closed. Un job senza credenziale viene rifiutato, e abilitare il fallback richiede un flag d'ambiente esplicito.
Dove il BYOC multi-provider diventa difficile
Un provider è un'integrazione; undici sono un problema di tassonomia. Sencai attualmente gestisce Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode di Akamai e Oracle Cloud, più server on-premise e bare metal tramite un host agent. Ciascuno di questi ha il proprio modello di autenticazione, il proprio sistema di quote, il proprio vocabolario, e una propria opinione su se un firewall appartenga a una macchina, a una rete o a un progetto. Normalizzare tutto questo senza mentire a riguardo è la maggior parte dell'ingegneria.
Il limite che cerchiamo di mantenere è che il control plane opera il provider, non una sua copia. Quando crei una rete, una regola firewall o una zona DNS in Sencai, la chiamata va all'API del provider e l'oggetto esiste lì - visibile nella loro console, cancellabile con la loro CLI, reale per chiunque non abbia mai sentito parlare di noi. Una piattaforma che registra solo l'intento nel proprio database produce un inventario molto convincente di cose che potrebbero non esistere.
La fatturazione segue la stessa logica. Poiché la fattura resta al provider, il compito della piattaforma non è fatturarti. È attribuzione e controllo. La spesa viene tracciata per organizzazione e progetto su tutti gli account collegati, con i limiti che imposti tu, così la domanda "quanto è costata la pipeline batch il mese scorso" ha una sola risposta invece di quattro export in quattro formati. Questa è anche la parte in cui BYOC è genuinamente più difficile della rivendita, perché non c'è un unico ledger da cui leggere; i numeri vanno estratti e riconciliati per ogni provider.
Per chi è pensato il bring your own cloud
Il BYOC è adatto a team con un parco che esiste già e vincoli già reali: qualche centinaio di macchine accumulate in tre anni, un requisito di giurisdizione dal team procurement di un cliente, un mix di provider che è successo invece di essere stato progettato. È meno adatto se parti da zero, vuoi esattamente una fattura, e non hai opinioni su dove gira qualcosa. Un rivenditore o un singolo hyperscaler saranno più semplici, e dovresti scegliere la cosa più semplice. Nessuno ha bisogno di un control plane multi-cloud per un account e undici server.
Due cose diventano più critiche con BYOC e meritano un design deliberato, non solo buone intenzioni. La prima è l'isolamento: le credenziali appartengono a un'organizzazione, l'appartenenza avviene per invito, e i ruoli decidono chi può spendere denaro o toccare un firewall - perché qui il raggio d'impatto è un vero account di produzione, non una sandbox. La seconda è l'audit trail. Ogni azione che la piattaforma compie per tuo conto dovrebbe essere registrata in modalità append-only, con l'attore, la risorsa e un correlation ID, in una forma che puoi esportare. Stai delegando delle operazioni, quindi il registro di quelle operazioni è ciò che hai al posto di averle fatte tu stesso.
Quindi, le domande che vale la pena porre a chiunque ti venda bring your own cloud. Di chi è il nome sul contratto col provider? Cosa può fare esattamente la credenziale che hai consegnato, e puoi limitarne lo scope? Cosa succede all'infrastruttura in esecuzione se smetti di pagarli domani? Puoi esportare il log di tutto ciò che hanno fatto dentro i tuoi account, e verificarlo in modo indipendente? Buone risposte a queste quattro domande sono ciò che separa l'esternalizzare le tue operazioni dall'esternalizzare la tua infrastruttura - e solo una delle due è reversibile in un martedì qualsiasi.