Le aziende stanno riconoscendo la necessità di passare a logiche di hybrid cloud per riuscire a scalare efficacemente la propria infrastruttura. Molte organizzazioni, infatti, hanno un patrimonio applicativo consistente, difficile da gestire “in casa”. Da alcuni anni – cioè dal momento in cui si sono rese conto delle potenzialità delle nuove tecnologie in cloud – la volontà di crescere in modo più veloce unite alle caratteristiche del public cloud hanno spinto le aziende a estendere la propria capacità di calcolo, di storage e di disponibilità.
Nel concreto, però, ciò significa anche dover gestire una transizione che facile non è: vanno governati i costi ricorrenti, che rischiano di sfuggire di mano, bisogna pianificare con precisione il business case che supporterà la migrazione e riconoscere gli applicativi che devono essere migrati.
Gli errori più comuni
Ci sono, infatti, una serie di errori che vengono comunemente fatti durante il percorso di migrazione e anche prima, nel momento in cui la migration viene organizzata: si tratta del processo principale, perché eventuali inefficienze a journey avvenuto dipendono in gran parte da una progettazione preliminare non adeguata.
Uno dei primi errori è credere che la sola migrazione a una soluzione IaaS (Infrastructure as a Service) sia sufficiente. In questi casi, invece, le organizzazioni non riescono a sfruttare appieno le capacità del cloud. La progettazione di workload cloud native consente di sfruttare appieno le potenzialità e i benefici della piattaforma cloud, sfruttando – e, quindi, facendo “leverage” su questi aspetti – la scalabilità, i servizi PaaS e i meccanismi di pay per use dei componenti.
“Quando sei in modalità PaaS non hai più problemi di dimensionare l’infrastruttura in base al carico che devi avere” puntualizza Daniele Salpietro, Technical Account Manager di Maticmind. “Se l’approccio è solo infrastrutturale, non porta benefici”.
Il secondo errore – che è più un problema intrinseco nelle soluzioni di cloud pubblico – è non riuscire a comprendere i costi che dovranno essere governati post-migrazione. Ogni Cloud Service Provider (CSP) usa tecnologie proprietarie: spesso farle parlare fra di loro, secondo logiche multicloud, non è semplice. Ciò significa che le organizzazioni possono trovarsi ad aver effettuato la migrazione aderendo eccessivamente a strumenti di natura proprietaria, rischiando di finire ingabbiate in fenomeni di lock-in.
“Spesso i clienti si trovano a governare i costi e i consumi legati al cloud anche quando i workload non cambiano: è un problema che ci viene spesso chiesto di governare fin da subito” fa notare Salpietro. “Molti costi sono trascurati, come il trasferimento dei dati cross-zone e cross-region; come cambia il licensing; i backup. Vanno relazionati con il business”.
Infine, c’è il tema dell’overprovisioning che, in un certo senso, è figlio delle logiche on-premise in cui avere capacità di calcolo in eccesso consente all’azienda di aver a disposizione un’infrastruttura più longeva: con il cloud la logica è molto diversa nel contesto di costi a consumo. Avere più istanze del necessario e risorse che non vengono sfruttate significa pagare per qualcosa che non serve all’organizzazione.
Calcolare i costi partendo dal Total Cost of Ownership (TCO) dell’azienda pre-cloud serve, quindi, a comprendere appieno la situazione prima e dopo la migrazione. “Non è facile identificare i costi ricorrenti dell’azienda. Il TCO comprende licenze, infrastrutture, tutto ciò che fa parte di quei costi che domani cesseranno per effetto del Cloud” spiega Salpietro. “Una volta mappati i costi è possibile definire una corretta allocazione dei costi anche nel cloud”.
Hybrid cloud, come governare la migrazione
Ne consegue, quindi, che la logica del multicloud è preferibile perché permette di governare più facilmente i costi, migrando l’infrastruttura senza usare il 100% di soluzioni proprietarie. Ciò permette alle organizzazioni, nel momento in cui stanno delegando al di fuori dell’azienda la propria capacità di calcolo, di continuare ad avere il controllo della propria infrastruttura. Inoltre, tale approccio ottimizza i costi del cloud.
In altre parole, un system integrator funge da mediatore fra le tecnologie dei principali CSP e i bisogni dell’impresa e traduce le complessità dei Cloud Services Provider in un unico linguaggio, più facile da comprendere dalle organizzazioni attraverso l’utilizzo di tecnologie cloud native, ma non proprietarie. In questo modo, le organizzazioni possono proteggere il proprio business. A tal fine devono anche essere predisposte tecnologie che consentano di identificare i consumi dei vari CSP per ogni servizio e costruire dei modelli che diano chiara evidenza dei costi e di cosa può essere fatto per ottimizzarli.
“Oggi è un grosso problema il fatto che ogni CSP abbia la sua tecnologia di analisi dei costi” sottolinea Salpietro. “I clienti che vogliono una visibilità multicloud hanno bisogno di una prospettiva unica della loro infrastruttura informatica.”
Prima della migrazione, quindi, è necessario discutere delle caratteristiche del carico di lavoro a livello di business: si studia il business need, il workload placement e si analizzano le metriche che il cloud mette a disposizione in termini di consumi per capire i razionali della consumption e se c’è, per esempio, un overcommittment. Questo genere di considerazioni si può poi concretizzare in soluzioni di tuning del mondo cloud per com’è stato concepito dagli hyperscaler, oppure in una revisione architetturale.
Il tema delle licenze è un altro aspetto della migrazione che dev’essere governato con attenzione. Si tratta, infatti, di una revisione dei contratti in essere perché, in alcuni casi, le licenze di cui dispone l’organizzazione non sono valide per il cloud; quindi, le condizioni vanno rinegoziate e a volte, invece, completamente riviste.
Un’ottimizzazione continua
È a migrazione avvenuta, però, che inizia il vero lavoro di ottimizzazione del cloud, di continuo miglioramento, sia dei costi, sia delle prestazioni. Il cloud è una creatura viva e, perciò, muta nel tempo: i CSP possono integrare nuove tecnologie che devono essere valutate in base alle esigenze dell’organizzazione, per esempio.
“Il cloud sta evolvendo e alcune tecnologie potranno portare ulteriori vantaggi a vecchie e nuove applicazioni” evidenzia Salpietro. “Bisogna continuare a gestire il cloud per poter approfittare di tutti i vantaggi che i CSP offrono”.
