Cloud Computing: leggende metropolitane e come non-venderlo

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

Martedì scorso ho partecipato al Cloud Communities Day a Milano, organizzato da EuroCloud Italia. Lo scopo, pienamente riuscito, era di far conoscere al pubblico e mettere in contatto tra di loro le varie User Communities che lavorano sul Cloud Computing: oltre ad alcuni di noi in rappresentanza del VMware User Group Italiano, c’eano anche persone di OpenStack, AWS e Microsoft Azure.

E’ stata un’ottima occasione di confronto, e come sempre il momento migliore, a mio avviso, si è avuto con la piccola discussione aperta alla fine dell’evento. Ho avuto l’opportunità di ascoltare diversi punti di vista, provenienti da utenti, consulenti, providers, che utilizzano differenti soluzioni; molto interessante e stimolamente, anche se ho dovuto notare purtroppo che ancora ci sono delle visioni un pò distorte del fenomeno Cloud Computing, e alcune posizioni da parte di utenti e (soprattutto) operatori del settore che temo a volte possano allontanare gli utenti. Questo post non vuole essere una sterile critica a queste idee, anche perchè non è detto che io sia nel giusto, ma piuttosto un’ulteriore opportunità di esporre le mie idee.

1. Il problema è il software Legacy

ZCloud

L’affermazione in sè è verissima. Applicativi monolitici nati per essere eseguiti su infrastrutture centralizzate non si sposano per nulla col Cloud Computing, che piuttosto prevede logiche di Scale-Out, Autoscaling e simili.

Da qui però, il concetto è stato declinato rapidamente in ragionamenti come:

” è l’IT Manager del cliente che non si assume la responsabilità di migrare il software da mainframe a distribuito “

” bisogna investire nel riscrivere tutto quel codice obsoleto “

e altri sullo stesso stile. Il problema è che l’IT Manager non è un codardo o uno che vuole preservare il suo “orticello” evitando qualsiasi innovazione, ma il fatto che ci si dimentica spesso che queste operazioni, benchè meritevoli, hanno spesso costi enormi e risultati incerti. Conosco più di una banca (si finisce sempre a parlare del mainframe bancario…) che ha pensato seriamente a migrare il codice presente sui loro mainframe verso sistemi distribuiti, ma che ha poi rinunciato perchè a conti fatti costava meno continuare a pagare il supporto a IBM, e il risultato era troppo incerto per mettere in pericolo un sistema così critico per il loro business.

Sento oltretutto queste affermazioni provenire sempre dai consulenti, mai dagli utenti finali. Secondo me l’errore è voler proporre a qualsiasi costo il Cloud come la panacea di ogni problema, e il voler forzare gli utenti ad adottarlo anche laddove non conviene. Benchè si affermi sempre il contrario a parole, il motivo primario (attenzione, non l’unico) di adozione del Cloud Computing è il risparmio economico che ne deriva; fino a quando non si riesce a dimostrare al cliente che conviene passare al Cloud, il cliente si guarderà bene dal farlo. E avrà tutte le ragioni. Inoltre, ci saranno sempre sistemi che per la loro natura non potranno mai essere trasportati sul cloud, ed è dannoso voler provare anche qui a vendere “Cloud” a tutti.

2. Il Cloud conviene a tutti

Anche qui, l’affermazione è vera, ma il modo in cui viene declinata spesso contiene degli errori di fondo, dettati a mio avviso dagli stessi motivi indicati sopra. Il Cloud non è adatto a tutti, almeno se lo intendiamo come l’esternalizzazione dei servizi IT a una società terza. Una frase in particolare mi ha fatto rabbrividire:

“Alcune società spendono milioni in budget IT. Pensate che risparmi potrebbero ottenere adottando il Cloud”

Non c’è niente di più sbagliato in questo ragionamento, e ve lo dimostro subito. Innanzitutto, se la società X spende tanti milioni per il suo IT, probabilmente ci sono aree in cui potrebbe ottimizzare le spese, ma sicuramente in larga parte il budget sarà proporzionale alle dimensioni dell’infrastruttura da gestire. Passare il tutto in massa al Cloud non potrà in ogni caso ridurre di un decimo quel budget, ma portare ottimizzazioni più o meno rilevanti.

Secondo, questa migrazione verso il Cloud ha un costo. E se l’infrastruttura è così grande, i costi di migrazione saranno sicuramente importanti. Siamo sicuri che da un punto di vista economico, i costi di migrazione verranno prima o poi pareggiati dai risparmi? Forse si, o forse no.

Ma terzo, e più importante, alcune infrastrutture sono così grandi, e prevedono in loro un numero di tecnici molto preparati, che la scelta più logica per le società che le gestiscono sarà si il Cloud, ma interno! Ho notato questo sentendo parlare i ragazzi di OpenStack, mentre portavano come esempi i “final user” che adottano la loro piattaforma: NASA, CERN, MIT… Nomi bellissimi da citare se si vuole fare colpo sulla platea, ma da un punto di vista di business sono esempi impropri: sono enti che per la dimensione delle loro infrastrutture e le competenze possedute, si sono “fatte in casa” la loro Cloud, e probabilmente hanno sviluppato anche alcune parti secondo le loro esigenze.

Si possono usare come esempi per convincere una società manifatturiera a migrare al Cloud (per lo meno Pubblico)? Secondo me NO.

3. Sicurezza non è solo Disponibilità

Sarà colpa del mio passato nella Sicurezza Informatica, ma ogni volta che sento parlare di sicurezza mi pare che il messaggio che passa sia sempre incompleto. A una semplice domanda di un utente riguardo la sicurezza di queste infrastrutture pubbliche, più persone si sono lanciate nel solito esempio:

“ma secondo lei è più affidabile un datacenter dove tutto è ridondato, con personale altamente specializzato che opera 24 ore al giorno, oppure il suo rack con un piccolo UPS e la linea ADSL, e dove dopo le 18:00 non c’è più nessuno in ufficio a guardarlo?”

Messa così, la risposta è ovviamente scontata, e anzi fa sentire un pò ignorante chi l’ha posta. Per chi proviene dall’Information Security come me, tocca purtroppo dover far notare a chi si avventura in queste spiegazioni, che la Sicurezza non è solo Disponibilità, ma anche altre due cose, Riservatezza e Integrità:

Security Triad

In particolare, i dubbi degli utenti sono rivolti alla Riservatezza dei dati, specie quando questi sono sotto il controllo fisico di un’altra entità. Fugare i dubbi di Confidenzialità parlando di Disponibilità non rende un gran servizio al Cloud Computing. Bisognerebbe parlare di governance dei dati, ma se si ha troppa “fretta” di vendere Cloud, si tenderà ovviamente (magari inconsciamente, intendiamoci) a passare oltre questi dubbi. Ma fino a quando non verranno fugati, i clienti avranno TUTTE le ragioni di questo mondo a diffidare.

Conclusioni

Il mio messaggio è semplice: il Cloud Computing ha degli indubbi vantaggi, non applicabili a tutti gli ambiti, e funziona a patto di spiegare bene pregi e difetti ai potenziali utenti, in modo che questi possano fare una scelta informata. Parlarne in modo approssimativo col solo scopo di “venderlo” rischia solo di allontanare la gente.

Non vorrei che il post apparisse cinico o troppo critico, ma semplicemente durante l’evento ho avuto poco tempo per esporre queste mie idee (consiglio per il prossimo evento, moderate gli interventi, altrimenti diventa un’arena dove parla chi è più lesto e prepotente a prendere la parola parlando sopra agli altri). Chiunque volesse replicare, può farlo come sempre nei commenti.

[Questo post è un lavoro originale di Luca Dell’Oca, pubblicato sul blog www.virtualtothecore.com ]

5 thoughts on “Cloud Computing: leggende metropolitane e come non-venderlo

  1. Mi permetto di aggiungere un quarto punto alla trattazione che condivido in pieno.

    La connessione tra gli uffici dove stanno gli utenti e il server (perché anche se lo chiamano “il clund” alla fine è sempre un diavolo di server che sta in un accidenti di data centre) dove stanno i dati e i programmi.

    L’ADSL citata nell’articolo potrebbe essere lo stesso canale che trasporta i dati da/verso il server. Quella stessa ADSL su cui transitano gli accessi web, la mail, skype, youtube, lo streaming della radio di qualche dipendente viene utilizzata anche per accedere ai dati aziendali. Certo, si può mettere una [S]HDSL, ma questo scrivetelo sotto l’elenco dei costi.

    Poi ci sarebbe il fatto che se ritardi il pagamento anche di 5 giorni (giorni, mica mesi) il fornitore chiude l’accesso al server. Me lo vedo con le abitudini italiane dei pagamenti…

  2. Ciao Luigi, concordo a metà.
    La prima parte sulla connettività mi trova concorde, col Cloud spostiamo il problema di “disponibilità” sulla connettività remota dei vari data center. Loro possono anche averla garantita al 100%, ma quella del cliente spesso non lo è. E le velocità disponibili spesso non rendono utilizzabili alcuni servizi.

    Per i pagamenti, nessuno chiude un servizio per 5 giorni di ritardo, ho visto alcuni clienti di AWS essere in ritardo anche di 20-30 giorni. Però non sono d’accordo perchè sarebbe l’occasione per rendere più affidabili i pagamenti delle aziende: nessuno si sogna di pagare in ritardo una bolletta, e se il Cloud deve diventare una “commodity”, beh allora si pagano puntualmente anche queste “bollette”.

    Luca.

  3. è verissimo il punto “inutile dire che Ebay sta passando a OpenStack per non avere più i costi delle licenze VMware” (sentito personalmente): le risorse umane di tecnici che un gigante come quello ha, rispetto ai 3 gatti che può avere l’azienda media italiana, fa sì che l’argomentazione sia di valore nullo, se non negativo…

  4. Luca,
    Complimenti, bell’articolo. Concordo su tutta la linea.
    Potrei portare mille esempi a sostegno della tua tesi… ma sono troppo preso a pensare alle vacanze in questo momento. 🙂
    ciao,
    Enrico

Comments are closed.