Are you planning to lift and shift VMs into Cloud? Or have you done migration and now looking for a way how to scale them automatically?
Well, this article can be right for you!
When it comes to lifting and shifting the application and/or services hosted on the Virtual Machines (VM) from an on-premise environment to the Cloud, building a strategy and design of how to achieve some sort of automatization in VM scaling can be a challenging task.
In general, some type of scalability can be achieved with Virtual Machines as they are but it’s going to be very inopportune.
That’s why it is very important to work on cloud-based infrastructure design prior to the lifting-and-shifting process itself. And remember, VM scaling needs to happen automatically.
The approach I like to teach others is to automate everything that follows repetitive cycles.
But hang on, what if I scale up horizontally in Cloud by adding extra HW resources (RAM, CPU) to logical machine computing power hosting my VM? .. Yes, this may work but with some scripting to be done first and that is less likely going to be repetitive with the same set of input properties…
But what if full scaling automatization can be accomplished with a higher running cost efficiency and as little configuration work as possible?
Yes, that is all possible these days and I am going to share how to use one of the options from the market.
The options I liked to pursue one project of mine is coming from Microsoft Azure Resources stash.
Why is that?
It’s not a secret that I’ve worked with Azure since the early saga beginning. Therefore, I have built a long experience with the Azure platform. On the other hand, I have to admit that Azure Software Engineers have done a great job on building platform APIs and Web Wide UX/UI interface (Azure Portal) to make this process seamless and as easy to use as possible. More on my driving decision factors later …
Let’s get started
The Azure resources I have been mentioning here in the prologue are:
- Virtual Machine Scale Set (VMSS)
- Azure Compute Gallery (Azure Image Gallery)
My reasons of choosing Azure
Every project has different needs and challenges coming from the business domain requirements. More importantly, rational justification on the economical side of the project complexity is mostly the driver of the project technological path in the design stage.
For this project, I was lucky because the customer I designed this solution for had part of the business applications and services in Azure already. Also, customer big ambitious plans to migrate everything else from an on-premise data centre to the Cloud in the near time horizon just made my decision more sealed and therefore Cloud in Azure was the way to go.
Let’s get a better understanding of the designed system infrastructure from the simplified infrastructure diagram below.
Take it with a grain of salt as the main purpose of it is to highlight the main components used in the project and discuss these in this post.
What I like most about the selected Azure stack
- VM redundacy accross multiple data centers globally
- has an ability to multiply VM instances as needed with an option to resize the instance computing power when needed (RAM, CPU, etc. => vertical scaling)
- high service availability and resilience (subject to infrastructure desing – in my case, I provissioned total of two VMSSs, one geographically different data center each)
- I like the flexibility of building my rules in VMSS on which system decides whether VM instances go up or down on quantity
- Azure traffic ballancer can be linked to VMSS easily
- the VMSS service can provision up to 600 VM instances (and that is a lot!)
- the Azure Compute Gallery (ACG) service is able repliate image globaly, supports image versioning and auto deployment of the latest model to VM running instance (and that was a hot feature for me)
Steps to provision services in Azure
In nutshell, follow these steps to provision Azure services and build the cloud infrastructure from the ground up:
- Lift and shift the VM into Azure (I can recommend to use Azure Migrate service to start this process)
- Create a new Azure resource: Azure Compute Gallery
- Go to running instance of VM and capture and generalize the image of the migrated VM
- Create two replicated images (for one datacentre each)
- Save the image into Azure Compute Gallery created in step 2
- Create two new Azure resources: Virtual Machine Scale Set (in geographically different data centers as per settings in ‘Target regions’ in step 4 for Scaleset redundacy capabilities)
- Create scale out/in rules in VMSS
Scale out/in VMSS rules example
The screenshot image below shows the example of setting up the Scaling rules for one of the VMSS instances.
As you can see in my default profile in the picture above, this VMSS instance is not running any VM instances by default (Minimum = 0). But rather, spins up some (scaling out) based on these criteria:
- The main VMSS instance hosted in datacenter A increases on average CPU (or)
- The load balancer availability drops below 70% in given timeframe
Very similar rules are used in the reverse process, aka scaling in.
If you’re planning to use a similar concept in your solution, count with a VM operation system booting time in your metrics if high VM hosted service availability and responsiveness is important to meet.
Microsoft Azure recently introduces a new feature called Predictive autoscale with Pre-launch setup (at the time of writing this article in preview only) which should solve a VM boot time issue for most of the use case scenarios. It works based on cyclical workload patterns determined by machine learning and predict scaling out need action in advance.
I like to say, using Machine learning capabilities in this sort of behaviour analysis is a very smart move from Microsoft forward.
I think VMSS has a lot to offer to businesses starting their journey to the Cloud.
The process of setting the infrastructure up is not complicated and can be done over UI/UX design in the Azure portal in no time. The VMSS scaling rules offer a lot of options to choose from and the level of integration with other types of Azure resources is on a very mature level, too.
Hope you enjoyed this reading and leave me some comments below 🙂