Il vendor lock-in è un tema dibattuto fin dagli anni ’80 e ’90 del secolo scorso; tema a cui si è contrapposto un movimento che ha portato allo sviluppo ed evoluzione del software open source. Negli ultimi anni il lock-in tecnologico è tornato ad essere al centro del dibattito in conseguenza della crescente affermazione dei servizi cloud e del modello “as a service” (IaaS, PaaS, SaaS…). Secondo uno studio condotto da Bain & Company nel 2020, il 65% dei CIO intervistati considera necessario l’utilizzo di una strategia multi-cloud; tuttavia, lo stesso studio mostra che il 71% degli intervistati utilizza i servizi di un solo cloud provider e il restante 29% concentra comunque gran parte delle proprie risorse su un singolo provider. Questa fotografia mostra chiaramente quanto il tema sia sentito e quanto scelte fatte negli anni scorsi pesino sulla capacità delle aziende di costruirsi valide alternative in tempi brevi.
Il modello XaaS ha innegabili benefici che hanno permesso a molte aziende di incrementare la propria competitività e il livello dei servizi a velocità impensabili con i modelli precedenti, non è quindi in discussione l’adozione; tuttavia, è necessario procedere in modo consapevole facendo scelte che non compromettano la propria libertà di scelta futura.
Vediamo tre elementi importanti della strategia aziendale che devono essere controllati e governati dal CIO per evitare il vendor lock-in dei servizi in cloud.
Molti cloud provider rendono difficile l’esportazione di dati e configurazioni applicative con conseguente rallentamento delle operazioni di migrazione in caso si voglia procedere con una diversificazione dei fornitori in favore di altri player di mercato. Inoltre, tipicamente l’esportazione dei dati è un servizio a pagamento e le tariffe applicate, che in genere sono legate al volume di dati spostati, possono generare voci di costo considerevoli non pianificabili in anticipo (essendo legate al volume di dati prodotti nel tempo). In questo caso è necessario un approccio critico alla valutazione dei termini e condizioni posti dal provider con relativa negoziazione degli stessi prima della sottoscrizione del contratto, in modo da garantirsi libertà d’azione a un prezzo ragionevole quando si verificherà il bisogno di operare queste scelte.
A parità di servizio offerto inoltre ogni provider presenta caratteristiche distintive e strumenti dedicati, di solito a tali strumenti viene data grande enfasi in termini di performance e vantaggi competitivi; nella realizzazione di ottimizzazioni mirate per il singolo provider è sempre utile considerare tanto i benefici quanto le limitazione nella libertà di migrare verso altre soluzioni. Questo assessment preliminare permette di esplicitare i razionali delle proprie scelte e di definire il piano d’azione da intraprendere per supportare un cambio di strategia.
L’inerzia gioca un ruolo determinante nella capacità di un’azienda di applicare la propria strategia cloud liberamente: la semplicità con cui è possibile avviare iniziative nel cloud porta ad aumentare progressivamente il proprio coinvolgimento con un provider, ritrovandosi presto a dipendere dalle soluzioni di quest’ultimo. È quindi fondamentale definire il proprio framework di cloud governance così da stabilire le regole di accesso e fruizione dei servizi ed esplicitare la strategia da applicare per evitare di incorrere nel vendor lock-in; tra le regole di buon senso da applicare c’è sicuramente la diversificazione dei fornitori di servizi cloud per impedire in modo trasversale il verificarsi di pericolosi sbilanciamenti nell’acquisto di servizi.
Un altro aspetto da tenere in grande considerazione è il formato di esportazione e la struttura dei dati esportati: alcuni provider, infatti, utilizzano formati compressi che richiedono software di decompressione proprietari per ricostruire i file originali. Inoltre, la struttura dei file potrebbe riflettere formati interni delle applicazioni con conseguente necessità di investire tempo e risorse per poter interpretare in modo corretto le informazioni ed esportarle. Un approccio efficace per mitigare questo rischio è approfondire il tema relativo al formato dei dati esportati preventivamente e selezionare fornitori in grado di supportare formati standard; parallelamente è necessario procedere con un’analisi delle strutture dati esportate e identificare il contenuto informativo da preservare, pianificando le azioni necessarie alla corretta migrazione verso altri fornitori o all’interno dei propri data center.
Le tecnologie proprietarie tendono ad essere collegate a uno specifico vendor. Se ad esempio si utilizzano piattaforme come Salesforce o ServiceNow, il lock-in avviene sia a livello di vendor che tecnologico; migrare verso un diverso provider richiede una completa reingegnerizzazione dei propri processi e delle proprie applicazioni. Questo genere di restrizione è particolarmente limitante quando si utilizzano soluzioni SaaS perché in caso di cancellazione della sottoscrizione o deplatforming l’effetto è il blocco totale del servizio e in molti casi di accesso ai propri dati.
Un altro aspetto critico è relativo alla realizzazione di applicazioni in cloud che fanno uso di soluzioni specifiche del singolo provider. Se ad esempio si utilizzano servizi FaaS (tra cui AWS Lambda, Azure Functions, Google Cloud Functions) è necessario tenere in considerazione che esistono specificità di contesto che richiedono una reingegnerizzazione del software se si vuole migrare verso un altro provider. Maggiore è l’utilizzo di soluzioni specifiche del singolo provider e maggiore sarà il costo complessivo di migrazione che si dovrà sostenere nel caso di un cambio di strategia; in questo caso la soluzione che garantisce maggiore libertà di movimento è l’utilizzo di framework che implementano standard open e che garantiscono la portabilità del software realizzato sui diversi provider senza la necessità di procedere con una costosa attività di adattamento delle applicazioni.
Tipicamente i vendor di soluzioni proprietarie obiettano che anche nelle soluzioni open si verifica un lock-in tecnologico, ovvero la realizzazione di applicazioni richiede comunque l’utilizzo di determinate tecnologie (database, linguaggi di programmazione…), su cui è necessario investire. Pur essendo un’obiezione in linea teorica plausibile esiste però una differenza significativa nella capacità operativa e di portabilità; ad esempio tecnologie come Python, PostgreSQL o Kubernetes non sono legate a uno specifico vendor e in generale con le tecnologie open source è possibile utilizzare una vasta rete di aziende a livello globale per accedere a servizi, training e supporto in grado di garantire libertà di azione da parte del cliente che può operare le proprie scelte in autonomia sulla base della propria strategia e dei vantaggi offerti dal mercato. Infine, le tecnologie open evolvono molto più rapidamente e sono più sicure e robuste di quelle proprietarie grazie a una rete globale di tecnici che collaborano attivamente alla loro evoluzione, non paragonabile per dimensione a nessuna struttura aziendale presente sul mercato.