Abbiamo visto come una delle proposte di valore primarie del cloud sia la sua flessibilità. Tuttavia, questa stessa caratteristica è tanto interessante quanto facile da compromettere: nel creare e gestire un servizio in cloud, infatti, il rischio di lock in, ovvero di dipendenza dal Cloud Vendor, è un aspetto da non trascurare assolutamente.
Cos’è il (cloud vendor) lock in?
Chi ha familiarità con i termini economici sa che il lock-in è quel fenomeno che, pur in assenza di vincoli contrattuali espliciti, rende di fatto un cliente dipendente da un fornitore per prodotti e servizi, in quanto il passaggio ad un altro fornitore richiederebbe investimenti (economici, di tempo o di altro tipo di risorse) talmente gravosi da rendere difficoltoso, irragionevole o antieconomico un cambio i cui vantaggi sarebbero altrimenti significativi.
Oltre ad impedire di cogliere opportunità di miglioramento, una situazione di lock in può di fatto annullare il potere contrattuale del cliente, obbligandolo ad accettare anche modifiche in senso peggiorativo delle condizioni (economiche o di SLA) di fornitura del servizio.
Si tratta di una circostanza certamente indesiderabile, ma purtroppo limitatamente mitigabile, soprattutto laddove esistono vincoli tecnologici forti, come tecnologie acquisibili solo da un unico o un numero molto limitato di fornitori. Il modo migliore per cercare di evitare il rischio è quello di definire e adottare misure congrue già all’avvio del progetto di Cloud Migration.
Quali sono i fattori che favoriscono il cloud vendor lock in?
In ambito cloud il rischio di lock in è particolarmente sensibile per diversi fattori, tutti derivanti – sebbene in modo diverso – dall’aspetto tecnologico. Vediamo i principali fattori di rischio che possono motivare un lock in:
- Rischio di trasferimento dei dati: non è facile spostare i dati da CSP a un altro, sia per questioni meramente legate alla loro mole – potenzialmente molto elevata e, dunque, tale da rendere le attività di trasferimento eccessivamente onerose – sia per questioni di formattazione. Ogni vendor ha infatti specifiche tecniche leggermente diverse da quelle dei competitor e questo fa sì che per migrare i database attivi possa rendersi necessario riformattare i dati per adeguarli alle specifiche del nuovo vendor.
- Rischio di trasferimento dell’applicazione: le applicazioni vengono create sfruttando molti servizi gestiti specifici di un Cloud Service Provider, la riconfigurazione per l’esecuzione nativa su un altro vendor può essere un processo estremamente costoso e difficile.
- Rischio di trasferimento dell’infrastruttura: come anticipato sopra, ciascuno dei principali Cloud Service Provider opera in modo leggermente diverso. Questo significa che anche dal punto infrastrutturale vi sono differenze che devono necessariamente venire gestite in fase di trasferimento.
- Rischio di conoscenza umana: ogni volta che si realizza una Cloud Migration il team IT deve necessariamente aggiornare i propri skill per poter operare nel nuovo ambiente, soprattutto se non si appoggia ad un MSP. Questo fa sì che in un’azienda si crei un importante bacino di conoscenze istituzionali sugli strumenti e le configurazioni specifici di un determinato vendor, conoscenze da aggiornare anche massicciamente in caso di passaggio ad un altro fornitore.
,---------------------------------------.---------. | | | | ,-----------------------------. | . | | | | | | | | | ,-------------------. | | | | | | | | | | | | | | `---- ,---- | | | | | | | | @ | | | | | | | ,---------"---------: | `----' | | | | | | | | `----: ,---------. | `---------. | | | | | | | | | . | | . | | ---------' | | | | | | | | | :----' | | | | | ,--------------: | | | | | | | | | . | `----' | | | ----. | | | | | | | | | | `----"--------- | | `---------' | | | | | `------------------------' `-------------------'
7 best practice cloud per allontanare il lock in
Sapendo quali sono i fattori che amplificano il rischio di lock in del cloud vendor, è anche possibile adottare pratiche e schemi idonei a mitigarne gli effetti. Ovviamente, la loro adozione deve essere commisurata alle specifiche della singola azienda: come sempre infatti, bisogna valutare ogni scelta in termini di costo-opportunità. Affidarsi ad un partner con solidi skill in ambito cloud può in questo senso fare davvero la differenza, permettendo di effettuare valutazioni a più ampio spettro e raggiungere il giusto mix di vantaggi operativi e indipendenza dal vendor.
- Approccio multi-cloud.
Un approccio multi cloud è indubbiamente la prima di tali best practice.
L’adozione di un unico vendor cloud è spesso vista come vantaggiosa in quanto permette di concentrare gli investimenti IT (economici ma anche di creazione degli opportuni skill) nella direzione di un solo vendor, massimizzando quindi la loro efficacia. Tuttavia, questa pratica ha come contraltare la creazione di un legame con il vendor stesso difficile da rescindere.
Al contrario, il multi cloud abilita l’azienda cliente a sfruttare le molteplici opportunità offerte dai vari vendor cloud senza rimanere legati a doppio filo con un solo soggetto.In quest’ottica, la collaborazione con un managed service provider come Bottega52 è di per sé un utile strumento per bilanciare le due esigenze di efficienza e di libertà: rende infatti possibile accedere al know how verticale legato ai principali vendor cloud senza dover moltiplicare gli investimenti per acquisire internamente tutte le competenze specifiche di ognuno di essi. - Approccio IaaS-first piuttosto che di PaaS e SaaS first.
Il ricorso all’impiego di risorse PaaS e SaaS rappresenta un importante strumento di semplificazione delle attività di sviluppo, ma vincola molto di più l’azienda ad uno specifico vendor rispetto ad un approccio prevalentemente IaaS. Nel caso del SaaS, si è legati ai particolari processi implementati dal SaaS scelto, che solo in parte si sovrappongono, o sono comparabili, ai software alternativi; nel caso del PaaS, non è detto che sia facile reperire una platform alternativa a quella scelta per la realizzazione di un certo insieme di funzionalità del software.
Un approccio al cloud maggiormente orientato all’impiego di risorse IaaS garantisce maggiormente la portabilità di infrastruttura, dati, applicativi tra i diversi fornitori cloud, in particolare grazie a tecniche di Infrastructure as Code (IaC) e containerizzazione. - Adozione di standard aperti.
Come sempre, la standardizzazione semplifica la portabilità. Di conseguenza, laddove possibile, è preferibile far uso di soluzioni e protocolli standard nella realizzazione delle interfacce e delle integrazioni di sistemi: in questo modo, la sostituzione di un sotto sistema sarà più facile in quanto la disponibilità di altri strumenti e sistemi compatibili con quello standard sarà più probabile. - Mantenimento della proprietà dei dati.
Per ovviare ai problemi di migrazione dei dati, è buona prassi, laddove possibile, realizzare e mantenere un proprio data lake. In questo modo si riescono a prevenire i problemi di migrazione causati dell’assenza – o poca funzionalità- di meccanismi di migrazione dei dati. A prescindere dall’esistenza di tali vincoli tecnici, questo permette di garantire inoltre l’efficienza economica del trasferimento: man mano che i dati aumentano di dimensioni, infatti, il costo e la durata della migrazione di tali dati potrebbero aumentare, diventando alla fine proibitivi e determinando il lock in con il particolare fornitore del cloud. - Approccio open source.
Questa è una ragione tradizionalmente valida anche in altri ambiti: l’adozione di soluzioni open source nello sviluppo dei prodotti digitali dà la libertà di prenderne il pieno controllo in qualsiasi momento e/o trovare con maggiore facilità partner con cui collaborare per adattare la soluzione alle proprie esigenze anziché doversi piegare a quelle del vendor. - Sviluppo di una Exit Strategy chiara dal giorno zero.
Questo è forse uno degli aspetti più trascurati, a torto. Avere una solida strategia di uscita dal Cloud (cloud-exit) è infatti importante tanto quanto avere una buona strategia di migrazione in cloud.
Diventare utenti di un cloud vendor senza valutare l’eventualità di dover smettere di utilizzarlo e senza immaginare il modo in cui questo potrà avvenire è la causa per cui molti operatori si trovano impreparati di fronte a questa evenienza. I responsabili IT devono sapere dove andranno i dati, come gestire la transizione tecnica e quindi come affrontare eventuali problemi aziendali o legali che potrebbero sorgere a seguito della migrazione.
Prevedere già dal giorno 0 come “uscirne” permette di ridurre i vincoli determinati dalle incertezze operative e dal rischio di disservizi. - Scelta di un Managed Service Provider piccolo e agile.
Su questo tema ci sono due scuole di pensiero. La prima liquida come ovvi e banali i benefici di una struttura più piccola, snella e pronta al confronto costruttivo con il cliente; la seconda invece, all’opposto, identifica la dimensione aziendale come un indicatore di solidità e, dunque, una garanzia. Come sempre, probabilmente c’è del vero in entrambe. Di certo, non bisogna trascurare il fatto che uno dei fattori determinanti quando si parla di lock in – ma anche di altre questioni paracontrattuali e di servizio – è il rapporto di forza tra cliente e fornitore. È evidente che una forte sproporzione tra fornitore e cliente mette quest’ultimo in condizione di subire maggiormente il volere del primo. Nuovamente, l’ottimale è commisurare bene il rapporto di forza e la capacità operativa necessari.
Un supporto competente contro il lock in
Bottega52 opera per limitare i rischi di vendor lock in già dalla fase iniziale del percorso di Cloud Migration. Durante il Cloud Migration Workshop, infatti, vengono valutate tutte le specifiche dell’applicazione e della realtà aziendale, per poter definire da subito i giusti parametri che permettano di ottenere il massimo beneficio dalla Cloud strategy senza legarsi eccessivamente ad un unico Cloud Vendor.
Inoltre, il team Bottega52 è costantemente aggiornato sugli sviluppi tecnici e commerciali relativi alla proposta di tutti i maggiori Cloud Vendor, così da permettere al cliente di concentrare le proprie attività sulle esigenze di business, evitando di dover disperdere energie e risorse nell’acquisizione di skill legati ai singoli fornitori di cloud.
Ti piace leggere?
A noi piace scrivere, dai un’occhiata alle nostre guide e approfondimenti
Library di Innovazione Digitale.--. .---. .---|__| .-. |~~~| .--|===|--|_ |_| |~~~|--. | |===| |'\ .---!~| .--| |--| |%%| | |.'\ |===| |--|%%| | | |%%| | |\.'\ | | |__| | | | | | | | \ \ |===| |==| | | | | | |__| \.'\ | |_|__| |~~~|__| | |===|--| \.'\|===|~|--|%%|~~~|--| ^--^---'--^ `-'`---^-^--^--^---'--'