Saving Your Wallet from the Cloud

Extended Director's Cut

Who Am I? What Am I Doing Here?

	Catallaxy Services
	Curated SQL
	PolyBase Revealed

@feaselkl

Motivation

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.

A Quick Note

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.

Agenda

1. Pricing in the Cloud
2. How Much Will My Stuff Cost?
3. Saving Money in the Cloud
4. Scalable Web Application
5. Microservices with AKS
6. Budgeting and Alerting

The Billing Model

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 Billing Model

The pay-for-use model is an Operating Expenditures (OpEx) billing model.

On-premises hosting is typically financed via Capital Expenditures (CapEx).

A Finance Fight!

Summarizing CapEx vs OpEx

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.

The Cost of Everything

With cloud providers, almost everything has a price.

• Data ingress? Usually free
• Data egress? Pay
• Data storage? Pay
• Compute? Pay
• Network utilization? Pay
• High availability? Pay
• Faster performance? Pay
• Running a dev or test solution? Pay*

That said, some services are free or have free tiers.

The Calculator

Azure has a fully-featured pricing calculator.

Points of Confusion around Pricing

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.

Points of Confusion around Pricing

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...

Azure SQL Database Service Tiers

• DTU Model
  • Basic
  • Standard
  • Premium
• vCore Model
  • General Purpose
  • Business Critical
  • Hyperscale
• Serverless

Points of Confusion around Pricing

3) Cross-product Variants

Do you want a Spark cluster? Take your choice:

• Azure HDInsight
• Azure Databricks
• Azure Synapse Analytics
• SQL Server Big Data Clusters
• Build it with VMs
• Build it with containers on Azure Kubernetes Service
• Build it in Azure Machine Learning
• Maybe something else too?

Agenda

1. Pricing in the Cloud
2. How Much Will My Stuff Cost?
3. Saving Money in the Cloud
4. Budgeting and Alerting
5. Scalable Web Application
6. Microservices with AKS

Diving into the Pricing Calculator

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.

Outside the Calculator

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.

Maximizing the Calculator's Value

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.

SQL Server Data Migration Assistant

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.

Azure Migrate

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.

The Cost of Migration

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.

Is This Really Cheaper than On-Prem?

It depends!

• If your data center is really expensive, public cloud is probably cheaper
• If you have extreme hardware requirements, then probably not (and they may not have appropriate offerings)
• If you simply lift-and-shift, it's almost definitely more expensive in the cloud
• If you have data in multiple geographical regions, moving to a public cloud is often cheaper
• Even if it is cheaper, it takes time and effort to optimize your apps for the way the cloud works!

Agenda

1. Pricing in the Cloud
2. How Much Will My Stuff Cost?
3. Saving Money in the Cloud
4. Scalable Web Application
5. Microservices with AKS
6. Budgeting and Alerting

Reserved Capacity

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.

Reserved Capacity

When would I choose PayGo?

• If you use a service less than 30-40% of the time and can have it off the rest of the time.
• If you just want to try out a service, start as PayGo and decide if you want to reserve later.
• If you want the lowest upfront price, PayGo has no "down payments."
• If you can fit everything into a very inexpensive tier, PayGo might be cheaper than reserved instances, especially for things like Azure Blob Storage.

Reserved Capacity

When would I choose 3-year reserved?

• If you constantly use a service (the closer to 100% uptime, the better) and are willing to make a 3-year commitment.
• 3-year reservations can be amortized as CapEx, unlike PayGo or 1-year reservations.

Reserved Capacity

When would I choose 1-year reserved?

• 1-year reservations tend to be the best trade-off between hardware flexibility and price savings.
• VM prices tend to drop over time, meaning it may actually be cheaper to take three 1-year reservations than one 3-year reservation!

Hybrid Benefit

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.

Dev/Test Subscriptions

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.

Free and Development-Grade Tiers

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

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.

Scaling Down -- The Downsides

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

"Cloud Native" development is the secret to a cheaper cloud experience. It includes:

• Microservices
• Event-driven development
• Pushing resources to the limit
• Hunting down technical debt
• Reducing dependence on virtual machines

Microservice Architecture

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.

Event-Driven Development

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.

Minimal Overhead

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.

Aggressively Hunting Technical Debt

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!

Reducing Dependence on Virtual Machines

"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.

This is NOT Your On-Prem Solution!

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.

The Secret to a Cheaper Cloud Experience

How do we get there from here?

• Take smaller product offerings and move them up first
• Perform ruthless technical debt cleanup
  • Remove external dependencies
  • Change access patterns--interact through an API
  • Optimize code performance and database performance
  • Minimize network bandwidth utilization
• Study up on cloud architectures; they're not the same as what works on-premises

Agenda

1. Pricing in the Cloud
2. How Much Will My Stuff Cost?
3. Saving Money in the Cloud
4. Scalable Web Application
5. Microservices with AKS
6. Budgeting and Alerting

Scalable Web Application

Demo Time

Saving Money

Summarizing how we can save money:

• Cache heavily
• CDNs are cheap--use them!
• Scale if you experience bursty behavior
• Prefer well-designed, fast functions
• Look for service overlap: Azure Front Door Standard & Premium include a CDN plus a WAF.
• Remove Azure Search + Cosmos or SQL

Agenda

1. Pricing in the Cloud
2. How Much Will My Stuff Cost?
3. Saving Money in the Cloud
4. Scalable Web Application
5. Microservices with AKS
6. Budgeting and Alerting

Microservices with AKS

Demo Time

Saving Money

Summarizing how we can save money:

• Use Azure Container Instances for dev and test
• For fairly simple apps, use App Services instead
• Use the same Kubernetes cluster to deploy several microservices
• Reduce VM size for Kubernetes cluster

Agenda

1. Pricing in the Cloud
2. How Much Will My Stuff Cost?
3. Saving Money in the Cloud
4. Scalable Web Application
5. Microservices with AKS
6. Budgeting and Alerting

Create a Budget

Budgets let us know when we reach a certain level of spend.

Create a Budget

Create Cost Alerts

Cost alerts send messages when you get close to or above budget.

Create Cost Alerts

Create Cost Alerts

Spending Limits

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.

Tagging and Chargebacks

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.

Wrapping Up

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.

Wrapping Up

To learn more, go here:
https://CSmore.info/on/wallet

And for help, contact me:
feasel@catallaxyservices.com | @feaselkl

Catallaxy Services consulting:
https://CSmore.info/on/contact