One of the big difference between on premise and public cloud is the fact that a public cloud is a multi-tenant environment backed by SLAs. That sounds trivial right?
But think about it for a minute. In order to implement an SLA, you need to enforce limits & quotas. It’s the good old “you can’t rob Peter to pay John”. In terms of cloud resources, it could be: “you can’t let Peter’s VM consume all the bandwidth and still guarantees John’s VM to have a given bandwidth”.
On premise, you’ll do things like overprovision CPUs & RAM because you know they aren’t going to all use it at the same time. Because you don’t know: each VM belongs to a different tenant and tenant A doesn’t want to see the lights dim because tenant B is having a party.
So… in order to have SLAs, you need to impose limits & quotas.
In Azure, they are well documented at http://aka.ms/azurelimits.
Now there are two types of limits: hard ones & soft ones. Hard ones you can’t change. Soft ones you can request Microsoft to change the limit for your subscription.
Hard ones typically comes from a limitation in the architecture. Those often are scaling units. For instance, you have a maximum of 500 TB per storage account. This is a hard limit. This is just the way the storage service is architected.
Soft ones are there for multiple reasons. The main ones:
- Protect you from provisioning too many resources and collecting a huge bill at the end of the month
- Controlling the provisioning in each Azure region
So for instance, by default you can only create 5 DocumentDB accounts in one subscription. If you want more than that, just contact Azure support and they’ll raise it for you.
Now when you do architect a solution in Microsoft Azure you do need to be cognizant of those limits. Easy, just consult http://aka.ms/azurelimits.
If you don’t, you’ll have surprises.
A classic is putting all your VHDs in the same storage account. One VM, two VM, cool. 50 VMs? Hum… a storage account has IO limits: 20 000 IOPS. So when you plan your VMs, plan the target IOPS and shard the VHDs into different storage accounts accordingly.
This goes for every single service in Azure. Most of those limits typically do not influence pricing, so beside a few ones, I tend to work this level of details once a project passes off the first gates where pricing is most important.
Limits to consider in pricing? Performance. You want more IOPS on a machine, you want less latency? Consider Premium storage disks. As its name suggest, the premium storage isn’t the same price as standard storage.
So consider those when you start a project.