Selezionare un fornitore di servizi cloud è un compito sempre più delicato: i progetti cloud crescono in numero e ampiezza e i vendor stanno cercando di differenziarsi focalizzandosi su specifici componenti d’offerta e garanzie di servizio (Sla). Esperti e consulenti possono fornire ‘guide pratiche’ anche approfondite su come procedere, ma per farsi un’idea iniziale basta un insieme di criteri, poi sviluppabili a piacere, come quello proposto da Geva Perry (nella foto), autore di Thinking Out Cloud, uno dei blog più seguiti sul cloud computing.
Secondo Perry la scelta del fornitore cloud deve basarsi su valutazioni di performance, stack tecnologico, Sla e affidabilità, sicurezza e conformità, e ovviamente costi. Un problema quindi molto complesso, anche se iniziano a emergere servizi appositi per comparare le diverse offerte.
Partiamo dalle performance, certamente un aspetto ‘pesante’ nella proposta di un fornitore cloud. “Per valutare la velocità d’erogazione dell’applicazione nella cloud – scrive Perry – occorre avere visibilità completa sul complesso percorso che fa l’applicazione per rispondere a una richiesta”. Tra gli elementi rilevanti ci sono la distanza fisica tra utente finale, applicazione e dati, le performance di rete entro la cloud e da questa all’utente, la velocità dell’accesso I/O tra layer di elaborazione e di storage. Come misurare tutto ciò? Un aiuto può venire da alcuni servizi specifici come CloudSleuth di Gomez, divisione di web performance monitoring di Compuware, che mostra con grafici e statistiche come si comporta un’applicazione negli ambienti public cloud più diffusi (Amazon Ec2, Google App Engine, Windows Azure, GoGrid, ecc.). O come CloudHarmony, start-up indipendente specialista appunto di misurazione di performance e disponibilità dei cloud provider.
Un altro elemento da valutare è lo stack tecnologico di riferimento. Per ampliare l’offerta da IAAS (infrastructure-as-a-service) a Paas (platform-as-a-service), il vendor spesso si concentra su un solo stack. Perry cita per esempio Heroku e Engine Yard per Ruby on Rails, VMforce e Google App Engine per Java/Spring, PHP Fog per PHP e Windows Azure per .Net. “Se la vostra applicazione si basa su un certo stack, è bene considerare fornitori che abbiano la relativa offerta PAAS: risparmierete tempo e denaro evitando setup e configurazioni al livello tecnologico più basso, anche se per sviluppare dovrete rispettare percorsi e best practice che creano un certo livello di lock-in”.
Un componente d’offerta rilevante è anche l’ambito SLA/affidabilità, su cui gli operatori cloud meno conosciuti cercano di differenziarsi rispetto a colossi come Amazon. GoGrid per esempio con il suo ‘10.000% Guaranteed SLA’ risarcisce un’indisponibilità di servizio con il centuplo del valore di quel servizio: se un’applicazione in cloud risulta inaccessibile per 4 ore; il cliente poi l’avrà fornita gratuitamente per 400 ore.
Come in questo caso, però, gli SLA sono spesso risarcimenti a posteriori più che livelli di servizio garantiti a priori: “E’ difficile ottenere informazioni sui reali livelli di uptime di un fornitore cloud: molti hanno una pagina web apposita che però contiene pochi dati sui giorni immediatamente precedenti – spiega Perry -. Per avere dati sulle disponibilità di lungo termine bisogna ricorrere a testimonianze di clienti o servizi come CloudHarmony e CloudSleuth”.
Un aspetto piuttosto sottovalutato è poi quello delle API (application programming interface) che il fornitore cloud ‘espone’ per l’accesso alle infrastrutture o per attività come l’attivazione o disattivazione dei server. Un’API supportata da tanti fornitori e comunità di sviluppatori riduce la dipendenza da un singolo vendor, e spesso è corredata da un ecosistema di servizi e funzioni accessorie. E’ il caso per esempio, scrive Perry, delle API esposte da Amazon Web Services (AWS) o dalle varie offerte cloud basate su stack VMware, con tool di governance (enStratus), monitoring e management (Cloudkick, RightScale). “Amazon, VMware e in parte anche Windows Azure permettono di implementare cloud interne sulla base dei loro stack e API, cosa che molti definiscono cloud ibrido”. Un’alternativa è Rackspace che, supportata dalla NASA e da vari fornitori cloud, ha reso open source il proprio stack software con un progetto chiamato OpenStack.
Pochissimi invece trascurano di valutare il fornitore rispetto a sicurezza e conformità, finora i ‘nemici’ principali del cloud computing. I timori delle aziende non sono tanto sulla sicurezza ‘tecnica’, quanto sulla propria capacità di rispettare sia le tante conformità richieste che gli standard di sicurezza. A questo molti cloud provider rispondono mostrando audit, certificazioni e white paper; Logicworks addirittura ha battezzato la propria offerta “Compliant Cloud”.
Nessuno trascura neanche la variabile costi, “anzi molti, sbagliando, la considerano l’unico e immediato criterio”. Il problema è che non c’è uniformità tra le terminologie dei vari fornitori cloud e tra queste e ciò che viene realmente fornito: “Le Virtual Machine possono essere molto diverse per memoria, velocità di clock e altre funzioni e anche le altre risorse possono essere virtualizzate o no; Amazon usa le EC2 Compute Units, Heroku i ‘Dynos’ e altri hanno le loro unità di misura. La cosa migliore – conclude Perry – è testare concretamente il rapporto costi-performance di un’applicazione nei vari ambienti cloud”.
