Business Strategy DefinedTerm

Vendor Lock-in

Conosciuto anche come: Proprietary Lock-in, Customer Lock-in, Blocco del Fornitore

Dipendenza da un fornitore di prodotti e servizi che impedisce il passaggio ad alternative senza costi sostanziali.

Updated: 2026-01-05

Definizione

Vendor Lock-in, o dipendenza dal fornitore, è una situazione in cui un’organizzazione diventa dipendente da un fornitore specifico per prodotti, servizi o tecnologie in modo tale che il passaggio a un’alternativa comporti costi sostanziali, rischi operativi o complessità tecnica proibitiva.

Il lock-in si manifesta quando i switching costs (costi di cambio) sono talmente elevati da rendere economicamente o operativamente irrazionale abbandonare il fornitore attuale, anche se alternative migliori o più economiche sono disponibili.

Tipi principali di switching costs:

Costi economici diretti:

  • Migration cost: riscrivere codice, trasferire dati, riconfigurare sistemi
  • Contractual penalties: penali da contratti long-term, early termination fees
  • Training cost: riqualificare team su nuova piattaforma

Costi operativi:

  • Downtime durante migration
  • Risk di errori, data loss, service interruption
  • Effort di re-integrazione con altri sistemi

Costi strategici:

  • Perdita di feature specifiche del vendor attuale
  • Delay in roadmap prodotto durante transition
  • Knowledge loss (competenze team specializzate su stack attuale)

Esempio concreto: un’azienda SaaS ha costruito applicazione su AWS usando servizi proprietari (Lambda, DynamoDB, SageMaker). Migrare a Google Cloud richiede riscrivere architettura serverless, trasferire terabyte di dati, riconfigurare ML pipelines. Costo stimato: 6-12 mesi effort engineering, 2-5 milioni euro. Questo è vendor lock-in.

Il concetto di vendor lock-in è emerso negli anni ‘60-‘70 con mainframe IBM. Le aziende che adottavano System/360 diventavano dipendenti da hardware, software, training IBM-specific. Switching a competitor (Burroughs, Honeywell) era proibitivo. IBM usò strategicamente lock-in per dominare mercato per decenni.

Oggi, vendor lock-in è rilevantissimo in cloud computing, AI/ML platforms, enterprise software (ERP, CRM), e SaaS. Fornitori progettano intenzionalmente ecosistemi che aumentano switching costs per massimizzare customer lifetime value e ridurre churn.

Come funziona

Il vendor lock-in opera attraverso molteplici meccanismi tecnici, economici e psicologici che aumentano la dipendenza del cliente nel tempo.

Meccanismi di lock-in tecnico

1. Formato dati proprietario

Vendor usa formati dati chiusi, non esportabili o incompatibili con standard aperti.

Esempio: Microsoft Office usa formati .doc/.xls proprietari (fino a Office 2007). Migliaia di documenti aziendali in questi formati creano dipendenza da Office. Solo nel 2007 Microsoft adotta Open XML (sotto pressione antitrust), ma compatibilità con alternative (LibreOffice, Google Docs) rimane imperfetta.

Esempio AI: se un vendor di annotation platform salva label in formato JSON custom senza schema pubblico, migrare a competitor richiede parsing e conversion complessa.

2. API proprietarie e mancanza di standard

Vendor offre API potenti ma non compatibili con standard aperti, rendendo integrazione deep ma non portabile.

Esempio AWS: servizi come Lambda (serverless), DynamoDB (NoSQL), Step Functions (orchestration) hanno API uniche. Codice scritto per Lambda non gira su Google Cloud Functions senza riscrittura. Alternative open-source (Kubernetes, PostgreSQL) esistono ma richiedono re-architecting.

3. Dipendenza da feature uniche

Vendor sviluppa feature differenzianti non replicabili altrove. Una volta adottate, diventano critiche per operazioni.

Esempio Salesforce: workflow automation, AppExchange integrations, custom objects sono profondamente integrati in business process. Migrazione a competitor CRM (HubSpot, Dynamics) richiede rebuild di automazioni custom e perdita di feature specifiche.

4. Ecosistema integrato (walled garden)

Vendor crea stack di prodotti strettamente integrati. Usarne uno incentiva adozione di altri, creando network effects interno.

