Vediamo perché unire multicloud e open source Le permette di valorizzare i punti di forza del Suo provider attuale, senza rinunciare alla flessibilità promessa dal cloud pubblico.
L'open source come leva per cogliere appieno la flessibilità del cloud
Uno dei principali punti di forza del cloud è la prospettiva di una flessibilità pressoché illimitata. Tuttavia, se cambiare cloud provider comporta costi rilevanti, complicazioni legali o incompatibilità tecnologiche, quella flessibilità ne esce fortemente ridimensionata.
Affidarsi a più cloud provider potrebbe sembrare la soluzione ideale, ma le cose non sono così lineari. Analizziamo il tema del vendor lock-in per i clienti cloud, spiegando perché il solo multicloud non basta a risolverlo e come l'open source può fare la differenza.
Come nasce il vendor lock-in nel cloud
Quando una tecnologia è disponibile presso un solo provider e non può essere utilizzata senza versare a quest'ultimo canoni di licenza o manutenzione, si parla di vendor lock-in. Il passaggio al cloud dovrebbe liberare da questo tipo di vincolo perché, in larga misura, consente di utilizzare i servizi alle proprie condizioni. Tutti i principali cloud provider, ad esempio, offrono una tariffazione pay-as-you-go: in teoria è possibile spegnere il proprio ambiente, esportare dati e macchine virtuali e abbandonare la piattaforma in qualsiasi momento.
Inoltre, i servizi cloud sono in genere progettati per supportare la migrazione dei dati sia in ingresso sia in uscita. I vendor hanno sviluppato servizi e strumenti per agevolare la migrazione di database e applicazioni, sia verso il cloud sia tra cloud diversi.
Cambiare provider nel cloud, però, non è un'operazione lineare. Prendiamo il caso del trasferimento dei dati: migrare dati tra server che utilizzano lo stesso motore di database (migrazione omogenea) è relativamente semplice. Una variazione minima come il numero di versione, però, può far emergere una serie di criticità da risolvere prima di passare a un motore diverso (migrazione eterogenea), al punto da richiedere un approccio e un'applicazione completamente differenti.
Va inoltre considerato il caso delle applicazioni costruite per sfruttare i punti di forza specifici delle offerte del vendor attuale: riconfigurarle per farle girare nativamente su un altro cloud è un'operazione complessa. Ed è qui il nocciolo del vendor lock-in nel cloud: ogni provider opera in modo leggermente diverso, perciò il passaggio dall'uno all'altro porta sempre con sé un certo grado di difficoltà, a partire dal gap di competenze del team rispetto alle tecnologie e all'approccio del nuovo vendor.
Perché il multicloud da solo non è la risposta
Un approccio multicloud riduce la dipendenza da un singolo vendor, ma non è la bacchetta magica contro il vendor lock-in. Spostare un'applicazione o un workload esistente da un deployment on-premises all'infrastruttura di un cloud provider è relativamente semplice e l'acquirente è ragionevolmente protetto dal vendor lock-in. Quando si paga un cloud vendor per server, rete e storage, il costo per spostare le proprie macchine virtuali su un altro cloud provider equivale, in sostanza, al costo per imparare una nuova API di provisioning.
Il discorso cambia con i servizi. I provider di cloud pubblico tendono a progettare i propri servizi con strumenti di gestione proprietari che funzionano solo all'interno del loro ecosistema. Per esempio, per fare il deploy di una sola applicazione su Amazon Web Services (AWS) può essere necessario utilizzare servizi come Kinesis, DynamoDB, ElastiCache, Simple Queue Services, TimeStream e Lambda – tutti servizi proprietari disponibili solo su AWS.
Considerato il costo del refactoring di un'applicazione sviluppata per una piattaforma cloud specifica e portata su un'altra, l'utilizzo di servizi cloud che combinano in modo articolato componenti proprietari di alto livello rende difficile disaccoppiare la scelta della tecnologia da quella del cloud vendor. In teoria è possibile eseguire lo stesso workload su più cloud, ma significa allinearsi al minimo comun denominatore e rinunciare al potenziale di innovazione che il cloud pubblico abilita.
La Sua strategia multicloud avrà più probabilità di successo se ogni applicazione viene progettata e realizzata sul cloud più adatto. Spesso, però, è la convenienza più che l'analisi a determinare dove viene fatto il deploy di un workload. Occorre valutare i punti di forza di ciascun cloud e il loro impatto sullo specifico caso d'uso aziendale. In assenza di dati affidabili sulle prestazioni di un workload in un determinato cloud, l'allocazione al cloud più adatto diventa una questione di fortuna più che di analisi.
Come l'open source aiuta a prevenire il vendor lock-in
Le aziende hanno a disposizione un'ampia gamma di piattaforme e strumenti di cloud computing open source per ridurre la dipendenza dalle piattaforme proprietarie. L'open source disaccoppia di fatto la scelta tecnologica da quella del cloud vendor. Gli sviluppatori possono adattare il codice sorgente di queste piattaforme e strumenti alle proprie esigenze nelle attività di deploy, provisioning e gestione di workloads e ambienti.
Kubernetes, il sistema di orchestrazione dei container per automatizzare deployment, scaling e gestione del software, e la service mesh Istio sono stati rilasciati in open source da Google, che si è affermata come uno dei principali leader e contributori della community open source.
Molti strumenti di Google Cloud Platform (GCP), per esempio, si basano su tecnologia open source e GCP aggiunge un layer di gestione operativa che ne aumenta il valore e consente ai clienti di adottare rapidamente la tecnologia. Google Kubernetes Engine (GKE) e servizi come Dataflow, Cloud Composer, Managed Service for Prometheus e Cloud Data Fusion sono progettati in modo che, in sostanza, sia possibile prendere la stessa logica di business ed eseguirla altrove semplicemente reimplementando la parte operativa.
Una piattaforma come Anthos di Google abilita la modernizzazione delle applicazioni in ambito hybrid multicloud, consentendo di orchestrare ed eseguire cluster Kubernetes e persino VM (in private preview) su GCP, AWS, Azure, cloud privato e bare metal. Anche quando Kubernetes non è la base dell'intero cloud, resta uno strumento prezioso per orchestrare parte dei workloads in esecuzione all'interno di un cloud pubblico.
Per garantire la sostenibilità futura del software open source, le aziende dovrebbero incoraggiare e incentivare i contributi open source dei propri dipendenti. Un recente report di CNCF ha rilevato che il 96% delle organizzazioni utilizza oggi Kubernetes e che nell'ultimo anno il numero di altri progetti open source cloud-native è cresciuto in modo esponenziale. Il software open source può supportare una strategia multicloud efficace ed evitare alle aziende di restare in ostaggio di un singolo cloud.
Affidarsi in misura significativa a servizi open source ha però un rovescio della medaglia: la responsabilità delle Day 2 operations ricade su di Lei. Ciò significa farsi carico di monitoraggio, aggiornamenti e sicurezza, con un carico di lavoro aggiuntivo che potrebbe non giustificare le risorse e i processi extra necessari.
Bisogna inoltre operare con meccanismi di supporto minimi, quasi sempre privi di SLA: in caso di outage in produzione, si è soli. E cosa succede quando si vogliono aggiungere funzionalità a un servizio chiave? I Suoi Engineers dovranno ritagliarsi del tempo per contribuire alla community open source invece di concentrarsi sul potenziamento delle funzionalità core del prodotto. Come per la sola strategia multicloud, affidarsi al solo open source per evitare il vendor lock-in non è la risposta.
I prossimi passi
Come fare, allora, per sfruttare la vera potenza del cloud senza i vincoli che un vendor potrebbe imporre? Lavorare con un partner che conosca a fondo tutti i principali cloud provider può aiutarLa a pianificare la strategia cloud in modo da estrarre il massimo valore di business dal vendor scelto.
Il team di DoiT non solo vanta una profonda esperienza nell'aiutare le aziende a utilizzare più cloud per raggiungere i propri obiettivi di business, ma ha anche sviluppato strumenti open source che semplificano le operations sul cloud, risolvono sfide tecniche complesse e aiutano a ridurre la dipendenza da piattaforme proprietarie. Con l'approccio giusto, può valorizzare i punti di forza specifici dell'offerta del Suo vendor attuale e godere al tempo stesso di tutta la flessibilità promessa dal cloud pubblico.