Today's talk will give you an idea of the cloud pricing model, using Microsoft Azure for examples.
We will get an idea of how much services may cost, look at ways to save money in the cloud, try it out on a couple reference architectures, and review budgeting and cost alerting options in Azuref.
This talk is a companion talk to Getting Stuck in the Cloud (https://csmore.info/on/thecloud), where I provide an introduction to cloud terminology and offerings.
This talk assumes you are familiar with key cloud concepts like IaaS/PaaS/SaaS and have some idea of the Azure ecosystem.
Cloud providers generally use a pay-for-use model with monthly billing.
With the move from rented virtual machines (IaaS) to platform services (PaaS) to serverless/functional applications, this is looking more and more like mainframe pricing during the 1970s and 1980s.
The pay-for-use model is an Operating Expenditures (OpEx) billing model.
On-premises hosting is typically financed via Capital Expenditures (CapEx).
|Intent||Buying a fixed asset||Daily operating expenses|
|Longevity||Measured in years (at least 1 tax year)||"Day-to-day" expenses (in 1 tax year)|
|Depreciation / Amortization||Draw down X% of the total cost each year of "useful life"||No amortization allowed|
|Budgeting||Typically requires negotiation and long-term planning||Easier for single decision-maker to budget|
|EBIDTA||No negative impact||May have negative impact|
CapEx tends to be harder to push through, and can be a risk if the hardware you purchase becomes insufficient for the job before its depreciation period (typically 5 years) expires. CapEx is more "fixed expenditure" but gets removed when calculating EBIDTA (and C-levels like that!).
OpEx is easier for a single business decision-maker (like a CIO) to approve and spending is much more flexible. It does count against EBIDTA, however.
With cloud providers, almost everything has a price.
That said, some services are free or have free tiers.
Azure has a fully-featured pricing calculator.
1) Complexity with the Pricing Calculator
One common complaint about cloud pricing calculators (not just Azure's!) is the complexity.
Another is that pricing terminology changes between services.
If you are new to Azure or to a particular Azure service, you will likely underestimate the actual cost.
2) Tiers, SKUs, and More
Each offering in Azure tends to have multiple tiers. The terms "Basic," "Standard," and "Premium" give you an idea of relative quality, but what they provide can differ drastically between services.
For an example of the extreme, there's Azure SQL Database...
3) Cross-product Variants
Do you want a Spark cluster? Take your choice:
The Azure Pricing Calculator is available at https://azure.microsoft.com/en-us/pricing/calculator/.
Although it can be confusing, it will be your best bet to understand how much a service will cost you.
Note that licensing for things such as the Power Platform (Power Apps, Power Automate, Power BI, etc.) is outside the scope of the pricing calculator. You will need to track that separately.
Also, for items which are in public or private preview, there is no calculator information, even if the service itself has pricing details laid out.
Given its complexity, the calculator works best when you have a good idea of your service requirements, including CPU, memory, and disk requirements. This is quite different from "What I have on my on-premises server"!
Migration assistants can help you get some of that understanding.
The Data Migration Assistant allows you to check compatibility issues which might impact database functionality when moving to a new version of SQL Server or to Azure SQL Database.
This isn't necessarily a cost-savings tool, but will give you an idea of what you might need to change before migrating.
The Azure Migrate tool provides a variety of assessments for services, such as Azure SQL Database, VMs, App Services, and more. These figure out your existing resource requirements based on workload and provide you recommendations on tiers and performance levels.
This helps you come in at a reasonable price without experiencing massive performance problems or unnecessary expenditure on servers which sit mostly idle.
Don't forget that migrations cost money! ScienceSoft estimates the cost of an app migration to Azure as ranging from $5-15K (small app) up to 500K or more (large app).
Even if you perform the migration in-house, that cost includes the opportunity cost of having staff work on other projects.
Azure typically offers three separate models for pricing: pay-as-you-go (PayGo), one-year reserved, and three-year reserved. Typically, 1-year reserved is 30-40% less expensive than PayGo and 3-year reserved is 50-70% less expensive.
When would I choose PayGo?
When would I choose 3-year reserved?
When would I choose 1-year reserved?
Azure Hybrid Benefit allows you to use on-premises, licensed versions of certain software in Azure. This includes Windows, SQL Server, and RedHat & SUSE Linux.
With SQL Server in particular, you can use Hybrid Benefit to migrate to Azure VMs in IaaS as well as Azure SQL Database and Azure SQL Managed Instance.
You cannot use the same license on-prem or in the cloud, though there is a 180-day "concurrent use" right to help with migration.
For development and testing workloads, you can create a Dev/Test subscription as part of your Visual Studio subscription.
With Dev/Test pricing, licensing costs are removed. This makes Windows VMs as inexpensive as CentOS or Ubuntu Linux VMs, removes licensing costs for Azure SQL Database, and provides discounts for services like Azure App Services.
This is, of course, only for development or test environments, not for production.
Certain services have Free tiers, which works well for low-use development environments. For example, IoT Hub has a Free tier which allows you to send up to 8000 messages per day.
Even for services lacking Free tiers, there are often significant price differences between Premium and Standard tiers, and for many services, the key differences are in things like High Availability and SLAs rather than differences in the development surface area.
Scaling down works well in dev environments as well as "9-5" scenarios where there most of the traffic happens during a small stretch of time during the day.
At the extreme, you can shut down services like Azure Synapse Analytics dedicated SQL pools and only pay for storage. This can reduce the cost during off hours by 80-90% depending on your storage requirements.
More commonly, you can't shut off a service because it needs to be available 24/7, but can scale down overnight.
Scale-down takes time and can frequently cause downtime while it scales down. Scale-down works best with applications and worst with databases.
You may also be at the minimum for scaling--you don't want to change tiers when scaling, moving from Premium to Standard. Even for services where that is possible, it's typically a bad idea which causes a lot of downtime.
Scale-down is typically not the best solution!
"Cloud Native" development is the secret to a cheaper cloud experience. It includes:
Microservices are small, independent, constrainted services. They receive information, do one key thing, and possibly output results.
Microservices can run on small VMs or containers, and you can sometimes host multiple microservices on the same instance.
Along with microservices, we want to use event-driven development. Microservices receive information as events, and handle these requests on an as-received basis.
Typically, we want to use queues to handle this message-passing. This allows us to keep services independent and scale them independently. Furthermore, if we don't need immediate responses, we could even shut off services overnight and messages can remain in the queue.
We typically over-allocate resources for on-premises VMs, as it's difficult to scale them up once created. We might have servers running on 10-20% CPU or using less than half of the allocated RAM.
In the cloud, we want to push closer to 65-75%. We don't want 100% utilization (because then the server is just spinning) but we're paying for unused resources. If you do need to scale up resources, it's typically easy to do this in the cloud--at least with applications.
It can be difficult to get the business side to let you fix technical debt because it's hard to quantify the benefit behind it.
In the cloud, certain types of technical debt are easy to classify: if it lets you scale down services or reduce the number of servers running, you have a direct measure of benefit: lower Azure costs!
"Lift-and-shift" strategies are common for getting into the cloud, as it's easy to move virtual machines from on-premises servers into Azure. This strategy is, however, rather expensive: it's typically cheaper to host all of those VMs locally, especially for larger companies.
The most price-effective services tend to be efficient platform-as-a-service and function-as-a-service offerings like Azure Blob Storage, Event Hubs, App Services, and Azure Functions.
Most likely, your on-premises solutions don't look anything like what I've described--though if they do look like this, you're probably a good candidate for Azure!
This doesn't mean "Don't move to the cloud," but it does indicate that you'll want to reshape services over time and plan migrations.
How do we get there from here?
Summarizing how we can save money:
Summarizing how we can save money:
Budgets let us know when we reach a certain level of spend.
Cost alerts send messages when you get close to or above budget.
If you have an account which uses Azure credits, spending limits are enabled by default to prevent you from owing Azure money beyond your credits. If you hit the spending limit, all services are shut off until the next billing period unless you disable the limit and set up a payment method.
Custom spending limits are not available in Azure.
For large companies or multi-client scenarios, chargeback can be important for internal or external accounting.
The easiest way to perform chargeback is to tag individual resource groups and resources with the relevant department or customer and to use the Azure Cost Management portal to create reports.
Performing chargeback within a resource, such as Azure SQL Database or a VM running SQL Server, is something you would need to control using your own accounting rules and processes.
In this talk, we looked at the billing model of the cloud, including how it fits in the "OpEx vs CapEx" debate. We reviewed the Azure pricing calculator and demystified it somewhat. Then, we looked at strategies to save money in the cloud, using two examples of Azure reference architectures to save up to 60% off the "naive" bill.
To learn more, go here:
Catallaxy Services consulting: