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 im­pos­si­bi­le tornare sui propri passi. Più esat­ta­men­te quando si viene a creare una di­pen­den­za del cliente nei confronti del fornitore. Anche in relazione all’uso di servizi cloud risulta im­por­tan­te prestare at­ten­zio­ne al rischio del co­sid­det­to effetto lock-in. Nei paragrafi suc­ces­si­vi vi sveliamo cosa si­gni­fi­chi esat­ta­men­te vendor lock-in e come fare per evitarlo.

In senso generale con effetto lock-in si intende la di­pen­den­za di un cliente da un prodotto, un servizio o una tec­no­lo­gia. La di­pen­den­za è dovuta dal ve­ri­fi­car­si di una con­di­zio­ne in cui un cam­bia­men­to risulta connesso a uno sforzo elevato e perciò poco at­trat­ti­vo. Se la tec­no­lo­gia ap­par­tie­ne 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 tec­no­lo­gie e servizi, tra le quali i clienti possono scegliere. Variano i prezzi e le con­di­zio­ni 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 si­tua­zio­ne com­pli­ca­ta.

Da un punto di vista am­mi­ni­stra­ti­vo ha senso lavorare con un numero ridotto di fornitori. I processi diventano più omogenei e perciò meno complessi. Nei casi più estremi è ad­di­rit­tu­ra 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 si­tua­zio­ne di completa di­pen­den­za. Il cliente si trova in una posizione di svan­tag­gio e possiede per questo motivo una capacità di ne­go­zia­zio­ne minore.

L’esempio classico di vendor lock-in nell’ambito software è il legame con Microsoft come fornitore di tec­no­lo­gie e servizi. In molti ambiti pro­fes­sio­na­li circolano quasi esclu­si­va­men­te i software della mul­ti­na­zio­na­le: 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 de­fi­ni­zio­ne dei prezzi, fino ad arrivare all’as­si­sten­za sono con­trol­la­ti da un singolo fornitore. In questo caso il vendor lock-in è totale.

La di­pen­den­za da un fornitore risulta dall’im­pos­si­bi­li­tà di cambiarlo, incluso quando il passaggio è teo­ri­ca­men­te possibile ma l’enorme sforzo richiesto rap­pre­sen­ta un ostacolo in­sor­mon­ta­bi­le. 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 com­po­nen­ti tec­no­lo­gi­che impiegate con il termine di “beni com­ple­men­ta­ri”, in­ten­den­do che ogni com­po­nen­te è in relazione diretto a un altro. Per esempio: se si possiede una Xbox o una Play­sta­tion e una relativa col­le­zio­ne di giochi, sono molto basse le pro­ba­bi­li­tà che si passi da un sistema all’altro. Sarebbe infatti ne­ces­sa­rio comprare nuo­va­men­te tutti i giochi, in quanto quelli che si pos­sie­do­no non fun­zio­na­no sull’altro sistema.

Oltre all’in­com­pa­ti­bi­li­tà appena descritta delle tec­no­lo­gie che si fanno con­cor­ren­za, alcuni ostacoli con­trat­tua­li e or­ga­niz­za­ti­vi rendono il passaggio ancora più com­pli­ca­to. Da un lato ci sono le con­di­zio­ni di licenza e gli accordi con­trat­tua­li del caso a legare il cliente a un fornitore. Dall’altro sono già stati fatti in­ve­sti­men­ti nel formare e ad­de­stra­re il singolo la­vo­ra­to­re all’utilizzo di un dato servizio. Se tale in­ve­sti­men­to è specifico per una tec­no­lo­gia e non è ap­pli­ca­bi­le altrove, la di­pen­den­za si ce­men­ti­fi­ca.

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

• Le parti (com­po­nen­ti)
• Le in­te­ra­zio­ni e le con­nes­sio­ni esplicite o implicite tra le parti
• Le ca­rat­te­ri­sti­che ri­sul­tan­ti dall’intero sistema.

