Bello il cloud: creare macchine virtuali su Amazon EC2 con pochi click o automaticamente e distribuire nuovi servizi in secondi pagando solo per quello che si consuma!
Ma, bisogna ricordarsi che ogni tanto le cose non vanno lisce e, come dicono gli americani, “shit happens”.
Oggi Amazon ha subito il suo più grande fail e, in un suo datacenter statunitense, ha problemi da più di 6 ore mettendo in crisi servizi quali Reddit, Foursquare, Hootsuite, Quora e tanti altri meno famosi. Non di rado ci si trova davanti a schermate simili a questa.
Fra l’altro sembra che il problema si ancora in cerca di una soluzione (qui e qui gli screenshot del Service health dashboard)!
Qui le domande sono due:
1. Questi fornitori di servizi sapevano del rischio ma hanno deciso di correrlo perchè il rischio era minore di quanto pensassero.
2. Si sono fidati più del dovuto del cloud provider che non è stato in grado di dare il giusto livello di servizio.
Come la metti, la metti male! Sta di fatto che Amazon, e anche i suoi clienti, hanno perso molta della loro credibilità oggi dando un’arma formidabile ai detrattori del cloud… Già immagino quanti sono li che stanno dicendo: “cosa avevo detto io sul cloud?”.
Il disaster recovery (ne ho parlato spesso negli ultimi tempi) è sottovalutato da molti soprattutto prima di un disastro. Ma poi, come in questo caso, bisognerà fare i conti con tutte queste ore di disservizio, i mancati introiti e le arrabbiature (se non peggio le richieste danni) dei clienti… ne valeva la pena?
Eppure l’infrastruttura di Amazon aveva resistito anche al terremoto…
Eppure l’infrastruttura di Amazon aveva resistito anche al terremoto…
La domanda che mi pongo io è diversa: ma se nemmeno Amazon riesce a governare il cloud (e loro ne hanno fatto un business) come si può pensare che dei comuni mortali possano farcela? Per quanta fiducia io abbia in me stesso penso di non essere al livello di Amazon!
Oppure: non si sta facendo di “un piccolo” down un gran chiacchierare? Alcune volte mi sarebbe piaciuto tanto dichiarare 6 ore (o anche 12…) di fermo… magari solo ogni 3 o 4 anni! Insomma… si vede la pagliuzza nell’occhio del vicino ma non la trave nel nostro!
Quindi se vogliamo trovare una morale in questa storia è che il cloud lo deve fare solo chi è capace! E gli altri? Appoggiarsi a chi è capace!
Ciaoo
Piero
Piero,
In realtà lo sbaglio è stato supporre che l’infrastruttura di Amazon fosse a prova di bomba, EC2 non è un servizio di Infrastructure as a Service che ti garantisce il 100% di uptime (anche perché costerebbe centinaia di volte di più, per costi di infrastruttura), è vero che hanno anche violato la loro SLA ma è da stupidi pensare di appoggiarsi ad EC2 con una applicazione critica e non prevedere ridondanza, Smugmug è un grosso sito di photo sharing (1+ PB di foto, tutte su Amazon) che utilizza pesantemente EC2 e grazie ad un design applicativo fatto come si deve i loro utenti non hanno subito disservizio: http://don.blogs.smugmug.com/2011/04/24/how-smugmug-survived-the-amazonpocalypse/
Per il resto, mi dispiace per quel poveraccio che aveva la sua applicazione di monitoraggio di pazienti con problemi cardiaci disegnata senza ridondanza, ma certe volte prima di realizzare delle applicazioni così critiche bisognerebbe rendersi conto di quello che si fa 🙂
ciao,
Fabio
Relativamente a che punto hanno violato la loro SLA Fabio?
Comunque i veri poveracci sono i pazienti di quel pazzo che si è appoggiato ad AWS con un applicativo cosi critico senza considerare alcun sistema di ridondanza 🙂
La domanda che mi pongo io è diversa: ma se nemmeno Amazon riesce a governare il cloud (e loro ne hanno fatto un business) come si può pensare che dei comuni mortali possano farcela? Per quanta fiducia io abbia in me stesso penso di non essere al livello di Amazon!
Oppure: non si sta facendo di “un piccolo” down un gran chiacchierare? Alcune volte mi sarebbe piaciuto tanto dichiarare 6 ore (o anche 12…) di fermo… magari solo ogni 3 o 4 anni! Insomma… si vede la pagliuzza nell’occhio del vicino ma non la trave nel nostro!
Quindi se vogliamo trovare una morale in questa storia è che il cloud lo deve fare solo chi è capace! E gli altri? Appoggiarsi a chi è capace!
Ciaoo
Piero
Piero,
In realtà lo sbaglio è stato supporre che l’infrastruttura di Amazon fosse a prova di bomba, EC2 non è un servizio di Infrastructure as a Service che ti garantisce il 100% di uptime (anche perché costerebbe centinaia di volte di più, per costi di infrastruttura), è vero che hanno anche violato la loro SLA ma è da stupidi pensare di appoggiarsi ad EC2 con una applicazione critica e non prevedere ridondanza, Smugmug è un grosso sito di photo sharing (1+ PB di foto, tutte su Amazon) che utilizza pesantemente EC2 e grazie ad un design applicativo fatto come si deve i loro utenti non hanno subito disservizio: http://don.blogs.smugmug.com/2011/04/24/how-smugmug-survived-the-amazonpocalypse/
Per il resto, mi dispiace per quel poveraccio che aveva la sua applicazione di monitoraggio di pazienti con problemi cardiaci disegnata senza ridondanza, ma certe volte prima di realizzare delle applicazioni così critiche bisognerebbe rendersi conto di quello che si fa 🙂
ciao,
Fabio
Relativamente a che punto hanno violato la loro SLA Fabio?
Comunque i veri poveracci sono i pazienti di quel pazzo che si è appoggiato ad AWS con un applicativo cosi critico senza considerare alcun sistema di ridondanza 🙂
Secondo me la premessa è sbagliata: non è un problema di cloud o non cloud, ma, se vuoi, di DR, come hai giustamente detto alla fine del post.
Anche un “normale” data center, gestito dai migliori sistemisti può avere problemi (non ultimo l’errore umano). Se hai un’architettura ridondata e localizzata in differenti città/paesi/continenti/pianeti, hai possibilita’ di sopravvivere “digitalmente” a qualunque evento (sempre che tu abbia lavorato bene).
Ma il tutto ha costi alti, e, soprattutto, necessita di due fattori determinanti:
1) una cultura informatica, all’interno dell’azienda, che spesso non è presente
2) una sensibilità del management che anteponga qualità e continuità del servizio a qualche decimale in più sui ricavi.
Secondo me la premessa è sbagliata: non è un problema di cloud o non cloud, ma, se vuoi, di DR, come hai giustamente detto alla fine del post.
Anche un “normale” data center, gestito dai migliori sistemisti può avere problemi (non ultimo l’errore umano). Se hai un’architettura ridondata e localizzata in differenti città/paesi/continenti/pianeti, hai possibilita’ di sopravvivere “digitalmente” a qualunque evento (sempre che tu abbia lavorato bene).
Ma il tutto ha costi alti, e, soprattutto, necessita di due fattori determinanti:
1) una cultura informatica, all’interno dell’azienda, che spesso non è presente
2) una sensibilità del management che anteponga qualità e continuità del servizio a qualche decimale in più sui ricavi.