Esempio Apple: iPhone + Mac + iCloud + AirPods + Apple Watch. Switching da iPhone ad Android implica perdere integrazione seamless con altri device Apple. Questo è lock-in ecosistemico.

Esempio Microsoft: Azure AD, Office 365, Teams, Dynamics, Power Platform si integrano profondamente. Migrare uno richiede riconsiderare intera stack.

5. Competenze e training lock-in

Team sviluppa expertise su tecnologie vendor-specific. Questo knowledge capital non è trasferibile.

Esempio: developer specializzati in AWS CDK, Azure ARM templates, o Google Deployment Manager hanno skills non portabili. Cambiare cloud richiede riqualificare team o assumere nuove competenze.

Esempio ML: team esperto in SageMaker (AWS) o Vertex AI (Google) deve re-imparare MLOps stack se migra a Azure ML.

Meccanismi economici di lock-in

1. Sconti per commitment long-term

Vendor offre pricing aggressivo per contratti pluriennali, aumentando costo opportunità di switch.

Esempio cloud: AWS Reserved Instances con 3-year commitment offrono sconto 60% rispetto a on-demand. Se al mese 18 vuoi migrare a GCP, hai pre-pagato 18 mesi di AWS capacity inutilizzabile. Questo disincentiva migration.

2. Bundling e cross-subsidization

Vendor offre bundle di servizi a prezzo attraente, ma componenti individuali costano molto se comprati separatamente.

Esempio Microsoft 365: bundle Office + Teams + OneDrive + Exchange costa 12 euro/user/month. Comprare solo Office costa 10 euro, solo Teams 4 euro. Se hai Office e Teams, aggiungere OneDrive costa incrementalmente poco. Ma se vuoi sostituire solo Teams con Slack, perdi bundle discount.

3. Exit fees e contractual penalties

Contratti includono clausole che penalizzano early termination.

Esempio enterprise software: contratto ERP SAP di 5 anni con termination penalty del 50% del valore residuo. Se al terzo anno vuoi migrare a Oracle, devi pagare 2 anni di license fees residue come penalty.

4. Effetto sunk cost

Investment già fatto (tempo, denaro, effort) in vendor attuale rende psicologicamente difficile abbandonarlo, anche se razionalmente converrebbe.

Esempio: azienda ha investito 2 milioni in customization Salesforce negli ultimi 3 anni. Anche se competitor offre soluzione migliore, abbandonare significa “buttare” quei 2 milioni. Decision-maker razionalizza rimanere per “proteggere investment”.

Meccanismi di lock-in strategico

1. Integrazione profonda in business process

Software vendor diventa parte integrante di operation critiche. Rimuoverlo causa disruption operativa.

Esempio: sistema ERP (SAP, Oracle) gestisce finance, supply chain, HR, manufacturing. È embedded in processi di centinaia di persone. Migration richiede re-training massiccio, rischio di errori operativi, downtime. Risk è talmente alto che aziende rimangono su ERP legacy anche se obsoleti.

2. Network effects e platform dependency

Valore della piattaforma aumenta con numero di utenti/partner. Lasciare significa perdere accesso a network.

Esempio Salesforce AppExchange: migliaia di app third-party integrate. Se migri a competitor, perdi accesso a questo ecosistema.

Esempio AWS Marketplace: centinaia di ISV offrono software su AWS. Infra su AWS significa accesso seamless. Su Azure, devi riconfigurare.

3. Data gravity

Volumi grandi di dati su piattaforma vendor creano inerzia. Trasferire terabyte/petabyte è costoso, lento, rischioso.

Esempio data warehouse: azienda ha 500TB dati su Snowflake. Migration a BigQuery richiede:

  • Egress cost (Snowflake carica trasferimento dati out)
  • Bandwidth time (settimane per trasferire 500TB)
  • Schema conversion (SQL dialect differences)
  • ETL pipeline re-write
  • Risk di data corruption durante transfer

Risultato: inertia favorisce rimanere su Snowflake.

Strategie vendor per amplificare lock-in

I vendor progettano intenzionalmente lock-in per massimizzare revenue e customer retention:

Free tier e subsidized onboarding: rendere facilissimo iniziare (low barrier to entry) ma difficile uscire (high barrier to exit). AWS Free Tier, GCP trial credits, Snowflake free trial attirano utenti. Una volta dentro, switching costs crescono.

