Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Doug Hauger: Inside the Windows Azure Platform Business Model

Download

Right click “Save as…”

  • High Quality WMV (PC)
  • MP3 (Audio only)
  • MP4 (iPhone, Android)
  • Mid Quality WMV (Lo-band, Mobile)
  • WMV (WMV Video)
Meet Doug Hauger, Azure General Manager. Doug owns the business side of the Azure Platform equation. How was the pricing determined? Are there different plans for "garage innovators" versus large enterprise customers? What does it all really mean? Would we be able to finish the converstion in under 15 minutes (hard for me to do, as you know...Smiley)? Of course, the complexity of the Azure business model would determine the time it takes to explain it (and the thinking behind it). Well, as you can see by the length of the interview, apparently the Azure people constructed a pricing model that is greatly simplified compared to some of our other business pricing models from years past. The overall simplicity of the plan is impressive.

Tune in. Meet one of the key minds behind the Azure business model and learn about some of the reasoning used in constructing the official plan:

Windows Azure, SQL Azure and .NET Services will be commercially available at the Professional Developer Conference 2009 and we hope you will continue building on the Community Technology Preview (CTP) at no cost today.    

Upon commercial availability we will offer Windows Azure through a consumption-based pricing model, allowing partners and customers to pay only for the services that they consume.

Windows Azure:
Compute @  $0.12 / instance hour
Storage @ $0.15 / GB / month stored
Storage Transactions @ $0.01 / 10K
 
SQL Azure:
Web Edition – Up to 1 GB relational database @ $9.99 Business Edition – Up to 10 GB relational database @ $99.99 

.NET Services:
Messages @ $0.15/100K message operations, including Service Bus messages and Access Control tokens

Tags:

Follow the Discussion

  • Andrew DaveyAndrew 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.

  • ZippyVZippyV Fired Up

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

  • ZippyVZippyV Fired Up

    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.

  • 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_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.

  • William Staceystaceyw 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

  • 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.

     

     

  • 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.

  • Cool,
    this is perfect for Blogtronix as we are a .NET platform and now we can offer a complete solution for our customers and even hit MOSS under the belt with their own solution.
    Need to start testing this as well as the new Amazon could windows solution.

     

    computerslanditcomputer computerslookup

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.