Welcome to the first post in our new series comparing managing Azure Virtual Desktop (AVD) with the native Microsoft components through the Azure portal and managing AVD with Nerdio. Here we are comparing Nerdio vs native AVD auto-scaling.
This is intended to be a high-level comparison suitable for audiences with any level of technical acumen. For a technical overview of the differences between native Azure and Nerdio Auto-scaling, please download our Comparison Chart linked below.
What Is Auto-Scaling?
Auto-scaling allows IT teams to turn on/off virtual machines (VMs), and in Nerdio’s case, storage options as well, based off things like usage, demand, or time of day. Nerdio also can build, delete, and scale resources using intelligent automation.
Auto-scaling can be thought of as similar to managing your home’s heating bill. You could pay 24/7 to heat your home during the winter. But if you are gone most weekends at your cabin and have a week-long vacation planned, why should you pay to heat the home when no one (or pets) are in it? Instead, you can set your heating system to run at the minimum temperature so pipes don’t freeze when you’re not there but time it to rise to a comfortable temperature when you will be home.
Microsoft Auto-Scaling for Azure Virtual Desktop
Microsoft has auto-scaling features that allow customers to apply some basic scaling logic. It allows VMs to be turned off at specified times of the day.
While it is never a bad thing to introduce additional auto-scaling natively in AVD, there are several limitations that exist.
All Users Are Not Equal
Microsoft’s native auto-scaling in AVD assumes that all users are equal. For example, if you set eight users as the threshold across all your machines, it would only turn on the next VM if eight users were connected to it, with no understanding of how much of the machine’s resources were being used.
In reality, we know not all users are equal. So, in this scenario, you’d end up with some machines that are under utilised. More importantly though, you’d get scenarios where a group of eight “heavy resource” users were all on the same VM requiring more compute than the machine can provide. The result… user experience would be through the floor, there would be an influx of service desk tickets, and some unhappy employees and probably end customers too.
Additionally, another thing to point out with inconsistent usage is end users’ login patterns and durations. There are lots of different work styles so simply powering machines on at 7am, planning for peak usage of machines at 9am, and then having machines powered down at 6pm doesn’t align with actual usage. It again assumes all users are equal. This disconnect between actual usage and assumed usage often leads to increased spending on unnecessary reserved compute.
Azure Storage Isn’t Optimized
The second important concept that the new features do not address is the fact that usage is rarely consistent across a week/month/year. With the new Microsoft scaling plans, you need to specify the number of machines you’d like built, the scaling will just power on and power off these VMs.
The issue with that? You’re still paying for the storage whilst VMs are powered off. So, to have capacity for the inevitable usage peaks within a month, you’re likely paying for the storage for all 30 days for a machine that is maybe used only 1-2 days.
Demand Is Not Constant
Microsoft’s scaling plans can only power manage resources, they cannot build additional machines (hosts) if you see an increase in demand. If you were to see a spike in usage during a busy period in a month, the demand will not be met, and the users unable to login. The same goes for a disaster recovery (DR) situation.
Perhaps the office needed to be closed for a day or there was a rail strike which meant more users needed to connect to AVD to grant remote access. You still pay for the storage disks when machines are powered off, so organisations don’t want this capacity to be sitting there ready in case of a scenario where this capacity was required.
Nerdio Auto-Scaling
Nerdio’s auto-scaling technology is built directly into Nerdio Manager. Once you have deployed the platform, you do not need to deploy anything else. Nerdio auto-scaling technology has far more features than the Microsoft native auto-scaling capabilities and saves much more money and time due to its advanced and customizable features.
Nerdio Multi-trigger Auto-scaling
Nerdio provides multi-trigger auto-scaling technology so that the scaling technology will not only look at the number of users but also the resource utilisation on a VM before deciding where to allocate users.
So, in the scenario of the heavy resource users being on a machine, Nerdio would attempt to get eight users onto the machine BUT if the allotted compute was used up by the first five (for example), it would push the next users to a new machine. The outcomes equal well-utilised machines, cost-efficient compute, and a good experience for users.
Nerdio Burst Capacity VM Provisioning
Nerdio also gives organizations the ability to not only power on and power off VMs but to also create additional VMs to provide this burst capacity for those peak periods. This is all done dynamically without any manual input. This ensures resources are always there so employees have excellent work experiences and can get their work done. And equally as important, it ensures the company isn’t paying for resources that aren’t being utilised.
Nerdio Auto-scaling for Azure Virtual Desktop Storage
Lastly, Nerdio not only auto-scales VMs and Azure compute, but also can automatically auto-scale storage to help companies compound their cost savings even further. One example is that we automatically swap out the OS disk type to a lower SKU (the admin specifies) to save on costs when VMs are stopped. By doing this, companies ensure they aren’t paying for Premium SSD storage when they aren’t actively using it.
If interested in reading more about Nerdio’s auto-scaling technology, I highly recommend you take a look at, ‘6 Cost Reduction Strategies for Azure Virtual Desktop’, written by our CEO and co-founder Vadim Vladimirskiy.