Menu
Note: if you are familiar with the Azure pricing model, just jump to the "question" section.
Microsoft will begin to charge for the use of the Azure platform starting February 1, 2010. The monthly bill will be a function of bandwidth, storage, and others. Among the factors used to calculate the bill is compute time. This latter factor, however, has a misleading name: it should be named instance hosting time instead. Quoting the windows azure pricing page:
When developing and testing your application, developers will want to remove the compute instances that are not being used to minimize compute hour billing
Thus making you think it's not compute hours, but uptime hours what you will be charged for. The doubt fades out completely after reading the official response to this question in MSDN forums:
I can confirm that each instance (of any role) counts, and all the hours you have the instance active count (regardless of how much "activity" they have). In the case of an application that has two web role instances and two worker role instances, you'll be billed for four instances
At $0.12/hour per instance, an app using N instances will be billed an average of 24*30*0.12*N/month = ~ $86/month per instance. The matter worsens for small websites when you take into account the fact that you can't have less than 2 instances if you want the 99.9% uptime service level agreement to apply.
So, a small, compute-power-inexpensive web site is probably not the target market for Azure. But for batch processes, the burden would probably go away.
Question
Speaking only in terms of compute-power and "compute hours" billing, Azure would be a good hosting option for a batch process that runs only a few hours a month, if and only if you can scale up (and down!) the number of instances easily. So:
Regarding the latter question: Take an extreme case where you have a very large number of instances (say, 1000) running for 45 minutes. If Azure isn't capable of taking notice of the scaling down within 15 minutes after after the process has ended, you will be charged for another 1000 compute-time hours.
889
At its most basic level, database scalability can be divided into two types: Vertical scaling, or scaling up or down, where you increase or decrease computing power or databases as needed—either by changing performance levels or by using elastic database pools to automatically adjust to your workload demands.
Vertical scaling is limited by the availability of larger hardware, which eventually reaches an upper limit. Hardware size availability varies in Azure by region. Vertical scaling may also require a restart of the virtual machine during the scaling process.
While horizontal scaling refers to adding additional nodes, vertical scaling describes adding more power to your current machines. For instance, if your server requires more processing power, vertical scaling would mean upgrading the CPUs. You can also vertically scale the memory, storage, or network speed.
Two main ways an application can scale include vertical scaling and horizontal scaling. Vertical scaling (scaling up) increases the capacity of a resource, for example, by using a larger virtual machine (VM) size. Horizontal scaling (scaling out) adds new instances of a resource, such as VMs or database replicas.
You are correct, you are paying for uptime hours, not compute hours.
One thing to be wary of is that you pay for partial hours without any proration, so if you rapidly scale up and down, you are eating full hours.
As other people have mentioned, you can programatically scale up and down from within your application. however, in general a particular role will only have access to its own metrics (unless you save the metrics into storage), plus any global resource metrics (queue length, etc) so doing scaling based on CPU utilization etc may be difficult.
Scaling up begins almost instantly with a machine taking a few minutes to spin up. There are no SLAs with spin-up offered currently. Microsoft has said that instances will come up at different times, so if you do a very large scale-up operation, it may be significant time before all instances are available; but some instances will be available almost immediately. You are not charged for an instance until it is fully spun-up.
Scaling down happens almost immediately, but you cannot control which instances are used for the scale-down, so if 50% of your instances are idle and you do a 50% scale-down, you may kill off all of your active instances, and that work would need to be restarted on the previously idle instances. You must make sure your design supports good restarting of work (if you use queue timeouts, this can happen mostly automatically)
There are a few 3rd party solutions starting to appear that aim to help out in scaling. One that I have looked at that looks promising is AzureWatch from http://paraleap.com/ which offers some things like automatic up/down scaling of web and worker roles based on utilization, queuelength, schedule etc.
170
A little warning, my comments below are not based on running production apps on Windows Azure; so far I have just fooled around with it and read docs.
Is it possible to programatically scale up and down the number of instances in Azure?
Yes, but AFAIK Azure doesn't scale up and down by itself, you'll have to do so via web service calls (much the same as using the UI to do it by hand). See this MSDN doc, the section "Hosted Services", and read on from there.
Something like the Hudson CI server can fairly easily be expanded to do basic work queue monitoring. Perhaps you need something more feature rich; there are quite many such systems from the whole "enterprise service bus" world.
Are there any non-obvious issues of scaling down the number of instances?
Hmn. You need to think about locking, i.e. how to ensure that each worker leaves the queue in a consistent state and completes its tasks before shutdown?
Additionally, from the Azure price list: "Partial compute hours are billed as full hours.".
How much time does Azure takes to "acknowledge" the scaling down of your application?
Honestly, I don't know, but assuming that your application has cleanly exited its work, I would assume it to be a couple of minutes at most. They instantiate new servers fast enough, and I'm guessing that starting new servers takes more time than shutting them down.
Try testing it. Make a cheap account, and start a few servers, shut them down, etc. Build a small prototype of your app (or use one of the Azure sample apps) and get a feel for it.
Another aspect is: What are your guarantees of being able to scale up whenever you want to? Currently, there is no such guarantee with any cloud computing vendor AFAIK; but Amazon has had a pretty good track record on this. Azure is a new offering, and we don't know how good Microsoft's capacity estimation is, i.e. we don't know how well they'll perform on this over the coming months. I expect this to be a non-problem; that Microsoft will handle this well -- but I have no evidence of this yet.
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