Fast innovation su feature proprietarie: rilasciare feature differenzianti rapidamente su API/servizi proprietari. Questo incentiva adoption e aumenta dipendenza. AWS rilascia 2.000+ feature/anno, molte su servizi managed proprietari.

Acquisizioni di complementari: comprare tool che estendono ecosistema. Salesforce ha acquisito Slack, Tableau, MuleSoft per espandere walled garden. Cliente che usa Salesforce + Slack + Tableau è più locked-in.

Pricing complex e opaque: rendere difficile comparare costi con competitor. Cloud pricing è notoriamente complesso (centinaia di SKU, regional variance, commitment tiers). Questo aumenta friction nel valutare alternative.

Casi d’uso

Cloud migration: AWS to multi-cloud strategy

Un’enterprise ha 300+ applicazioni su AWS. Nel 2023, decide strategia multi-cloud per ridurre lock-in e negoziare pricing migliore.

Lock-in analysis:

Servizi portabili (basati su standard open):

  • EC2 instances running Docker containers (migrabile a GCE, Azure VMs)
  • RDS PostgreSQL (migrabile a Cloud SQL, Azure Database)
  • S3 storage (compatible con GCS, Azure Blob via S3 API)

Servizi locked-in (proprietari AWS):

  • Lambda functions (FaaS vendor-specific)
  • DynamoDB (NoSQL con API unica)
  • SageMaker ML pipelines
  • Step Functions orchestration

Strategia migration:

Fase 1 (6 mesi): migrare workload containerizzati e stateless a GKE (Google Kubernetes Engine). Portability alta, effort moderato. Risparmio: 20% su compute cost grazie a GCP discount.

Fase 2 (12 mesi): sostituire DynamoDB con MongoDB Atlas (multi-cloud). Richiede schema migration e application rewrite. Effort: 3 team-months per app.

Fase 3 (18 mesi): re-architecting serverless. Sostituire Lambda con Cloud Functions (GCP) o valutare Kubernetes-based alternative (Knative). Effort alto, benefici long-term.

Risultato:

  • Dopo 2 anni, 40% workload su GCP, 60% AWS
  • Leverage negotiation con entrambi vendor per pricing migliore
  • Reduced risk di total dependency

Lesson: migration completa è irrazionale (troppo costosa). Approccio pragmatico: migrare subset high-value, mantenere resto su AWS finché economicamente sensato.

SaaS startup: scegliere tra AWS managed services e open-source

Una startup SaaS deve decidere tech stack per MVP. Trade-off: velocità (managed services) vs portability (open-source).

Opzione A (AWS-native, alta velocità):

  • Compute: Lambda + API Gateway (serverless)
  • Database: DynamoDB (managed NoSQL)
  • ML: SageMaker
  • Monitoring: CloudWatch

Pro: time-to-market rapido, operational overhead basso, scaling automatico Contro: lock-in totale AWS. Migration futura molto costosa.

Opzione B (open-source, alta portability):

  • Compute: Kubernetes + Docker
  • Database: PostgreSQL
  • ML: MLflow + Kubeflow
  • Monitoring: Prometheus + Grafana

Pro: portabile cross-cloud, no lock-in, controllo totale Contro: time-to-market più lento, operational complexity alta, team deve gestire infra

Decisione strategica:

Se priority è product-market fit rapido: Option A. Lock-in risk è accettabile perché a stage early, survival è priorità. Se PMF non si raggiunge, startup fallisce e lock-in è irrilevante. Se PMF si raggiunge, revenue permette di investire in migration futura se necessario.

Se priority è enterprise sales con multi-cloud requirement: Option B. Alcuni clienti enterprise richiedono deployment on-premise o su cloud specifico. Portability diventa requirement, non nice-to-have.

Approccio ibrido (raccomandato): usare managed services per accelerare MVP, ma wrappare con abstraction layer. Esempio: usare DynamoDB tramite interface layer che potenzialmente supporta MongoDB. Costo upfront maggiore, ma riduce lock-in senza sacrificare troppa velocità.

Enterprise AI: dipendenza da OpenAI vs open-source LLM

Un’azienda B2B integra AI generativa in prodotto. Scelta: OpenAI GPT-4 API vs modello open-source (Llama, Mistral) self-hosted.

OpenAI API:

Pro:

  • Qualità output superiore (GPT-4 è state-of-art)
  • Zero operational overhead (API call, pay per use)
  • Fast iteration (no ML expertise richiesta)

