AWS ed i disservizi nell’area US-East 1

I problemi che hanno interessato i servizi AWS e dei clienti dell'area US-East 1 hanno riaperto le discussioni sull'affidabilità del cloud

AWS infrastruttura a livello globale

Nella giornata di domenica 20 settembre si è nuovamente tornati a parla di resiliency (resilienza, “capacità di ripresa/recupero” – parola poco utilizzata dalle nostre parti) e ridondanza. Tra le 2 e le 8 del mattino (tra le 11 e le 17 ora italiana) si sono verificati infatti alcuni problemi nel data center AWS situato in North Virginia –  sul quale poggia l’area US-East 1 della nota piattaforma cloud.

E’ inutile ribadire che il disservizio non è passato certamente inosservato  – per tutta una serie di prevedibili motivi: a parte il soggetto interessato, AWS è il leader indiscusso del mercato, le difficoltà riscontrate dal data center hanno mandato offline o causato evidenti disagi a vari servizi del provider (ElastiCache, Glacier, EC2, Redshift etc) e di noti portali che “risiedono” nell’area US-East 1 – tra i tanti citiamo ad esempio Reddit, Netflix, IMDB.

I commenti a caldo e del giorno dopo hanno invece ricalcato un copione più o meno conosciuto: dall’eccessiva fiducia che erroneamente si ripone nei servizi cloud in generale (ad eventuali disservizi si pensa unicamente a fatto avvenuto) fino a opinioni varie sul come mitigare tali avvenimenti (affidarsi a più colocation provider ad esempio). Come ha sottolineato l’editorialista di Forbes Justin Warren, il recente disservizio AWS non dovrebbe influire minimamente sull’approccio che medie e grandi imprese adottano nel cloud: i disservizi sono e saranno sempre parte integrante del sistema e pensare che [“spostare le applicazioni nel cloud renda tutto magicamente migliore e perfetto è abbastanza ingenuo”].

D’altra parte, prosegue, anche il corretto approccio di coloro che danno per scontati inevitabili imprevisti non risolve completamente il problema: lo studio di applicazioni su larga scala in grado di fare fronte a variabili tipologie di imprevisto (“failure”) è infatti un’ardua e complicata “scienza”. E per dimostrarlo è possibile affermare in sintesi quanto segue: un’applicazione puà essere programmata nell’ottica di un utilizzo in un’infrastruttura “fragile” o “robusta”. Cosa significa esattamente?

Nel primo caso lo sviluppo è più impegnativo perchè bisogna tenere conto delle problematiche dietro l’angolo (un’infrastruttura economica è più soggetta a “failure”); nel secondo caso, dando per scontato che l’applicazione sarà adoperata in un’infrastruttura perfetta o quasi (ma costosa per via delle configurazioni RAID, ridondanza etc), lo sviluppo sarà teoricamente più semplice – eppure compagnie come Google, AWS e Microsoft si trovano periodicamente a fronteggiare problematiche del genere.

A fronte di quanto detto, è ovvio che la prevedibile costante resta sempre la seguente: prima o poi si verificherà un guasto o un disservizio e occorrerà disporre di un piano adeguato per sopperire ai temporanei disagi. La sfida per le aziende del settore ed i programmatori continua.

 

Facci sapere cosa ne pensi!

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