Azure platform: scaling instances up and down

6
votes

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:

  • Is it possible to programatically scale up and down the number of instances in Azure? Are any other options besides manually changing the configuration file?
  • Are there any non-obvious issues of scaling down the number of instances?
  • How much time does Azure takes to "acknowledge" the scaling down of your application?

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.

4
batch-fileazurecloudmultiple-instances
Small note: "Scaling up" and "down" are usually used for adding resources to a single node. In this case I think you mean "scaling in" and "out" which is adding more nodes to a system. - You can script the updating of a config file to a new number of instances with csmanage (code.msdn.microsoft.com/windowsazuresamples). You would still have to kick of that script locally (not in azure). You might want to check this out: Automating the App Lifecycle (microsoftpdc.com/Sessions/SVC25) – Jason Haley
I made a similar question a few minutes ago in MSDN Azure Forum: social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/… P.S.: Thanks Jason! I'll visit the links (and will definitely review my language! :) – Pablo Marambio

4 Answers

4
votes

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.

3
votes

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.

3
votes

As of June 26, 2013, Windows Azure includes the autoscaling capabilities baked into the platform. For now just in preview and with only 2 metrics supported (CPU utilization and queue length), it is very intuitive and easy to enable. Check it out.

2
votes

Yes, now with the newly released Autoscaling Application Block, programatic scaling up and down of the number of instances in Azure is easier then ever.

See my detailed answer on this thread.