Il vendor lock-in nel cloud è una dipendenza da un solo provider così profonda che cambiare costerebbe più – in denaro, tempo e rischio – che restare. Nessuno lo sottoscrive: si accumula – un servizio proprietario, un terabyte, un’assunzione specializzata alla volta – finché il prezzo dell’uscita diventa un numero che nessuno vuole pronunciare in riunione.
Punti chiave
| Domanda | Risposta |
|---|---|
| Che cos’è | Costi di migrazione così alti che restare smette di essere una scelta |
| Come si forma | API proprietarie + gravità dei dati + costi di egress + competenze + contratti |
| È sempre un male? | No – la profondità su un solo vendor compra velocità; la colpa è non conoscere il prezzo dell’uscita |
| Cosa è cambiato | Il Data Act dell’UE: addebiti per il cambio limitati dal 2025, vietati dal 2027 |
| La difesa vera | Standard aperti e un’uscita provata – non il multi-cloud per riflesso |
Il prezzo di andarsene, in cifre
Il lock-in resta astratto finché non finisce su una fattura:
# Il pedaggio di uscita sui soli dati (prezzi classici dell'egress)
50 TB archiviati, in uscita a ~0,09 USD/GB:
50.000 GB × 0,09 USD ≈ 4.500 USD – per copia, per tentativo
# Alla scala reale, da documenti pre-IPO e blog di ingegneria:
grandi piattaforme di streaming e social hanno dichiarato
da 20 a 50 milioni di USD all'anno solo di egressE poi c’è il versante codice del pedaggio: un’app scritta contro API proprietarie paga in riscritture quello che i dati pagano in egress. Il controschema è codice che tratta il provider come un dettaglio di implementazione:
// JavaScript / Node.js — Back4app JS SDK
// The whole "migration": point the SDK at any Parse Server you run
Parse.initialize('APP_ID', 'JS_KEY');
Parse.serverURL = 'https://parseapi.back4app.com'; // hosted today
// Parse.serverURL = 'https://api.yourcompany.com/parse'; // self-hosted tomorrow
// Every query, ACL, and Cloud Function call stays identical.// Flutter / Dart — Back4app Flutter SDK
// Hosted today; swap the URL to self-host tomorrow — nothing else changes
await Parse().initialize(
'APP_ID',
'https://parseapi.back4app.com', // or https://api.yourcompany.com/parse
clientKey: 'CLIENT_KEY',
);// iOS / Swift — Back4app Swift SDK
// Hosted today; swap the URL to self-host tomorrow — nothing else changes
ParseSwift.initialize(
applicationId: "APP_ID",
clientKey: "CLIENT_KEY",
serverURL: URL(string: "https://parseapi.back4app.com")! // or your own server
)// Android / Kotlin — Back4app Android SDK
// Hosted today; swap the URL to self-host tomorrow — nothing else changes
Parse.initialize(
Parse.Configuration.Builder(context)
.applicationId("APP_ID")
.clientKey("CLIENT_KEY")
.server("https://parseapi.back4app.com") // or https://api.yourcompany.com/parse
.build()
)Come si somma il lock-in
I cinque tipi di lock-in
| Tipo | Meccanismo | Forma concreta |
|---|---|---|
| Piattaforma/API | Codice scritto contro servizi senza equivalente altrove | Database, funzioni, code e autenticazione proprietari |
| Dati | Gravità + costi di egress + formati proprietari | 50 TB che costano migliaia di dollari da spostare, una volta |
| Contrattuale | Impegni, sconti, rinnovi automatici | Contratti pluriennali che mettono il prezzo dell’uscita nella durata |
| Competenze | Competenze del team specializzate su una sola piattaforma | Certificazioni e padronanza di strumenti che non si trasferiscono |
| Economico | Crediti e prezzi a pacchetto | Crediti “gratuiti” che maturano in dipendenza |
La corrispondenza che disinnesca la prima riga: per la maggior parte dei servizi proprietari esiste un equivalente aperto – database gestito → compatibile con PostgreSQL; coda proprietaria → Kafka o RabbitMQ; funzioni proprietarie → runtime aperti come Knative o OpenFaaS; backend proprietario → Parse Server. Scegliere la variante compatibile con l’open source di un servizio gestito costa poco al momento dell’adozione e ridetermina il prezzo di tutta l’uscita.
Architettura vincolata vs. architettura portabile
| Dimensione | Vincolata per impostazione predefinita | Portabile per progetto |
|---|---|---|
| Servizi | Solo API proprietarie | Servizi gestiti compatibili con l’open source |
| Dati | Formati del provider, esportazione non collaudata | Formati aperti, percorso di esportazione provato |
| Calcolo | Runtime specifici del provider | Container + runtime standard |
| Configurazione | Clic nella console | Infrastruttura dichiarativa e versionata come codice |
| Uscita | Una teoria | Un runbook collaudato con un prezzo noto |
La svolta normativa
L’economia del lock-in è cambiata per legge. Il Data Act dell’UE – applicabile da settembre 2025 – limita ai costi diretti quanto i provider possono addebitare per il cambio di fornitore, e da gennaio 2027 gli addebiti per il cambio relativi a servizi cloud che servono clienti dell’UE sono vietati del tutto. I grandi provider hanno giocato d’anticipo nel 2024, rinunciando ai costi di egress per i clienti che se ne andavano definitivamente. Le clausole in piccolo contano: quelle rinunce coprono di norma l’uscita, non il normale spostamento di dati in multi-cloud – e il Data Act non fa nulla contro le API proprietarie o le competenze. La norma ha abbassato il pedaggio; resta l’architettura a decidere se la strada esiste.
Casi d’uso tipici
- Scegliere i servizi gestiti con cognizione. Valutare ogni adozione proprietaria “comoda” contro la sua alternativa compatibile con l’open source: la decisione di lock-in meno costosa è quella presa al momento dell’adozione.
- Pianificare la strategia di uscita. Regimi di conformità e consigli di amministrazione richiedono sempre più spesso piani di uscita dal cloud documentati e collaudati; l’inventario della tabella qui sopra è il modello.
- Negoziare i contratti. Conoscere il costo di migrazione reale è potere contrattuale al rinnovo: i provider calibrano le offerte sul prezzo dell’uscita di chi sta davanti.
- Fusioni e consolidamenti. Il consolidamento cloud dopo un’acquisizione è il punto in cui le uscite mai collaudate diventano sorprese molto costose.
- Selezionare la piattaforma per un nuovo prodotto. Il momento di massima scelta e minimo costo, quello in cui le piattaforme basate su open source convertono il lock-in da trappola in preferenza.
Conviene ottimizzare contro il lock-in? Matrice decisionale
| Andare a fondo su un solo provider quando… | Investire in portabilità quando… |
|---|---|
| La velocità di arrivo sul mercato domina tutto | I volumi di dati crescono in fretta (la gravità si somma) |
| Il carico è esplorativo o di breve durata | Il sistema è centrale e di lunga vita |
| Il team è piccolo e un solo insieme di competenze è un vantaggio | Contratti o regolatori impongono un’uscita collaudata |
| I servizi compatibili con l’open source coprono già le esigenze | Ci si appoggia a servizi senza equivalente aperto |
| Il costo di uscita è noto e accettabile | Il prezzo dell’uscita è ignoto – questa è la bandiera rossa |
La sintesi: la profondità va bene, la cecità no. Prendere la velocità del provider unico, con servizi compatibili con l’open source dove esistono, un percorso di esportazione già eseguito davvero e un prezzo di uscita che si possa dire a voce alta.
Limiti e trade-off
- Anche la portabilità ha un prezzo. Livelli di astrazione, strumenti multi-cloud e scelte di servizi al minimo comune denominatore costano tempo di ingegneria reale, speso a difendersi da una migrazione che forse non arriverà mai.
- Il multi-cloud non è una cura automatica. Due provider possono significare due piattaforme padroneggiate a metà, superficie di integrazione raddoppiata e dati divisi fra due pozzi gravitazionali.
- L’open source sposta il rischio invece di cancellarlo. Ospitare in proprio uno stack aperto scambia la dipendenza dal fornitore con il carico operativo: l’uscita è reale, ma non è gratuita.
- I contratti sopravvivono alle architetture. Il parco containerizzato più pulito resta vincolato da un impegno triennale firmato per lo sconto.
- La parte non mitigabile: ciò che davvero differenzia un provider è, per definizione, ciò che nessun altro offre. Va usato – con cognizione, in un solo punto, dietro un’interfaccia di proprietà.
Il vendor lock-in su Back4app
Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. L’analisi del lock-in è insolitamente breve: tutto lo stack è open source, quindi lo stesso backend – dati, chiamate SDK, funzioni, ACL – gira ospitato in proprio su qualsiasi infrastruttura, e la migrazione mostrata nelle schede di codice qui sopra è un cambio di URL, non una riscrittura. Questo converte il trade-off abituale del BaaS (massima comodità, massimo lock-in) in comodità gestita con un’uscita permanente e provabile: la dipendenza come scelta che si rinnova ogni volta, non come una porta che si è chiusa alle spalle.
Domande frequenti
Che cos'è il vendor lock-in nel cloud computing?
Una dipendenza da un solo provider cloud così profonda che cambiare richiederebbe costi, sforzo o rischio proibitivi. Si accumula attraverso i servizi proprietari contro cui è scritto il codice, i dati che diventano troppo grandi e costosi da spostare, le competenze del team specializzate su una sola piattaforma e i contratti che premiano chi resta. Il lock-in è raramente una singola decisione: sono cento piccole comodità che si sommano.
Quali sono le cause del vendor lock-in nel cloud?
Cinque meccanismi che si rinforzano a vicenda: API e servizi gestiti proprietari che altrove non hanno un equivalente sostituibile; la gravità dei dati, per cui i dati accumulati attirano verso di sé altri carichi; i costi di egress, che tassano ogni byte in uscita; il lock-in sulle competenze, man mano che il team si specializza negli strumenti di una piattaforma; e il lock-in commerciale, attraverso sconti, crediti e impegni pluriennali che rendono doloroso andarsene.
Che cosa sono i costi di egress?
Sono gli addebiti per far uscire i dati da un cloud – storicamente intorno ai cinque-nove centesimi di dollaro per gigabyte. I dati entrano gratis ed escono a pagamento, e così i dati archiviati si convertono in silenzio in costo di migrazione: far uscire cinquanta terabyte può costare migliaia di dollari a tentativo. I prezzi dell'egress sono stati il meccanismo di lock-in più criticato di tutti, e il primo su cui si sono mossi i regolatori.
Il vendor lock-in è illegale?
No, ma in Europa è ormai regolamentato. Il Data Act dell'UE, applicabile da settembre 2025, limita gli addebiti per il cambio di fornitore ai costi diretti sostenuti dal provider – e da gennaio 2027 gli addebiti per il cambio relativi a servizi cloud che servono clienti dell'UE devono essere eliminati del tutto. I grandi provider hanno anticipato la norma nel 2024, rinunciando ai costi di egress per i clienti in uscita. Il lock-in contrattuale e tecnico resta legale in ogni Paese: ciò che i regolatori hanno attaccato è il pedaggio di uscita.
Il vendor lock-in è sempre un male?
No, e sostenere il contrario porta a decisioni peggiori. Andare a fondo su un solo provider compra velocità reale: servizi integrati, prezzi a pacchetto, un solo insieme di competenze. Un multi-cloud prematuro compra costi reali: competenze duplicate, architettura al minimo comune denominatore e collante di integrazione. L'inquadramento maturo è un trade-off governato: prendere la velocità, ma conoscere i costi di uscita prima che si sommino, non dopo.
Kubernetes evita il vendor lock-in?
Riduce il lock-in solo per il livello di calcolo. I container si spostano, ma database gestiti, code, sistemi di identità e servizi serverless che stanno loro attorno no – e lo stesso Kubernetes gestito cambia da un provider all'altro. La portabilità è una proprietà architetturale, non qualcosa che un singolo strumento concede. Un cluster che chiama dieci servizi proprietari è esattamente tanto vincolato quanto lo sarebbe senza il cluster.
Che cos'è la gravità dei dati (data gravity)?
È la tendenza dei dati accumulati ad attirare applicazioni e servizi là dove risiedono, perché spostare il calcolo verso i dati costa poco e spostare i dati verso il calcolo no. Man mano che i dati crescono, costi di egress e tempi di migrazione crescono con loro, quindi la gravità si somma: ogni terabyte archiviato rende più probabile che il carico successivo atterri lì accanto, e l'intero parco più difficile da spostare.
Come si evita il vendor lock-in nel cloud?
Conviene preferire standard aperti e servizi compatibili con l'open source (un database gestito che parla PostgreSQL batte uno proprietario), containerizzare il containerizzabile, tenere i dati in formati esportabili con percorsi di esportazione collaudati, mettere livelli di astrazione davanti ai servizi specifici del provider che non si possono evitare, negoziare le condizioni di uscita in anticipo e provare l'uscita: una via d'uscita mai aperta è un'ipotesi, non un piano.