Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

costi e opportunità

Cloud in azienda, i fattori concreti da valutare per l’adozione

Più il tempo passa e più cresce la necessità delle aziende di essere più efficienti, produttive, resilienti e agili. Chi non riesce a stare al passo è destinato ad incontrare difficoltà in un prossimo futuro. Ecco tutte le opportunità, reali, offerte dal cloud computing

25 Feb 2019

Andrea Beggi

Solution Architect per Cloud e Data Center


Il costo del cloud computing non è così basso, per le aziende, come si tende a credere. Però sbaglia chi – nel considerare la migrazione – si ferma soltanto all’aspetto economico senza valutare con la dovuta attenzione anche i vantaggi o chi tenta scorciatoie che sembrano funzionali ma non consentono di sfruttare a pieno i benefici del cloud.

Un cambiamento di paradigma così dirompente non deve spaventare, per quanto complesso possa sembrare. Occorre però affrontarlo in maniera fluida, superando i pregiudizi e considerando anche fattori quali produttività, agilità e resilienza nel calcolo del costo totale di possesso (TCOe nella valutazione dei benefici.

Cloud in azienda: valutazioni economiche e opportunità

La valutazione delle implicazioni e il ritorno dell’investimento necessario sono tra i problemi più spinosi per le aziende che stanno considerando la migrazione in cloud. Mentre, però, da un lato sono chiari e facilmente individuabili tutti gli aspetti più evidenti (da CapEX a OpEx, outsourcing, scalabilità), sul fronte del TCO la visione è spesso limitata all’ambito meramente economico, senza approfondire le grandi opportunità che la migrazione può creare.

L’adozione del cloud computing passa per il superamento di pregiudizi culturali (“è roba mia, voglio microgestirla”), personali (“se sposto i server in cloud perderò il mio lavoro”), di sicurezza (“non so dove sono i miei dati, non mi fido”), e per la capacità di valutare i benefici nella loro interezza senza fermarsi al semplice computo economico.

Partiamo dalla (scomoda) verità: il cloud computing non costa poco. O, meglio, non costa poco come le aziende italiane sembrano pensare. Ma i fattori da considerare sono molteplici e riguardano il TCO – o la percezione del TCO, come vedremo – la propensione all’innovazione, la velocità del proprio mercato di riferimento, gli attori coinvolti nel cambio di paradigma, l’adozione di un modello di erogazione dei servizi e delle applicazioni che trascenda l’architettura tradizionale.

Nel computo del TCO è certamente corretto valutare la differenza di costo di esercizio tra le risorse on premises e quelle in cloud basandosi sui parametri “fisici” che sono facilmente individuabili e sono quelli tradizionalmente considerati (spazio, energia, condizionamento, manutenzione ecc. ecc.), ma spesso non vengono presi in considerazione altri aspetti fondamentali che, proprio per la loro difficile quantificazione, richiedono quel salto culturale a cui si faceva riferimento prima.

Una infrastruttura tradizionale porta con sé degli oneri che non siamo abituati a vedere poiché li abbiamo sotto gli occhi da così tanto tempo che ormai sono quasi invisibili.

Per esempio, con un modello tradizionale, quasi ⅔ del budget IT sono impegnati solo per tenere in piedi l’azienda, solo per il “metabolismo basale” (Gartner IT Key Metrics, 2017), quindi rimane poco spazio per l’innovazione e per la sperimentazione di nuove strade, e questa è una cosa che si tende a trascurare, ma è invece sempre più importante.

Se l’azienda è più libera di esplorare e di fare tentativi a costi molto inferiori, con modalità reversibili e meno impattanti sull’architettura tradizionale, sarà molto più semplice trovare nuove vie e nuovi processi più efficienti e più sicuri.

Prendiamo per esempio la tecnologia dei container: è un approccio innovativo e dirompente per erogare le applicazioni che non è stato ancora completamente scoperto dall’IT tradizionale, ma ha la potenza epocale che ebbe a suo tempo l’avvento della virtualizzazione, e si tratta di una tecnologia che è fatta per funzionare nativamente in cloud, ma richiede un approccio nuovo alle modalità architetturali che sottendono alle applicazioni, e ciò non può essere affrontato senza un cambio culturale che permetta l’adozione di nuove tecnologie. Stessa cosa per la buzzword del momento, i Big Data, che senza il cloud non esisterebbero né avrebbero possibilità di essere trattati.

Produttività, agilità, resilienza

Nel computo del costo totale di possesso e nella valutazione dei benefici vanno inclusi anche fattori importanti quali produttività, agilità e resilienza.

  • Produttività: essere liberi dalle pastoie delle infrastrutture tradizionali aumenta l’efficienza dei processi, concentra il focus sul proprio core business, aiuta a razionalizzare le risorse e permette di fare maggiore leva sui punti chiave che danno un vantaggio rispetto ai propri competitor. Il cloud concede la possibilità di dedicare risorse che sono state finora occupate a erogare servizi di base indifferenziati alle attività ad alto valore aggiunto, che sono lo strumento principale a disposizione delle aziende per ottenere vantaggi competitivi sul mercato.

https://lh6.googleusercontent.com/5QLu9thsCCGjI-niWe59tT3TuYB7eL9cfLMTCg3CWkxX7cfqiN_Hl8PUDhYO0XZYHas41ajeQm5fXQWCEQKistTEZi8QwctEn3Cjh5oFqF1sd5WeqMtjBOoOTkYMa7Hx05TCtSpk
  • Agilità: con l’adozione del nuovo modello aumenta esponenzialmente la capacità di rilasciare nuove applicazioni riducendo nel contempo il time-to-market, aumentano la frequenza di deploy e la quantità di nuove feature mentre il tempo per provisionare un nuovo ambiente è drasticamente ridotto. Tutti questi fattori aumentano l’agilità e la velocità, favorendo l’innovazione.
  • Resilienza: quando si decide di migrare in cloud, si passa da un modello in cui si paga per avere a disposizione delle risorse (che siano di proprietà, in locazione, on premises o in housing) a uno in cui si pagano SLA e SLO in base ai quali i servizi vengono erogati. La conseguenza di ciò è che tutti i problemi economici, operazionali e (parzialmente) di governance di eventuali downtime e/o degradi di performance non sono più in carico all’azienda, ma al service provider che è un attore che ha il focus delle proprie operazioni proprio sull’infrastruttura e sui servizi che si è deciso di migrare. Le migliori economie di scala, l’importanza dell’affidabilità e la necessità della massima sicurezza fanno sì che la Business Continuity sia nativa e più efficiente di quella fornita dai sistemi on premises, quindi che la resilienza sia più alta e i downtime ridotti. I costi legati ai downtime sono spesso difficili da calcolare perché trascendono il mero fatturato, e ci sono diversi studi che cercano di quantificarne l’impatto: questi sono alcuni dati da IDC e Ponemon.

https://lh4.googleusercontent.com/AFswP7RDlql2fgoBDwIYBNemGGwdyHra0iBr8i4_nD6KKmmbghL5FpV-itYKPiUwHsATdlebhvF2ZlnEkTb_4VXqsIRvMR-z2aLWvx1PY6nsIpX6WGgOSC00PTEvnTbXAsWXZpXi

Un cambio di approccio che parte dai vertici aziendali

La natura dirompente di un cambiamento di paradigma così profondo ha implicazioni anche sugli interlocutori interessati. Mentre fino a poco tempo fa il management aziendale aveva spesso nei confronti dell’IT l’atteggiamento “non mi interessa, basta che funzioni”, i nuovi obiettivi che impattano più in profondità sull’identità aziendale, sui processi, e sulla possibilità di rimanere competitivi nei mercati globali a velocissima evoluzione, devono essere abbracciati prima di tutto dall’alto. Gli interlocutori di chi ha un ruolo consulenziale su questi aspetti non sono più solo CIO e/o IT Manager, ma praticamente tutto il C-level, proprio perché le cose che si possono fare, una volta svincolati dalle pastoie di un’infrastruttura fisica on premises, sono molte di più e su un perimetro di funzioni e processi molto più ampio. E anche il CIO stesso deve ripensare il suo ruolo, passando da un dominio prettamente tattico/operazionale a uno in cui il suo ruolo diventi più attivo nelle strategie di business aziendale.

Confrontando due survey di Deloitte fatte a due anni di distanza, nel 2016 e nel 2018, emerge chiaramente che il cost saving non è più il principale motore di adozione del modello cloud, proprio per i motivi esposti qui sopra.

https://lh3.googleusercontent.com/HKXAUqB3bl-QIIq_1_TVnMhnaveqpTFU8dI2lGlAOlBbcbhM7tsiv4xyWNPvfCHolnouenJVaMXFMMIDOP1Bnez6o_rW6TM2q5cJkJBWQAnquxREXdeC_JbbFPxvNmwOY0J44f0G

https://lh3.googleusercontent.com/RIJPd3ka8Cqe7VaolHI7n3Dr8KRn8xnHCYwVgAE4pnJ2Pw0-UE8ymn5g2Sd4FHj0TOb0f7aU2UMbVjXmKjPe0JmGoZlJdqz8eGPZAv2lgXsTa6FiyhtKels0G1mvM2xKNnkItLs_

Uscire dalla comfort zone per innovare

Certo: il “lift and shift”, cioè il trasferimento dei carichi di lavoro su una infrastruttura in cloud che ricalchi pedestremente quella on premises, è un modo di sfruttare alcune delle possibilità del cloud, soprattutto in termini di scalabilità delle risorse, ma rappresenta una scorciatoia che non fa altro che rimandare il problema vero, cioè che il passaggio richiede un ripensamento e una trasformazione dell’architettura applicativa fatto per sfruttare in pieno le potenzialità che il cloud offre.

Sta arrivando il momento in cui smetteremo di ragionare in termini di  “risorse computazionali”, “CPU Virtuali”, “risorse condivise”, e tutta quella serie di strutture che rimappano in cloud gli oggetti dei tempi in cui i server erano fisici, facevano una cosa sola ed una alla volta.

C’era quella vecchia storiella di due persone che vogliono montare una mensola. Una, un nerd, sente il bisogno di un trapano battente, a 7 velocità, con mandrino autoserrante e punta al carburo di tungsteno, l’altra, la persona normale, ha solo bisogno di due buchi nel muro.

E’ ora che tutti si faccia le persone normali: non abbiamo bisogno di un cluster di server a 8 vCPU e 128 GB di RAM che “giri” presso il nostro service provider: abbiamo bisogno di un’istanza database a cui connetterci, con una serie di SLO definiti che assecondino i nostri carichi di lavoro (spesso ondivaghi e sottoposti a picchi periodici), che paghiamo se e quando la usiamo, senza preoccuparci di quello che c’è dietro per farla funzionare, che semplicemente non ci interessa e non ci serve sapere.

È anche evidente che una trasformazione di questo tipo non può essere un salto quantico: è necessario adottare una strategia fluida, un percorso misto di infrastrutture legacy che (Inter)operino con il cloud nativo, per creare un circolo virtuoso che indirizzi l’evoluzione in un modo “liquido”, che segua il percorso di minima resistenza verso l’obiettivo finale, cioè l’indipendenza, l’astrazione e la flessibilità degli strati applicativi.

https://lh3.googleusercontent.com/YTX189KdprN7ue1TUL3WqyyXVUZOiMoE2KrbLfAwaXF8pNZU74aUgexTyUTn-26DO1YgR0N6ACJpYTQtJBR4rdJWl8rNxID0A2uqDy4Gg69ALIYd-yZqVjY_vEj_rCjKVhX9YSuw

Con un percorso di questo genere l’IT è destinato a diventare invisibile al business, con un cambiamento graduale che trasformi in commodity tutte le infrastrutture e i processi a basso valore aggiunto.

Questo percorso è ormai inevitabile, e diversi studi hanno ormai dimostrato che i benefici sono innegabili e che rappresenta un percorso sicuro per le aziende.

Amazon, anche se è parte in causa, ha un modo efficace nel definire questa scelta “no brain”, nel senso che non bisogna neppure pensarci, va fatta e basta.

Questi aspetti che abbiamo brevemente analizzato sono benefici che vanno oltre la valutazione tradizionale del TCO, e la stasi e le frizioni che rallentano l’innovazione sono costi che impattano sul business e sull’efficienza aziendale.

L’innovazione richiede che si esca dalla propria comfort zone, ha bisogno di velocità, leggerezza, efficacia e possibilità di sbagliare senza subire grosse conseguenze, e il cloud è un fattore abilitante.

Quindi: agilità nell’erogazione di nuove applicazioni per cogliere tutte le opportunità del mercato + rimozione delle barriere all’innovazione + maggiore sicurezza e resilienza e aumento della Business Continuity = Trasformazione.

@RIPRODUZIONE RISERVATA

Articolo 1 di 3