Alla Worldwide Partner Conference 2009 di New Orleans sono stati finalmente annunciati i dettagli del pricing di Windows Azure. Il post dettagliato lo trovate qui.
In sostanza, si pagano 0.12 $ all’ora per tenere attiva un’istanza di Azure e per avere un buon SLA si deve pensare ad averne al minimo due.
Se si usa lo storage di Azure, tabelle e code, si parla di 0.15 $ per GB al mese e 0.1 $ per 10mila transazioni su questi dati.
Poi c’è un tot per il traffico in entrata (0.1 $ per GB) ed in uscita (0.15 $ per GB).
SQL Azure costa 9.99 $ per un database da 1 GB, oppure 99.99 $ per per un database da 10 GB, sempre al mese; non sono disponibili dimensioni di db maggiori, fattore importante da tenere a mente.
Ipotizziamo uno scenario con un paio di istanze che rimangono attive sempre, come deve necessariamente essere per dei servizi web a supporto di smart client. Quindi abbiamo 2 istanze * 24 ore * 365 giorni * 0.12 $ = 2104 $.
Aggiungiamo il traffico, ipotizzo la saturazione totale e continuativa di 2 Mbps in uscita ed il traffico in entrata al 60%. Secondo i miei calcoli ottengo 923 $ (per 6159 GB in uscita all’anno a 0,15 $) e 369 $ (per 3695 GB in entrata all’anno a 0,1 $).
Consideriamo anche lo storage di Azure, per uno scenario come questo ipotizzo l’uso delle code e del “disco” di 100 GB mediamente al mese, con 10 mila transazioni all’ora. Ottengo 180 $ all’anno.
SQL Azure è più difficile da considerare; per questo scenario ipotizzo 10 database da 10 GB, uno per ogni cliente (penso a delle catene di negozi). Ottengo quindi circa 12000 $ all’anno.
In totale, senza considerare SQL Azure, ottengo un costo annuno pari a poco più di 3500 $. Se aggiungo SQL Azure secondo la mia ipotesi salgo a più di 15 mila $ all’anno.
Si dovrebbero analizzare meglio diversi aspetti di questo scenario per renderlo più realistico: calcolare meglio il traffico, che però non incide molto, considerare con maggiore attenzione le transazioni sullo storage. Aggiustamenti che non cambiano l’impressione che mi sono fatto confrontando il tutto con i costi di licenze software, hardware e hosting che si affrontano per mettere dei server in un datacenter, cioè che Azure sia molto competitivo nei confronti delle offerte tradizionali ed interessante, ovviamente, per chi realizza applicazioni SaaS.
Di SQL Azure trovo strano e poco coerente il pricing.
Per una soluzione SaaS considero importante garantire ai clienti l’isolamento massimo dei propri dati da quelli degli altri clienti. Un modo per avvicinarsi all’obiettivo credo sia isolare fisicamente i dati del cliente, creando un database per ogni cliente. In questo modo anche le operazioni di backup e restore si semplificano. Quindi, per me, 100 clienti significano 100 diversi database.
Di questi 100 clienti, nella mia realtà, alcuni possono avere meno di 10 postazioni su cui operano gli smart client che interagiscono con i servizi web, altri clienti avranno centinaia di postazioni che producono dati, oltre ad interrogarli. Quindi avrò alcuni database da “solo” 200 MB dopo un paio di anni di attività ed altri da 10 GB già al primo anno di esercizio.
Avrei trovato più “giusto” ed affine al pricing degli altri servizi se SQL Azure fosse fatto pagare a tot centesimi per GB occupato al mese, con tetto masso di 10 GB per database se necessario e senza distinzioni di numero di database.
Magari un esperto di SQL Server mi darà del pazzo per l’idea di isolare i dati dei clienti separando i database, magari sa che SQL Server è allergico ad un numero elevato di database. Io questo non lo so ma sono abbastanza convinto della mia osservazione: SQL Azure dovrebbe essere fatto pagare per lo spazio occupato indipendentemente dal numero di database.
Segnalo un interessante white paper in cui David Chappell descrive gli scenari che Azure apre agli ISV.
Inoltre, ecco una interessante spiegazione di cosa è Windows Azure, by Steve Marx.
Post