Le singole parti possono so­li­ta­men­te essere so­sti­tui­te con relativa facilità in seguito a un cam­bia­men­to, mentre a volte i col­le­ga­men­ti devono essere creati nuo­va­men­te. In un sistema cresciuto in maniera organica, i col­le­ga­men­ti tra i com­po­nen­ti risultano per lo più impliciti. In questo caso manca la de­scri­zio­ne ne­ces­sa­ria per la ri­co­stru­zio­ne dell’intero sistema e il passaggio diventa da com­pli­ca­to a im­pos­si­bi­le.

Un esempio concreto: im­ma­gi­na­te­vi un sistema di database presente all’interno dell’in­fra­strut­tu­ra IT di un provider. I dati ar­chi­via­ti al suo interno sono re­la­ti­va­men­te facili da migrare qualora si decida di passare a un altro servizio. Ma che cosa ne sarebbe degli altri com­po­nen­ti e delle relative con­nes­sio­ni, come le im­po­sta­zio­ni, i permessi di accesso, la sud­di­vi­sio­ne del database su più server (sharding), ecc.? Siete a co­no­scen­za della com­ples­si­tà dell’intero sistema, o meglio, siete in grado di com­pren­der­la? Se sì, lo sforzo richiesto per ri­pro­dur­la sulla nuova in­fra­strut­tu­ra è so­ste­ni­bi­le? In molti casi la risposta a questa domanda sarebbe no.

Av­va­len­do­ci del controllo di sicurezza come esempio, risulta più facile chiarire come le ca­rat­te­ri­sti­che di sistema rendano com­pli­ca­to il cambio di fornitore. Un controllo di questo tipo prende in con­si­de­ra­zio­ne dei requisiti tecnici, or­ga­niz­za­ti­vi e con­trat­tua­li. Per attestare la sicurezza di un sistema si ricorre a una cer­ti­fi­ca­zio­ne. Ma questa cer­ti­fi­ca­zio­ne è 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 cer­ti­fi­ca­zio­ne. L’esborso ag­giun­ti­vo aumenta perciò i costi legati al passaggio, di­sin­cen­ti­van­do­lo e quindi con­tri­buen­do 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 im­por­tan­ti di un’azienda sono ar­chi­via­ti nell’in­fra­strut­tu­ra cloud di un provider. Se si decide di affidarsi a un fornitore di servizi diverso per l’ela­bo­ra­zio­ne dei dati, allora bisogna tra­sfe­ri­re i dati at­tra­ver­so la rete. Questa tra­smis­sio­ne comporta però dei costi. Per questo motivo può risultare in­te­res­san­te affidare l’ela­bo­ra­zio­ne al provider iniziale. In questo modo si scatena però un inar­re­sta­bi­le effetto lock-in.

Più dati si ar­chi­via­no e più risulta saldo il rapporto e quindi più forte l’effetto lock-in. Se il metodo di gestire la propria attività fa ri­fe­ri­men­to a funzioni, API e con­fi­gu­ra­zio­ni spe­ci­fi­che per fornitori, risulta più difficile sbro­glia­re la matassa. Come già accennato, nei casi più estremi tutte queste com­po­nen­ti ap­par­ten­go­no a un solo provider di servizi gestiti. Anche le soluzioni su misura create da una società di in­ge­gne­ria in­for­ma­ti­ca vengono rese di­spo­ni­bi­li con riserva. Un elevato grado di modifiche ad hoc rende il cliente for­te­men­te legato al fornitore del servizio.

Volendo rias­su­me­re le capacità tecniche fon­da­men­ta­li comuni a tutti i cloud ne abbiamo iden­ti­fi­ca­te tre:

• Software Defined Net­wor­king (SDN): invece di uti­liz­za­re e con­fi­gu­ra­re router e switch, vengono impiegate reti e di­spo­si­ti­vi 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 di­spo­si­ti­vi fisici di ar­chi­via­zio­ne di massa.
• Soluzioni di ser­ver­less computing: le “In­fra­struc­tu­re as a Service” (IaaS) e i “Container as a Service” (CaaS) servono a vir­tua­liz­za­re sistemi operativi e ap­pli­ca­zio­ni. Con le “Function as a Service” (FaaS) come “AWS Lambda” e “Microsoft Azure Functions” si mettono a di­spo­si­zio­ne singole funzioni per l’accesso ai dati.

