[MUSIC]
>> Hey, so Azure Advisor
gives me personalized recommendations based on
a Well-Architected framework so I can better
use my cloud resources. Why don't we take a look?
Let's go to Advisor, right over here.
I'm going to click on "All Recommendations".
This one says, "Right-size or
shutdown underutilized virtual machines".
I'm not quite sure what right size is?
I wish I could go to some Azure Advisor Clinic to figure that out.
[MUSIC]
>> Well, maybe I can!
It turns out I have Ritesh Kini here,
PM from the Cost Optimization group.
I suspect Ritesh, that you know what Rightsize means?
Can you tell me about what 'Rightsize' means?
>> Sure. I can definitely help you with that.
Rightsize basically means you get to choose the right size.
When you are spinning up a VM,
for example, in Azure,
Azure gives you a ton of options
and you might not always choose the right size.
We take a look at the information and then we figure out,
are you using the best size for the workload that you're using.
That's what we basically mean by Rightsize recommendations.
>> Can we dig into that? I would really like to
know how this all happens.
>> Sure. I've got few slides for us to walk us through.
Let's take an example of a sample VM.
This is a D16 VM,
and so we get telemetry about your workload,
that is CPU, memory,
network from the Azure host.
This is totally anonymous data,
we don't really know what's happening on your workload.
We just know how much CPU, memory, and network you're using,
and we get that for
every 30 seconds and aggregate that over 30 minutes.
Then we take the maximum value of that so that we're being
ultra-conservative and we take seven days of that telemetry.
Plotted out this is what it looks like.
This white space on top
essentially tells you that you're wasting that much capacity.
You're paying for it, but you're wasting it.
What we do with rightsizing is try to
get the utilization up on top so
that you pay for what you need
without impacting your performance. Does that make sense?
>> Yeah, that makes total sense.
I'm really interested in how you
figure this out and how do you do this?
>> Perfect yeah, I can break that down for you.
Taking this utilization telemetry,
we separate our CPU from memory
because CPU and memory need to be handled differently.
You can hit the peak of CPU points and not get impacted,
but if you hit 100 percent of memory,
you can run into an out-of-memory
exception which can potentially crash your application.
When it comes to CPU,
we consider the 95th percentile
of CPU usage over the last seven days.
When it comes to memory,
we consider the 100th percentile,
which is essentially the maximum value.
Then what we do is we consider the utilization as a bucket.
If the bucket represents the VM,
how much capacity it has,
then the P95 is this filled-up portion.
What we're trying to do is fill it up so
that we get the maximum usage of this bucket.
Once we've figured out how much is
the current utilization, what's the P95,
what's the P100, we then
start figuring out what can we move it up to.
For CPU and memory, we have different targets, and beyond that,
we also have categorization based
on whether the workload is user-facing or non-user-facing.
>> Okay, wait. I got to stop you right there.
I thought we said that this is all
anonymous. What's going on here?
>> It is anonymous.
That's a great question.
What we're doing is we've got
some really smart folks in Microsoft research to help us with
some algorithms that help categorize
these workloads based on the waveform of the utilization.
They basically figured out running thousands
of examples of the waveform looks like this,
then its user-facing workload or the waveform looks like that,
it's a non-user-facing workload.
By user-facing, I mean a workload that is
directly addressing requests from a user.
When a user clicks on a website or something like that,
the web front end is the user-facing workload.
Using this algorithm, we've categorized it.
The reason we have different targets is because
we want to be more
conservative when it comes to user-facing workloads,
we don't want a case where
users face performance issues
because of our cost optimization recommendations.
Our utilization targets are lower in
user-facing and a little
bit higher when it comes to non-user-facing.
Does that make sense?
>> Yeah, that makes total sense to me.
Though I have to admit it's still magic that you can just look at
waveforms and determine whether our workload is user-face or not,
but I think it's really cool that we do it.
>> I consider it magic too.
Thankful for our partners in
Microsoft research to help figure this out for us.
Moving on to further explain it.
Now that we have the current utilization and we have our targets,
the way to increase our utilization is by,
we don't expect you to change your workload,
the workload's going to remain pretty standard.
What we can do to increase
the utilization is choose smaller buckets.
For user-facing workload, we might choose a four-core bucket.
In the example, I used,
the D16 is a 16 core VM.
By moving to a four-core VM,
we can basically quadruple the utilization to 40 percent.
For a non-user facing workload,
we can go down even lower and go down to
a two-core machine so that utilization goes up to 80 percent.
On the memory side, it's something similar.
We use 60 percent for user-facing and
80 percent for non-use-facing and then again,
we look at what are the VM options
available so that we can move the workload too.
Then finally, we consider
a solution that works for all three parameters, a CPU,
memory, and network and find
the best fit such that it's the cheapest option.
While at the same time,
because of the targets that we have,
it doesn't impact your performance.
Finally, you end up saving,
so in this case, from a D16,
we would recommend a D4_v3,
which would have four cores and 16 GB
and save you 60 percent in cost.
Utilization is going to look a lot better.
It's going to look a lot more busier.
But there won't be peaks,
especially when it comes to memory.
Your performance is good and your utilization
improves while you save 60 percent of costs.
>> Okay, that makes total sense to me and I understand
how picking a smaller machine means.
It's going to use up more of the machine
and the bucket's going to be more full.
I get how this goes,
I'm wondering if we can do a lightning round together.
I have some really small questions I'd like to do.
Let's see if I can ask you some real quick questions
that I know that we get asked all the time.
Does the recommendation I get from
Azure advisor about rightsizing
take into account negotiated customer discounts?
>> Oh, that's a great question we actually don't right now,
but it is something we are actively looking
into on how do we consider customer
discounting so that they
get the best deal when it comes to rightsizes.
>> Okay. Question number 2,
which is similar, there's
definitely different ways that customers buy Azure today.
Some use Pay-as-you-go, some go through cloud solutions provider,
others have an enterprise agreement.
Does the recommendations I get from Azure advisor around
rightsizing work for all those agreement types
and ways to purchase Azure?
>> It does. Like I was saying,
when we get telemetry from the Azure hosts,
we don't even know who you are,
and so we just generate recommendations for everyone,
and basically everyone benefits.
>> Cool. Well, thank you Ritesh, that was super helpful.
I think I have a much better understanding what we
mean by right-sizing and how this all
gets calculated when we get this as a recommendation from Advisor.
I want to thank you Ritesh for that help
and I want to thank you-all for watching this.
I hope that you'll join me on a future episode of
the Azure Advisor Clinic as part of the Azure Enablement Show.
[MUSIC]