This is Part 20 of azure tutorial. In our previous video, we discussed azure app
service plan. In this video, we'll discuss azure pricing tiers. When we create app service plan,
one of the important decisions we have to make is, selecting the appropriate pricing tier,
because it is the pricing tier that determines, what features are available for the applications
that we deploy in azure, the hardware that is available and the price we pay. In general,
the higher the pricing tier, the more features and capabilities we get. We discussed this
in detail in our previous video. In general, azure pricing tiers are classified into three
broad categories - Shared Compute and Dedicated Compute and Isolated. At the moment, we are on
this screen "Create app service plan" and we have the "spec picker" dialog open. The workload "Dev
/ Test" is selected, and take a look at these two pricing tiers F1 and D1. In the box of F1
pricing tier, at the bottom it says, it is free. So, this pricing tier is free and if we take a
look at the D1 pressing tier, again in the box at the top, it says it is shared. So, the point is
both these pressing tiers F1 and D1 are in this category. With these two tiers,
you cannot scale out resources and they use shared infrastructure. This means, all your apps
run on the same azure VM as other app service apps including apps of other customers. Next,
we have "Dedicated Compute" category. Take a look at this pricing tier B1. When I select this,
notice in this box right here, Azure Computer Units, it says dedicated compute resources
and then if I click on this link "See additional options", we have additional pricing tiers here,
and again when I select this pricing tier B2, same idea, notice in azure compute units box,
again, this pricing tier also has dedicated compute resources. So, both these pricing tiers
B1 and B2 are in this dedicated compute category, and this means, they run apps on dedicated azure
VMs. Only apps in the same app service plan share the same compute resources. The higher the tier,
the more VM instances are available for scale out. Finally, we have "Isolated" category. Now,
let me click on this "Isolated" workload. Notice, the message that we have right here "Inline
creation of app service environment is currently not supported". We'll discuss, what is app service
environment and its significance in our upcoming videos. For now, just understand, with this
"Isolated" pricing tier category, you not only get dedicated virtual machines but also dedicated
virtual networks. This means, on top of compute isolation to your apps, you also get network
isolation and that is made possible through virtual networks. It also provides the maximum
scale out capabilities. Now, when I was learning app service plans and pricing tiers, one of the
questions I had was, can I run more than one app in an app service plan? The straight answer is,
yes, you can, but the point to keep in mind is, if multiple apps are in the same app service plan,
they all share the same VM instances. If you have multiple deployment slots for an app,
maybe a staging and production slot for example, all these deployment slots also run on the same VM
instances. If you're new to deployment slots, don't worry, we'll discuss them
in our upcoming videos. Similarly, if you run web jobs, enable diagnostic logs or perform backups,
they also use CPU cycles and memory on these VM instances. So, the point is, if you have
three VMs in your app service plan for example and you have deployed multiple apps, all the apps
run on all the three VM instances. If the plan is configured to auto scale, then all apps in the
plan are scaled out together based on the auto scale settings. Now, how many apps can I run in
one app service plan? Is there any such hard limit on the number of apps? Well, there is no such
limit, it really depends on the capabilities of your existing plan. The point is, as long as your
existing plan has enough resources to handle the load, you can continue to add apps to it. However,
keep in mind deploying too many apps and overloading your plan can potentially cause
downtime for both your new as well as existing apps. So, the obvious next question you might
have is, how to determine if my new app needs a new plan or if I can use my already existing plan.
Well, there are some general guidelines, when you may want to create a new plan. Maybe,
for example, your new app needs resources in a different geographical region than your existing
apps. This may be because your national or regional regulations require you to do so,
or maybe, your new app is resource intensive and putting it in your existing app service plan can
negatively affect already existing apps or maybe, your new app needs different set of capabilities
and features altogether, for example you want to scale this new app independently from the other
apps in the existing plan. Now, as we have already discussed when we create a new app service plan,
one of the important decisions that we have to make is, selecting the appropriate pricing tier.
Now, let's say accidentally, I've selected a higher pricing tier. This obviously means it
is costing me more. So the question I have is, can I change pricing tier after the app service plan
is created? The answer is yes, you can change the pricing tier anytime you want. If you want more
features or more computing power, you can change to a higher pricing tier. On the other hand,
if you discover you're not using all the features or computing power, you can revert to a lower
pricing tier. The point is, you can scale your app service plan up or down anytime simply by changing
the pricing tier of the plan. For example, let's say you have a web application and you want to
deploy it in azure, but the problem is, you're not sure which pricing tier is right for you.
What you can do is, get started by hosting your web application in a free app service plan and pay
nothing. Let's actually do that. At the moment, we are on isolated workload. Let's select this
Dev / Test workload. This pricing tier F1, as you can see is free. So, let's select this
and apply. Click this button "Review and create". Validation passed. Click "Create". There we go,
deployment is complete. This means, our app service plan is created. Let's navigate to it
and the easiest way to do that is to search for" app service plans" and navigate to it.
Here is our plan - plan-pragimtech. Let's click on it. At the moment we are on the "Overview" blade.
Let me actually collapse this, so we have a bit more room. Let me click on "Apps". Keep in mind,
we don't have any apps deployed in this app service plan yet, so we see no results. Let
me click on this "File system storage". As you can see, we have one gigabyte storage space available
of which we are using zero kilobytes and that makes sense because we don't have any
apps deployed in this plan yet. Now, let's click on the "Scale up" tab, we see pricing
tiers here. If you remember, we selected this free pricing tier when we created this plan,
so that's what is selected at the moment. Now let's say, the app that we are deploying
needs custom domain feature, but this free plan doesn't support that feature whereas this plan
D1 supports custom domains. Now, let's say along with custom domains, we also want SSL support,
again this plan D1 doesn't support SSL bindings, whereas this plan P1 supports both custom domains,
SSL bindings and we can also manually scale up to three VM instances. So, if you're not sure which
pricing tier is right for you, you may get started with the free pricing tier and pay nothing. If you
want to add more features like a custom domain for example, you can scale up to the next higher tier
that supports custom domains. If you want to add even more features or computing power scale up to
the next higher tier so on and so forth. You can do the opposite as well. When you no longer need
the hardware or features of a higher tier, you can scale down to a lower tier which obviously
saves you money. So, the point is, you can scale your app service plan up or down anytime
simply by changing the pricing tier of the plan. That's it in this video. Thank you for listening.