Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Prestazioni nel cloud: che fare se la nube si oscura

pittogramma Zerouno

Prestazioni nel cloud: che fare se la nube si oscura

21 Ott 2011

di Giampiero Carli Ballola

Il cloud soddisfa le esigenze degli utenti e del business? Quale velocità di risposta e d’interazione delle applicazioni è consentita? Quale controllo delle prestazioni e dell’avaibility delle applicazioni e quale continuità è garantita? Questa è la sfida a cui è chiamata l’It delle aziende. Da un’indagine condotta in 300 grandi imprese europee (oltre mille dipendenti) dalla società di ricerca Vanson Bourne emerge la consapevolezza di un gap tra il livello di awareness e quello di capacità stimata che va colmato affiancando all’adozione di nuovi strumenti di Application performance management un programma di formazione e riqualificazione delle persone. Per approfondimenti scarica il white paper e la survey performance in the cloud.

Sul cloud computing e sui servizi alle imprese che ne discendono si è scritto e si continua a scrivere tanto che non staremo certo a "reinventare la ruota" descrivendone caratteristiche e proprietà. Crediamo che ciascun lettore le conosca e sappia capire se e in che misura, applicate alla propria situazione, possano dare un vero vantaggio per l’impresa e per il business. Incominceremo subito, invece, parlando dei problemi. E in particolare di quelli che l’erogazione di un’applicazione composita, che sfrutta cioè più servizi cloud (come è il caso tipico delle applicazioni di e-commerce B2B e B2C, ma non solo), pone alla funzione IT dell’azienda.
Il grande problema, o la sfida se così la si vuol chiamare, che il cloud pone all’IT è riuscire a soddisfare le attese del business e soprattutto degli utenti finali riguardo alla velocità di risposta e d’interazione delle applicazioni mantenendo una visibilità e un controllo end-to-end delle prestazioni e dell’availability dell’applicazione stessa attraverso una rete sempre più fitta di service provider terze parti.
Non è un problema facile. E non lo è perché sulle prestazioni non si hanno compromessi: diverse ricerche dimostrano che se l’apertura delle pagine o l’attivazione delle funzioni rallenta, dopo pochi secondi di attesa l’operazione viene abbandonata. In media, dopo sei o sette secondi un terzo dei potenziali acquirenti se n’è andato. Per non dire quando la pagina si blocca su una funzione o non si apre nemmeno. Anche se non si fa e-commerce l’immagine di inefficienza che viene trasmessa al pubblico è pesante.
D’altra parte, la delivery di un servizio cloud passa attraverso una catena che supera i confini del data center e delle strutture che l’IT può gestire e controllare per comprendere aree e sistemi che non sono sotto il suo controllo. Parliamo dei service provider su base WAN, dei fornitori esterni di servizi applicativi, dei carrrier telecom, dei service provider locali e via via sino al Pc o allo smart-phone dell’utente e al suo browser e sistema operativo. Se il maggior freno al cloud computing resta la sicurezza (al primo posto per l’87,5% degli intervistati secondo l’indagine Idc The Maturing Cloud – What It Will Take to Win), disponibilità e prestazioni la seguono molto da vicino, con l’83,3 e 82,9% delle risposte rispettivamente.

Controllare tutta la catena di erogazione del servizio
Dato che i punti critici della delivery chain delle applicazioni cloud sono gli ISP, su base geografica e su base locale, si dirà che questi dovrebbero offrire dei livelli di servizio garantiti su base contrattuale. In effetti, secondo l’88,6% degli intervistati della già citata indagine Idc, gli Internet service provider dovrebbero impegnarsi su precisi SLA. Ma pochi lo fanno, e anche quelli che lo fanno valutano i livelli di prestazioni e availability seguendo dei criteri disomogenei e quindi difficili da confrontare.
Per citare un nome noto, Amazon valuta il livello di disponibilità garantito in termini di ‘cadute’ per anno, cioè di periodi di almeno 5 minuti nei quali il servizio Amazon EC2 non è disponibile. Altri invece si esprimono in termini diversi, per esempio garantendo un’availability “superiore al 99,95%”, il che equivale a un tempo d’interruzione non pianificata inferiore ai 12 minuti in un mese. Sembrerebbe una buona disponibilità, specialmente considerando i tempi medi d’interruzione di un comune exchange server (cioè con architettura non high-availability né hardware ridondato), ma credere che il 99,95% di availability del provider equivalga a una disponibilità del 99,95% del servizio è un grave errore. Perché l’ISP è solo un anello, per quanto importante, della catena.
Dal punto di vista dell’utente, che la lentezza di risposta o il mancato caricamento di una pagina dipenda dal data center, dall’internet provider, dalla rete geografica (non è per niente vero che l’Internet funzioni allo stesso modo in tutto il mondo) o, al limite, anche dal proprio dispositivo, non ha nessuna importanza. Finchè ci sarà il sito di un concorrente più veloce o che funziona meglio, la colpa del problema sarà sempre dell’azienda.
Se la caduta di prestazioni dipende dal proprio data center o dall’infrastruttura e dalla connessione con il provider primario, quello cioè che è responsabile del livello di servizio con il quale porta l’applicazione sul Web, l’It aziendale può in qualche modo intervenire o quanto meno essere informata del problema. Può capitare però anche che secondo gli strumenti di monitoraggio e controllo delle prestazioni applicative tutto vada bene ma che alcuni utenti (non tutti) protestino per il disservizio. In questo caso, senza informazioni dettagliate sul livello di performance dei diversi dominii attraverso tutta la delivery chain, è praticamente impossibile isolare un problema di prestazioni e sistemarlo in tempo utile, prima cioè che impatti sugli utenti.

Monitorare il tutto
L’unica soluzione possibile sta nel superare il tradizionale approccio ‘specialistico’ al monitoraggio delle prestazioni del software, che prevede il ricorso a tecnologie e strumenti che controllano le prestazioni dei singoli componenti di un’infrastruttura o di specifiche parti di un processo. La strada alternativa è invece quella di un approccio olistico, capace di coprire tutta la delivery chain delle applicazioni importanti per il business. Bisogna dire che i responsabili IT si rendono conto di questa necessità di cambiamento di prospettiva. Un’indagine condotta in 300 grandi imprese europee (oltre mille dipendenti) dalla società di ricerca Vanson Bourne per conto di Compuware (clicca qui per scaricarla – con registrazione) dimostra che viene percepito il bisogno di stabilire nuovi SLA che non siano basati su metriche di matrice tecnologica ma su criteri di valutazione dell’esperienza-utente. Su questo punto concorda l’84% degli intervistati.
Il problema però è che alla domanda se lo staff IT abbia l’esperienza e gli skill necessari per negoziare SLA di questo nuovo genere, che considerino cioè le prestazioni delle connessioni Internet, la user experience e altri fattori, la percentuale delle risposte positive cala al 67%. Esiste quindi un gap tra il livello di awareness e quello di capacità stimata che va necessariamente colmato affiancando all’adozione di nuovi strumenti di Application performance management un programma di formazione e riqualificazione delle persone.

Giampiero Carli Ballola
Giornalista

Giampiero Carli-Ballola, nato nel 1942 e giornalista specialista in tecnologia, collabora con ZeroUno dal 1988. Segue i processi di digitalizzazione del business con particolare attenzione ai data center e alle architetture infrastrutturali, alle applicazioni big data e analitiche, alle soluzioni per l’automazione delle industrie e ai sistemi di sicurezza.

Articolo 1 di 5