Che cos’è il vendor lock-in e come fare per evitarlo?

Il vendor lock-in entra in gioco quando un cliente si lega a un fornitore di servizi in maniera tale da rendere impossibile tornare sui propri passi. Più esattamente quando si viene a creare una dipendenza del cliente nei confronti del fornitore. Anche in relazione all’uso di servizi cloud risulta importante prestare attenzione al rischio del cosiddetto effetto lock-in. Nei paragrafi successivi vi sveliamo cosa significhi esattamente vendor lock-in e come fare per evitarlo.

In senso generale con effetto lock-in si intende la dipendenza di un cliente da un prodotto, un servizio o una tecnologia. La dipendenza è dovuta dal verificarsi di una condizione in cui un cambiamento risulta connesso a uno sforzo elevato e perciò poco attrattivo. Se la tecnologia appartiene a un solo fornitore o venditore (in inglese si parla di “vendor”), il cliente è di fatto legato a lui e ha così luogo il vendor lock-in.

Sul mercato esistono un elevato numero di tecnologie e servizi, tra le quali i clienti possono scegliere. Variano i prezzi e le condizioni e ogni rapporto tra cliente e fornitore ha diversi vantaggi e svantaggi specifici. Dover scegliere tra diversi o alcuni fornitori di uno stesso servizio crea una situazione complicata.

Da un punto di vista amministrativo ha senso lavorare con un numero ridotto di fornitori. I processi diventano più omogenei e perciò meno complessi. Nei casi più estremi è addirittura possibile che tutti i prodotti e i servizi di cui si ha bisogno vengano forniti da un unico fornitore. In questo caso si verifica però una situazione di completa dipendenza. Il cliente si trova in una posizione di svantaggio e possiede per questo motivo una capacità di negoziazione minore.

L’esempio classico di vendor lock-in nell’ambito software è il legame con Microsoft come fornitore di tecnologie e servizi. In molti ambiti professionali circolano quasi esclusivamente i software della multinazionale: il sistema operativo (Windows), i programmi di lavoro (Office), i database (Access) e così via. In questo modo tutti i software, dai programmi, passando per le licenze e la definizione dei prezzi, fino ad arrivare all’assistenza sono controllati da un singolo fornitore. In questo caso il vendor lock-in è totale.

La dipendenza da un fornitore risulta dall’impossibilità di cambiarlo, incluso quando il passaggio è teoricamente possibile ma l’enorme sforzo richiesto rappresenta un ostacolo insormontabile. Di fatto anche in questo caso il cliente risulta legato al fornitore. Cerchiamo di rendere la teoria più chiara con un semplice esempio.

Spesso ci si riferisce alle componenti tecnologiche impiegate con il termine di “beni complementari”, intendendo che ogni componente è in relazione diretto a un altro. Per esempio: se si possiede una Xbox o una Playstation e una relativa collezione di giochi, sono molto basse le probabilità che si passi da un sistema all’altro. Sarebbe infatti necessario comprare nuovamente tutti i giochi, in quanto quelli che si possiedono non funzionano sull’altro sistema.

Oltre all’incompatibilità appena descritta delle tecnologie che si fanno concorrenza, alcuni ostacoli contrattuali e organizzativi rendono il passaggio ancora più complicato. Da un lato ci sono le condizioni di licenza e gli accordi contrattuali del caso a legare il cliente a un fornitore. Dall’altro sono già stati fatti investimenti nel formare e addestrare il singolo lavoratore all’utilizzo di un dato servizio. Se tale investimento è specifico per una tecnologia e non è applicabile altrove, la dipendenza si cementifica.

Il tutto è più della somma delle parti. Infatti, il tutto (un sistema) comprende:

• Le parti (componenti)
• Le interazioni e le connessioni esplicite o implicite tra le parti
• Le caratteristiche risultanti dall’intero sistema.

Le singole parti possono solitamente essere sostituite con relativa facilità in seguito a un cambiamento, mentre a volte i collegamenti devono essere creati nuovamente. In un sistema cresciuto in maniera organica, i collegamenti tra i componenti risultano per lo più impliciti. In questo caso manca la descrizione necessaria per la ricostruzione dell’intero sistema e il passaggio diventa da complicato a impossibile.

Un esempio concreto: immaginatevi un sistema di database presente all’interno dell’infrastruttura IT di un provider. I dati archiviati al suo interno sono relativamente facili da migrare qualora si decida di passare a un altro servizio. Ma che cosa ne sarebbe degli altri componenti e delle relative connessioni, come le impostazioni, i permessi di accesso, la suddivisione del database su più server (sharding), ecc.? Siete a conoscenza della complessità dell’intero sistema, o meglio, siete in grado di comprenderla? Se sì, lo sforzo richiesto per riprodurla sulla nuova infrastruttura è sostenibile? In molti casi la risposta a questa domanda sarebbe no.

Avvalendoci del controllo di sicurezza come esempio, risulta più facile chiarire come le caratteristiche di sistema rendano complicato il cambio di fornitore. Un controllo di questo tipo prende in considerazione dei requisiti tecnici, organizzativi e contrattuali. Per attestare la sicurezza di un sistema si ricorre a una certificazione. Ma questa certificazione è collegata a un caso concreto, ossia il sistema com’è al momento del controllo. Dunque, nel caso in cui si decida di cambiare fornitore di servizio, il sistema viene costruito di nuovo e per questo motivo è richiesta una nuova certificazione. L’esborso aggiuntivo aumenta perciò i costi legati al passaggio, disincentivandolo e quindi contribuendo all’effetto lock-in.

L’impiego del cloud offre molti vantaggi, ma presenta comunque il rischio di vendor lock-in. Un esempio classico: i dati importanti di un’azienda sono archiviati nell’infrastruttura cloud di un provider. Se si decide di affidarsi a un fornitore di servizi diverso per l’elaborazione dei dati, allora bisogna trasferire i dati attraverso la rete. Questa trasmissione comporta però dei costi. Per questo motivo può risultare interessante affidare l’elaborazione al provider iniziale. In questo modo si scatena però un inarrestabile effetto lock-in.

Più dati si archiviano e più risulta saldo il rapporto e quindi più forte l’effetto lock-in. Se il metodo di gestire la propria attività fa riferimento a funzioni, API e configurazioni specifiche per fornitori, risulta più difficile sbrogliare la matassa. Come già accennato, nei casi più estremi tutte queste componenti appartengono a un solo provider di servizi gestiti. Anche le soluzioni su misura create da una società di ingegneria informatica vengono rese disponibili con riserva. Un elevato grado di modifiche ad hoc rende il cliente fortemente legato al fornitore del servizio.

Volendo riassumere le capacità tecniche fondamentali comuni a tutti i cloud ne abbiamo identificate tre:

• Software Defined Networking (SDN): invece di utilizzare e configurare router e switch, vengono impiegate reti e dispositivi di rete virtuali.
• Software Defined Storage (SDS): vengono impiegati Object Stores come “Amazon S3” e Block Stores come “Azure Blob Storage” in un Software Defined Data Center invece di dispositivi fisici di archiviazione di massa.
• Soluzioni di serverless computing: le “Infrastructure as a Service” (IaaS) e i “Container as a Service” (CaaS) servono a virtualizzare sistemi operativi e applicazioni. Con le “Function as a Service” (FaaS) come “AWS Lambda” e “Microsoft Azure Functions” si mettono a disposizione singole funzioni per l’accesso ai dati.

Un ambiente di cloud computing comprende aspetti tecnici quali hosting, archiviazione e applicazioni, ai quali si vanno ad aggiungere aspetti organizzativi relativi alla configurazione, all’assistenza e agli aspetti giuridici. Un ambiente cloud specifico punta a modo proprio su diversi di questi aspetti. Data la varietà delle possibilità risulta facile intuire quanto complessa possa risultare mediamente la migrazione da un fornitore a un altro:

I prodotti cloud sopramenzionati come IaaS, PaaS, SaaS e CaaS altro non sono che servizi. Vengono messi a disposizione dai provider in cambio del pagamento di un canone, ma in nessun momento appartengono al cliente che li adopera. Sta perciò al provider decidere se e a quali condizioni offrire i servizi, come specificato nei contratti di fornitura degli stessi.

Cosa succede allora se variano i parametri del servizio richiesto? Nel peggiore dei casi ci sono delle perdite in termini di qualità o in merito all’entità del servizio, altrimenti il provider aumenta il prezzo o cambia le condizioni a proprio favore. Solitamente il fornitore ha il coltello dalla parte del manico, in quanto il cliente dipende da lui.

I motivi per la dipendenza da un provider possono anche verificarsi lato cliente. Ad esempio, quando i lavoratori di un’azienda sono abituati a lavorare con un determinato programma o tecnologia fornita da un provider. I tecnici sono solitamente specializzati nell’uso di determinate tecnologie. Passando a un altro fornitore di servizi, il personale ha bisogno di essere nuovamente istruito o addirittura può risultare necessario fare nuove assunzioni.

Per scampare il pericolo del vendor lock-in i dati e i processi devono essere migrati a un nuovo provider. Una migrazione di questo tipo rappresenta nella maggior parte dei casi un procedimento complicato. Poiché il benessere della propria impresa dipende dal successo della migrazione, questa deve essere pianificata e messa alla prova prima di procedere. Ma anche prestando massima cautela non è possibile escludere che si presentino degli errori, anche in un secondo momento. Una migrazione complessa rappresenta sempre un rischio elevato, motivo per il quale ci si chiede sin da subito se il gioco valga veramente la candela.