Un ambiente di cloud computing comprende aspetti tecnici quali hosting, ar­chi­via­zio­ne e ap­pli­ca­zio­ni, ai quali si vanno ad ag­giun­ge­re aspetti or­ga­niz­za­ti­vi relativi alla con­fi­gu­ra­zio­ne, all’as­si­sten­za e agli aspetti giuridici. Un ambiente cloud specifico punta a modo proprio su diversi di questi aspetti. Data la varietà delle pos­si­bi­li­tà risulta facile intuire quanto complessa possa risultare me­dia­men­te la mi­gra­zio­ne da un fornitore a un altro:

I prodotti cloud so­pra­men­zio­na­ti come IaaS, PaaS, SaaS e CaaS altro non sono che servizi. Vengono messi a di­spo­si­zio­ne dai provider in cambio del pagamento di un canone, ma in nessun momento ap­par­ten­go­no al cliente che li adopera. Sta perciò al provider decidere se e a quali con­di­zio­ni offrire i servizi, come spe­ci­fi­ca­to 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, al­tri­men­ti il provider aumenta il prezzo o cambia le con­di­zio­ni a proprio favore. So­li­ta­men­te il fornitore ha il coltello dalla parte del manico, in quanto il cliente dipende da lui.

I motivi per la di­pen­den­za da un provider possono anche ve­ri­fi­car­si lato cliente. Ad esempio, quando i la­vo­ra­to­ri di un’azienda sono abituati a lavorare con un de­ter­mi­na­to programma o tec­no­lo­gia fornita da un provider. I tecnici sono so­li­ta­men­te spe­cia­liz­za­ti nell’uso di de­ter­mi­na­te tec­no­lo­gie. Passando a un altro fornitore di servizi, il personale ha bisogno di essere nuo­va­men­te istruito o ad­di­rit­tu­ra può risultare ne­ces­sa­rio fare nuove as­sun­zio­ni.

Per scampare il pericolo del vendor lock-in i dati e i processi devono essere migrati a un nuovo provider. Una mi­gra­zio­ne di questo tipo rap­pre­sen­ta nella maggior parte dei casi un pro­ce­di­men­to com­pli­ca­to. Poiché il benessere della propria impresa dipende dal successo della mi­gra­zio­ne, questa deve essere pia­ni­fi­ca­ta e messa alla prova prima di procedere. Ma anche prestando massima cautela non è possibile escludere che si pre­sen­ti­no degli errori, anche in un secondo momento. Una mi­gra­zio­ne complessa rap­pre­sen­ta 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 con­tra­star­lo stra­te­gi­ca­men­te sin da subito. Invece di puntare su un provider e con­fe­rir­gli pieno potere, conviene basarsi su più aspetti. Inoltre, as­si­cu­ra­te­vi di strut­tu­ra­re i sistemi interni in modo che sia poi possibile so­sti­tuir­ne i com­po­nen­ti.

Nei seguenti paragrafi abbiamo riassunto alcune misure stra­te­gi­che, or­ga­niz­za­ti­ve e tecniche spe­ci­fi­che che po­treb­be­ro aiutarvi a evitare l’effetto di vendor lock-in.

Se già al momento della scelta dei fornitori e dei servizi viene con­si­de­ra­to il pericolo di vendor lock-in, la scelta è già più con­sa­pe­vo­le. Per esempio, se si valuta l’offerta tec­no­lo­gi­ca com­pa­ra­bi­le 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.

Ge­ne­ral­men­te una verifica rigorosa è d’obbligo: capire quali sono le proprie esigenze in relazione alla tec­no­lo­gia tenendo conto dell’in­fra­strut­tu­ra IT già esistente è in­di­spen­sa­bi­le. L’analisi delle offerte presenti sul mercato parte proprio dalla co­no­scen­za delle proprie necessità e sistemi in­for­ma­ti­ci. È im­por­tan­te prendere in con­si­de­ra­zio­ne le tendenze emergenti e il termine (End of Life) delle tec­no­lo­gie. Se, ad esempio, ci fossero dei sistemi legacy all’interno della vostra struttura dovreste rim­piaz­zar­li.

