>> Welcome to the Cost Optimization session.
This is two reasons why you should believe us
when we say you can optimize your Azure Costs
with Ritesh Kini and Priyanshi Mittal,
and me David Blank-Edelman.
When we're looking at the cost optimization question,
we thought let's provide the thing
that is most useful to our customers.
But how are we going to know that?
We decided to look at the data for Azure Advisor,
which gives recommendations to our customers
on how they can optimize their costs
and get the most value for what they're trying to run in Azure.
When we looked at the top recommendations
that Azure Advisor gives out,
we saw that there were two that
stood out that we thought we should talk about.
Let's go take a look at the first one.
Let's go into Advisor and see what recommendations we have.
The recommendation we're going to talk about
first today is this one right here,
right-size or shutdown underutilized virtual machines.
I thought I bring to the studio an expert on this.
Hey Ritesh, I'm wondering
if you could talk a little about rightsizing.
>> I would love to. Let me jump right in.
Here's an example of a recommendation
that we show for virtual machines for rightsizing.
In this specific example,
we suggest that you can change
your Reco desktop VM from a D16_v3,
which is 16 core VM,
to a D4sv3, which is a 4 core VM.
In doing so, you will save $10,000 on yearly Azure costs.
Not bad for a single recommendation.
Let's walk through how we produce this recommendation.
First, we start by looking at the utilization
of each VM across the Azure obsolete.
Don't worry, we have no idea
what you're running on this VM or who's running it,
we just boil down the telemetry to CPU, memory
and network utilization in the form of percentages.
This chart shows the utilization over the last seven days.
As you can see, the utilization of CPU memory network
never goes beyond 28 percent in this case.
The shaded red area represents under utilization,
which in this case takes up majority of the chart.
The workloads running on this VM simply
don't mean the power that this VM is capable of.
Another way to look at under utilization is with buckets.
Let's say this is the utilization over the last seven days.
It comprises of data points collected
every 30 minutes and over seven days
that translates to 336 data points.
For ease of calculation,
we just take the 95th percentile
while figuring out our recommendations.
The 95th percentile considers most of the high load
while ignoring some non-typical spikes.
Let's say in this case,
the 95th percentile of CPU is 10 percent.
Similarly, this is the utilization
of memory over the last seven days.
However, in the case of memory,
we take the 100 percentile,
or simply the max value absorbed over the last seven days.
There is a difference in the percentiles
that we consider for CPU and memory
because most workloads can handle the CPU peeking out.
But if the memory leaks out,
there is a risk that workloads
can crash due to out of memory exceptions.
Performance and reliability is
the number one thing that we think
about while generating a recommendations.
We want to make sure that those aren't impacted at all.
The P100 of memory in this case is nine percent.
We can represent the total capacity
of virtual machines in the form of buckets,
such that if the bucket is filled up,
it means that the resource is being utilized completely.
In this case, since the P95th of the CPU is 10 percent,
the bucket is filled up only at 1/10th of its capacity.
Memory is filled up even lower than that.
As part of our right-size recommendations,
what we're trying to do is get you
to move to a smaller size buckets
such that the utilization is increased
and the empty space in the bucket is minimized.
While at the same time,
making it cheaper for you to run your workloads.
The D16s_v3 is a 16 core VM with 64 gigs of memory.
We can quadruple the utilization of the workload
by moving to a VM that is 1/4th the size.
By moving to a VM that has four cores and 16 gigs of memory,
the CPU utilization can be moved from 10 percent to 40 percent,
and the memory utilization can move
from nine percent to 36 percent.
Similarly, we go to a even smaller size,
the utilization can go up even higher.
Thanks to the number of skills available in Azure,
it ensures that we always have enough sizes to choose from.
How did we land on the right size to choose?
As the title suggests,
it's with the form of targets.
We identify what we want the ideal max utilization
to be based on the type of workload,
and then try to choose a size that gets
the utilization up to that target without going over.
You might be wondering what is user facing
and what is non-user-facing.
Or you might be wondering,
how do we even know what is user-facing?
What's good and what is a non-user-facing workload?
I'll answer the first question first and discuss
the second question later because
that's where some of the magic really happens.
User-facing simply implies that it
is processing user requests directly.
Non-user-facing implies that it is
processing bashed or scheduled request.
User-facing workloads are more critical in nature
because they are directly processing user requests.
That's why they have a lower target of
40 percent for CPU and 60 percent for memory.
Non-user-facing workloads have a target
of 80 percent for both CPU and memory.
This is how we finally land on the right size to recommend
by figuring out the size that gets you closest to the target.
Let's discuss how do we know if a workload is
running user-facing or non-user-facing.
This is the magical part.
Supper smart friends in Microsoft research
did some investigation
and found out with high degree of confidence
that it's possible to categorize a workload as user-facing
or non-user-facing simply by looking at
the waveform of the load average of the VM.
They've published this paper where it has
some very interesting details on
how they came up with this research
and how they landed on the conclusions.
Definitely check it out, it's extremely interesting.
Now let's go back and figure out
how we come up with the recommendations that we show in advisor.
We start with collecting the utilization information.
We get that from the Azure host machines that run the VMs.
Again, we don't know who the VMs
are run by and what workloads are being run.
We simply know what the CPU memory and network utilization is.
The metric information is sampled at 30 seconds
and aggregated over 30 minutes.
When we're aggregating, we take the max values
just so that we're ultra-conservative
when we come up with the recommendations.
As always, we don't want to impact performance
or reliability when you adopt our recommendations.
Finally, we considered the last seven days of utilization
while figuring out our recommendations.
Now let's look into exactly
what happens to derive a recommendation.
We first compare the current utilization
with the capacity of the VM that's currently on.
We identify the type of workload
that's running the user-facing
or non-user facing part
and figure out what the targets should be based on that workload.
Then we'll take a look at
all the different sizes available in Azure
and see which size can get the workload
to the right target utilization.
We don't want it to go over.
It's going to be as close to the target as possible,
but not go over.
Then finally, we pick the cheapest options
so that you get the most cost optimization
while keeping the performance and reliability intact.
Finally, what we'll end up with as a recommendation that moves
the utilization from something like this to something like this.
Which means you get to optimize your costs
while keeping your performance and reliability intact.
Pretty cool, right, David?
>> Yeah, that's really cool.
I would like to also take a look at
a second recommendation here since we're on a roll here.
Let's go back into adviser
and see our second recommendation for this session.
This recommendation is buy
virtual machine reserved instances
to save money over pay-as-you-go costs.
I'd like to bring another expert on
to talk a bit about reserved instances.
Hey, Priyanshi, I'm wondering if you could tell us
a little bit about reserved instances.
>> Hi, David. Absolutely.
Let me jump right into what are reserved instances,
or also known as Azure reservations.
If you have consistent VM usage that supports reservations,
buying reservations give you the option to reduce
your cost with same configuration,
same reliability, and same performance, but reduced costs.
For example, when you continuously run instances of VMs,
you are charged at pay-as-you-go prices.
When you buy a reservation,
you immediately get that reservation discount.
The resources are no longer charged at pay-as-you-go rates
and Azure reservations help you save money committing
to one-year or three-year lands for multiple products.
Why would you buy reserved instances?
They save up to 72 percent on your pay-as-you-go costs.
After you purchase a reserved instance,
you don't have to redeploy.
The discount is automatically applied to matching resources.
You can come into one-year or three-year plans wherever available.
It's also an advantage for our Azure teams
so that they can optimize the capacity planning
for VM instances effectively.
Now let's look at what data points
we use in the recommendation engine
to get the right recommendations for you.
If your resources are shut down regularly,
the simulation won't find any savings,
and no purchase recommendation is provided.
It looks at currently deployed resources for VMs.
It takes into account any special discount
that you may have on your pay-as-you-go
or on-demand prices.
It looks an aggregate's usage across multiple days,
including 7, 30, and 60 days.
It also considers any recent reservation purchases that you have.
Lastly, it also calculates
usage for each and every Azure subscriptions.
Then it provides recommendations with
projected usage and potential savings.
Now that we've looked into what data goes into system,
let's also look at how
these recommendations are calculated or simulated.
The recommendation engine evaluates
the hourly usage for your resources
in the given scope over past 7, 30, and 60 days.
Based on the usage data,
it simulates cost with and without reservations.
The costs are simulated for different quantities and
the quantity that is recommended maximizes your savings.
The recommendations in advisor are based on
single scope and are based on last 30 days' usage.
Let's look at a very simple example here.
In the chart, you see that your VM usage fluctuates
from using 35 VMs to up to 70 VMs every hour.
Now, how would the recommendation be
calculated since it's been fluctuating a lot?
The recommendation looks at the most consistent usage.
In this case, though,
the most consistent usage would be around 40,
it may recommend the quantity to be 45
because though the utilization
of the reservation might not be 100 percent,
but it will give you the maximized savings.
Now, how do I get these recommendations
and how do I purchase these VM instances?
VM recommendations are available in Azure Advisor.
Recommendation are also available
in reservation purchase in Azure portal,
and also in cost management Power BI app.
You can also get them through our APIs.
When purchase the quantity that Azure recommends,
that will give you the maximum savings possible.
The recommendation quantity and savings are
for a three-year reservation where available.
If a three-year reservation isn't solely for the service,
the recommendation is calculated
using one-year reservation price.
Isn't that cool, David?
>> Yeah, I find all these things really cool.
Being able to see behind the scenes
how we calculate this stuff is really super interesting.
If our folks watching this want more information
about what we've been talking about,
both about rightsizing and reservations.
They can check out these docs on Microsoft Docs.
I want to bring Ritesh back if we can for a moment.
I think that people who are
watching this live are going to have questions for you.
Would the two of you be willing to
answer some questions from people?
>> Yes.
>> A 100 percent.
>> Great. Let's switch back to the live environment.