Contro:

  • Lock-in totale: OpenAI può cambiare pricing, deprecare API, modificare modello
  • Data privacy: input/output passano per OpenAI server
  • Costo variabile: scala linearmente con usage (100K call/giorno = 6K euro/mese)

Open-source (Llama 3 self-hosted):

Pro:

  • No vendor dependency: full control su modello e infra
  • Data privacy: tutto on-premise o su cloud proprio
  • Costo predicibile: capex GPU + opex cloud, non scala con usage

Contro:

  • Qualità inferiore (Llama < GPT-4 su task complessi)
  • Operational complexity: serve team ML per deployment, fine-tuning, monitoring
  • Capex upfront: cluster GPU costa 500K-2M euro

Scenario analysis:

Caso 1: MVP per validare use case Decision: OpenAI API. Lock-in risk basso perché ancora in exploration. Se use case non funziona, abbandonare è facile.

Caso 2: feature mission-critical con sensitivity dati Decision: Llama self-hosted. Lock-in risk inaccettabile per feature critica. Data privacy requirement impone on-premise.

Caso 3: scale production (10M+ call/mese) Decision: valutare open-source. A questo volume, OpenAI API costa 200K+ euro/mese. Self-hosting con Llama fine-tuned può costare 50K/mese (ammortizing GPU capex). Break-even a 6-12 mesi.

Strategia multi-model: molte aziende usano GPT-4 per task complessi, Llama/Mistral per task semplici. Questo riduce lock-in e ottimizza costi.

CRM migration: Salesforce to HubSpot

Un’azienda mid-market (500 dipendenti) ha usato Salesforce per 8 anni. Costi licensing sono cresciuti a 500K euro/anno. HubSpot offre funzionalità equivalenti a 150K euro/anno.

Lock-in analysis:

Data migration:

  • 2 milioni record (accounts, contacts, opportunities)
  • Custom fields e relazioni complesse
  • Effort: 2 mesi per ETL e validation

Customization rebuild:

  • 50+ workflow automation custom su Salesforce
  • 20 Apex triggers e Visualforce pages
  • Effort: 6 mesi developer per ricostruire su HubSpot

Integration re-work:

  • Salesforce integrato con ERP, marketing automation, support ticketing
  • APIs re-configuration: 3 mesi

Training:

  • 200 utenti sales/marketing da re-trainare su HubSpot
  • Effort: 1 mese + productivity dip nei primi 3 mesi

Total migration cost: 800K euro (labor + consulting + downtime risk)

Break-even analysis: Saving annuo: 500K - 150K = 350K euro/anno Break-even: 800K / 350K = 2.3 anni

Decision: migration conviene se commitment è long-term (5+ anni). Se c’è incertezza strategica, rimanere su Salesforce riduce risk.

Risk: durante migration, rischio di data loss, process disruption, churn clienti per service degradation. Questo soft cost può superare hard cost.

Public sector: evitare lock-in con procurement open-source

Ente pubblico deve implementare piattaforma gestione documentale. Requisito: evitare vendor lock-in per sovranità digitale.

Strategia procurement:

  1. Mandare open standards: richiedere formati open (ODF, PDF/A), API conformi REST/OpenAPI
  2. Preferire open-source: valutare soluzioni FOSS (Alfresco, Nextcloud) vs proprietarie (Microsoft SharePoint)
  3. Clausole contractual: includere data portability guarantee, source code escrow, exit assistance
  4. Multi-vendor strategy: evitare single-source dependency. Architettura modulare permette sostituire componenti.

Implementation:

  • Core: Alfresco (open-source document management)
  • Storage: MinIO (S3-compatible, open-source object storage)
  • Frontend: Custom React app via open API
  • Authentication: Keycloak (open-source IAM)

Risultato: stack completamente sostituibile componente per componente. No vendor ha leverage per lock-in. Se Alfresco diventa problematico, si può migrare a Nextcloud perché API standard.

Trade-off: operational complexity alta. Open-source richiede competenze interne per maintenance, security patching, troubleshooting. Public sector deve investire in team tecnico o consulenza.

Considerazioni pratiche

Valutare lock-in risk in vendor selection

Durante procurement, framework per quantificare lock-in:

1. Lock-in Score (0-100)

Criteri da valutare:

Data portability (0-25 punti):

  • Export format standard open: +25
  • Export possibile ma formato proprietario: +15
  • Export difficile o limitato: +5
  • Export bloccato o paywall: 0

