E’ di pochi giorni fa la notizia che alcuni servizi API gratuiti forniti da Google verranno chiusi. Tra questi spicca Translate API, la più apprezzata libreria gratuita per la traduzione automatica sul web. Basta una occhiata ai commenti per rendersi conto dello sconcerto generato dall’annuncio, per altro del tutto inatteso. Molti si dicono disposti a pagare pur di non rinunciare alla API, ma non è  questa l’idea di Google che in alternativa propone Google Translate Element, widget gratuito che certo non è una soluzione accettabile per applicazioni che attualmente integrano la API in maniera trasparente. Immagino che proprio qui stia il nocciolo della questione: una API non è visibile né apprezzabile dall’esterno, mentre un widget promuove il brand Google.

Migliaia di aziende, enti pubblici e organizzazioni non governative internazionali che oggi usano la API dovranno trovare soluzioni alternative, probabilmente a pagamento. Almeno gli è stato concesso un po’ di tempo: Google garantisce un periodo di tre anni prima della sospensione del servizio.

Questa notizia induce ancora una volta alcune riflessioni circa l’affidabilità del Cloud Computing, modello di sviluppo verso il quale, volenti o nolenti, tutti noi siamo diretti.

Stand-Alone Vs Cloud Computing

Le vecchie applicazioni stand alone funzionano sempre e comunque. Prima o poi il programmatore originale sparisce dalla circolazione; del codice sorgente (se disponibile) nessuno capisce più nulla, ma l’applicazione continua a girare. E se una delle librerie usate dall’applicazione (le vecchie .dll, per capirci) viene improvvisamente abbandonata dal produttore? Non ci sono problemi, l’installazione gira come prima.

Nel dorato mondo PaaS le applicazioni smettono di funzionare non appena una singola API remota diventa inaccessibile. Non mi sembra una differenza da poco.

Disservizi e sorprese

Si potrebbe obiettare che appoggiarsi a una API gratuita per sviluppare un prodotto strategico non è una mossa intelligente e che comunque casi di disservizi come questo sono assai rari. In Aprile alcuni server Amazon AWS (la piattaforma cloud più usata al mondo) sono andati in corto circuito lasciando improvvisamente a piedi centinaia di fornitori di servizi e diversi milioni di loro utenti. Il disservizio, durato oltre ventiquattro ore, è avvenuto nonostante AWS sia un servizio a pagamento di altissimo livello che garantisce un livello di Service Level Agreement (SLA) superiore al 99%.

Un caso diverso ma dalle stesse conseguenze  si è verificato proprio in casa Google poche settimane fa, quando Google App Engine è diventato a pagamento (almeno per alcuni livelli di utilizzo prima gratuiti), mettendo di fatto fuori mercato molti piccoli servizi gratuiti che avevano scelto la piattaforma cloud del gigante di Mountain View.

Le contromisure necessarie

Non per questo penso che il cloud computing vada evitato, ne sono anzi un sostenitore convinto, ma è importante per noi tutti comprendere a fondo i limiti e i rischi che questo nuovo paradigma porta con sé.

Un paio di anni fa ho scritto un programma di backup remoto che si appoggia a Simple Storage Service (S3), uno dei servizi della piattaforma Amazon AWS. Il programma ha continuato a lavorare impunemente mentre il disastro si abbatteva sui server Amazon della East Coast perché, fin dall’inizio, era progettato per far fronte a evenienze come questa. Usa server multipli ridondanti dislocati su più aree geografiche, in modo che il crash di una singola server farm non lo mandi in tilt. E’ bene aspettarsi il peggio dai servizi cloud per essere pronti a gestire la crisi se (quando) verrà.

Per quanto riguarda il modello di business, è necessario adottarne uno che garantisca margini sufficienti a compensare improvvisi aumenti delle tariffe, anche solo per il periodo necessario alla eventuale dislocazione. La tendenza generale del mercato è comunque rassicurante: in questi anni costi dei servizi cloud sono calati costantemente.

Le responsabilità stanno da entrambe le parti

E se domani mi si annunciasse che S3 è improvvisamente deprecato? Fortunatamente per me e per le migliaia di altri il servizio non è gratuito e assicura ad Amazon utili stellari, ma non è questo il punto. Il punto è che in ogni momento potrebbe succedere.

I fornitori di servizi cloud hanno una grande responsabilità: garantire la continuità del loro servizio anche e soprattutto nel lungo periodo. Speriamo che ne siano coscienti. Noi programmatori e analisti dobbiamo tenere conto dei rischi che corriamo quando scegliamo di lavorare su piattaforme cloud, progettando i nostri prodotti di conseguenza.

Aggiornamento. Venerdì 3 giugno Google ha ritoccato l’annuncio ufficiale. La chiusura è annullata e la Translate API verrà messa a pagamento.