Ops / IT Pro
The course is part of these learning paths
There's a lot of effort that goes into keeping our applications available, and secure. That's why so many cloud vendors offer platforms for hosting web-based applications. If you're building web apps, APIs, mobile backends, or business processes then you should consider looking into App Service! App Service has a lot of functionality. It meets compliance standards from around the world, it's highly scalable, it supports multiple languages and makes it easy to get your code deployed.
This Getting Started with Azure App Service course it's basically an intro, but for developers and IT Pros. In this course, you'll learn about the features of App Service at a high level as well as for each component. Then you'll learn about each of the 4 components of App Service through some demos. If you're a developer or IT Pro working with Azure, but new to App Service, this course is for you.
This course will help get you up-to-speed on App Service so that you can start developing / managing apps.
Getting Started With Azure App Service: What You'll Learn
|Lecture||What you'll learn|
|Course Intro||What to expect from this course|
|App Service Overview||A high-level overview of App Service|
|Web, Mobile, API App Overview||A high-level overview of Web, Mobile, API Apps|
|Logic App Overview||A high-level overview of Logic Apps|
|Mobile Apps: Easy Tables||How to use Easy Tables as a "no-code" option|
|Mobile Apps: Client||Running the client code from an iOS simulator|
|Mobile Apps: .NET Backend||Using a .NET backend|
|Mobile Apps: Auth||Using authentication with App Service|
|API Apps||Creating API Apps|
|Logic Apps||Automating business processes|
|Web Apps||Authentication and remote debugging|
|Deployments||Deployment slots and GitHub based deployments|
|Monitoring and Logging||Monitoring and logging options|
|Scaling||Scaling up and out|
|Next Steps||What's next|
Welcome back! In this lesson we’re going to cover scaling up and out, and auto-scaling.
When it comes to scaling with App Service, the scaling happens at the Service Plan. All of your apps in the same plan will share resources, so if you’re running a lot on let’s say a single S1 instance, then you’re likely to run out of system memory. Luckily it’s easy to scale up by changing the service plan. At the different tiers, service plans offer more functionality. And inside a tier, you can select a different SKU that will determine the available resources.
If you need to scale up then it’s as easy as changing the service plan, and you can do that by selecting the aptly named “Scale Up” option. Notice here that the tiers determine things such as how many deployment slots you have, how much storage space, if you can integrate traffic manager or not, among other settings.
To scale up, just select the tier and sku, and click okay. It’s that simple.
Scaling out on the other hand, while also simple, has more functionality. To scale out, you use the Scale out option. There are currently 3 options, the first is the option to manually set the number of instances you want to use. This works fine for very predictable workloads, especially internal applications. However your app may not have such predictable traffic, and if you don’t want to be woken up at 3am to add more instances, then you’ll want to consider auto-scaling.
Auto scaling allows you to use rules to determine when to add and remove servers. Because scaling based on the CPU usage is common, Azure has this option here to set the allowed instance range, and then the target CPU scaling range.
The instance range allows you to determine a minimum number of servers, and then the maximum that can be added by the autoscaling. The target CPU range is a bit ambiguous here, but it works by removing an instance when the average of all the instances are below the minimum, and adding an instance when the average hits the max value.
Besides this, there’s another option that allows for more robust functionality, which is the schedule and performance rules. This allows you to really setup rules that work for your workloads.
To setup performance rules you can click this add rules link and it’ll open a new blade. There are options for the resource the rule will apply to besides the service plan. For example, It could be that you want to add new instance based on the amount of messages in a queue, however we’ll focus on the service plan.
Like with the alerts we have options for the metric we want to use. Let’s set this rule for memory percentage.
Then we can change the operator, however I’ll leave this to greater than.
The threshold is the memory percentage which I’ll set to 50%.
I’ll set the duration to 5 minutes which is the lowest value you can use.
The action will be to increase the instance count by 1, with a 5 minute cool down so it’s not adding instance before the new instance has had a change to help out.
And we could add another rule to decrease the number of instances too, so let’s just add another rule.
Let’s set the action to decrease instance count, and the value will stay set to 1. I need to set the metric to memory, and then change the operator to less than or equal, with a threshold of say...30. And I’ll set the duration to 5 minutes.
So far these rules apply to this service plan, however it could be that you have certain days of the week that you want different rules. For example, maybe on the weekends you don’t want your internal company app to scale up at 65% CPU, because only a few people use it. So maybe you want different weekend rules that scale it up at say 85%.
That’s where scheule profiles are for. If you click on the Add Profile option, you can use the always option, the recurrence which is for recurring schedules, or fixed dates for a specific date.
Once you set up a profile, you could then add rules under it that are specific to that schedule.
Okay, scaling is important, though, I suspect if you’re watching this course, I don’t need to tell you that. App Service makes it easy to scale up and out, which is one of the best parts of using cloud based solutions.
Alright that’s going to wrap up this lesson, in the next lesson we’ll talk about next steps.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.