giovedì, dicembre 10, 2009

aKite su PMI.it

Oggi su PMI.it è pubblicata in home page un’intervista con Francesco Caccavella in cui si parla ampiamente di aKite.

logo_aKite

mercoledì, ottobre 21, 2009

aKite Retail Web Services

In questi ultimi mesi tutti noi di BEDIN Shop Systems siamo stati impegnati nella migrazione dei nostri Retail Web Services alla piattaforma Azure di Microsoft.

La nostra soluzione è stato rinominata per riflettere questo grande cambiamento: aKite Retail Web Services
Spero che il nome piaccia al “pubblico” tanto quanto piace a noi.

logo_aKite
Maggiori informazioni sono disponibili nel sito del prodotto: www.akite.net

La migrazione si è completata con soddisfazione in questi giorni, ad un mese dall’annuncio della disponibilità della piattaforma che verrà fatto a PDC09 a Los Angeles, dal 17 al 19 Novembre 2009.

PDC09Bling_General_WhatsNext_240[1]

Anche questo anno saremo a PDC09, in questa occasione tra le primissime aziende al mondo che hanno realizzato un gestionale completo su Windows Azure e SQL Azure.

mercoledì, luglio 15, 2009

Pricing di Windows Azure

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.

giovedì, febbraio 12, 2009

Azure Needs A Real RoadMap

Per la serie “è meglio aspettare che sia un’autorità ad esprimere per prima questo pensiero”, Scott Watermasysk scrive che Microsoft Azure necessita di una vera, chiara ed attendibile roadmap, altrimenti è veramente difficile affrontare seriamente lo sviluppo sulla piattaforma.

Azure Needs A Real RoadMap

Non passa una settimana che Amazon Web Services faccia un nuovo annuncio, che si tratti di un nuovo servizio o dell’abbassamento delle tariffe.

Azure, se ci sei, batti un colpo!

PS: ricordo che è stato Scott a dirlo!