Answered Processor time billing

  • Tuesday, March 06, 2012 1:38 AM
     
     

    My boss asked me to study azure cause we are heavly considering moving our inhouse apps and public sites... he asked to focus on billing and scaling...

    i have a few scenarios that i cant predict the outcome by myself:

    1. If my app does nothing in a day... just sits there... nothing is done... no requests... no responses... nothing... what will be the bill on the end of the day?
    2. If i have a enviroment, lets say a "medium", and im all time running 2 threads... will i be billed extra? what if i only use 1 thread? will i get a discount?
    3. What happens when my app "consumes" all the resources in the current VM???
    4. Can my "farm" auto-grow? if so... can it auto-shrink too?
    5. How does queries in SQL are billed? regular compute time?
    6. My app needs ALOT more processor than memory like a 100x1 scale... what will i do? i dont want to pay 1 gazillion dollars for memory i wont use...
    7. Reverse! my app need alot more MEMORY than compute...
    8. Anonymous is DDoSing me! will azure detect it and will i be billed?

    Thats it for now! Im really excited to start working in this enviroment!

All Replies

  • Tuesday, March 06, 2012 2:30 AM
     
     Answered

    Single simple answer to multiple questions: Azure does not do processor-time billing.  Azure does VM-time billing similar to how Amazon AWS bills.  It is more "infrastructure" like in this regard.  You decide how many VM's you want to rent and what their sizes are (there are 5 sizes available: Xtra-SMall, SMall, Medium, Large, Extra-Large, although only the latter four are good enough for production environment).  

    Azure bills you per VM per hour.  Regardless of how busy that VM is.  Azure also bills for the amount of data coming out of the data center and for the space you consume OUTSIDE of VM's like in SQL Azure or Azure Storage.

    Azure does not auto-adjust quantity of your VM's or SQL Azure databases automatically in anyway.  You're in full control.  You can program the auto-adjustment (autoscaling) yourself - there are a few examples on the web, including the WASABi application block.  Or you can take the easy way out and use a service like AzureWatch (link in signature).

    Thus, your answers are:

    1.  It doesn't matter that your app doesn't do anything.  You will be billed for the amount of VM's running per hour.  So, in times when your app is not doing anything, scale down to 1 or 2 VMs (depends on your SLA requirements).

    2.  You can run as many threads on your VM's as your VM's can handle.  You're not billed for threads.

    3.  Your app slows down and you should consider scaling out to more VM's. 

    4.  Yes but only if you build it yourself or use something like AzureWatch

    5.  SQL Azure is not billed by queries.  Only amount of space consumed.  Data transferred outside of the Azure data center boundaries (regardless of it was originating in your VM's, or SQL Azure, or Azure storage, etc) also has a fee per gigabyte

    6.  You're not paying for memory separately than for CPU.  You're paying for a VM per hour.  Up to you to decide what size is optimal for the amount of ram/cpu/cost that you get.  Only 4 real choices available.

    7.  Ditto.

    8.  Azure has a number of DDOS preventative measures at the data center and load-balancer level.  If there is some DDOS attack that does get through you will unlikely be charged alot unless you start scaling up out of control and don't notice it for weeks.  Since most of the requests are inbound during a DDOS attack, you're not charged for them, only for data responses that they generate.  I've had this discussion with a few folks on a LinkedIn group who were afraid of letting automating systems like AzureWatch scale them out of control during a DDOS attack.  Because it sounds "scary".  But reality is too boring.  During a DDOS attack, you will likely be scaling up up no more often than once per15 minutes.  Thus, even if you chose to not set any safety limits to scaling up in a service like AzureWatch, and you raise your Azure quota to 200 cores (by default it is 20 cores), you would have to ignore scale-up alerts for 24hours to ring up a mighty bill of $5.76 (assuming you scale up by a single core once per 15mins for 24hrs).  Your business impact of the DDOS will be much greater than Azure charges.

    Hope this helps.


    Auto-scaling & monitoring service for Windows Azure applications at http://www.paraleap.com


  • Tuesday, March 06, 2012 12:30 PM
     
     

    tks for the answer!

    only one thing did not made itself clear to me yet: in item 6 you said that i am paying for VM and that i only have 4 choices (ok so far)... but in 8 how can i have 200 cores??? will i have like 100 medium VM's???

    this is quite important for us because we have a physics simulation application that consumes alot of processors (currently optmized for 400 gpus)...

  • Tuesday, March 06, 2012 1:31 PM
     
     Answered

    Sorry, I didn't elaborate.

    The point of Azure and most other cloud platforms is that they let you scale out by having more than one VM do the same job.  You write your code in a way that distributes the load across all of your machines and in a way that the more machines you have, the more processing you can perform. The goal is to be linearly scaleable. IE: if you had 1 VM you could process X per hour.  If you had 2 machines, you could process 2X per hour, etc. 

    So, you want to divide your processing across multiple machines, so that you can run 10 or 100 Medium instances (if medium is the optimal size) and you can do your processing 10x or 100x faster.


    Auto-scaling & monitoring service for Windows Azure applications at http://www.paraleap.com

  • Tuesday, March 06, 2012 2:31 PM
     
     
    Thank you! i must confess im a bit frustated with this behavior... its a game-over situation... i was really excited about porting the app to the cloud... i was hoping for a more flexible platform where the VM would grow, not the number of VMs...
  • Tuesday, March 06, 2012 6:55 PM
     
     Answered
    Thank you! i must confess im a bit frustated with this behavior... its a game-over situation... i was really excited about porting the app to the cloud... i was hoping for a more flexible platform where the VM would grow, not the number of VMs...

    Hi,

    Cloud platforms are based on scale out and not scale up. If your "very big" VM fails what happens? Service unavailable? 


    If you found this post useful, Please "Mark as Answer" or "Vote as Helpful". Best Regards.