Having a hard time estimating costs...

Question

I have to report to the boss man how much Azure is going to cost for 100, 1000, 10000 etc. users.  Problem is, I am completely clueless on how to estimate this. 

For an "average" web application running ASP.NET 4 (MVC 3) and Entity Framework, can anyone provide estimations for outbound bandwidth?  At what point do we need a larger instance?  At what point do we need multiple instances?  I really just need ball park estimations... I don't know where to start.

Also, is there anyway to see these current statistics through the Azure management portal?

Any help would be greatly appreciated.

Answer 1

The first step is to look at how you'd estimate this on-premises. You should have a ball-park idea of how many users can be supported on say a single server. Using this as a base "scale unit" you establish the costs associated with bandwidth and storage needs (relational and non-relational). Add in some factor to account for the transaction costs (I've used anywhere from 10-25%) and you have a rough cost needed to support nn users. Now its just a matter of multiplication to determine how many of those "scale units" you'll need to support a given load.

Now keep in mind, this does make some broad assumptions. The key one of which is that your application will scale out several times of magnitude without modification or an increase in resource needs.

What you'll also likely find going through this is that 90% of the time, on-premises hardware requirements are simply a guess. And that we need to start developing better ways to help profile the resource needs of our on-premises applications.

Answer 2

The first step is to look at how you'd estimate this on-premises. You should have a ball-park idea of how many users can be supported on say a single server. Using this as a base "scale unit" you establish the costs associated with bandwidth and storage needs (relational and non-relational). Add in some factor to account for the transaction costs (I've used anywhere from 10-25%) and you have a rough cost needed to support nn users. Now its just a matter of multiplication to determine how many of those "scale units" you'll need to support a given load.

Now keep in mind, this does make some broad assumptions. The key one of which is that your application will scale out several times of magnitude without modification or an increase in resource needs.

What you'll also likely find going through this is that 90% of the time, on-premises hardware requirements are simply a guess. And that we need to start developing better ways to help profile the resource needs of our on-premises applications.

Thanks for the reply Brent.  There is no such thing as "on-premises" for us.  I am part of a start-up and we really are COMPLETELY CLUELESS when it comes to estimating this stuff.  Like I said, I have no idea where to start.

We have very basic web application at this point.  I just need some ball park estimates...

Answer 3

Your best (and likely only) bet would be to push it up into a single small instance and see what kind of load it can handle. If its a simple app, there's little risk of vendor lock-in. There's also the added bonus that this test will help you demonstrate the performance failure points for your app.

 

I am also going to be VERY straight-forward with you. Unless you're highly confident that your app will experience the types of demands that would call for massive/dynamic scalability, you may find it more cost affective early on to use a budget hosting provider. Then as demands ramps up, looking at using a more cloud oriented approach. If you don't need scalability, you're paying a premium for Azure that doesn't provide you any immediate benefit.

Answer 4

In my opinion it really depends about what resources (RAM, CPU and Storage) will be consumed for a single user of your web application, application deployment scenario and the forecast for your grow.

Azure charges for how you consume services compute time, storage and bandwidth. You can start with Pay-As-You-Go model to pay only for what you use to get some raw estimation. Later it could be cost effective to move to a subscription model.

There is a TCO and ROI calculator (http://www.microsoft.com/windowsazure/tco/) available which uses information about your company and the application. The tool can help you estimate the correct configuration and its costs, the costs of migrating an application to Windows Azure, and compare on-premises and Windows Azure application delivery costs. I suggest you to play a little bit and get some ball-park estimations.

Answer 5

Your best (and likely only) bet would be to push it up into a single small instance and see what kind of load it can handle. If its a simple app, there's little risk of vendor lock-in. There's also the added bonus that this test will help you demonstrate the performance failure points for your app.

 

I am also going to be VERY straight-forward with you. Unless you're highly confident that your app will experience the types of demands that would call for massive/dynamic scalability, you may find it more cost affective early on to use a budget hosting provider. Then as demands ramps up, looking at using a more cloud oriented approach. If you don't need scalability, you're paying a premium for Azure that doesn't provide you any immediate benefit.

Yes, we have it on a single small instance now.  I guess my question would be: How can I view our current usage statistics for the subscription we have?

As for your advice, thank you.  We did discuss this option.  For our situation, starting with Azure is something that makes sense (vague, I know).  We did not want to deal with the mad dash to switch to a cloud provider when our application usage begins to peak, opening the possibility to failures and poor user experience at the exact moment our application begins to gain momentum...

Answer 6

In my opinion it really depends about what resources (RAM, CPU and Storage) will be consumed for a single user of your web application, application deployment scenario and the forecast for your grow.

Azure charges for how you consume services compute time, storage and bandwidth. You can start with Pay-As-You-Go model to pay only for what you use to get some raw estimation. Later it could be cost effective to move to a subscription model.

There is a TCO and ROI calculator (http://www.microsoft.com/windowsazure/tco/) available which uses information about your company and the application. The tool can help you estimate the correct configuration and its costs, the costs of migrating an application to Windows Azure, and compare on-premises and Windows Azure application delivery costs. I suggest you to play a little bit and get some ball-park estimations.

The calculators are useless to me... I would love to use them but I have no idea on the metrics they are asking for.  I love your "Pay-As-You-Go" model suggestion, this is the best suggestion I have heard so far!  I need to look into this...  currently we have a subscription.

Answer 7

If you have a subscription you can view all usage statistics in the online bill. Login in Microsoft Online Services Customer Portal (https://mocp.microsoftonline.com) and click on "View my bills".

There you will find data transfer, sql azure, windows azure usage statistics. Hope they will help you.

 

Answer 8

I have the same question as diddy433.

Take a basic application with .Net; what is a reasonable way to filter the cost calculator? I know it is there to use but like diddy I dont know how to use it.

What is reasonable to fill in with 1000 users?

What is reasonable to fill in for 10000 users?

I am just looking for a monthly cost for basic forecasting.

Diddy433 did you ever figure out the answer to your question?