What is Demand Elasticity, how does it affect my apps, why should I care, and how does Azure address this?

Demand Elasticity is an issue because almost no app has a constant demand over time: Some apps are used primarily during business hours and very little during the night; some apps have abnormally high demand during specific events, such as the launch of a new product or while NFL games are broadcasting; some businesses have peak seasons when they do nearly all their business (I once worked for an electronics retail store that earned over 80% of their revenue between Thanksgiving and New Years Day.)

Each of the above examples describes demand variability that you can plan for. An even more difficult problem is unexpected changes in demand. Imagine if a popular TV show recommends your online service. Demand would likely skyrocket. Could your services handle this extra, unexpected load?

Because of this change in demand, you need to decide how much hardware to deploy for your application. If you deploy too much hardware, you are wasting your money, but if you deploy too little, you will miss out on potential users and revenue. And in the fact that hardware is not easy or quick to deploy - It may take your organization weeks or months to respond to a sudden, unexpected increase in demand. And what do you do with that extra hardware when demand falls? For most organizations, it's not practical to buy and sell hardware as demand goes up and down.

Ideally, as demand increases and places higher load on your servers, you would increase the amount of hardware to which your application is deployed. Then, you would remove that hardware (and stop paying for it) as demand and workload decrease.  If you are managing and deploying the hardware yourself, this is not really practical. There is no quick market to buy and sell servers and most organizations take days – if not weeks – to provision a new server.

But Azure allows you to deploy more servers to your application and it automatically deploys them for you in a matter of minutes. Most services in Azure have a setting that allows you to change the number of running instances. This can be the number of web sites, web roles, mobile service, virtual machines, or dozens of other service instances available.

Below is the setting for configuring the number of instances of an Azure Web Site.

figure 1

Some services even allow you to automate this process. For example, you can configure Azure to monitor the CPU used by your web sites and automatically deploy a new instance of your site when CPU rises above a certain percent and remove an instance when it falls below a given percent. You can set a minimum and maximum to keep the number of instances within this range.

For Azure Web Sites, this Auto-scaling feature is available if we select the "Standard" hosting plan. Below are the controls that allows you to set these configuration.

Figure 2

Scaling up helps your service deal with extra usage (planned or unplanned), while scaling down helps you save money. The quicker you can do both, the more agile you will be.

Azure allows you the flexibility to scale up and down to meet changing demand.