Google Apps III: le obiezioni alla tecnologia cloud – Parte A

Di - 13 June 2012 - in

Prosegue la serie dedicata alle Google Apps. In questo capitolo mi concentrerò sulle obiezioni mosse alla tecnologia cloud. Vorrei subito premettere che, prima di stendere questo pezzo, ho cercato molte fonti, post su blog e documentazione ufficiale. Il mio scopo era quello di raccogliere quante più voci possibili in merito ai difetti di questa architettura e, più in dettaglio, alla soluzione Google Apps. La cosa strana è che mi sono imbattuto quasi del tutto in articoli “vecchi“, risalenti al periodo 2008-2010, o propagandistici (pro o contro Google). Mi sono concentrato allora sugli aspetti strutturali, rimandando al prossimo intervento la descrizione del software Google, ma nemmeno in questo ambito ho avuto maggior fortuna.

Alcune delle domande che mi sono posto sono: è sicuro il cloud? Che fine fanno i miei dati? Cosa può accadere in caso di guasti? Un servizio di questo tipo è migliore di uno tradizionale? Che soluzioni possiamo adottare e con quali benefici?
Dopo alcune indagini e considerazioni personali ho individuato i seguenti 5 lati meno gradevoli di questa scelta tecnica:

  1. Possibile downtime
  2. Sicurezza e trattamento dei dati
  3. Mancata flessibilità delle soluzioni
  4. Difficoltà nell’ottenere supporto da parte del fornitore
  5. Stress e riflessi comportamentali

Il primo problema è sicuramente legato alla possibilità, o meglio, all’impossibilità di fruire del servizio cloud. Queste problematiche sono causate da molteplici motivi, primo tra tutti la connessione che lega il rapporto cliente-provider; a farne le spese sono quasi sempre aziende o istituzioni di piccole dimensioni che non possono accedere, per via dei costi, a risorse ridondanti. Altri disagi sono, per fortuna sempre meno frequentemente, legati alla piattaforma utilizzata: eventi naturali, eventi imprevisti (bugs) o guasti possono compromettere alla fonte la nostra user experience.


Nessun software o architettura, proprietaria o remota, è sempre pienamente ed al 100% operativa, specie se si tratta di sistemi di produzione che, come ogni altro strumento, sono soggetti a carico e ad inevitabile usura. Non poter tuttavia gestire i malfunzionamenti o prevederli ci mette in uno stato mentale, più che operativo, di rifiuto nei confronti delle implementazioni nella nuvola.

La sicurezza è un altro aspetto fondamentale: cloud non è sinonimo di sicuro. Come per ogni altro prodotto la scelta che dobbiamo operare, all’atto di adesione, deve essere basata sulle caratteristiche e sulle garanzie (o certificazioni super partes) che ne attestino l’affidabilità.
La storia recente ci ha fornito parecchi esempi di come molti provider siano stati violati o chiusi per utilizzo illecito delle loro piattaforme.
L’implementazione cloud deve garantire la sicurezza fisica, logica ed intellettuale delle informazioni gestite. Inoltre devono essere valutate altre due condizioni a mio parere chiave: che uso viene fatto dei nostri dati e che certezze abbiamo che la società a cui li affidiamo abbia solide basi future (come recuperare in caso di fallimento i nostri contenuti). Trovo curioso che, nella situazione attuale, ci porremmo molti meno problemi se sostituissimo nella frase precedente la parola dati con soldi e società con banca.

Cloud sicuro o sicurezza nel cloud?

Le soluzioni cloud sono subito pronte all’uso ed erogano app e servizi secondo i loro standard. È evidente che software allestito internamente possa richiedere un tanto maggiore sforzo implementativo quanto possa fornire, sul medio e lungo termine, un vantaggio anche notevole in termini di customizzazione e flessibilità.
Da questa prospettiva anche i migliori provider, cioè quelli che espongono le più vaste interfacce di personalizzazione, spesso, a causa della continua evoluzione tecnica, non possono garantire “a vita” la presenza di API o tools per gli sviluppatori ma dettano e cambiano le proprie librerie per meglio adattarsi agli sviluppi del mercato. Questo aspetto, di certo positivo, costringe però molte organizzazioni ad adeguarsi alla soluzione scelta.

Sempre ricollegandomi ai possibili problemi di offline, è necessario, per ogni cliente, accedere a sistemi di supporto in caso di malfunzionamenti o anomalie delle soluzioni previste.
Il fattore che più conta in queste casistiche è il tempo della risoluzione. Chiedere aiuto potrebbe non essere sempre facile (per via di fusi orari, o questioni linguisitiche) oppure potrebbe capitare di non riuscire a spiegare/riprodurre sistematicamente l’errore o la causa del disservizio.

L’ultimo aspetto su cui mi vorrei concentrare è più connesso ad aspetti comportamentali che tecnici. La soluzione cloud infatti comporta il più delle volte un cambiamento nei modi di pensare e lavorare degli utenti. Ricollegandomi ad un mio precedente articolo è fondamentale approcciare l’adozione di un nuovo servizio con adeguata attenzione al change management.
Un altro fattore da non dimenticare è inoltre la possibilità, da parte del nostro provider, di sospendere o interrompere la fornitura di servizi se alcune nostre azioni, volontarie o meno, dovessero usarli impropriamente. Virus o malware potrebbero impossessarsi a nostra insaputa delle risorse nella nuvola per attività illecite; con molta probabilità il nostro accesso sarebbe sospeso dandoci l’impressione, errata, che la piattaforma sia poco affidabile.

L’unico modo per evitare di incorrere in alcune di queste situazioni è una scelta oculata del proprio fornitore cloud. Per questo motivo nel prossimo capitolo mi occuperò di descrivere alcune implementazioni di questa architettura e due prodotti che l’hanno utilizzata per costruire il proprio business: Google Apps e Office 365.

Leave a Reply

Andrea Testa Articolo scritto da

Laureato in Comunicazione Digitale, curioso ed affascinato dall’informatica, specialista Google Apps. Sviluppatore software, ama tutto ciò che si manifesta sotto forma di intelligenza, tecnica ed innovazione, come il web e l’open source.

Contatta l'autore

Previous post:

Next post: