Non vorrei essere nei panni di chi ha passato il weekend di pasqua alle prese con i problemi di Amazon, non mi riferisco solo ai clienti ma anche ai sistemisti che non se la saranno vista proprio bene…

Amazon Web Services e molti dei suoi clienti hanno perso una bella fetta della loro credibilità ma, come ho detto in un tweet: “non è in discussione il modello cloud ma la sua implementazione”

Comunque è tutto finito, ora sembra che la situazione sia tornata alla normalità, ed è ora di fare qualche ragionamento più serio.

un fatto importante

La cosa più importante che vorrei sottolineare è che alcuni siti (es. SmugMug), anche fornendo servizio dai datacenter oggetto dei problemi, non hanno subito impatti importanti, perchè?
Semplice, avevano previsto questa eventualità ed avevano disegnato la loro applicazione in modo intelligente! Già, perchè molti hanno omesso di dire che gli strumenti per reagire a quanto successo esistono e sono insiti nell’architettura di AWS stesso… è solo che implementarli e gestirli costa e non tutti si sono sentiti di spendere.

ci vuole più maturità

La corsa al cloud, specialmente nell’ultimo anno, è stata furibonda! La promessa di abbattere il TCO delle proprie infrastrutture muovendo le proprie risorse verso il cloud ha fatto ubriacare molta gente e, spesso, questa migrazione è stata fatta senza conoscere a fondo la realtà del cloud. Molti sono partiti sperimentando qualche macchina virtuale per poi muovere pezzi interi di infrastruttura senza chiedersi cosa c’era dietro quelle allettanti bollette o i pannellini di controllo. Amazon (come tutti gli altri) è una architettura complessa basata su concetti molto nuovi e spesso in controtendenza rispetto a tutto quello che siamo abituati a vedere nei nostri datacenter tradizionali! E’ necessario studiare a fondo le architetture che i provider hanno messo in piedi, capire come funzionano, quali sono i limiti, e come sfruttarle per ottenere più con meno. 
Esistono tonnellate di documentazione, libri e articoli che spiegano in dettaglio AWS e tutti i suoi derivati ma, spesso, vedo che in molte aziende questo viene ignorato e che tutto si risolve con la mere credenza che EC2 sia solamente una qualche sorta di servizio che permette solo di creare macchine virtuali (magari da template preconfigurati).
Prima di affidare la propria infrastruttura al cloud è necessario capire bene come funziona.

pensare cloud

Capire le architetture e le API messe ad disposizione dai provider è fondamentale per poter scrivere applicazioni in grado di sfruttare al massimo tutte le caratteristiche con il minor impatto economico possibile.
Un esempio eclatante viene proprio da quanto ho scritto sopra, SmugMug ha scritto una applicazione da zero pensando al cloud come piattaforma su cui fare il delivery: l’alta affidabilità non è stata delegata all’hardware (come accade nelle infrastrutture tradizionali perchè se ne ha il controllo) ma al software!!
Questo approccio non è applicabile per tutti ed è per questo che la maggior parte degli utilizzatori di architetture cloud rimangono le startup e le PMI: aziende che non hanno molti vincoli con il passato in termini di dati, applicazioni e processi e che possono disegnare (o adottare) nuove soluzioni senza dover fare i conti con troppi fattori.

riassumendo

L’incidente di Amazon non ha cambiato nulla se non una maggiore consapevolezza che non esiste la panacea per tutti i mali (o meglio che l’affidabilità costa). Spero solo che quanto accaduto rimarrà nella memoria di molti e che aiuterà a creare infrastrutture migliori nel prossimo futuro.