Summary
When I see IT professionals working in Public Clouds, I often encounter knowledge and habits that have shifted from valuable to less so due to the different economics in public clouds.
Let's discuss how rethinking old habits gives your company an edge in this new hosting landscape.
The "Pay What You Use" Myth
For many years, the cloud was—and often still is—advertised as a "pay what you use" charging model.
When I first heard this, I thought it meant I'd only pay for the time I actually put a load on a server or the data I had sitting on a disk.
You may already know that's not how the cloud actually bills for its services. With most services, you're not charged for the seconds a CPU is utilised but for having "booked" the CPU in the first place.
Booking, I've learned, is an excellent way to think about cloud resources. Many of the resources a public cloud offers work like a hotel: bigger rooms cost more than smaller ones, and the hotel doesn't care if you sleep in your bed, on the floor, or not at all—you still have to pay for it. And if you forget to check out, you might get an unpleasant surprise when the bill arrives.
This charging model radically differs from on-prem, rented data centre space, or colocation hosting. In those setups, you had a distinct cost spike whenever hardware was renewed, but you basically only paid for maintenance and electricity between these renewals. As hardware was purchased with future growth in mind, the cost of a new virtual machine was its setup time rather than the daily recurring line item on a public cloud bill.
Let's compare the hypothetical costs of a forgotten sandbox VM that was supposed to run for a single month after 36 months on-prem and in the public cloud:
On-premises | Public Cloud | |
|---|---|---|
Setup Costs | 1 | 1 |
Patching Costs | 2 | 2 |
Running Costs | 0 | 36 |
On-prem, all it needs is a bit of extra electricity. In the public cloud, every additional day a resource runs adds another full day at its full rate to your bill.
Habits for Avoiding It
When setting up temporary resources or capacity in the public cloud or temporarily increasing a resource's size, set yourself a reminder to retire or resize the system. It can be a tag on the resource that your ops team acts on, a reminder in Outlook or a sticky note on your screen—as long as it stops you from forgetting the cleanup.
Takeaway
The public cloud's business model is "pay what you book". Cloud providers are happy to charge you the same for oversized, idle, or zombie resources as for a well-sized system. Powering down and right-sizing excess capacity when it's no longer needed helps prevent a cloud hosting "bill that could kill" your IT budget.
The Cloud Alphabet Soup
Have you ever struggled with picking a model for a Virtual Machine or a platform service like a Web Service? I keep training folks on what I lovingly call the "Cloud Alphabet Soup", and the unanimous sentiment is that this is more confusing than buying chips or ketchup in a supermarket.
What doesn't help is that public clouds seem to guide your choice by what they show first in their pricing calculators. From outdated VM Series to cheaper deployment locations (when these, by far, are not the most affordable options in that geography), the opportunities to mess up are plenty.
One would hope that, at least in their portals, the recommendations would be a bit better. I can only speak for Azure—where the "most frequently used" Virtual Machines or App Service Plans shown during resource creation are outdated models.
How This Introduces Tech Debt
Until Version 3 in Azure, Virtual Machines had temporary storage, giving you a drive for your page file or swap space. Starting with Version 4, Azure gives you a choice of VMs with and without temporary storage. VMs with temporary storage are, on average, 15% more expensive. Also, there's no direct upgrade path from a VM with temporary storage to one without.
But Why Would You Want to Upgrade in the First Place?
While a Virtual Machine with 16 vCPUs and 64 GB RAM looks the same as any other with those specs, there are two strong reasons you should consider upgrading to the latest version:
Savings Plan rebates on older models, at least on Azure, are significantly lower than for current models: you end up paying more for the same number of vCPUs and GB RAM.
Based on Passmark measurements I repeatedly did on Azure and AWS, the main series versions 3+4 (Azure) and 4+5 (AWS) are significantly slower than the latest version (5 in Azure, 6 in AWS).
We have observed the same for App Service Plans in Azure: their latest version (Premium V3) has a better performance-to-cost relationship than its predecessor. Premium V3 is also the first App Service Plan that can be reserved and savings planned.
Fortunately, upgrading from V2 to V3 is straightforward in most cases.
Picking Guide
Stick to these three rules when selecting public cloud SKUs, and you'll have fewer headaches:
Always pick the latest version available for a given resource.
Choose Virtual Machines that come without temporary storage unless you have a well-defined use for it.
Start small. The cloud has near-unlimited capacity; you can always scale up later.
Let's talk
Do you share these experiences? Do you see things differently? Do you have a question? Leave a message.
I am looking forward to discussing it with you!