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