>> Hi. Welcome back to the
Azure Cloud native series.
I'm Gary Hope, a Program Manager
on the Azure Cosmos DB team.
This is the second part of our
video looking at what makes
Azure Cosmos DB a great database
for your Cloud native
application development.
We will continue to look at some
of the leeways you can use to
optimize cost when using it
to build these applications.
If you haven't watched the
first part of this video,
I suggest that you
do that now as we're
build on some of the
concepts explained there.
In the previous video,
I introduced Azure Cosmos DB
and provisioned throughput.
We ended with some
demos on how you can
practically provision and manually
adjust throughput to make sure
the provision throughput matches
your application requirements,
either through the portal,
running an automation script,
or programmatically in your code.
What if you don't have
such automation in place
and you need to cope with
regular fluctuations such as
those associated with
daily business hours,
changes in needs of weekends or
monthly billing cycles as examples.
This is where you want to
automate the adjustment of
your throughput for a specific
time of day or week or month.
We're going to configure
some automation to
manage the throughput of
our dedicated container.
First things first, I need to
download the project from the repo.
Let's open the project
and see what it contains.
Here you can see there
are two functions,
one called ScaledUpTrigger and
the other, ScaleDownTrigger.
Within each function definition,
that's the function.json file,
you can see they're defined as
timer based trigger functions,
and you can see they have schedule
attributes that defines when
the timer triggers
the function itself.
Those of you familiar
with Unix or Linux will
recognize that this is being
specified in cron format.
In this case, 8:00 AM every weekday.
Every day at this time,
the function will run the
PowerShell code defined here.
First thing the code does is retrieve
the resources to be updated,
and their target values.
It then validates
that the database or
content exists and
what API it's using.
It then does some checks and
finally sets the throughput to
the value configured in
the resources JSON file.
As I mentioned, each
of the functions has
a resources file that
specifies the resource group,
the account, the database,
and the container you wish to
manage along with the
throughput value desired.
In this case, 4,000.
Here you can see the same
scaled down function.
Specifying the throughput should
be brought back down to 2500.
Switching back to the portal,
you can see here I've created an
empty Azure Function app as per
the instructions in the repo
ready to receive the
functions themselves.
Back to VS Code to deploy my
function by hitting "F1",
selecting the "Azure
Functions Deploy'',
specifying the resource group,
select an Azure Function app,
the one I've just created,
and click ''Deploy''.
A couple of seconds
later, we're done.
If we now go to our
Azure Functions app,
click ''Refresh'',
click ''Functions''.
You can now see the two
functions we just created.
I've opened browser tabs for
each of the functions here.
Let's refresh these.
If I click the "Test/Run"
on the function,
I have the option to run the function
now rather than waiting
for the scheduled time.
But before I click "Test",
let's check what value the throughput
the dedicated container
is configured for now.
Here you can see the
dedicated container is
configured for 4,000
request units per second.
Going back to the
scale down function,
we can click ''Run'',
remembering that the resource
file was configured to adjust
the throughput to 2,500
request units per second.
We give it a couple of
seconds to run to completion.
Now, we can go back and see if
the throughput has been updated.
Hit ''Refresh'' and here you
can see it's been scaled
back down to 2,500
request units per second.
The same would apply to
this scale up function.
For now, I'll leave that up to you
to explore in more
detail on your own.
What if my traffic patterns
are unpredictable.
In this situation,
it's impractical or
even impossible to use manual scaling
because we never know
when we will need
more throughput and
when we will need less.
That's when autoscale
comes into play.
In this mode, you only
have to configure
the maximum amount of throughput
you expect your application to need.
Azure Cosmos DB will
then automatically
scale your provision
throughput up and down to
accommodate your
application's requirement
within the range that spans
from the maximum level you
configured down to 10
percent of that maximum.
Autoscale delivers on
the exact same availability
and latency promises.
It is the best solution when you
have unpredictable traffic patterns,
but also need to
guarantee performance.
Let's create a new container
in the same way we did before.
Selecting the database we're
going to create it in,
giving it another imaginative name,
specifying the partition key,
choosing to provision dedicated
throughput for this container,
and here instead of choosing manual,
we're going to choose autoscale.
Here I'm going to specify the
maximum value up to which we
want Cosmos DB to automatically
provide throughput.
It will automatically scale
back down to 10 percent of
that value when not
needed. Clicking ''OK''.
If we go to the overview page,
you can now see autoscale container
with 4,000 request
units per second max.
Let's click back on the
container itself and
draw back into the settings
of this container.
As you can see here,
we can revert back to
manually provisioned
throughput whenever we choose.
Azure Cosmos DB offers a
free tier that gives you
the first 400 request units
per second throughput,
and five gigs of storage
free each month.
Free tier can be applied to
production apps and offers
a discount that developers can take
advantage of for the
life of the account.
This gives you an effective
400 request units per second
irrespective of whether you use
standard or autoscale
provision throughput.
This capability is especially
interesting when combined
with autoscale throughput.
Not only does it provide you
with 400 request units per
second discount no matter
how large or small the
throughput is scaled to.
When a container is configured at
a maximum of 4,000
request units per second,
the minimum 400 request units per
second effectively disappear
when free tier is enabled,
thus providing you with a
deployment that is completely free
in the hours where there is no
or minimal application traffic.
Remember that Cosmos DB is
also offered as part of
the Azure free account,
which offers access
to a wide variety of
Azure products that you can use
to build your apps for free,
including things like
Azure Functions,
App Services, AKS and many more.
Let me show you how
easy it is to enable
free tier when you deploy
your Azure Cosmos DB account.
Here I am back in the portal.
This time I'm going to add a new
service to our resource group.
I choose Azure Cosmos DB,
click ''Create'', choose my
subscription and resource group,
specify the account
name I want to create,
choose the API I want.
Now, if we scroll down a little,
we have some options,
one of which is the ability to apply
free tier discount to the
account we're creating.
Just clicking this
option on at the time of
account creation will ensure that we
get the 400 request units per
second discount applied
to the account.
Remember, only one account per
subscription can have the
free tier discount applied.
Then lastly, options to specify
whether we want non-production use,
the geo-redundancy and
multi-region writes.
All of these are disabled
to ensure that we
keep the costs of our
development account down.
Obviously for production accounts,
we will want to make
these choices based on
the needs of our application
as discussed earlier.
The provision throughput
offer we have covered so
far lets you provision
throughput capacity.
But what if you don't need any
real throughput when, for example,
performing development
or testing activities or
even when running small
noncritical applications,
and ADMS may sit idle most of
the time and only needs to
process requests occasionally?
We can certainly use autoscale
here again as it will dynamically
scale up the delivered throughput
whenever a request kicks in.
But because a building granularity
of autoscale is one hour,
and because it always provisions
at least 10 percent of maximum
throughput you've configured,
this would represent unused capacity.
To best accommodate
this kind of workload,
we're introducing a
new offer, serverless.
Azure Cosmos DB
serverless is going to
be a pure consumption model where
only request units consumed by
each application
request will get both.
This eliminates the need for
the provision capacity concept,
and request units per second
for the scenario altogether.
We recently announced this
new offer at Build 2020,
and it will be available in
public preview within the
next couple of months.
In this video, I hope to have
provided you with some
insight into what makes
Azure Cosmos DB a great
database for your Cloud
native applications.
We've also explored the
provision throughput offer
that is available today
on Azure Cosmos DB,
demonstrated how you can optimize
your cost by appropriately
selecting the options that's
best for your workload,
and finally, introducing
the new serverless offer
that will become available soon.
By giving you the granular control
to handle any traffic pattern,
these comprehensive
offerings ensure that
Azure Cosmos DB is a cost-effective
solution for any workload.