Il metodo migliore per evitare il vendor lock-in consiste nel contrastarlo strategicamente sin da subito. Invece di puntare su un provider e conferirgli pieno potere, conviene basarsi su più aspetti. Inoltre, assicuratevi di strutturare i sistemi interni in modo che sia poi possibile sostituirne i componenti.

Nei seguenti paragrafi abbiamo riassunto alcune misure strategiche, organizzative e tecniche specifiche che potrebbero aiutarvi a evitare l’effetto di vendor lock-in.

Se già al momento della scelta dei fornitori e dei servizi viene considerato il pericolo di vendor lock-in, la scelta è già più consapevole. Per esempio, se si valuta l’offerta tecnologica comparabile a un prezzo simile di due diversi provider, può avere senso scegliere quella più costosa se questo permette di diminuire il pericolo di vendor lock-in.

Generalmente una verifica rigorosa è d’obbligo: capire quali sono le proprie esigenze in relazione alla tecnologia tenendo conto dell’infrastruttura IT già esistente è indispensabile. L’analisi delle offerte presenti sul mercato parte proprio dalla conoscenza delle proprie necessità e sistemi informatici. È importante prendere in considerazione le tendenze emergenti e il termine (End of Life) delle tecnologie. Se, ad esempio, ci fossero dei sistemi legacy all’interno della vostra struttura dovreste rimpiazzarli.

Se una tecnologia o un provider dovesse comportare il rischio di vendor lock-in, dovreste definire sin da principio una strategia di fuga. In questo modo, qualora necessario, potreste reagire in modo rapido e preciso a cambiamenti per voi poco adatti. Saprete già cosa fare e sarete già a conoscenza dei costi e dei rischi.

Il modo migliore per impedire che si venga a creare una situazione di vendor lock-in è quello di non dipendere da un solo provider. Invece di archiviare tutti i processi aziendali nel cloud, scegliete una soluzione ibrida. Per esempio, potreste usare un cloud privato come integrazione alle risorse cloud esterne. In questo modo i processi centrali e i relativi dati rimangono sotto il vostro controllo, garantendovi la sovranità dei dati.

Secondo lo stesso principio potrebbe risultare vantaggioso anche affidarvi a diversi servizi cloud invece che a uno solo. In questo caso risulta però decisivo poter accedere a tutti i servizi adottati attraverso un’unica interfaccia apposita. Solo in questo modo è possibile organizzare un sistema coerente mettendo assieme le singole componenti. Inoltre, dovreste prediligere i servizi di quei provider che supportano l’interoperabilità attraverso un’interfaccia aperta.

Tutte queste misure risultano efficaci soltanto se le strutture effettivamente esistenti vengono gestite internamente alla vostra azienda. Se i processi vengono eseguiti lontano dai radar, allora il rischio di vendor lock-in sussiste nonostante tutti gli sforzi intrapresi. Questo risulta particolarmente chiaro dando uno sguardo ai cosiddetti “dark data”. Con questo termine ci si riferisce ai dati che esistono all’esterno degli appositi sistemi. Il modo migliore per ottenere l’indipendenza è renderla un obiettivo dichiarato e standardizzare il più possibile processi e sistemi.

Le misure tecniche più facili per evitare il vendor lock-in consistono nel rifiuto a impiegare sistemi e formati proprietari. Se si punta costantemente su standard open source e freeware è impossibile per definizione diventare dipendenti da un singolo provider. Tuttavia, questo approccio risulta infruttuoso in relazione al cloud se non si ha il controllo delle risorse hardware.

Fortunatamente, negli ultimi anni sono stati sviluppati potenti strumenti di orchestrazione che servono proprio a questo. Tra questi si annoverano OpenShift e Terraform. Questi strumenti servono da livello intermedio e disassociano le proprie esigenze dal livello del provider, che sta alla base dell’infrastruttura informatica. In questo modo risulta possibile creare un’infrastruttura IT completa suddivisa su più cloud.

La parola chiave in questo caso è “Infrastructure as Code” (IaC). Attenzione: “code” e non “service”. Mentre un servizio viene affittato, il codice rimane sotto il proprio controllo. All’interno del codice vengono definite le strutture desiderate. Queste contengono singole componenti, così come i relativi collegamenti. Oltre alla documentazione sempre più esplicita dei sistemi all’interno del codice, questo offre diversi vantaggi decisivi.

Partendo dalle strutture definite in astratto nel codice, i software di orchestrazione mettono a disposizione i sistemi informatici corrispondenti. È possibile suddividere le singole componenti su più cloud. Questo funziona per le infrastrutture cloud di diversi provider così come per i cloud privati interni alla propria azienda. L’ulteriore riduzione dei costi di passaggio da un servizio all’altro che ne consegue contribuisce significativamente a proteggere dal vendor lock-in.