Ok, questo è il “solito” post sul cloud computing. Lo spunto sono naturalmente le attuali vicende di Amazon. Ma sia chiaro, io non ce l’ho con questa tecnologia in particolare. Se guardiamo le critiche al cloud, sono in realtà praticamente tutte critiche all’outsourcing, e sorvolano sull’effettiva capacità delle aziende di ottenere affidabilità migliori in casa. Se prendiamo la tecnologia cloud in sè, dal punto di vista della sicurezza non ha svantaggi, secondo me, rispetto alla virtualizzazione, anzi: casomai ci sono vantaggi in termini di flessibilità e resilienza; che poi il marketing possa “promettere troppo”, in termini di resilienza appunto, è un’altra questione. Una volta sceso il polverone, penso che si potrà discutere della questione nei termini più corretti. Il problema fondamentale è quello dell’outsourcing: dare i propri dati a terzi, dipendere per la propria operatività da terzi, la capacità di avere garanzie vere sui livelli di servizio e il rispetto degli SLA e la capacità di gestire disservizi sui quali si ha un controllo limitato. Il cloud, o il SaaS, da un punto di vista dell’offerta commerciale non è molto diverso dagli ASP (Application Service Provider) che sembrava dovessero cambiare l’informatica circa dieci anni fa. Allora, mi è capitato di discutere di una collaborazione con un’azienda “rampante” del settore (non ricordo più il nome, credo che almeno con quel marchio non esista più da tempo), che voleva offrire Office come servizio. La mia prima domanda è stata: come fate a garantire la connettività al cliente? La risposta è stata: “non la garantiamo, se vuole il cliente si può pagare una linea dedicata fino al nostro datacenter”. Adesso la connettività è un’altra cosa, ma resta il fatto che ci sono applicazioni che fermano l’operatività di un’azienda per tutto il tempo per cui non sono disponibili, o che sono mooolto lente… quante PMI hanno una connettività ad Internet ridondata? Che senso ha allora preoccuparsi della disponibilità dell’outsourcer, quando si ha magari un contratto ADSL che anche in caso di guasti banali prevede, se va bene, un intervento (non necessariamente risolutivo) entro 48 ore lavorative? Tornando alla disponibilità, è interessante leggere un paio di post relativi ad aziende che si appoggiano ad Amazon e non hanno avuto grossi problemi. Una è SmugMug: leggendo il loro post, si vede che sono stati fondamentali tre punti. Primo, i loro servizi sono progettate per sopravvivere alla “morte violenta” di qualsiasi componente: siamo lontani anni luce dalla maggior parte dei progetti che ho visto finora nelle aziende Italiane. Anche Netfix ha un approccio simile, tanto che hanno questa incredibile “Chaos Monkey”. Cito:”One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.” Immagino cosa succederebbe se un programma del genere girasse in molti costosissimi e “protettissimi” datacenter privati… molto più simili ad altri clienti di AWS. Il secondo punto che ha salvato SmugMug è che non utilizzano il principale componente di AWS che ha avuto problemi, ovvero EBS. Cito: “we don’t use Elastic Block Storage (EBS), which is the main component that failed last week. We’ve never felt comfortable with the unpredictable performance and sketchy durability that EBS provides, so we’ve never taken the plunge. Everyone (well, except for a few notable exceptions) knows that you need to use some level of RAID across EBS volumes if you want some reasonable level of durability (just like you would with any other storage device like a hard disk), but even so, EBS just hasn’t seemed like a good fit for us.” Possiamo chiamarlo “ottima preveggenza e valutazione delle caratteristiche tecniche di un servizio”, o anche fortuna, fatto sta che di nuovo c’è stata una scelta ingegneristica azzeccata. Naturalmente, questo vuole dire che non hanno una “silver bullet” per eventuali problemi che possano colpire altre componenti di AWS, ma in un’ottica di gestione del rischio, possiamo dire che questi eventuali problemi hanno un rischio (una probabilità) più bassa, che magari SmugMug potrebbe anche tollerare, a fronte dei vantaggi. Ultimo punto importante: non hanno portato su AWS parti importanti della loro architettura:”we aren’t 100% cloud yet. We’re working as quickly as possible to get there, but the lack of a performant, predictable cloud database at our scale has kept us from going there 100%. As a result, the exact types of data that would have potentially been disabled by the EBS meltdown don’t actually live at AWS at all“. Riguardo a SmugMug c’è un ultimo punto da considerare riguardo alla disponibilità. Cito da un altro articolo: “[SmugMug’s] data-center related outages have all been far worse … we’re working hard to get our remaining services out of our control and into Amazon’s.“. Quindi, serve capire quello che si sta facendo (non comprare un servizio come se fosse un webmail e fidandosi delle affermazioni dei commerciali) e valutare i rischi che si affrontano, confrontandoli però con quelli che si corrono tenendo le cose in casa. Anche un disservizio di tre giorni può essere accettabile in molti casi, non bisogna essere “fanatici” su queste cose. Lavorare sulla BIA in ambito Business Continuity insegna molto: alla domanda sui downtime accettabili, tutti dicono che nessun servizio si può mai fermare, ma quando si comincia a parlare di soldi gli RTO si allungano subito 😉 E naturalmente, a seconda del tipo di business la scalabilità offerta dal cloud può essere più o meno importante.
Vediamo ora il punto della riservatezza. Il fatto che sia cloud non riduce certamente i rischi di riservatezza per i dati aziendali rispetto alle forme di outsourcing precedenti: se c’era perplessità a dare all’esterno certi dati, al cosa non dovrebbe cambiare con il cloud. In effetti, per l’utente la differenza in realtà è generalmente poca. Sento dire continuamente: “dicono di non usare il cloud, ma in realtà lo usano e non lo sanno”. È vero, ma ci aggiungerei: “e non gli interessa”. Almeno per la riservatezza, la valutazione non ha niente a che fare con il cloud, la vera valutazione è sul dato e su chi lo gestisce. Di nuovo, non bisogna eccedere: i dati realmente riservati, tali da costituire un rischio per il solo fatto di essere dati in outsourcing, per la maggior parte delle aziende sono veramente pochi. Nel caso della riservatezza però, bisogna partire dal “disastro”: a differenza della disponibilità, la riservatezza non si recupera dopo qualche giorno, se un dato è compromesso è compromesso. Quindi l’azienda si deve chiedere: quali sono i dati che, se pubblicati, non mi procureranno un danno tale da farmi “ripagare” tutti i risparmi ottenuti dall’outsourcing? Quelli potranno andare sul cloud. Per gli altri la valutazione è molto, molto difficile. Riguardo alla riservatezza però, c’è un’ultima considerazione: l’outsourcer ha come obiettivo fare soldi, ovvero in linea di massima avere molti clienti, e qui arriviamo alla recente questione di Dropbox (non quella della cattiva autenticazione): una società che vende servizi di storage o backup ha molte più probabilità di perdere un cliente perché questi si è perso la chiave di cifratura dei dati e non riesce più a recuperarli, piuttosto che perché il cliente scopre che “in certi casi” il fornitore è in grado di accedere ai dati, e quindi la scelta della maggior parte dei fornitori di backup è scontata: avranno un modo per recuperare i dati. Naturalmente ci sono i clienti che preferiscono piuttosto perdere i dati (ma non solo a parole), ma sono una minoranza e rimangono un mercato di nicchia; per questi, la soluzione è sempre cifrare in proprio i dati prima di darli all’outsourcer.
