There must be a fairer use model possible. Google App Engine seems to manage it.

posted by Andrew Davey

posted by ZippyV

Also, the Azure storage tables are a joke. The primary key system is unnecessary complex and there is no sorting possible.

posted by ZippyV

posted by ChrisStepaniuk

It would be nice if it was a platform that really scales, that it would be a viable option for small systems that aim to potentially build, perhaps not yet.

posted by stevo_

Also, as a last resort backstop, I would like some kind of Do-Not-Exceed limit per month.  So just in case something goes haywire, I don't end up needing to sell the house to pay Azure fees.  I would guess this has be in there somewhere as I don't see any other business man signing off on an open monthly check ?  TIA

posted by staceyw

Pricing per instance is indeed $86.40, and for SLA's to kick in you would need 2 instances ($172.80) more on SLA's below.

So now there are some applications/services that probably don't make a lot of sense. As an example, I probably wouldn't want to run my blog at $172.80+ /per month, but if I am an ISV, I may want to host my multi-tenant CRM application in the cloud.

Part of the value of the cloud, is the ability to scale up and down and only pay for what I consume. Let's say I'm in the travel business, and Jan/Feb are the 2 busiest months of the year, where I need 100s of servers to handle the load. The rest of the year I could be running 10s of servers to handle the load. If I run this in my own datacenter, I need 100s of servers. If I host this in Windows Azure, then I only pay for those servers/instances I use. So in Jan/Feb I'll be paying for 100s of servers/instances, and the rest of the year only 10s. The great thing is, if there is a unforseen spike, I can simply add more servers/instances. I can also remove servers/instances when times are quiet.

The other thing to keep in mind is that we do all of the infrastructure work for you. We manage and maintain the OS, network, load balancers, DNS, cooling, monitoring, availability, disaster recovery, hardware maintenance etc. All you really need to worry about is building your application. The simple example is that if there is a hardware failure, we simply move you to another server. No need for you to get involved there. Couple that with the ability to scale up and down and I think its pretty awesome.

On the point of SLAs - we hint at some SLA's on the pricing page at http://www.microsoft.com/azure/pricing.mspx, but don't go into specifics. At commercial availability there will be detailed SLA information as well as details of retrobution/consequences etc. The final billing/SLA model will also help clarify the question around DOS attacks etc.

Google App Engine have a different approach to Windows Azure, where we allow you to control absolutely the number of instances running, Google App Engine do not. There are pros and cons to both approach depending upon the application/service you want to host.

posted by DavidAiken

If your data has complex relationships, you need to aggregate data, query based upon multiple parameters, then Windows Azure Tables may not be the right answer. For this kind of "storage", you really need compute + storage. There are 2 choices for this.

1. Use SQL Azure - SQL Azure is essentially SQL Server hosted in the cloud, with all the infrastructure/operations elements taken care of. You only need worry about the database. This will give you the SQL functionality you know and love. Remember SQL Server is maintaining those indexes/views etc. that make querying the data easy.

2. Use Windows Azure Storage to store the data and Windows Azure compute to maintain de-normalized data. Here you do have to do some work yourself.

If you data can be found by using a key and is usually accessed as such, or you have semi-structured data - then Windows Azure table storage could be a good answer. When thinking of tables, think of them more as collections of entities. Each entity in the table could be a different structure. Entities are organized by partition key. Entities with the same partition key are together on disk. Partitions can be on the same storage server as each other, or on different servers. This allows us to scale out, but also we can potentially move hot partitions onto other servers. On the scale out side, tables are designed for scale, so billions of entities across x partitions.

Using Entities, you could store a users profile, wish list, shopping cart, invoices and past orders all in the same partition, and read all that data in a single API call.

Hope this gives you some more ideas on tables, but chime in with your thoughts.

posted by DavidAiken

posted by petersan