La mitologia del “Cloud” computing.

Vedo che da ogni parte la gente si sta facendo grossa con il cloud computing, e vedo che iniziano gia’ a girare grosse leggende a riguardo. Per “grosse leggende” intendo dire che i grossi operatori stanno giocando sulle aspettative drogate dei possibili clienti al fine di convincerli di aver inventato la tecnologia per il pasto gratis. In realta’, non esiste nulla come il “pasto gratis”. Avendo lavorato molti anni nel settore HPC, avrei qualcosa da ridire onde sfatare questa aspettativa enorme. Quindi, andiamo: perche’ cloud SI, e perche’ cloud NO.

Innanzitutto, un pochino di debunking.
Per prima cosa, il cloud computing NON e’ High Performance Computing. Non c’entra nulla il fatto che voi otteniate tutti i TFLOPS che avete chiesto come se aveste un supercalcolatore in casa: non avete idea delle performance dell’oggetto che vi fornisce la potenza di calcolo.

Se voi aveste potuto ottenere tutti i TFLOPS che avete chiesto con, diciamo, 4096 CPU, magari chi vi sta vendendo la potenza di calcolo l’ha ottenuta usando 16000 CPU. In questo caso, sul piano delle performance saremmo a livelli penosi, ma dal vostro punto di vista stareste ottenendo quello che avreste ottenuto facendo HPC. Il problema e’ che non e’ affatto High Performance, ma piu’ semplicemente “massive computing”. State facendo un sacco di conti, sulla performance non stiamo discutendo.
Questo punto, ovvero che per parlare di HPC oltre alla quantita’ di calcoli che fate occorre anche calcolare la quantita’ percentuale di cicli di CPU usati, e’ il punto che sta alla chiave delle considerazioni finali. Se ottenete 1000 TFLOPs con un uso medio delle CPU del 20%, state facendo sicuramente un uso massivo di calcolo, ma di certo “High Performance” ve lo sognate.
Punto secondo: il Cloud computing NON e’ una tecnologia, ma un modello di costo. Non solo non c’e’ nulla di innovativo o nuovo nel concetto di cloud (IBM faceva le stesse cose sui mainframe con sistema supervisore gia’ diversi anni fa) : cio’ che e’ nuovo e’ il modello di costo, ovvero il modo con il quale voi, cliente, calcolate le spese.
Mentre normalmente costruire un’infrastruttura per il calcolo ha dei costi fissi, e un limite architetturale legato all’investimento iniziale, il modello di costo del cloud computing e’ un modello per il quale a prescindere dai costi iniziali il cliente ottiene la potenza che vuole. Ma non solo: a differenza dell’ HPC tradizionale, puo’ scalare la potenza on demand, senza dover acquistare nuovo hardware. Tutte queste, pero’ , cono considerazioni puramente economiche, cosa che rende evidente quanto detto sopra: il cloud computing e’ un modello di costo per il cliente, o se volete un modello di business per chi lo vende.
Per prima cosa, mettiamoci dal lato cliente: perche’ si e perche’ no.
Perche’ SI:
perche’ siete una PMI o un’azienda che per ragioni varie non ha un settore IT consistente. Se lo fate, lo fate perche’ avete un bisogno momentaneo e molto variabile nel tempo di potenza di calcolo, forse addirittura per una sola volta.
Se siete una grande corporate, e’ perche’ nonostante abbiate gia’ un settore IT, non avete in loco le competenze (e non volete pagare le consulenze)  per mantenere un grosso datacenter da usare per il calcolo. Non avete in casa le competenze tali da assumervi il rischio insito nell’ HPC, ovvero quello di sbagliare l’architettura dell’hardware. Inoltre, e’ ottimo se avete un sustanied basso e dei picchi molto alti; come puo’ succedere che so io al transcoder di MMS durante una partita di calcio, o durante un evento molto fotografato.
siete un ente governativo. si pagano gli acconti IVA entro il tal giorno. Il vostro sistema e’ scarico fino a due giorni prima, poi ha un picco pazzesco. Questo capita con regolarita’. Minchia, siete il cliente perfetto per il cloud. Tenete in casa il sustained medio e comprate in cloud i picchi.
Perche’ NO:
se siete una PMI o un’azienda media, faticherete a trovare la fase di preanalisi che vi permette di predire quanta potenza chiederete per il vostro calcolo. Ne’ potrete facilmente stimare in anticipo il limite da dare alla richiesta. Insomma, senza una robusta fase di preanalisi rischiate una “bolletta” piuttosto salata, oppure di aver speso i soldi e ancora il vostro software e’ anni luce dal finire i conti.
siete un ente governativo che fa ricerca su problemi specifici, e avete un uso sostenuto e regolare di risorse hardware. In questo caso, pagare il rischio al provider di cloud non vi converra’ nel medio e lungo termine.
se siete una corporate, avrete dei problemi di definizione del caso specifico. Nell’ HPC davvero intensivo, la potenza di calcolo per CPU non e’ tutto, ma entrano in gioco pesante una serie di fattori che vanno dall’output di uno specifico bus molto stressato fino alla reale capacita’ totale del sistema. Dal punto di vista interno, avete un preciso committment a finire il calcolo in un preciso giorno, o almeno in una precisa porzione di tempo. Se non riuscite a percepire in che modo scali il sistema, rischiate di trovarvi di fronte ad un’alternativa commerciale molto dura: o comprate un limite massimo di calcolo tale da permettervi di finire il calcolo in tempo, pagando il rischio al vostro fornitore, oppure accettate il rischio di non avere il ritorno di investimento quando previsto. Se come corporate avete continuo bisogno di quantita’ massicce di calcolo, e non avete grossi picchi, vi conviene di molto farvi una struttura one-purpose in casa.
L’ultima affermazione verra’ immediatamente contestata da chi pensa che produrre TFLOP sia come produrre automobili: la produzione su scala conviene. Il che e’ assolutamente FALSO. Il costo per TFLOP non sempre si abbassa con la quantita’ , anzi, crescendo la dimensione del sistema di calcolo si inizia ad andare incontro a fenomeni di gestione delle piu’ piccole cose che normalmente non hanno troppo bisogno di gestione: se per 32 nodi mi basta uno switch ethernet, quando andiamo sui 8192 comincio ad aver bisogno di un’infrastruttura pesante. Se per 32 nodi mi basta un buon raid qualsiasi, per 8192 inizio ad aver bisogno di storage massivi , filesystem dedicati e ottimizzati, eccetera.
Come se non bastasse, la particolarita’ del problema vizia parecchio l’architettura del sistema di supercalcolo. Se dovete spendere 2 M di euro per un sistema potreste avere un problema che e’ molto CPU-intensive (e allora comprerete nodi) o un problema che viene affrontato in maniera molto I/O intensive, come capita a molti problemi da risolvere alle differenze finite: nel secondo caso investirete nell’ IO corrispondente (SAN , architetture BIG-IP, etc etc).
In definitiva, a seconda del settore e del tipo di problemi, l’architettura del vostro sistema HPC cambia, e deve essere cosi’ se davvero volete un ottimo ROI, cioe’ se volete usare tutte le lire che spendete per comprare dell’hardware.
Adesso immaginate la cosa dal lato di chi FORNISCE i TFLOP. Avete per forza di cose un’infrastruttura hardware  che e’ all-purpose, cioe’ non deve essere troppo sbilanciata verso l’ I/O perche’ ci sono clienti che chiedono solo CPU, e non puo’ essere troppo sbilanciata verso la CPU perche’ ovviamente non potete penalizzare chi fara’ cose I/O-intensive.
In piu’ avete l’overhead della virtualizzazione e quello della gestione del carico on demand. Morale della storia: riuscirete a rispettare il vostro OLA , o lo SLA verso il cliente, solo finche’ la media del carico in un periodo medio/alto e’ MOLTO inferiore al 100% dell’utilizzo del vostro hardware. Nel momento in cui vi avvicinate all’esaurimento di una specifica risorsa hardware per via delle specificita’  , vi state accollando il rischio enorme di non rispettare lo SLA.
Cosi’, sicuramente il cloud apparira’ come un modello di costo fantastico a chi vuole comprare calcolo, nel caso in cui rientri tra le aziende che ne hanno convenienza. Se il nostro fornitore di HPC ha un grande numero di PMI, e quindi il carico medio non e’ troppo sbilanciato (intendo dire non troppo CPU intensive e non troppo I/O intensive) riuscira’ a raggiungere (a meno del rischio), anche il 70% della capacita’ totale del proprio hardware come capacita’ utilizzata nel sustained time.
Il problema viene da parte del nostro fornitore. Se si avvicina troppo ad usare grandi percentuali della propria installazione hardware, si sta accollando i rischi di avere un prossimo cliente molto sbilanciato , che esaurisca tutta una risorsa senza toccare le altre: arriva qualcuno che vuole girare un’applicazione molto CPU intensive e satura il sistema. Solo che non usa I/O, il che significa che rimanete con I/O inutilizzato che pero’ non potete vendere perche’ non avete piu’ CPU per altri utenti.
Insomma, per voi i grandi clienti sono rischiosissimi: vi bastano una decina di chimici-fisici che fanno cloud per saturare una risorsa del vostro cloud senza usare le altre. Se vanno di moda , che so io, le grandi proteine, e  alcuni  metodi basati sul calcolo delle traiettorie, vi troverete gente che vi satura lo storage come ridere. Magari le CPU sono al 10%.(1)
Morale: dal punto di vista del fornitore, il cloud computing e’ ragionevole SOLO se rivolto a piccoli clienti con richieste tutto sommato modeste. Coi sistemi molto scarichi sara’ possibile accettare anche richieste di grossi clienti e rimanere relativamente certi di essere lontani dal limite di rischio.
Ma anche con una discreta curva di qualita’ tra rischio del prossimo cliente e capacita’ residua, raggiungeremo una quantita’ di rischi insostenibile attorno al 70% del carico complessivo, ovvero del ROI dell’hardware che usiamo.
Se invece granularizziamo estremamente il carico su molti piccoli clienti, a meno di varianze estreme siamo relativamente certi di avere un carico ben bilanciato tra le varie risorse, e quindi possiamo tenerci su limiti di carico piu’ alti.
In generale, dal punto di vista del sistema host che offre cloud computing, il modello di rischio NON puo’ che contenere il numero di utenti e la percentuale di risorse per utente, nonche’ lo sbilanciamento verso una singola risorsa del carico globale.
Questa e’ la ragione per la quale uno dei provider che si e’ lanciato nel business e’ amazon, che ha una penetrazione sull’utenza low-end e middle-end piuttosto estesa. Amazon probabilmente spera di avere milioni di piccoli clienti , cosa che permetta di bilanciare il carico sulle singole risorse hardware.
Ovviamente, nessuno sara’ cosi’ fesso da proporre HPC usando cloud computing se i clienti iniziano a diventare grossi: il rischio di saturazione o di carico sbilanciato su una singola risorsa e’ troppo alto. Se si accettasse un rischio del genere , l’unica pianificazione accettabile sarebbe quella che usa non piu’ del 70% delle risorse sul sustained, e quindi il rimanente 30% del prezzo dell’infrastruttura  lo paghera’ il cliente senza effettivamente usare le risorse.
Un altro capitolo sarebbe quello dei prezzi attuali del cloud computing: e’ ovvio che siamo nella fase di “evangelism”, cioe’ le banche hanno finanziato questa figata che e’ la nuova buzzword, (2) e le aziende che si buttano nel business dicono agli investitori che i profitti arriveranno.(3) Quindi per ora i prezzi saranno ragionevoli.
Il problema e’ che tutti coloro che vendono cloud e consulenze sul cloud stanno facendo tutti gli stessi errori, cioe’ dirigersi verso utilizzatori intensivi di tecnologie HPC,  cioe’ sul target sbagliato. Se, con un impegno disumano, si portassero il 30% degli attuali GRANDI utilizzatori di HPC verso il cloud, si introdurrebbe cosi’ tanto rischio di specificita’ da rendere impraticabile il modello di business.
Il vero problema di mercato che il cloud computing ha oggi e’ che se come modello di costo e ‘(=per il cliente)  qualcosa di fantastico, per il fornitore il modello di business soddisfa le esigenze di ROI solo con un determinato tipo di clienti, che sono clienti con richieste hardware tutto sommato piccole.
Cosi’, il provider di cloud computing si stanno gettando sul mercato facendo business plan che contemplano necessariamente un numero molto alto di clienti piccoli: il guaio e’ che moltissimi di quelli che pensano di aver capito il modello di business in realta’ hanno capito solo il modello di costo: sanno perche’ e quando al cliente conviene comprare cloud, ma non hanno capito benissimo quando al fornitore convenga venderlo.
Il rischio generale per questo mercato non e’ quello di muovere pochi soldi, ma di muovere quelli sbagliati: se in fase iniziale Amazon puo’ permettersi di vendere molti TFLOP ad un singolo utente, giusto per avere lo use case da sbandierare , lo fa solo perche’ ha i sistemi scarichi. A regime, un singolo grosso cliente rappresenta un rischio troppo alto, e potra’ venire sostenuto solo tenendo scarichi i sistemi entro un margine di certezza: i costi dell’hardware che non ha ROI, pero’, verranno per forza di cose scaricati sul cliente finale.
Morale della storia: ricordate che non tutto quello che conviene al cliente conviene al fornitore; e se il grande cliente trova preferibile il cloud per calcolo massivo su un singolo problema, il fornitore si vedra’ sbilanciare le risorse usate verso la risorsa critica di quel singolo problema e preferirebbe vendere tanti piccoli contratti per tenere bilanciato l’uso di risorse hardware.
Quello che non vedo tra gli evangelist, insomma, e’ la consapevolezza chiara del fatto che il modello di costo e quello di business in questo caso non coincidono perche’ il modello di rischio che il fornitore si fa comprende il bilanciamento medio delle risorse usate, on modo da garantire un ROI adeguato a tutte le componenti della sua serverfarm (4) , e quindi una intensa granularita’.
Gli evangelist invece sembrano aver trovato la panacea di ogni male: si illudono di aver superato la gigantesca necessita’ di consulenza pre-sale che caratterizza l’ HPC, trasformando l’ HPC in un mero problema commerciale. Ma questo, se applicato (come vedo che si intende fare) alle grandi realta’, non fara’ altro che alzare i prezzi del servizio per via dei grandi rischi.
Il fatto che uno dei grandi provider sia Amazon dovrebbe parlare loro chiaramente del modello di business che gli host hanno in mente;  ciononostante noto con allarme che le aziende interessate stanno bussando alla porta dei normali clienti di HPC intensivo.
Insomma, se l’idea e’ buona di per se’, e i fornitori di cloud computing sembrano avere in mente il modello di business, sembra che gli evangelisti (spesso anche manager della stessa Amazon) siano cosi’ concentrati a vendere l’ottimo modello di costo al cliente da dimenticare che l’hardware NON e’ gratuito, e che se possono essere degli sbruffoni in questa fase iniziale, poi otterranno che tutti faranno riferimento al modello proposto inizialmente.
Quindi, pur essendo il cloud molto diverso dall’ HPC, e proprio per questo, dico :fermate le cavallette. Il pasto gratis non esiste.
Uriel
(1) Ipotesi ottimistica. Nel mondo HPC i chimici fisici sono famosi per saturare qualsiasi supercalcolatore si dia loro in mano, e c’e’ gente a Bologna che sostiene di aver visto finire la nutella nel frigorifero di casa per colpa di una routine scritta male  in viale Risorgimento. I chimici fisici esauriscono le risorse , fine. Sono i migliori clienti, BTW. 🙂
(2) Tra qualche mese ne avremo gia’ piene le palle di Cloud e di SCRUM.
(3) Faccio notare che la stessa Amazon non e’ nuova a questo genere di comportamenti, e che e’ rimasta in perdita per un bel pochino di tempo, prima di mostrare degli utili.
(4) Non e’ che il cloud fa miracoli e allora non avete piu’ bisogno di una serverfarm o di un mainframe, eh.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *