Quando il clima influenza l’ecosistema delle API, c’รจ qualcosa che non va.

Per chi non lo sapesse – ma non ci credo nemmeno un po’ย – Instagram (e non solo loro) da questa mattina รจ completamente KO.

Colpa di Amazon, si dice.

Da quello che ho letto, tanti instagrammers hanno scoperto il problemaย di Instagram verso la mezza mattinata di oggi, quando, ripresi dalla serata del venerdรฌ o ancora impegnati nella vita familiare del sabato mattina, dopo aver impugnato lo smartphone per scattare qualche foto, hanno trovato un messaggio che diceva che il servizio non era disponibile.ย Tutti hanno cominciato a twittare che qualcosa non andava, che non era possibile caricare foto e cosรฌ, tra il turbamento, lo shock, l’ansia da scatto frenetico mancato e la sindrome da InstagrammersSenzaInstagram, si รจ diffusa la notizia del problema.

World wide, Instagram รจ down. E la colpa รจ di Amazon.

Aย me non รจ andata esattamente cosรฌ. O meglio, lo shock l’ho avuto anche io, ma per colpa delle API. Quelle di Followgram.

Praticamente le notifiche del problema di Instagram le ho iniziate a ricevere dalle ore 5.30 di questa mattina, mentre dormivo: prima ricevo un DM su Twitter da un brasiliano che mi dice di avere problemi ad autenticarsi. Poi dalle ore 5.45 circa, iniziano ad arrivare in sequenza segnalazioni e mentions sull’account di Followgram da parte di utenti che segnalano malfunzionamenti sul sito e lamentano di non poter accedere.

E cosรฌ, ancora cotto di sonno, mi alzo, controllo la posta, poi uservoice,ย guardo twitterย e trovo una quantitร  industriale di segnalazioni relative al malfunzionamento di Followgram. Tra un tweet ed un altro, leggo che si tratta di un problema di Amazon che ha colpito anche altri siti (Pinterest, Netflix and Heroku). Faccio due verifiche, il server รจ su, il Db anche, il dominio si vede… e Amazon?!? Ma dai, รจ perfetto e non ha problemi.ย Siamo up e running: Amazon fino ad ora non ci ha mai tradito, รจ sempre su, e poi noi siamo tranquilli, abbiamo anche una VPS dove manteniamo un clone per sicurezza, perchรจ ci piace dormire tranquilli, non su Amazon.

Ma allora che problema c’รจ? In effetti, Amazon รจ giรน. Ma non il nostro che si trova in un’altra area: รจ giรน quello che sta in Virginia, dove รจ passata una mega tempesta che ha spento tutto. E si, Instagram รจ proprio lรฌ. “Solo lรฌ”.

Peccato che se noi siamo su, e loro sono giรน, anche noi siamo giรน. O meglio, un pรฒ meno giรน di loro (magra consolazione), ma allo stesso tempo incasinati perchรจ strettamente legati alle loro API: non cresciamo, non eroghiamo il servizio, non acquisiamo nuovi utenti, non fatturiamo.

Ed ecco qui la riflessione: quando il clima influenza l’ecosistema delle API, c’รจ qualcosa che non va.

C’รจ qualcosa che non va perchรจ se hai un modello di business o un servizio basato su altri (nel nostro caso tramite API di Instagram), sei praticamente come un apetta lavoratrice legata all’Ape regina. Se quella non funziona (o peggio ancora muore), tu sei nei casini. E non pochi.

C’รจ qualcosa che non va, soprattutto, perchรจ, come giustamente ha detto anche Alessio nel suo post, la Cloud sembra perfetta ma non lo รจ ancora e non ci si puรฒ ancora fidare al 100%. Ed il problema, secondo me, non รจ solo un problema tecnologico, ma di strategia, perchรจ ogni azienda, ogni applicazione, ogni progetto ha una sua struttura, un suo dna, un suo funzionamento e i suoi tempi di batch, allineamento, backup e gestione dei dati e nessuna infrastruttura potrร  mai, singolarmente, sostituire in modo standard ogni singolo modello.

La dimostrazione l’abbiamo avuta oggi con Amazon e Instagram: un’applicazione comprata per milioni di dollari che non รจ raggiungibile per quasi 20h consecutive perchรจ il suo carrier รจ andato giรน per una tempesta. Praticamente Amazon รจ stato il Single Point of Failure di Instagram.

All’inizio del post ho detto, non a caso, “Colpa di amazon, si dice”. Il si dice fa riferimento al fatto che tutti stanno guardando al problema di Amazon, ma nessuno (o quasi nessuno, leggete il post di Ingrid Lunden su techcrunch) sta pensando al fatto che Instagram, ribadisco, progetto pagato milioni di dollari, non abbia un piano di Disaster Recovery e Business Continuity tale da garantire il funzionamento anche a fronte di una tempesta e non abbia saputo garantire ai suoi utenti e al suo ecosistema di API e applicazioni, un ripristino immediato o in tempi ragionevoli.

Credo che questo tema, la business continuity, sia un tema caldo da affrontare su molti progetti di startup che sottovalutano ampiamente il concetto di continuitร  operativa.

Alla fine, la cosa positiva di oggi รจ che, non sapendo stare fermo ad aspettare, mi son messo a lavorare su altro.

Il lato oscuro del Cloud Computing

Nel 2010 la parolaย Cloud Computing รจ stato uno dei termini piรน citati dai CIO, dagli addetti ai lavori dell’IT, dalla maggior parte degli utenti della rete ed รจ stato come avevo anticipato uno dei driver dell’anno. Tendenzialmente tutti hanno valutato, preso in considerazione e utilizzato, almeno una volta, soluzioni Cloud per scopi privati o business. Basti pensare alle email, e magari al caso specifico di Google Gmail o delle Google Apps, per rendersi conto di quante persone utilizzano questo tipo di sistemi, o al crescente utilizzo di DropBox o sistemi di disco remoto per foto, video e hosting.

Gli esperti di Stonesoft Corporation, nota societร  americanaย finlandese (Grazie a Francesco per la segnalazione dell’errore) che si occupa da anni di sicurezza informatica, giร  in una nota di Marzo 2010, stimava un aumento dei servizi di Cloud Computing per l’anno in corso e allo stesso tempo segnalavano il potenziale aumento anche di minacce per la sicurezza.

Dal mio punto di vista se non si tiene nella giusta considerazione la sicurezza dei dati affidati a terzi, il Cloud Computing puรฒ rappresentare un rischio sia se si tratti di un azienda, sia per il privato. Nel momento in cui le societร  o le persone utilizzano i servizi in Cloud e affidano i propri servizi IT a terze parti, consegnano a tutti gli effetti la riservatezza, lโ€™integritร  e la disponibilitร  dei loro dati e sottomettono tutte queste informazioni alla legislazione del territorio sul quale depositano i dati.

Anche se la qualitร  del servizio (QoS ย – Quality of Service) รจ garantita da accordi tendenzialmente forti come quelli sul livello del servizio (SLA – Service Level Agreement), raramente questi livelli di servizio considerano alcuni aspetti della sicurezza strettamente legata al business specifico del cliente. Nella scelta del fornitore, nel caso del Cloud si puรฒ parlare di partner tecnologico piuttosto, i responsabili IT delle aziende o gli utenti che scelgono di portare i propri dati su una nuvola, dovrebbero prestare molta attenzione ai sistemi di sicurezza di cui dispongono le aziende, dovrebbero analizzare le caratteristiche tecniche del servizio e approfondire i requisiti dellโ€™azienda dal punto di vista della soliditร  dei sistemi, delle procedure di disaster recovery, della business continuity e di tutti i sistemi di audit, logging e reporting qualora si verificasse un abuso ai dati o un danno.

Purtroppo, troppo spesso, l’attenzione per la sicurezza emerge solo a seguito di gravi incidenti legati alla perdita o alla violazione di dati distribuiti โ€œon the cloudโ€ o non gestiti correttamente.

Nel mia esperienza privata, malgrado la mia “maniacale” attenzione per backup e ridondanza di dati, un mese fa sono stato vittima del cloud di Google Gmail: per circa 48 ore la mia casella di posta elettronica e quindi tutti i miei dati non sono stati accessibili per un “disservizio” sul mio account. Panico. Per fortuna tutto รจ tornato disponibile in “poco” tempo. La prima cosa che ho fatto al momento del ripristino del servizio รจ stato configurare un ulteriore download della posta su un pc di backup. Ma se non fosse tornato su?

Ma quindi esiste un lato oscuro del Cloud Computing? Secondo me si. Andare in Cloud ha tantissimi vantaggi e lati positivi, ma in fondo, il fattore piรน importante, la disponibilitร  del dato e la riservatezza, viene sottovalutato.

Quindi attenzione: portate i dati in cloud, ma non rimanete con la testa fra le nuvole.