Chiedi a dieci team infrastrutturali se hanno una cloud exit strategy e nove risponderanno di sì. Chiedi in cosa consista e di solito ottieni una pagina wiki scritta durante una vendor review, che elenca quali servizi sono proprietari e quali portabili. Questo è un inventario, non una strategia. Il vero test è meno comodo: se il tuo provider raddoppiasse i prezzi, cambiasse giurisdizione o sospendesse il tuo account un martedì mattina, quante settimane ti servirebbero per servire traffico altrove - e chi nel tuo team saprebbe rispondere senza aprire un foglio di calcolo?
La pressione normativa qui è reale, ma non è la parte interessante. Il Data Act sta eliminando le commissioni di uscita, il che toglie all'ufficio finanziario la sua scusa. Schrems II e il CLOUD Act hanno tolto quella legale anni fa. Ciò che resta è la realtà ingegneristica, e nessuna direttiva la risolve. Un regolatore può rendere l'uscita più economica sulla carta; non può far funzionare la tua pipeline di deploy, il tuo modello di identità, i tuoi record DNS e il tuo percorso di ripristino presso un secondo provider. Quel lavoro è tuo, ed è l'intero costo.
Cosa significa davvero avere una cloud exit strategy
Una exit strategy è una proprietà misurabile della tua architettura, non un documento. La misura è brutale: quale quota del tuo parco infrastrutturale in esecuzione potresti far ripartire presso un provider diverso, usando strumenti che già gestisci, senza scrivere nuovo codice? Per la maggior parte dei team la risposta onesta si colloca tra il quaranta e il settanta percento, e il divario non è mai dove se lo aspettavano. Raramente è l'applicazione. È il database gestito, la coda, la semantica dell'object storage, e gli undici piccoli automatismi operativi che nessuno ha mai messo per iscritto.
L'errore tipico è credere che avere due provider dimostri qualcosa. Molte aziende gestiscono la produzione su un hyperscaler e un dimenticato progetto di test altrove, e poi chiamano il risultato multi-cloud. L'opzionalità non è la presenza di un secondo account; è la capacità di esercitarla. Finché un workload reale - con monitoring, backup, un turno di reperibilità e un ripristino che hai effettivamente eseguito - non gira altrove rispetto al tuo provider principale, hai una seconda fattura, non una seconda opzione.
Le tre cose che rendono difficile andarsene
Primo, la data gravity, che è noiosa e decisiva. Copiare byte è economico, ma spostarli in modo coerente mentre un sistema è live è costoso. Nel momento in cui i tuoi dati risiedono dentro un servizio gestito proprietario, l'uscita smette di essere una copia e diventa una riscrittura di tutto ciò che ci comunica. Ecco perché i team che mantengono il proprio stato in qualcosa che potrebbero gestire da soli - anche se oggi scelgono di non farlo - conservano opzioni che i team su stack completamente gestiti perdono silenziosamente nel giro di pochi anni.
Secondo, la memoria muscolare operativa. Il tuo team conosce il modello di identità di un provider, un'astrazione di firewall, un modo di nominare le reti, il layout di una console alle tre del mattino. Passa a un secondo provider e ognuna di queste cose diventa sconosciuta sotto pressione. Il costo non è il weekend di migrazione; sono i sei mesi successivi di incidenti gestiti un po' più lentamente da persone che stanno tirando a indovinare. Nessuno lo mette in una stima di migrazione, ed è di solito la voce più grande.
Terzo, l'attribuzione dei costi. La maggior parte dei team non sa dirti quanto costa oggi un singolo workload, il che rende il confronto tra provider impossibile in linea di principio. Se la tua fattura è un unico numero per provider e la tua architettura conta quaranta servizi, la conversazione sull'uscita degenera in sensazioni. Prima di poter quantificare un'uscita ti serve la spesa suddivisa per servizio, progetto e ambiente, su ogni provider che usi, compresi quelli piccoli che avevi dimenticato. È un lavoro di base poco appariscente, ed è un prerequisito per ogni altra decisione qui trattata.
Come evitare il cloud vendor lock-in nell'UE
Se vuoi evitare il cloud vendor lock-in, il mercato UE è messo meglio di quanto la maggior parte dei team pensi. Il rapporto prezzo/prestazioni di Hetzner fa sembrare le fatture degli hyperscaler un errore di arrotondamento nella direzione sbagliata. OVHcloud gestisce data center e fibra propri in tutta Europa. Scaleway offre una developer experience genuinamente moderna dalla Francia. UpCloud fornisce compute affidabile dalla Finlandia. Nessuno di loro sostituisce ogni servizio di un hyperscaler - ma per compute, block storage e networking, dove va la maggior parte del budget infrastrutturale, sono credibili e rispondono solo alla legge UE.
Il limite onesto sono i servizi gestiti. Se il tuo prodotto è costruito su un database serverless proprietario, un event bus specifico o una piattaforma di machine learning senza equivalenti altrove, nessuna quantità di entusiasmo europeo cambia la situazione in un trimestre. La mossa utile non è una migrazione eroica tutto-o-niente. È sapere esattamente quali workload sono portabili oggi, farne girare alcuni dove giurisdizione e prezzo ti convengono, e trattare il resto come una decisione deliberata e documentata, non come un incidente della storia.
Cosa comporta davvero una prova di uscita
Trattala come un'esercitazione di ripristino, perché è esattamente quello che è. Scegli un workload reale - non il sito marketing, qualcosa con uno stato e un runbook. Fallo ripartire presso un secondo provider. Indirizzagli una frazione di traffico reale. Rompilo deliberatamente e verifica se anche lì funzionano il tuo monitoring, il tuo modello di accesso e il tuo turno di reperibilità. Poi annota il tempo reale impiegato e tutto ciò che ti ha sorpreso. Una prova che non produce sorprese di solito significa che hai scelto qualcosa di troppo facile.
Il motivo per cui la maggior parte dei team non fa mai queste prove non è la pigrizia, è lo strumentario. Ogni provider aggiuntivo significa un'altra console, un altro modello di credenziali, un altro export di fatturazione, un altro insieme di stranezze da imparare - e un piccolo platform team non può assorbire tutto questo una volta per ogni cloud. Questa è la tassa operativa che trasforma silenziosamente una conversazione sulla sovranità nel problema dell'anno prossimo, ogni anno. Ed è esattamente il problema che un control plane dovrebbe togliere dalla tua scrivania.
È esattamente questo che abbiamo costruito con Sencai. Un unico control plane su undici provider - Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Linode di Akamai e Oracle Cloud - più i tuoi server tramite un host agent. Reti, firewall e DNS vengono gestiti dove risiedono davvero, presso il provider, così un secondo provider diventa un riquadro nella stessa interfaccia invece di un secondo platform team. La spesa viene tracciata per organizzazione con limiti massimi, così la conversazione sull'uscita ha dei numeri dentro.
Puoi eseguire tutto questo sui tuoi account provider, oppure acquistare la capacità tramite noi e mantenere un'unica fattura - entrambe le opzioni sono supportate, ed è una scelta che puoi cambiare in seguito. In entrambi i casi il risultato è lo stesso, ed è l'unico numero che vale la pena riportare ai vertici: quanto tempo ti servirebbe per essere operativo altrove. Misuralo una volta e smette di essere una paura. Misuralo ogni trimestre e diventa leva - in una negoziazione, in una revisione degli acquisti, e nel giorno in cui qualcosa costringe a porsi la domanda.