Scritto da Marco Lucchina
La notizia che uno dei leader del cloud computing abbia avuto un fermo dei suoi sistemi è di per sé una bomba; il fatto che i suoi clienti maggiormente colpiti siano i campioni della digital trasformation, ossia quelle aziende che hanno costruito il proprio modello sui sistemi informativi e sulla capacità di questi di scalare, nel momento in cui una app dovesse diventare un fenomeno globale, dà alla notizia una risonanza ancora più ampia.
È altresì evidente che quando il primo della classe inciampa, gli altri un po’ gongolano e, magari, provano a prendere un po’ di quello spazio che normalmente sarebbe loro precluso. Sto mettendo le mani avanti, me ne rendo conto, ma una cosa che veramente non voglio fare è sminuire l’incredibile lavoro fatto dagli hyperscaler o provare a portare acqua ad altri mulini. Però un ragionamento di approfondimento mi sento di farlo.
Too big to fail? Il dilemma della sicurezza e dell'affidabilità
Le infrastrutture dei cloud provider hanno un set di caratteristiche che sono anche la chiave del loro successo. Sono basate su una scalabilità pressoché infinita, se riferita al potenziale di un singolo cliente, sono self service, sono condivise tra tutti i loro clienti, sono standard (più o meno uguali per tutti) e sono, ovviamente, virtuali e remote (molto remote).
Queste infrastrutture, per poter mantenere le promesse di cui sopra, devono anche scendere a compromessi con le personalizzazioni e le attività amministrative che un singolo cliente può fare.
Senza entrare nel dettaglio, possiamo affermare che non è possibile prendere alcune delle decisioni architetturali che i CIO hanno sempre preso. Mi riferisco in particolare alle politiche di gestione e salvaguardia del dato.
È luogo comune confidare più del necessario sul fatto che queste infrastrutture siano in alta affidabilità e too big to fail, sia dal punto di vista tecnico che societario. I recenti fatti hanno dimostrato che l’errore umano è possibile in qualunque contesto, per non considerare l’ipotesi di una volontà umana, volta al danno deliberato e ovviamente esterna elle organizzazioni partner, che potrebbe creare guai anche peggiori. Le cyber security wars sono un concetto ancora molto astratto, ma, di fatto, anche un rischio reale.
Diamo per scontato, perché ragionevolmente è così, che i service provider facciano di tutto per tenere i propri clienti al riparo sia da problematiche di affidabilità che da quelle di sicurezza e che gli hyperscaler siano più attenti degli altri, per via della loro visibilità sul mercato.
Ci si può affidare agli hyperscaler?
Credo, da consumatore, che la cosa peggiore sia non sapere cosa sta succedendo e avere solo delle risposte telefoniche del tipo “stiamo lavorando per ripristinare il servizio al più presto” non sia sufficiente.
Suppongo inoltre, che la parte più imbarazzante sia, per un CIO, dover rispondere alla domanda del board “cosa possiamo fare per evitare che il problema si ripeta”, dato che la risposta dovrebbe essere “noi nulla, possiamo solo fidarci del partner che abbiamo scelto e sperare che non si ripeta”. Di fatto questa risposta è corretta, purtroppo quando viene data alle persone che dirigono il business di una azienda, per “qualche motivo”, non ha mai un grande successo. Tra manager ci si aspetta che si possa, e si deva, fare qualcosa di fronte a qualunque problema.
Purtroppo il fermo di un hyperscaler è paragonabile ad un disastro naturale, non si può prevedere, bisogna solo aspettare che passi e poi ricostruire; fare qualcosa per la prossima volta? Purtroppo non è possibile. A questo va aggiunto il fatto che la scelta di un hyperscaler, ad un certo punto, porta ad una situazione di vendor-lock-in. Questo avviene perché servizi e funzionalità sono così semplici da implementare tramite loro che si perde la capacità di farlo in autonomia, rendendo ancora più accentuato l’imbarazzo nei confronti della domanda del board.
Agilità e semplicità senza rinunciare a affidabilità e sicurezza
L’ideale sarebbe aver qualcosa di tradizionale con cui confrontarsi, protestare, discutere, trattare, metaforicamente un citofono al quale suonare per poter parlare con chi ha in gestione il cuore dell’azienda. Un po’ come il diritto all’oblio che un individuo può esercitare quando vede la sua immagine digitale in pericolo, così un CIO dovrebbe poter avere un indirizzo ove ritirare uno scatolone pieno di nastri tramite le quali riprendere il comando della trasposizione digitale del business della sua azienda.
Si dice che la necessità di agilità sia il primo fattore decisionale che porta i CIO dagli hyperscaler; agilità che definiremmo come la velocità di portare in produzione una applicazione e la possibilità di aggiustare il tiro qualora le richieste del business dovessero cambiare. Ma se di fronte ad un problema la possibilità è (forse) solo quella di accettare passivamente le conseguenze della scelta fatta, dove sta il privilegio di poter cambiare idea?
Sono argomenti interessanti e sui quali esistono diversi punti di vista, noi li approfondiremo, insieme a oltre 150 CIO, il prossimo 7 Aprile. Live dagli studi RAI di Milano, in streaming & via social. Forse in questo caso ho dato l’impressione di portare acqua al nostro mulino, spero di no, dato che l’intenzione è solo quella di confrontarsi. E poi gli hyperscaler sono forme di agricoltura intensiva, i mulini sono un’altra cosa, presente, romantica e “non per tutti”.