Welcome to this lesson on Virtual Machine Scale Sets (VMSS).

VMSS let you create and manage a group of VM instances, either identical or mixed.

One of the key benefits for me of cloud computing is the ability to dynamically acquire more resources when we need them and get rid of them when we don't.

Think about it. It's not hard to do. Keep an eye on a metric or metrics indicating how much pressure the system is under, and, if that metric goes above a certain threshold for a certain amount of time, spin up more resources with an API call.

And then when it drops below another threshold, tear them down again.

And because it's so easy to do, Azure's already done it for us.

So, that's the first benefit of VMSS: Autoscaling automatically adjust the number of VM instances based on metrics like CPU usage, memory, or custom rules.

Another benefit is high availability. VMSS distributes VMs across fault domains and availability zones to improve resiliency.

And we get a consistent configuration. All VMs are created from the same base image and configuration. I've talked about rip and replace a lot. If a VM is misbehaving, don't SSH into it and fix the problem, just terminate it and VMSS will replace it for us with that same configuration.

Now, obviously, if the problem is with the configuration in the first place, this isn't going to work, but I hope you see the point.

We don't pay any extra for using VMSS, that's basically free, but we do, of course, pay for the VMs it creates.

And we talk about autoscaling in a cost management course because by shutting down unnecessary resources when we don't need them, we can save money.

Now, if we have more than one of something, an application server for example, we're going to need to distribute the traffic evenly around all those things. So, VMSS integrates with Azure Load Balancer, layer 4, the network layer, and application gateway, layer 7, the application layer, for traffic distribution.

I mentioned earlier that we could have mixed or identical groups of servers. Let me explain.

There are two orchestration modes, uniform and flexible. I feel it might be better to call them legacy and sensible, or, to use that hackneyed expression, classic and modern.

Remember, in IT the word classic generally means rubbish.

I'm kidding, it's fine.

Uniform mode uses scale set-specific APIs which provide limited control over VMs whereas Flexible uses the standard Azure VM APIs.

Uniform only supports up to 100 VMs whereas Flexible supports up to 1000.

Clearly, the biggest difference between the two is that in Uniform mode all the VMs have to be identical, while Flexible supports a mixture of sizes, operating systems, and spot or pay-as-you-go instances.

So, why use Uniform mode at all?

Well, it's more straightforward and simpler to set up than Flex mode, and for most use cases it's fine, but, if we want to maximise our chances of getting VMs when we need them, then asking for a variety, up to five, of different sizes means we're more likely to get something when we need it.

And if our workload supports it, we can ask for spot instances in the mix too, if we're using Flexible mode.

The mix of operating systems is a bit of a red herring for me. I can only ever have one scaling metric for all the machines in the set.

So, while it sounds like I could have a bunch of Windows application servers and a bunch of Linux-based database servers in the same group, the reality is that scaling will break downat that point. I'd be better off having two different scale sets.

I have one more point to make about VMSS: sizes. Let's say we're running D4s in a scale set with four CPUs each, and each one can handle 500 users. I made that number up. And we're currently running 2.

So, that's 1,000 users at about $0.40 per hour. The system comes under pressure because another 200 users have started using it. So, our scale set spins up another D4 to handle it. We're over-provisioned. We've got 1,200 users, but we've got capacity for 1,500 and we're paying around $0.60.

If we were using D2s instead, and we originally had four of them, the cost was the same because a D4 costs exactly twice as much as a D2. But when our scale set spins up another VM, we've got room for 1,250 users, and we're saving half the cost of that extra D4 VM.

We're better off using more smaller VMs than fewer larger VMs, if our workload can handle that.

If we're doing heavy-duty number crunching that can't be parallelized, then we'll probably be better off with the larger VMs.

VMSS will only save us money if we use them wisely.

See other lessons for help on right-sizing VMs.

Virtual Machine Scale Sets (VMSS)

About