- Introduction to App Services
Now you may have heard other terms, such as mobile app and API app. These are all just web apps. API is a web application that doesn’t have a user interface but simply communicates in XML or JSON. A mobile app is a backend app that integrates with a mobile on the front end. It can also do things like send notifications to Apple iOS and Google Android. So it’s covered by the web app. However, you can go into greater detail here. I believe it’s still possible to go and search the mobile app. Now they’ve removed it. So you used to be able to search for mobile apps, and it was a Sep con. It’s all a web application now. Okay, so we’re going to go and create a web application, and we’ll demonstrate how this works. We’re going to look into the settings and the integrations. How does getting code into a web app differ from getting code into a VM? So in this section, we’re talking about web apps.
2. App Service Plans
Alright, by now we know where to go to create a resource. We can see that the virgins are numbers one and two of the features, and the web app is number three. Instead of going that way, I’m going to go into the category. And we can see web apps listed here, but we can also see something called an app service plan. Now, a web app requires an app service plan to run. You can think of the web app as being the occasion and the app service plan as being the hosting. You can have multiple web apps on the same app service plan. So the app service plan is where the resources are constrained.
It’s what you’re paying for. And then you can have as many webapps as you can fit into those resources running on the same app service plan. So we’re going to start by creating an app service plan. Now, we don’t have to do it this way. We were to go and create a web application. We could choose or create a wasp service plan at the same time. But I’m going to separate it out for the purposes of teaching here. So we’re going to create our first app service plan. Very simple. There’s only the basics tab, and then you’ve got tags and creation. So the app service plan, again, like hosting, is where the cost is incurred. So let’s create a new resource group. I’m going to call this the AZ SJD app plan. Now again, this resource group is the other section and has to be unique for this subscription.
We only need app service and details now. I’m going to call it the same AZ SJD app plan. Now we can see right away that we’re being asked to choose an operating system. There are going to be limitations. If we choose Linux, we’re going to be blocked from running some apps. If we choose Windows, we’re going to be blocked from running some app. You really do have to have an understanding of what types of apps you’re going to run, and we’ll talk about that more in Web apps. Part of the video The next video I create But briefly, you can imagine that Linux apps have certain languages like Ruby or Java that, I believe, do not run on Windows. And then Windows apps have things like ASP.Net (the non-cross-platform version), ASP.Net 4, and ASP.Net 3 that do not have Linux versions.
And so now there’s a lot of stuff that’s cross-platform; I think NodeJS, PHP, and Net Core, things like that, are cross-platform, but some things are language-specific. So, since I’m going to.net core, I’m going to leave it as a possibility that it could be Windows as well because it’s cross-platform. Now, just like with virtual machines, you want to choose a region that is close to your target audience. If your users are all based in Chicago, you want this to be in the central US. If it’s based in New York, perhaps you want East US, and so on. There is a pricing implication. So if you choose Japan, you’re going to be paying more for this resource than if you choose US Central, for instance. And I believe even the US and US Central have different pricing.
You’re going to have to go to the pricing calculator and find different pricing. The final major decision you make is what type of hardware it runs on. Now we’re going to see that you do not get to choose the actual hardware, but it does constrain you because it’s intended to commute. Let’s see that there are three separate tabs here. One is for development test workloads, one is for production workloads, and one is isolated hardware. We’ll deal with the development test first. Now, there’s a note here that says the first basic BONE core for Linux is free for the first 30 days. So there’s a 30-day free plan. Under B1, there is a free plan. So for Linux, we don’t have the shared plan, which we’ll see under Windows. A different plan is available, the D plan. But for Linux, you do have a free plan. And you can see that you get one gig of memory, 60 minutes per day of CPU time, and 1 GB of disc storage.
So it’s a very constrained amount of space, memory, and your time, but it’s free. So, while you can certainly run a large WordPress website, you can also run a WordPress website in Azure for free indefinitely using this app. Now, I wouldn’t recommend this for development purposes. It’s probably too constraining for most development applications. You might want the B plan for a dev test workload, and you have B 1, B 2, and B 3. Now, the way that Azure measures performance is based on these ACCUs, or Azure compute units. Azure. Compute Units. It doesn’t really represent anything other than the performance. So whereas B1 is a 100 ACUperformance, B2 should deliver twice the performance at 200 and double B2 at 400. And the pricing, not accidentally, is exactly right as well. So you’re basically getting the same price for the same level of performance across all the different app service tiers. Now, there are different benefits.
So at F1, you can’t even set your own domain. F2 offers a custom domain, an SSL certificate, and scaling. So I’m not sure if you’re running production instances on BONE; probably, hopefully, but if performance is an issue, you can scale up and get more disc space. Ten gigabytes at the B1 level; I believe this applies to all BS. So those are the production workloads at the dev-test level. Standard and Premium (S1 and P1, V2) are available. The price goes up accordingly. So we were in the development world, going from sixteen dollars to sixty-five dollars. In the production world, you go from $88 up to $400 a month. Yeah, this is OK, so now we can see that the pricing is a little different there’s. For the standard plan, you are getting a little bit more memory. 175 gigabytes, the same ACU performance as the basic B One. So it’s only 100 ACUs, but it’s more memory it’s running on. It’s just an asterisk equivalent. So we don’t know the exact hardware, but that’s what it’s indicating. A series going down here gets us 50 GB of storage.
So going from 10 to 50, as soon as we get into stainable, we get things like backups, staging slots, and auto scaling. The standard plan is the smallest plan that has automatic scaling; manual scaling is available in the B series, as well as traffic manager for travelling across regions. So we can see that for 100 to 400, the price goes up, the memory goes up, and then we get to the premium plans. We are getting even more scale instances, so up to 20. So the standard plan had ten, and you could upgrade to a premium plan for more staging slots, more frequent backups, and significantly more storage. Now, at the beginning, you can run as many webapps as you want, but if you’re on the P One plan, you can run ten web apps under that if those web apps are not using too many resources. So for that $100 a month, you can have ten separate web apps with ten different URLs, all sharing resources, and it’s up to you. So for this example, I’m going to, you know what, start off on the B-1 series plan, and then we can show you how to scale this. So this app service is going to be a B. Now I can set tags just like with virtual machines, review, and create. So here’s a Linux basic B-1 plan: 100 ACUs and 175 gigabytes of memory. I’ll click “create,” and then we won’t have much of a hosting area for our platform as a service web apps.
3. Web Apps
So this deployment went by very quickly. We have an app service plan. If I say, “Go to resource,” you can see that this is a basic plan, and it is running on that free trial. So I do have approximately one month to use this application service plan for free because it’s a Linux plan. We can now see under “app” that there are no apps currently running, indicating that we haven’t created one yet. There is no point in talking about scaling yet until we start putting apps there.
So I’m going to leave most of this alone. Let’s go back to the homepage and create a web app. So we’re going to say “create a resource,” and I’m just going to pick this web app right off the home page here. It has a very simple wizard interface as well. I’m going to create this and put it in the same app plan resource group. So I’ll choose the Azsjdap plan. This is where we find that the name itself has to be unique across all of Azure. So this is a fully qualified domain. Unless we add security, it will be publicly accessible, and it will end up in Azure websites. Net. Now you do have the ability to attach a custom domain to basic plans and not to free plans or shared plans, but we are going to have to give this a name.
Now you’ll find that a lot of the common names are going to be taken because there are millions of Azure customers, and so Azure.net is obviously taken. You’ll have to think outside the box to come up with a name for this. So do keep in mind that the name you’re giving it now is probably not the name you’re going to deploy. It looks as if you’re going to use a custom domain name. So it doesn’t matter if it has a number in it or something like that. Alright, so I’m going to give it a very simple name. Now we do get to choose between code, web apps, and containers. This is distinct from the Azure Kubernetes service and the Azure contain instances. This is a third type of container, which is a container web application. I’m going to create a set of talks about container web apps, but for now we’re going to choose code.
Now remember, when we were creating the app service plan, I said there were restrictions on the type of code that you could run depending on the operating system of your device. I can see the cross-platform net core, Windowsonasp net, and Java eight Nodes, PHP, Pun, and Ruby if I open this drop-down menu. So if we chose ASP.Net, since that is a Windows-only plan, we can’t choose Linux, and therefore we can’t choose the application service plan that we just created. If we switch over to the net core, then it’s a cross-platform plan. So we can choose Linux, and we can choose the Abet SJD app plan that we just created. So I’m going to put this as Net Core running in the central United States. And the app plan that we just created, we can’t change it here because we already have this plan, and it’s a basic B1 plan.
We can enable application insights. Application Insights allows us to use our code to return telemetry and trace other notifications up to the Azure Portal so that you can run the Azure Monitor and be able to review application events. Let’s not leave that on for now. We’re going to skip this as well, and we’re going to say review and create. So remember, there’s no additional cost for creating a web app within an existing app service plan because you’re paying for the app service plan. This plan is free for 30 days. You’re not even paying for that. So I can say “Create,” and that will go off and create a web app. Or first, in our app service plan, we’re going to let that run. When we come back, we’ll have a look at that.
4. Web App Settings
Alright, so let’s go to the resource page and see that we have our app. Let me scroll down a little bit. There’s no data here yet, but we do have a URL, and we chose the number; we chose this URL. So if I were to copy this URL or click on it, it should take me to a website that’s going to give me a default page that tells me that it’s working. So I’m going to click it.
The web app takes a second to start up, and then we can say, “Hey, Net Core, your app service is up and running.” So this is sort of a default page. There is no code deployed, but this is our default page indicating that we are now deploying something here. So that, to me, is successful. The web app is running right now. Because this is a web app, we can prevent it from restarting by returning to the portal. I’ll talk about the swapping in a second, but as we should be able to see here, we just visited the web page, so 400 bytes of data are left. The Azure. We can see our one request. So we’re the only ones who’ve been to this website. As I previously stated, one of the best things about web apps is how well they integrate into deployment environments. And so you can set up what’s called “continuous integration” or “continuous deployment.” If your git code is stored in Azurerepo’s Bitbucket hub or a local git environment, Every time you commit code to your git repository, that could trigger a publish into Azure.
So, once the code is finally committed, you’ll have a brand new, updated website. And that’s one way to work in a development setting: just have your development environment always reflect the latest committed code. You can also do an FTP push. We do have FTP credentials, and you know, some environments like Eclipse and, I think, even Visual Studio support an FTP deployment, but that’s not required. Visual Studio has built-in connections to Azure for deployments. Now let’s look at the configuration tab. If you’re familiar with the Microsoft Web server running on different versions of Windows, you’ll recognise this. You’re going to have this much of the same configuration. So application settings are basically variables that you can set that have a value per application. This is like the web configuration that has app settings inside of it. You can also have connection strings, so instead of putting your database connection strings in the code, you can have them deployed in your portal so the app can access them, but they aren’t in the code. So there’s some security in that.
We’ve chosen NetCo 3-1 once more. We can go in here and change to the most recent version one or two, but we have authority over a different versioning system. If we allow FTP deployment, it is either limited to FTPs or disabled all the time. So there is a cold-start problem. They don’t visit this web app. After some period of time, Azure is going to shut down in order to save resources. It’s nice to start it up very quickly, but it does take a few seconds to go from being unstarted to starting it. And you can always turn this on. Session infinity exists. So if you’ve got stored session variables, you do not want users to be flipping between different pieces of the web app. You can force session affinity. This is Net Core on Linux, but if we’re running like Net, we can do remote debugging. So we could step through the code line by line within Visual Studio, running inside of Azure required certificates. We can see this again; it’s very similar to the settings I mentioned. We can set up custom domains, and we can force HTS only.
So if we don’t want people visiting this in an unsecured manner, So SSL has a certificate that’s been created for this. We can see Venet integration if we switch to the tab. This is an outbound connection from your web application to resources on a private virtual network. And so you can basically enable or whitelist your web app to access any VMs, databases, or other things on a virtual network. Azure Front Door Service is relatively new. It’s a load-balancing network on a global scale, etc., etc. That’s the overview for now. In the next video, we’re going to talk about scaling web apps.
5. Scaling Web Apps
Okay, so let’s say your app is extremely popular and you’re starting to see, let’s go over your screen, that you’re reaching capacity in terms of time slowing down and you’re basically starting to feel like you’re filling out this service plan. What are your options for scaling a web app?
Now you do have two options. Firstly, they are called scale up and scale out, and I’ll try to explain them here. So scaling up an app service plan basically means moving to the next larger plan or to a larger plan. So we are currently on the B-1 plan, as you remember from a few videos ago.
And we can simply just move to the B plan and say “apply,” and our app is going to be basically moved over to our code running on a B-2 plan. This is going to be seamless for end users. There might be a little, but basically, traffic will be pointing to one service at the moment, and then suddenly it’ll point to a different end user, and you won’t notice. So this is one way of scaling it, and basically I’m going to hit apply. So it’s going to create my app service plan, move my web apps over, and then it’s going to redirect the traffic to Bamboo. I’m running on twice as powerful an app service plan as I was previously. So that’s one way of scaling.
When you go from 100, 200, and 400 ACU, the largest one on the premium P-3 V-2 plan is 800. So there’s an upper limit to the size that we can scale up to. Okay, now the other option, which is probably more flexible, is scaling out. So if we go into scaling out in the basic plan, the only option you have is what’s called “manual scaling.” So we had just hit apply to move to the B plan, which is 200 ACU, and we can now decide that we can move up to two instances. So we can basically double the number of processes that are running to support our web apps. So remember, this is an app service plan. You could have multiple web apps running on it. If you scale this out, you’re basically creating a second app service plan, and the apps are being duplicated as well, as it automatically puts a load balancer in front of this as well. So, if I say, “Move me to two instances,” I’ll have to have two instances running with a loan search, and our performance will basically double under the basic plan for manual scaling, where the maximum number of instances is three.
Now that this is on the scale, let’s go back to “I’m going to discard this,” scale up, and we can see that “B 2” on my scale has up to three instances. So that was set. By choosing this B-2 plan, we were to move to a standard S-1 plane. So, from B-12, we can suddenly go up to ten instances. So that was the other option. We could have gone up to ten instances if we had gone from B1 to S1 instead of B1 to B2. Now the other thing about standard and premiumplans is it does support auto scaling. Auto-scaling allows you to monitor the resource utilisation of your app service and, if it’s too busy, add another instance, and then, when it slows down, remove that instance. So I’m going to check on this. My app service plan is updated. I can actually access the Overview screen. We can see that we’re running on the B-2 plan in the overview screen. So I’m going to scale up to an S-1 plan. Today you get an “S” for feeling good.
So I’m switching from B2 to S2. The plan was updated successfully. If I go to the overview screen, we can see that we’re on an S-2 plan. Now, when I go down to scaleout, I have the manual audit. I also have an auto-scaling option. Now, auto-scaling is based on a metric. And so if we go down to the rules here, we’re going to have to add some scaling rules. So let’s say we want, when the CPU percentage is greater than 70, to put this at 75%. So when the CPU utilisation averages 75% in a ten-minute period, then I want to increase the instance count by one, and I’m going to wait five minutes before doing that again. So the cooldown is basically to prevent you from going 12345 in less than a minute.
Okay? So there’s a five-minute wait to add additional instances. Now whenever you scale up, you’re probably going to want to scale down because this is sort of a one-way ratchet. So let’s do a scaled-down version as well. So now we’re going to say that when CPU utilisation is less than 20% over a ten-minute period, I want to decrease the count by one. So this is the scale-down option. So I have a scale out and a scale in for this rule. And we can say, remember, we have a standard plan for up to ten instances. And so let’s say we want the default E three, and we want it to go between one and five. So if I say we’re going to end up with three instances, it will go down to two, then down to one, and then put that.
So the way you can tell the number of instances that are running or on the ScaleOut screen, it’ll take the current state as “three instances here.” I can actually go to the overview screen. I can see it’s now down to two. So remember, we have an auto-scaling plan. That is, the system will evaluate its utilisation every five minutes, and you should subtract one. So, if I wait another few minutes, this pair will be reduced to one instance. And if I go back down to scale out, we can see that the three became a two. So this rule is basically going to kick in and bring the instances back down to one. So it’s working the way that we intended. This basically shows that auto scaling is available on standard and higher. And this is the other way of scaling compared to just moving to a bigger service plan. You.