Se una tec­no­lo­gia o un provider dovesse com­por­ta­re il rischio di vendor lock-in, dovreste definire sin da principio una strategia di fuga. In questo modo, qualora ne­ces­sa­rio, potreste reagire in modo rapido e preciso a cam­bia­men­ti per voi poco adatti. Saprete già cosa fare e sarete già a co­no­scen­za dei costi e dei rischi.

Il modo migliore per impedire che si venga a creare una si­tua­zio­ne di vendor lock-in è quello di non dipendere da un solo provider. Invece di ar­chi­via­re tutti i processi aziendali nel cloud, scegliete una soluzione ibrida. Per esempio, potreste usare un cloud privato come in­te­gra­zio­ne alle risorse cloud esterne. In questo modo i processi centrali e i relativi dati rimangono sotto il vostro controllo, ga­ran­ten­do­vi la sovranità dei dati.

Secondo lo stesso principio potrebbe risultare van­tag­gio­so anche affidarvi a diversi servizi cloud invece che a uno solo. In questo caso risulta però decisivo poter accedere a tutti i servizi adottati at­tra­ver­so un’unica in­ter­fac­cia apposita. Solo in questo modo è possibile or­ga­niz­za­re un sistema coerente mettendo assieme le singole com­po­nen­ti. Inoltre, dovreste pre­di­li­ge­re i servizi di quei provider che sup­por­ta­no l’in­te­ro­pe­ra­bi­li­tà at­tra­ver­so un’in­ter­fac­cia aperta.

Tutte queste misure risultano efficaci soltanto se le strutture ef­fet­ti­va­men­te esistenti vengono gestite in­ter­na­men­te alla vostra azienda. Se i processi vengono eseguiti lontano dai radar, allora il rischio di vendor lock-in sussiste no­no­stan­te tutti gli sforzi in­tra­pre­si. Questo risulta par­ti­co­lar­men­te chiaro dando uno sguardo ai co­sid­det­ti “dark data”. Con questo termine ci si riferisce ai dati che esistono all’esterno degli appositi sistemi. Il modo migliore per ottenere l’in­di­pen­den­za è renderla un obiettivo di­chia­ra­to e stan­dar­diz­za­re il più possibile processi e sistemi.

Le misure tecniche più facili per evitare il vendor lock-in con­si­sto­no nel rifiuto a impiegare sistemi e formati pro­prie­ta­ri. Se si punta co­stan­te­men­te su standard open source e freeware è im­pos­si­bi­le per de­fi­ni­zio­ne diventare di­pen­den­ti da un singolo provider. Tuttavia, questo approccio risulta in­frut­tuo­so in relazione al cloud se non si ha il controllo delle risorse hardware.

For­tu­na­ta­men­te, negli ultimi anni sono stati svi­lup­pa­ti potenti strumenti di or­che­stra­zio­ne che servono proprio a questo. Tra questi si an­no­ve­ra­no OpenShift e Terraform. Questi strumenti servono da livello in­ter­me­dio e di­sas­so­cia­no le proprie esigenze dal livello del provider, che sta alla base dell’in­fra­strut­tu­ra in­for­ma­ti­ca. In questo modo risulta possibile creare un’in­fra­strut­tu­ra IT completa suddivisa su più cloud.

La parola chiave in questo caso è “In­fra­struc­tu­re as Code” (IaC). At­ten­zio­ne: “code” e non “service”. Mentre un servizio viene affittato, il codice rimane sotto il proprio controllo. All’interno del codice vengono definite le strutture de­si­de­ra­te. Queste con­ten­go­no singole com­po­nen­ti, così come i relativi col­le­ga­men­ti. Oltre alla do­cu­men­ta­zio­ne 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 or­che­stra­zio­ne mettono a di­spo­si­zio­ne i sistemi in­for­ma­ti­ci cor­ri­spon­den­ti. È possibile sud­di­vi­de­re le singole com­po­nen­ti su più cloud. Questo funziona per le in­fra­strut­tu­re 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 con­tri­bui­sce si­gni­fi­ca­ti­va­men­te a pro­teg­ge­re dal vendor lock-in.