Doug Hauger: Inside the Windows Azure Platform Business Model | Charles

Andrew Davey
www.aboutcode.net

Charges for "compute" are applied even when an instance is idle. So a website that does nothing will cost $86.40 per month!

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

ZippyV
Fired Up

For 86$ a month I can get a lot more than just a stupid webserver without a database.

ZippyV
Fired Up

In reply to Andrew Davey

#Aug 18th @ 3:39 AM

And if you have only 1 compute instance you are not guaranteed any uptime. Servers will be patched and your instance will go down because of that. When that instance go down it will be automatically started on another server but that might take some time.

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

ChrisStepaniuk

Not to be a pessimist, but you still haven't mentioned the SLA. You know, the document that says, who gets in trouble when my instance is down. When I see an SLA that has retrobution and consequences in it, I'll take Azure more seriously.

stevo_
Human after all

If you pay for idle time the same as processing time, and it costs that much for idle time then it only proves this platforms powers aren't in its costs, but its 'cloudyness'..

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.

staceyw
Before C# there was darkness...

Lets say I build my app and api and get things going and publish my api for customers to test and build their own client (ala twitter like clients for example using azure backend - seems a fairly reasonable senerio). Now, what controls do I have to protect myself from customers that may try to spin off thousands of api calls during testing or some DOS attack? IIRC, the twitter backend will block calls after so many per hour. I may want X many per day per IP or other such policy. Will there be support for this kind of policy I can apply to my azure services?

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

DavidAiken

Thanks for the comments on this. I'll try to clarify a few things, or at least provide more information/fuel for the discussion.

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.

DavidAiken

In reply to ZippyV

#Aug 18th @ 8:36 AM

On the subject of Tables being a Joke. It really depends upon why you need to use them.

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.

In reply to {0}

Download:[Pending]