Il lock-in non si vede. Fino al giorno in cui provi a uscirne.

Il lock-in non si vede. Fino al giorno in cui provi a uscirne.

Succede sempre nello stesso modo.

Un'azienda sceglie un fornitore cloud. La migrazione "verso" è gratuita, veloce, tutta in discesa. Il sales engineer è disponibile, la documentazione è eccellente, il prezzo iniziale è competitivo. Tutto bene.

Passano gli anni. I workload crescono, i dati si accumulano, le integrazioni si moltiplicano. L'infrastruttura diventa parte del tessuto operativo dell'azienda — non in modo visibile, ma in modo capillare.

Poi, per un motivo o per un altro — costi saliti, un cambio di policy, una fusione aziendale, una nuova direzione strategica, un incidente di sicurezza — qualcuno decide che è il momento di cambiare.

E lì inizia il problema.

Il momento in cui il lock-in diventa visibile

I dati hanno un costo per uscire. Non per entrare — quello era gratuito. Per uscire si paga, per ogni gigabyte trasferito fuori dal perimetro del fornitore. AWS chiama questo costo "data transfer out". Azure lo chiama "bandwidth". Google Cloud lo chiama "network egress". I nomi cambiano, il meccanismo è lo stesso: hai portato i dati qui gratuitamente, ma portarli altrove costa.

I formati non sono compatibili con nient'altro. Il database gestito che sembrava così comodo da usare usa estensioni proprietarie che non esistono nell'equivalente open-source. Il sistema di storage oggetti ha un'API leggermente diversa dallo standard S3. I container girano su un runtime personalizzato che non si comporta come Docker standard. Ogni piccola scelta tecnica — presa in buona fede, per convenienza — è diventata un filo che lega.

L'unica documentazione API decente è quella del fornitore che si vuole lasciare. Ogni tool di migrazione, ogni guida di best practice, ogni risposta su Stack Overflow è scritta assumendo che stai usando il loro sistema. Uscire richiede di ricostruire quella conoscenza da zero, su una piattaforma che conosci meno.

La libertà di scegliere, quella promessa all'inizio, si è consumata senza che nessuno se ne accorgesse. Non c'è stato un momento preciso in cui è svanita — è successo gradualmente, una piccola scelta tecnica alla volta.

Il caso più clamoroso degli ultimi anni

Il caso Broadcom-VMware è l'esempio più visibile di questo meccanismo applicato su scala industriale.

VMware era, per anni, la piattaforma di virtualizzazione di riferimento per il mercato enterprise. Affidabile, ben documentata, ampiamente supportata. Le aziende ci avevano costruito sopra interi datacenter, processi operativi, competenze interne.

Quando Broadcom ha acquisito VMware nel 2023, le regole sono cambiate. Licenze perpetue eliminate. Bundle obbligatori con funzionalità che nessuno aveva chiesto. Aumenti di prezzo fino al 1.500% per alcuni clienti. E il costo di uscita? Enormemente più alto di quanto chiunque avesse calcolato — non per le egress fee, in questo caso, ma per la complessità tecnica di migrare anni di workload ottimizzati per un sistema proprietario su qualcosa di completamente diverso.

Non è un caso isolato. È il modello di business del lock-in applicato nel momento di maggior forza negoziale.

Perché il lock-in funziona — e perché è difficile accorgersene

Il lock-in funziona perché si costruisce lentamente, attraverso decisioni ragionevoli prese in buona fede.

Usare il database gestito del fornitore cloud è ragionevole — elimina la complessità operativa. Usare le sue funzioni serverless è ragionevole — accelera lo sviluppo. Usare il suo sistema di monitoraggio è ragionevole — è già integrato. Ogni singola scelta ha senso. La somma di tutte quelle scelte costruisce una dipendenza che non era nell'intenzione di nessuno.

Il problema è che il costo del lock-in non appare nei budget iniziali. Non c'è una voce "futura difficoltà di migrazione" nel TCO che si presenta al board quando si sceglie un fornitore cloud. Appare solo quando è troppo tardi per fare scelte diverse a basso costo.

La domanda giusta da farsi

La domanda che si fa di solito quando si sceglie un'infrastruttura cloud è: quanto costa entrare?

La domanda giusta è un'altra: quanto costerebbe uscire, se dovessi farlo domani?

Non tra cinque anni, in una situazione ideale, con tempo e budget pianificati. Domani — per un'acquisizione che cambia la strategia, per un incidente di sicurezza che impone un cambio rapido, per un aumento di prezzo unilaterale che rende il costo insostenibile.

Se la risposta è "non lo so" o "sarebbe molto complesso", quella è già un'informazione importante.

Come costruiamo l'infrastruttura in Epic Edge

Da Epic Edge partiamo dal problema opposto.

Costruiamo ogni infrastruttura assumendo, fin dal primo giorno, che un giorno il cliente potrebbe voler cambiare — fornitore, architettura, tecnologia, persino noi.

Questo non è un approccio altruistico. È semplicemente il modo in cui pensiamo che un'infrastruttura professionale dovrebbe essere costruita. Un'infrastruttura che non puoi lasciare non è un servizio — è una prigione con un contratto di manutenzione.

In pratica questo significa lavorare esclusivamente su standard aperti. OpenStack per il compute e il networking. Ceph per lo storage distribuito. Kubernetes per i workload containerizzati. Formati standard, API standard, protocolli standard. Non perché siano sempre la scelta tecnicamente più semplice — a volte non lo sono — ma perché garantiscono che le competenze, gli strumenti e i dati rimangano portabili.

Significa lavorare sull'hardware che l'azienda già possiede o affitta in colocation. Non ospitiamo nulla di nostro, quindi non c'è nessuna "uscita" da negoziare con noi. I dati sono fisicamente nei datacenter del cliente o in una colocation che il cliente controlla. Non ci sono egress fee perché non ci sono infrastrutture di Epic Edge da cui uscire.

Se un giorno un cliente volesse andare altrove, sarebbe un cambio di fornitore di supporto — come cambiare la società che fa manutenzione agli impianti. Non un progetto di migrazione da un anno, non un costo di uscita negoziabile, non una dipendenza tecnica da sciogliere.

La reversibilità come criterio di valutazione

Quando valutiamo un'infrastruttura esistente o progettiamo una nuova, aggiungiamo sempre una domanda al processo di assessment: questa architettura è reversibile?

Reversibile significa che i dati sono in formati standard esportabili. Che le configurazioni sono scritte in Infrastructure as Code (Terraform, Ansible) e versionata su Git — non bloccata in un pannello di controllo proprietario. Che la documentazione esiste e non dipende dalla conoscenza di una singola persona o di un singolo fornitore. Che il costo tecnico e operativo di un cambio di fornitore è misurabile e accettabile.

La reversibilità non è un costo aggiuntivo. È una caratteristica che si progetta dall'inizio o che si paga molto cara dopo.

Conclusione

Il lock-in cloud è un rischio che quasi nessun budget di IT considera esplicitamente. Appare solo quando è già costoso da risolvere.

La buona notizia è che si può evitare — non con tecnologie magiche, ma con scelte architetturali deliberate fatte fin dall'inizio. Standard aperti. Hardware del cliente. Infrastructure as Code. Documentazione portabile.

Se non conosci la risposta alla domanda "quanto costerebbe uscire dalla tua infrastruttura attuale se dovessi farlo domani", è il momento buono per scoprirla.

→ Contattaci per un assessment della tua infrastruttura