La necessità di differenziare…

Oggi facciamo una digressione dagli aspetti tecnici verso temi che propriamente non lo sono: parliamo di gestione del rischio tramite suddivisione in più unità.

Mi spiego con un esempio venuto con l’esperienza: avete una ditta, dovete anticipare delle fatture per cui vi serve un castelletto di 100.000,00 Euro. Il periodo è difficile, le banche prima di esporsi ci pensano 1.000 volte (belle stronze, visto che il casino l’hanno causato soprattutto loro con i mutui subprime e derivati vari), per cui è difficile che un istituto vi conceda un simile fido.

Come fare?

Come si è sempre fatto: vado in 10 banche e chiedo a ciascuna un affidamento di portafoglio di 10.000,00 Euro. E’ più difficile viaggiare per 10 banche diverse, ma grazie a 10 piccoli passi al posto di uno gigante, alla fine ho più probabilità di ottenere quello che mi serve. E non solo: se una delle banche mi crea problemi ne ho altre nove su cui contare e non su una sola che mi lascerebbe a piedi.

Lo stesso discorso si può applicare con i clienti: meglio un cliente che mi fa fatturare 100.000,00 Euro all’anno oppure 100 clienti da 1.000,00 Euro? Con un cliente solo “mi smazzo di meno”, ma quando ci sono i primi problemi (e prima o poi i problemi, anche temporanei, arrivano) si vede la differenza.

Come diceva la pubblicità: du is megl che uan!

Questo si chiama suddivisione del rischio e deve essere applicato in tutti i contesti con criticità… e non fraintendetemi, non sto dicendo di trovarvi 100 amanti per stare tranquilli se litigate con il cogniuge.

E’ per dirvi invece che la stessa filosofia deve essere applicata nell’ambito informatico per minimizzare i rischi causati da un disservizio: troppo spesso in questo blog abbiamo trattato argomenti legati al cloud, all’alta affidabilità, a più server in load balancing… ma se per caso prendono fuoco gli UPS ed il datacenter resta al buio?

Lungi da me criticare Amazon e Aruba che hanno avuto questo tipo di problemi proprio di recente, anzi, complimenti (soprattutto al secondo) per la rapidità con la quale sono tornati operativi: come si dice, la bravura non sta a non cadere mai da cavallo, ma a rialzarsi in fretta dopo una brutta caduta.

Critico però tutti coloro che concentrano tutti i servizi presso un’unica struttura, senza valutare il rischio che questa cosa può generare e, quando accade, piangono…

E, paradossalmente, per affrontare questo problema ci viene in aiuto proprio il cloud: forse non tutti sanno che i cloud di possono federare. Bella parola, ma cosa vuol dire questo? Che pressochè tutti i sistemi di cloud utilizzano le API EC2 di Amazon e quindi, per definizione, esiste un layer di compatibilità che permette di unire assieme più cloud per bilanciare il carico di lavoro (e quindi anche il rischio in caso di guasto).

Nella pratica, per il proprio web server, meglio avere un’unica grande VM su Amazon o 10 piccole VM su 10 differenti cloud in load balancing?
Ok, il vostro ISP (io) è strafigo, vi assicura continuità… ma le recenti vicissitudini indicano che nessuno è immune da problemi, per cui magari costerà di più ma è meglio avere 10 web server in load balancing piuttosto di concentrare il rischio in un’unica struttura, per quanto importante possa essere.

Quindi, nel momento in cui state per acquistare un servizio “on-the-cloud” quantomeno informatevi se il Vostro provider permette la federazione con altri cloud. Diffidate da chi non la prevede, potreste pentirvene amaramente un domani.