Welcome to this overview of the
on demand capacity reservations,
a new feature that Azure is
introducing for virtual machines.
My name is Bill DeForeest.
I'm a Principal Program Manager
in the Azure Compute team and
excited to share with you all of
these new developments that we're
providing you as our customers.
We're going to talk about what
this feature is and what it does.
We'll compare it to our existing
capabilities for reserved VM instances,
talk about some capabilities and benefits
that this new feature will provide you.
Some common scenarios where
you may want to apply it,
and some billing and payment
considerations before we move to
a demonstration of the feature.
So what is this new feature? An On Demand
Capacity Reservation is a feature
for virtual machines that allows
you to get a SLA for a quantity
of a particular VM size in a
particular Azure location.
It is something that you provision
via the Azure portal or via the
standard Azure APIs such as PowerShell,
CLI or your favorite SDK.
Once you successfully deploy an
on demand capacity reservation,
you will receive an SLA for that
capacity to be available to you
whenever you need to use it for
whatever virtual machines of a
matching size in the matching
location you would like to deploy.
So let's compare this capability
to our existing reserved virtual
machine instances or RIs.
Both the on demand capacity
reservations and RIs are
applicable to virtual machines,
and they typically apply to a
particular size of virtual machine,
or, in the case of RIs,
a family of virtual machines.
The term commitment for the reserved
instances of one or three years does
not apply to the On Demand Capacity
Reservations. There is no commitment required.
You can create the On Demand Capacity
Reservation whenever you want.
You can cancel it anytime you want.
You can keep it for two weeks
for a special event,
or you can keep it for three
years for disaster recovery.
It's really up to you.
The On Demand Capacity Reservation's
key capability is that it is a
true reservation of capacity.
It is set aside for you as a customer.
It is backed by SLAs that Microsoft will
make that capacity available to you.
And we will prevent other customers from
consuming the capacity that you've reserved.
In contrast,
reserved instances the capacity
is not technically reserved.
It is prioritized,
but it is not guaranteed,
and so this is an opportunity now
for you to get assurance that you
will have the capacity you need to
deploy your applications. On Demand
Capacity Reservations is not
a discounting mechanism.
Typical usage rates will apply to
your On Demand Capacity Reservation.
If you want discounts,
then you compare that...you can pair
your On Demand Capacity
Reservations with RIs
and receive the best of both worlds.
You get a term-based discount
on your consumption,
but you also get a SLA
on the capacity that
you need to run your business.
Azure's goal is to support all of the
VM series shown here. At this stage of
our preview we are supporting primarily
our general purpose virtual machines,
so our entry level A2s
are burstable B series.
The general purpose D Series
compute intensive F series and
the memory optimized E series.
The remaining series that you
see listed here including GPU,
high performance storage intensive,
and the rest of our the rest of
the series that are grayed out.
Those...we're working on providing support
for all of those in the coming weeks
and months and will provide updates as
we get closer to general availability.
So the benefits of using this new
feature include insured ensuring
increased uptime for your applications.
You can reserve capacity ahead of
an actual deployment so that you
know will be successful and will not
receive the capacity error and you
can scale your business critical
applications with confidence.
You gain additional operational agility.
Azure is going to set aside compute
capacity regardless of whether or not
you have virtual machines deployed.
And the capacity is reusable
for any workload.
If you want to deallocate your
production workload overnight in
order to deploy temporary workloads,
run batch jobs, or
other kinds of things,
other kinds of applications,
that's all perfectly safe to do
because Azure will keep that
capacity available to you and will
ensure that you can redeploy.
You also get flexibility of deployment.
There is no time commitment required.
You can create and cancel on demand
capacity reservations at any time
for any reason. You think of it like
creating and deleting virtual machines.
It works very similarly.
There's some common scenarios
that we've heard from customers
that...in which they want to use
this type of capability.
The first is basic business continuity.
So without On Demand Capacity Reservation.
Sometimes you need to do
maintenance on your virtual machine.
You deallocate it in order to
replace it with a new updated image.
Perhaps it's patch Tuesday and
you are going to redeploy it at
some point in the future,
perhaps an hour or maybe even a day later.
You'll notice in the top part of the
picture that there's an empty rectangle,
but in the bottom part there isn't.
And that's because another customer
has come along and taken the
capacity that you had for your virtual
machine while it was deallocated.
This doesn't happen very often,
but occasionally we will see customers
who are unable to redeploy their virtual
machine because in the meantime,
Azure has had a surge in usage and
we are actually running a little bit
short on capacity temporarily. And
in those cases we do see occasional
situations where customers will fail.
With On Demand Capacity Reservation,
you can remove all of these risks
from your use of Azure. If you have
the On Demand Capacity Reservation
then the reservation will will
remain in place even while your
virtual machine is deallocated.
So when you come back and
reallocate your virtual machine,
you can have full confidence that you
will receive a successful allocation.
The second scenario is scale out
of mission critical applications.
So without an on demand capacity reservation,
if you're running your
standard 2 virtual machines,
they need to scale out to four
due to either a immediate surge
in demand or an anticipated one,
say for a special event.
In the current system,
it doesn't happen again very often,
but it does occasionally happen where
if you try to scale out 2, 3, 4...typically
it's a much higher number of scale out...
you may eventually reach a
point where Azure is unable to
accommodate your scale out request.
And so you could get at the very high end
of your scale out potential VM failures.
With On Demand Capacity Reservations,
you can have the rest...
you can have the capacity
set aside ahead of time,
know that it's available to
you whenever you need it.
You can reuse it for whatever you want
when you're not in your special event,
or when you're not in required...
requiring a full scale out
of your application.
And so when you go to actually
scale out the application for the
critical moments that you need it
in order to support your business,
you can deploy with full confidence
that the capacity will be available.
And finally,
probably the most common request
that we hear is customers gaining
assurance for capacity in the
event of a disaster recovery.
So without a capacity reservation today,
a customer will typically
be deployed in their
primary region or in some cases
their primary zone. And they all
have a secondary region and a
secondary zone...or a secondary
zone that they want to deploy
in the case of a natural disaster or
something that takes the takes part
of Azure offline for a period of time.
So today when that happens,
the primary region goes offline,
there will be an attempt to
fail over all of those
virtual...all the critical virtual machines
into the secondary region or zone,
and some of those may fail.
This is definitely a potential with,
say, a region wide outage due to
a natural disaster because there
are many customers who need to
fail over to other regions.
They're not all going to go
to the same region,
but if enough of them go to the
region that you're targeting,
there is some risk that Azure will run
out of capacity before you fully failed
over. With capacity reservations in place,
you can have all of the reserved
capacity set aside ahead of time
and receive assurance that you
will get that capacity when...if
and when a disaster recovery occurs.
You can also have that capacity
available when you need to run your
disaster recovery tests to ensure
that you have business continuity.
So now when the primary region goes down,
the secondary region has the
capacity set aside.
If you have temporary
workloads using that capacity,
you would evict them on your as
part of your client application and
then you'll be able to deploy all
of your virtual machines into the
secondary zone with confidence.
So let's talk briefly about the
billing and payment considerations.
An on demand capacity,
reservation is not about discounts,
it is about the operational benefit
of giving yourself an SLA to assure
that you will have capacity in the
event you need it for whatever reason.
However, it is the case that if you
have purchased our term discounts,
those will be applied automatically to
your capacity reservation whether it's
being consumed by a virtual machine
or whether it's sitting empty waiting
for your future virtual machine.
So this means that when you create
an on demand capacity reservation,
you will be charged for usage as
soon as you successfully deploy the
On Demand Capacity Reservation.
But you're only going to be charged once,
either at the PAYGO rates or at the
reserved instance term discounts.
The nice side effect of this design
is that you can now decouple the
payment process and the management
of your term commitments,
which is typically a financial operation
for most of our customers, from the
day-to-day run administration of your
applications in your use of Azure,
where the technical people understand
the capacity requirements,
the performance requirements
of individual applications.
And so this allows the technical people
to do their job and the financial
people to do their job and not have
to worry about trying to tangle the
two together and make a decision
about capacity versus term discounts.
You just make each decision
independently and the system just works.
So with that, let's move to a demonstration.
So let's see on demand capacity
reservations in action.
In the portal,
always start by creating a
capacity reservation group.
This will allow you to collect sets
of different sizes of virtual machines
and potentially those machines across
multiple availability zones into a
single object that you can then use
for an application or as blocks of
capacity for multiple applications.
It's always up to you how you want
to organize your resources.
To create a group, the first
step is to provide a name.
And then the second step
is to pick a location.
If I pick a location like US South
Central that has availability zones,
I have the option of either leaving
the availability zone set to none,
meaning all of my virtual machines
will be deployed directly to U.S.
South Central without specifying
an availability zone.
Or if I select one or all
of the availability zones,
then all of the virtual machines
that I deploy will subsequently
be required to specify the
exact one of those availability
zones that I included as part
of the deployment specification.
So just keep this in mind when you're
creating your capacity reservation group.
Do you want to use zones or do you not?
For this example,
just for simplicity,
we're actually picking...will
pick a different region that
doesn't have availability zones.
This is where I'm going to specify
the sizes that I want to reserve
in the quantities that I want.
You always give a reservation name.
Pick the quantity and pick the
exact size of virtual machine
that you want to reserve.
You'll be displayed a cost.
This is the pay as you go cost.
If you have reserved VM instances available,
they will be applied automatically
without any intervention on your part,
just like they would be for virtual machines.
And as mentioned, you can collect
multiple sizes under a single
capacity reservation group and
this way if I have a multi-tier
application I can have one group in
which I manage all of my resources.
Now if I click on create...I will
attempt to deploy my reservation.
My deployment has succeeded. So now
we're going to go to view the resource.
So here's my reservation group with the
capacity...with the capacity reservation
demo name that I gave it and if I
click on the reservations tab you'll
see that there is a reservation for
the D2 S V3 size and reservation
for the D4 S V3 size, both of which
I specified during my deployment.
And neither of them has
an allocated instance.
So let's remedy that now.
To use my reservation,
I start by deploying a virtual
machine just like I normally do.
Pick the resource group.
Give my virtual machine a name.
No special requirements.
I'm going to pick US West Central
just because that's where my
reservation is and this is one
of the sizes that I reserved.
I can accept the defaults for the virtual
machine except for on the Advanced tab.
This is where the new capacity
reservation option will appear.
If I drop this list down,
here is the name of the capacity
reservation group that I created and
the specific reservation that matches
the size that I'm trying to deploy.
Azure will do the work for you: if you
specify the capacity reservation group,
we will figure out which which of
the member reservations are actually
supposed to consume based on the size
that you deploy and potentially the
zone if you had specified zones as part
of your reservation group creation.
So if I go to create my virtual machine.
Then click create and I will begin
the deployment of my virtual machine.
My virtual machine is successfully
deployed, so let's go look at it.
The virtual machine looks perfectly normal,
has all the usual properties,
but now there's this additional
one: capacity reservation group.
This is how you determine that you...
this particular virtual machine
is consuming reserved capacity.
If I go back and refresh the
capacity reservation group.
Now we see that there is one allocated
instance of one instance that is reserved,
so I'm using one of the one instance
of the quantity that I reserved.
And I have one associated instance.
For fun, let's go back and try this again.
So I'm going to create
another virtual machine.
In the same resource group.
Call it demo VM two. Notice that
I'm specifying the same size of
the virtual machine that I did last time.
I'm going to skip to the Advanced
tab just like I did with demo VM one.
If I drop down the list.
Capacity reservation demo group that I
created and the specific reservation
of the D2 S V3 size is available to me,
so let's select them.
Review and create.
And then deploy.
The virtual machine is successfully deployed.
If we look at it, it looks very
much like Demo VM one and it even
has the capacity reservation...
reservation group associated with it.
I go back and look at my
capacity reservation group.
Now we see that Demo
D2 S V3 has two instances allocated
against one instance that's been reserved.
This is perfectly valid and Azure
will always let you do this
if it has capacity available.
It is referred to as over allocating,
so the over allocated column
in this instance is set to yes.
If you think about cases where you
want to just deploy your virtual
machines like you normally do,
and not worry about hitting the upper
end of your capacity reservation.
This is exactly why Azure operates
this way. A capacity reservation
is always the minimum
number of virtual machines
that you have reserved.
You are always allowed, as long as
space is available, to exceed that amount
as part of your capacity reservation.
Think about a virtual machine
scale set that has an auto scale
rule that might happen...that might
trigger in the middle of the night
while no one is paying attention.
We certainly don't want that allocation
to fail just because you happen to
hit the limit of your reserved space.
So this means that Azure will
always just manage and will always
allow you to allocate as many
virtual machines as we have space
and you have quota available.
We never stop you from deploying
just because you happen to have
used up your reserved capacity.
It's also the case that if I
go in and manage reservations.
I decided that both of the machines
that I have allocated are important
to me and I would like to make
sure that they're reserved.
I can now change the quantity to two.
And now both instances of my D2 S V3
VMS are occupying reserved capacity.
Now, just for completeness,
let's go back and look at the
virtual machines that we have.
And let's say I decide to stop one of
my virtual machines because I don't
need it right now and I press stop.
I say OK. Now my virtual machine is stopping.
So my virtual machine is now in
the stopped deallocated state,
meaning is no longer occupying hardware.
In at...in the West
Central US region. However,
the capacity reservation group remains
specified on this virtual machine,
meaning that if I attempt to deploy it again,
it will automatically attempt to
use the reserved capacity that I
have that I've set aside for myself.
If we go back and look at what that
state looks like in the capacity
reservation itself, now you...as you would
expect you have one of the two instance...
reserved instances actually allocated,
but you still have both instance...demo VM,
one that is now stopped and deallocated,
and demo VM two, that is still allocated.
They're both still associated
with the reservation.
This allows you to manage your
usage of capacity and understand the
expected use of capacity in the future.
The difference between the
allocated instances,
one used of two tells you you have
one spot available for future use.
The number of associated instances
at two is one additional VM of
expected demand in the future,
and therefore you have enough
capacity to cover all of all of your
expected virtual machine deployments.
In this way,
Azure is giving you all of the tools
for you to manage your capacity,
both currently and into the future as
your use of Azure changes and grows.
If you want to learn more,
there's documentation available,
there's a web page for the reserved
VM instances to review,
how how that existing feature works,
and we have pricing for Linux VMS.
An Windows virtual machines
available for you to review.
Thank you and we look forward to
sharing this feature with you at
a general availability and we look
forward to hearing all the feedback
on this great new capabilities.