API openness (0-25 punti):

  • API REST standard con OpenAPI spec: +25
  • API documentata ma proprietaria: +15
  • API limitata o undocumented: +5
  • No API o locked: 0

Switching cost (0-25 punti):

  • Migration tool/assistance fornita: +25
  • Documentation per migration: +15
  • No support, ma tecnicamente possibile: +5
  • Impossibile o prohibitively expensive: 0

Ecosystem dependency (0-25 punti):

  • Standard de-facto, multi-vendor ecosystem: +25
  • Alcuni competitor compatibili: +15
  • Walled garden ma alternative esistono: +5
  • Monopolio, no alternative: 0

Score interpretation:

  • 75-100: Low lock-in risk
  • 50-74: Medium lock-in risk
  • 25-49: High lock-in risk
  • 0-24: Extreme lock-in risk

Esempio AWS Lambda: Data portability 20 (code esportabile), API 15 (proprietaria), Switching 10 (no tool, manual), Ecosystem 10 (alternative esistono ma incompatibili). Score: 55 (Medium lock-in).

Esempio PostgreSQL: Data 25 (SQL dump standard), API 25 (SQL standard), Switching 25 (multi-vendor), Ecosystem 25 (ubiquitous). Score: 100 (No lock-in).

Strategie di mitigation lock-in

1. Abstraction layer pattern

Wrappare vendor-specific API con interface layer custom.

Esempio:

# Interface custom
class StorageService:
    def upload(blob, key):
        pass
    def download(key):
        pass

# Implementation AWS
class S3Storage(StorageService):
    def upload(blob, key):
        s3_client.put_object(Bucket=bucket, Key=key, Body=blob)

# Implementation GCP
class GCSStorage(StorageService):
    def upload(blob, key):
        gcs_bucket.blob(key).upload_from_string(blob)

Application usa StorageService interface. Switching da S3 a GCS richiede solo cambiare implementation class, non riscrivere application code.

Costo: overhead sviluppo iniziale per abstraction layer. Beneficio: portability futura.

2. Multi-cloud architecture

Distribuire workload su più cloud provider per evitare dipendenza singola.

Esempio:

  • Compute: AWS EC2 (60%), GCP GCE (40%)
  • Database: Azure Cosmos DB (primary), AWS DynamoDB (secondary)
  • Storage: multi-cloud replication (S3 + GCS)

Pro: leverage negotiation, risk mitigation, no single point of failure Contro: complexity operativa, inconsistency tra cloud, costi overhead

When justified: enterprise con budget large, risk-averse, regulatory requirement di resilienza.

3. Open-source first policy

Preferire componenti open-source quando possibile.

Esempio stack:

  • Kubernetes vs AWS ECS
  • PostgreSQL vs DynamoDB
  • Kafka vs AWS Kinesis
  • Prometheus vs CloudWatch

Pro: portability, controllo, no licensing risk Contro: operational burden, no managed service convenience

4. Contractual safeguards

Negoziare clausole contrattuali che riducono lock-in:

  • Data portability clause: vendor deve fornire export completo in formato machine-readable entro 30 giorni da richiesta
  • API stability guarantee: major API changes con 12 mesi notice
  • No exit fees: eliminare termination penalties
  • Source code escrow: per software critical, vendor deposita source code in escrow. Se vendor fallisce, cliente accede a codice.

5. Regular lock-in audit

Ogni 12-18 mesi, review:

  • Quali vendor sono single-source critical?
  • Switching cost per ciascuno?
  • Alternative disponibili?
  • Migration plan aggiornato?

Questo mantiene awareness e permette course correction proattiva.

Quando lock-in è accettabile o desiderabile

Lock-in non è sempre negativo. Casi in cui accettarlo:

1. Early stage startup: velocità è priorità assoluta. Usare AWS managed services accelera time-to-market. Lock-in risk è accettabile perché survival è incerta. Se startup ha successo, può investire in portability dopo PMF.

2. Non-core systems: per tool/servizi non critici (email, payroll, expense management), lock-in è irrilevante. Switching questi sistemi è rare e costo è basso relativamente.

3. Vendor eccezionale: se vendor offre valore difficilmente replicabile (es. Google Search Algorithm, AWS scale), lock-in è price of excellence. Alternativa peggiore è strategicamente costosa.

4. Integration depth crea valore: lock-in implica integrazione profonda. Esempio: Apple ecosystem offre UX seamless grazie a tight integration. Perdere questo per “portability” sarebbe strategicamente errato per molti utenti.

Key: lock-in è tool, non inherently good/bad. Decisione dipende da risk tolerance, strategic priorities, alternative available.

Lock-in e antitrust

Vendor lock-in può diventare antitrust concern quando:

1. Market dominance + lock-in = abuse

EU ha multato Microsoft (anni 2000) per bundling Internet Explorer con Windows, creando lock-in e danneggiando competitor (Netscape).

EU ha multato Google per Android bundling (Google Search, Play Store mandatory), creando lock-in device manufacturers.

2. Predatory lock-in tactics

Vendor intenzionalmente rende interoperability impossibile per bloccare competitor.

Esempio: Epic vs Apple. Epic sostiene che Apple App Store mandatory payment (30% fee) è lock-in abusivo. Utenti non possono installare app fuori da App Store (walled garden iOS).

Regulatory trends:

  • DMA (Digital Markets Act, EU): richiede interoperability e data portability per gatekeeper platform.
  • Data portability laws: GDPR (EU) garantisce diritto a data export in formato machine-readable.
  • Open Banking: regolazione impone API aperte per permettere third-party access a banking data.

Questi interventi mirano a ridurre lock-in structurally.

Fraintendimenti comuni

”Vendor lock-in è sempre da evitare”

Lock-in può essere strategicamente vantaggioso se benefici superano costi.

Esempio: azienda automotive usa stack software Tesla per autonomous driving. Lock-in è totale (hardware, software, data pipeline proprietari). Ma vantaggio competitivo giustifica dipendenza. Alternative non offrono stesso livello integrazione.

Netflix è locked-in su AWS (infra cost billions to migrate). Ma partnership strategica con AWS offre pricing preferenziale, support dedicato, co-innovation. Lock-in è consapevole e bilanciato da valore.

Trade-off key: velocity vs optionality. Lock-in sacrifica optionality per velocity e integration depth. Se execution rapida è critical, accettare lock-in può essere optimal choice.

”Open-source elimina lock-in”

Open-source riduce lock-in ma non elimina completamente.

Operational lock-in: anche con software open-source, team sviluppa competenze specifiche, configurazioni custom, process dependency. Switching a diverso OSS stack richiede re-training, migration effort.

Esempio: azienda usa Kubernetes per 5 anni. Team ha expertise profonda su K8s. Anche se tecnicamente potrebbe migrare a altro orchestrator (Nomad, OpenStack), knowledge capital accumulato crea inertia.

Distribution lock-in: molti OSS sono forniti come managed service da cloud provider (AWS RDS for PostgreSQL, Azure Kubernetes Service). Anche se software è open, infra e tooling attorno creano lock-in operativo.

Esempio: Aurora (AWS) è MySQL/PostgreSQL compatible, ma migration da Aurora ad altro MySQL ha friction (Aurora-specific feature, backup format, networking integration).

Ecosystem lock-in: OSS con ecosystem grande (plugin, extensions, community) crea dependency indiretta. Migrare significa perdere accesso a questo.

Esempio: WordPress ha 60.000+ plugin. Migrare a Drupal significa rebuild di funzionalità via plugin custom.

”Multi-cloud elimina lock-in”

Multi-cloud riduce lock-in ma introduce complessità e costi:

Operational complexity: gestire 2-3 cloud provider richiede competenze duplicate, tool multipli, process inconsistenti. Questo aumenta overhead e error rate.

Cost overhead: multi-cloud spesso significa sacrificare economia di scale (volume discount su singolo provider) e pagare premium per multi-cloud management tool (HashiCorp Terraform, CloudHealth).

Lowest common denominator: per portability, si usano solo feature comuni tra cloud. Questo significa non sfruttare innovation vendor-specific (es. non usare AWS Lambda perché GCP Cloud Functions ha API diversa).

Reality: true multi-cloud è raro. Più comune è “multi-cloud hybrid”: workload primary su un cloud, DR/backup su altro. Questo riduce lock-in catastrophic (vendor failure) ma non elimina operational lock-in.

Termini correlati

Fonti

Articoli Correlati

Articoli che trattano Vendor Lock-in come argomento principale o secondario.

Torna al Glossario