One of the major benefits of using the cloud is scalability. With Azure autoscaling, you can scale up and out like you couldn’t do with your own hardware, as much as your wallet allows. But more importantly, you can scale down and in when you don’t need the resources, thereby saving money. This is something you wouldn’t be able to do if you bought a bunch of servers to accommodate your peak load.
Basically, there are two main ways to scale resources:
Scaling up and down speaks for itself, you scale the number and power of resources up and down. For instance, you provision a bigger server with more horsepower to scale up and a smaller, slower one to scale down.
Scaling out and in is different. When you scale out, you increase the number of hardware resources that the application runs on – you increase a number of instances. This could mean that instead of using 2 servers, you use 3. Scaling in is the opposite: you decrease the number of instances that your application runs on.
Out of the box, Azure App Services provides scaling abilities. You can scale both ways, up and out. There are many ways to scale, including third-party applications. I’ll only discuss the options that you have when you just use the capabilities within Azure.
You can scale up in two ways:
You can only scale up and down by scaling the App Service Plan. The App Service Plan basically represents the resources that your App Services use – the hardware that runs them. You can have many App Services running in one app service plan. So when you scale up or down, you will do that for all the Apps in the service plan.
Scaling up or down is a manual operation, even when you use the Azure Rest API. Out-of-the-box, there is no capability to scale up or down based on a schedule or a metric, like CPU usage. If you want to automate that, you’d have to build that yourself, using the Rest API, or look into third-party tooling. I think that the reason why this isn’t an out-of-the-box functionality is because it would scale all Apps in the app service plan and that Microsoft feels that this should be a well-thought-out action.
The image below shows how you can scale up or down in the Azure Portal. You choose a higher or lower pricing tier for the App Service Plan and apply it. In my experience, this is usually applied very quickly, in under a minute.
You can scale App Services out and in using the Azure Portal and the Azure Rest API. Scaling out will increase the number of instances of your App that are running. You can scale out and in with the following methods:
The simplest way of scaling instances is manually. You literally have a slider that lets you slide a number of instances up or down.
Another way is to scale on just CPU percentage. Using this, you can automatically scale up or down based on CPU Percentage.
A more controlled way to scale is to use scaling rules. These consist out of a schedule and optionally, rules.
A scale out or in action typically takes a couple of minutes to complete. Keep that in mind when you design your scaling strategy.
Cloud Services are one of the oldest services that Azure has to offer. They offer an abstraction over Virtual Machines, just like Azure App Services do, although cloud services are more tied to virtual machines.
With App Services, you can’t remote desktop into the underlying machine, because Azure really abstract the machine(s) away through its elastic magic. There could be multiple machines running your App Service instance. With Cloud Services, you specifically run your service on one or more virtual machines of a certain type. You can even remote desktop into the machines if you want to.
Cloud services were the beginning of Azures’ Platform-as-a-Service offering and were pretty revolutionary at the time. They do have lots of drawbacks. Amongst other things, they are extremely slow to deploy to. This is because of their tight relationship with virtual machines. The same goes for scaling. When you scale up, you literally provision another virtual machine to run the services – that takes time.
You can scale a cloud service up by changing the deployment configuration of the service. You can also change this configuration through the Azure Rest API.
In the file called ServiceDefinition.csdef, you indicate how large or small the instances need to be:
<WebRole name=”WebRole1″ vmsize=”Small”>
This is a very clunky way to scale up, but nevertheless, it’s possible.
You can scale out or in by changing the deployment configuration of the service, just like scaling out.
In the file called ServiceConfiguration.environmentname.cscfg, you indicate how many instances you want:
<Role name=”WebRole1″>
<Instances count=”1″ />
Just like App Services, you can also scale out or in from the Azure Portal. You can also use the Azure Rest API to do this. You have almost the exact same capabilities as for App Services:
Remember that scaling cloud services is a slow process, as it has to literally provision and de-provision virtual machines. Therefore, adding an instance can easily take 5 minutes or more.
Azure provides the ability to scale for most of its services, not only App Services and Cloud Services. This is extremely useful for the availability, performance, and cost of your application. This is what makes the cloud a great tool to work with. You can scale to unimaginable amounts of resources and you can scale back when you don’t need them anymore.
The trick is to create a good scaling strategy. Out of the box, Azure can help you with your basic requirements and scale out when needed and in when you don’t. You will minimize downtime and keep customers happy.
But you need to figure out what fits best for your application. Which metrics you use, or which schedule is best. And what the right performance to cost ratio is. You can only find this out by trying it and extensively monitor the behavior of your app with something like Stackify Retrace to find out what works and what doesn’t.
Not sure if you should use App Services or Cloud Services? Check out our comparison:
Comparison: Azure App Services vs Cloud Services
Take advantage of the cloud and scale! Let me know what you think in the comments.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
