Setting up your application for scaling in cloud is like driving a Red Ferrari. You have to learn to pump and break appropriately. Pump too much — you could end up in your neighbors drive way. Break too soon — you could bang your head into steering wheel.
You don’t want to ruin your exotic purchase.
You want to ride around town in style.
You want to enjoy those smooth cornering.
You want to showoff your prized belonging.
Similarly, understanding when to scale in Azure is a bit overwhelming. You have to familiarize yourself with which lever to pull and when. The first time it may all look like an airplane cockpit. Too many control switches.
Why is it important?
Isn’t it something you just setup after project is deployed? No.
It is very important to optimize your scaling initiatives to address business needs and technical difficulties. Scale too less — you could end up with slow websites, and less happy customers. Scale too much — you could be costing your IT departments significant budgets.
By matching up your company business needs, and architecting your web applications you can optimize costs, and maximize benefits of scaling.
When is the right time to consider scaling?
To profit from scaling we have to start early.
Scaling needs to be in consideration right from designing, and in coding as well. To maximize the benefits of cloud infrastructure we have to explore all the possibilities.
Types of scaling:
Below are the 3 major ways to get started with scaling.
- Scaling in Design.
- Scaling in Code.
- Scaling in Infrastructure.
Scaling in Design:
To be able to add more fire power you have to design a suitable Stateless system. Stateless applications enables us to create as many instances of code as possible. Code running in any of the instance will not be dependent on another instance – hence independently scalable.
For example by moving cache data into separate server or better into RedisCache, we can scale independently. We do not to have to manage cache checks across all instances this way.
Scaling in Code:
C# Multi-threading and Asynchronous programming allows us to write code that can do resource intensive tasks in parallel.
Asynchronous programming allows you to scale right from the very fabric of software — code.
Instead of the wasting money on more and more instances we can have the same benefits squeezed out of parallel programming. Companies may pay programmers ahead by doing so, however it will pay itself in long term.
For example, in Azure webjobs you can setup BatchSize upto 32 messages to process in parallel. This is ideal in workflows where a single request has to be run down to several dependencies before reaching a completion. No need to accommodate multiple servers.
Scaling in Infrastructure:
Scaling as we all know is the ability to be flexible in infrastructure when deploying and running our code. Below are the various mechanisms to accomplish scaling in Azure.
Types of Infrastructure scaling:
- Vertical: Vertical or scaling up/down is all about adding more CPU and RAM resources to support increasing load. However, it is expensive to re-deploy and add more fire power to a single server.
- Horizontal: Horizontal or scaling in/out is about adding more servers instead of making one single powerful server. This has a significant cost benefit, and may be ideal for distributed computing. However, multiple servers means more configuration and deployment overheads.
Configuring Infrastructure scaling:
Means setting pre-defined monitoring and watch parameters. These diagnostic services are in-built in the Azure services and can be used to automatically heal surges. Once the demand goes down, resources are automatically decommissioned.
Some e-commerce companies have high volumes during weekends or evenings. You can utilize schedule based scaling to address such high volumes.
Metrics based: based:
Used to accommodate unforeseen demand in peaks. Say you have lots of customers logging into your website all of a sudden because of a regulatory change. You can setup to automatically instantiate new VM, based on the number of requests. More the requests, more the VM you cook up.
Autoscaling may not be ideal for all the scenarios. Azure monitoring services are reactive — meaning there could some wasted time before the diagnostics services start instantiating.
You can tailor scaling parameters based on business workflow instead of technical.
Say your e-commerce website is receiving high orders – you can programmatically detect such surges and increase VM for fulfillment. Azure SDK allows you to configure scaling parameters from code.
Ideal for use cases when it is difficult to gauge technically, or by business workflow. Also the quickest and easiest way to scale applications. You login into azure portal, and slide up the parameters yourself. You could set an expiration time when the instances will be scaled down.