Real World Windows Azure Costing Examples, Anyone?

Question

OK, we're in Dec 2010, azure has been out now for a decent period. Sure I've come across silly articles predicting what it might costs to run with Azure (http://robburke.net/2010/01/28/windows-azures-pricing-model-discourages-small-scale-apps/). But what I'd really like to know is who has run Real World Live Azure Apps? What did your applications looks like - which services, how many roles, what storage, how many users etc. and ultimately how much did it cost you?

Right now, trying to figure out whether to invest 6 months in developing an azure app is looking grim because it's such a black box predicting what is might costs to run an application.

I'm surprised I couldn't find a good real world set of examples that would help developers have more visibility into helping them buy into the platform...

Answer 1

Check out the SQL Azure pricing calculator:

http://www.microsoft.com/windowsazure/pricing-calculator/

Answer 2

It's a pretty use case specific question, but I'd make the following comments:

1. Designing to run on Azure will benefit your app regardless - stateless services, caching, multiple instances and segregation of roles are all good practice that transfer to any deployment.
2. If you are an MSDN subscriber or Microsoft Partner (Bizspark etc), you can get Azure time for free. Even if you aren't there's an introductory offer which is free.
3. The beauty of cloud is the ability to start small - with the new "Extra Small" Role instance, you can be up and running for under $50 a month.

The way I cost azure (in a very oversimplified way) is that each "compute unit" (1 cpu and std block of RAM) is ~$90, store and bandwidth are negligible in comparison, so round up to $100 a month per compute node. Store is already redundant so you don't have to worry. So a typical web scenario of a pair of web servers, one small SQL database and a chunk of table store and you're looking at about $210 per month.

Answer 3

I think its a fair question to ask, but anyone will struggle to give you an answer, as your results will always vary and replies from people in the field would be too specific to their particular situation.

I have a real-world solution that we run in Azure. In fact, if you do decide to go with Azure, consider using it to optimize your compute-instance allocation for Azure: http://www.paraleap.com :)

I can tell you that you want to budget at least 20% extra computing hours due to various times when you need to deploy/redeploy/and re-deploy again an environment into staging area (which costs extra in hourly increments) only to find out that's something else in the cloud does not work when it worked in the dev fabric. This is especially true in the initial unstable time of your application. It does not matter if you have a large QA team that bangs the heck out of your Azure-QA environment or you're going to customers for beta-testing and they're testing your Azure-Prod environment. You will need to be redeploying for them quiet often. Furthermore, as I already mentioned, plan to adjust your instance counts to demand - hopefully automatically or on a schedule. If you're going to write your own monitoring to do this, add a /bunch/ to development costs, storage costs, and transaction costs just for that. Outsourcing this will still cost a little bit, as performance metrics will need to be at least saved once and at least loaded back once. This will save you in the compute-instance costs easily as much as 50-80%, depending on how variable your demand is.

Storage costs - those should be easy to estimate if you know your usage patterns and target schema... Problem is, if you've worked with Relational databases before and now will be using table Storage, plan to have 3-4 times the size that you would have thought your relational database to have. With table-storage you get to denormalize ALOT more. 3-4x maybe even too small of a multiplier - your results may vary.

Transaction costs. I'm finding out that with these, I've been further-off in my estimates. Coming from relational world, I wasn't totally prepared for the level of denormalization I needed to do. Denormalization not only leads to higher storage costs, but also to more calls (alot more calls) to the storage - resulting in higher transaction count.

Unfortunately, my nature of the app, I can't very well use transactional model. If you can use transactions, where a bunch of stuff is stored in one PartitionKey within one table and committed with one transaction - then the costs are much less. So, whatever you think your transaction costs will be - multiply that by 10 or so to be on the pessimistic side.

I found that transfer costs were easiest to plan for, probably because those are part of the interfaces and are much better defined upfront. Your mileage may vary.

And lastly, diagnostic data - you will want to save some trace/performance counter/etc. information. Don't forget to plan for it. It's somewhat denormalized and can take plenty of space.

SQL Azure is great as it does not charge by transaction cost and no transfer costs if inside the same data center - but is very limited by space and cost to store the data. So, I use it for frequently queried for, but small data items.

Hope this helps