Ops / IT Pro
Please note: An updated version of this course is available here.
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’ll go through the features of Web, Mobile and API Apps at a high level. The best place to see all of the features is the portal. So let’s jump right into the portal, where I already have a Web App created.
Starting off on the overview tab you can see some basic info such as the URL to the app, the status, which in this case is “Running,” and then there’s some basic monitoring info showing requests and errors.
Clicking on the URL shows the default Azure supplied application. There’s not all that much to the default app, it’s just a placeholder until you deploy your first app.
Next up are the common options, which are the Activity Log, IAM, Tags, and the Diagnose problems blade.
Under the deployment section is the quickstart blade, and this is possibly one of the few, maybe the only blade that’s different between web, mobile and API apps. For web apps, this is going to point you to some info on how to get started the different supported tech stacks.
Next up there’s the deployment credentials where you can set the username and password for FTP based deployments. You can use FTP as one of the supported deployment options, and this is where you’d set the credentials.
The next blade is for deployment slots which is an interesting feature. Deployment slots allow you to have multiple versions of your app running, and then swap them out with the version running in other slots. Even if you haven’t created a deployment slot, you still have the production slot, which always exists, and doesn’t show under deployment slots.
Here’s a crude example of how deployment slots work, you could have a staging slot and the default production slot. You can deploy new code to the staging slot, and once you’re ready you can swap it with what’s in production. The swap will move the code and some settings into production. If there’s a problem then you can swap the environments back, allowing for a fast rollback.
The next blade is where you can configure the deployment options. Web, Mobile and API apps allow you to select from different ways to get your code deployed. We looked at the FTP option a few moments ago, here are a few options.
There are a couple of cloud storage options such as OneDrive or DropBox. Now, maybe you have some sort of production pipeline that actually stores your build artifacts on one of these options, however, this isn’t a deployment option I tend to see used outside of demos.
That being said, the rest of the options are source control systems. Using a source control system will allow you to have whichever branch you want be deployed whenever a commit happens.
Okay, on the next blade we have the Continuous Delivery options. If you’re not familiar with continuous integration, continuous delivery or continuous deployment, check out some of my previous courses on CI and CD to get a more complete understanding; however for now, I’ll say that continuous delivery is the pipeline that starts with source control, and after a commit has been made the code is automatically built and tested. This includes unit and integration tests, and then after the tests have passed the code is the ready to be delivered to some environment for functional and nonfunctional tests that aren’t really suited to be automated.
So you may be wondering what this provides that you can’t do with the deployment sources and deployment slots, and the answer is more complete testing. Now you can perform some limited testing by using Kudu scripts when deploying from source control. However, a solid continuous delivery pipeline should have the ability to run all of the automated tests, and fail the build if the tests don’t pass. It also have a dashboard that allows stakeholders to see the state of a build; as well as send notifications when a build fails.
This is going to add a lot of value to App Services once it’s out of preview. However until then you’ll want to think about incorporating your existing CI server into App Service. If you’re using something like Octopus then you already have integration between your CI server and App Service.
Next up is the App Settings blade, this is where you can adjust the languages and versions used, as well as setting up things such as remote debugging.
As I scroll down you’re probably going to start to see some familiar sections such as App Settings and connection strings. Then the typical default document precedence order for the home page.
At the bottom there are options for handlers, which allow you to set the default handlers for specific file types. And then there’s the virtual directories, so if you’re familiar with IIS then you know that this will allow you to have another app running under a virtual directory. For example you could run another app that’s accessible under /customers.
The next blade is to enable authentication and authorization, which will allow you to use Azure AD, or social identity providers such as Google, Twitter, etc.
Next up is the backups blade, which allows you to backup your app on some schedule, or just whenever you click the backup now button. And backups aren’t useful if you can’t restore them, so there’s also a restore now option.
Next is custom domains. This is where you can configure your domains to map to your app.
Next is the SSL certs, which will allow you to make sure your traffic is encrypted.
Then there’s the networking blade which has options for putting the web app into a vnet. One of the use cases would be so that you access on-prem data in your web app, if you’re using a site-to-site VPN.
Alright the next two blades are where you’d go to scale up and out. These configure the App Service plan. When it comes to scaling up you only need to select a new services plan that provides more resources.
For scaling out you have some options to either manually scale, or scale based on some metrics. Since scaling based on high CPU is common it’s an option that’s broken out into it’s own option. The third option is the schedule and performance option, which would allow you to adjust the scaling options based on some schedule. We’ll go into this more later in the course, so don’t worry if you don’t understand it all now.
The next option is a third party security scanner.
After that is the WebJobs blade which allows you to run code that doesn’t need to be triggered by a web request. This can be useful for long running tasks, or for tasks that do some sort of scheduled data import or export. WebJobs allow you to upload your code and then determine when it should run. We’ll see an example of this later in the course.
Next up is the Push notifications which are based on Notification Hubs. This is more useful for mobile apps than web apps.
Next there’s the MySQL option, which is a cool feature for development. It allows you to have a MySQL database running on a single instance. This can be used while in development, and then you can export your database so you can import it into a production ready MySQL database.
If we jump down to the Development tools, you can see we have some interesting sounding options. The first allows you to clone an app if you’re using one of the Premium plans.
After that is the console, which gives you a sandboxed commandline. This gives some lower level access even though the underlying servers are managed.
The next blade takes you to one of my favorite features, which is Kudu. Now Kudu could be a course on its own, so this isn’t going to be a full explanation. Kudu is the engine that is used for git deployments as well as running webjobs, among some other features. It also allows you to get a glimpse into the underlying system. It also has a PowerShell terminal that allows you to interact with your code; and it also has a simplistic code editor. These are good for some pre-production work, as well as debugging. You can also use Kudu to manage site extensions, which allow you to add new functionality to your apps.
The next blade is the App Services editor, which is a web based code editor. Just like what’s in Kudu, this is good for debugging or pre-production systems; however, I’m sure I don’t need to tell you not to edit code in production...right? No...I can tell, you wouldn’t do that!
The last feature under Development tools that I want to show is the Testing in production option. What this does is allow you to do a canary deployment, which is where you deploy the latest code to a small group of users so you can monitor it for errors.
Okay, next up is the mobile features. The first is the easy tables, and this allows you to manage a table that resides in an already existing SQL database. This is used as a mobile backend database. Easy tables are the “no-code” or “minimal-code” way to get a REST API in front of a simple SQL table. Behind the scenes this deploys a simple Node.js app. If you want to use .NET for your back-end app then you’ll need to deal with the database and schema migrations yourself. The currently recommended way with .NET being to use EF migrations.
Then there’s the easy APIs which are used to allow you to wire up REST API calls to interact with your tables.
Data connections defines the connections to your SQL databases.
The next section is for APIs, which allows you to specify the path to a Swagger definition file. That allows your APIs to be discovered.
Under the API section is a CORS section too, which allows you to specify which domain’s requests are allowed.
The final section is for monitoring options. This is an important set of features because if you don’t know how your app is performing, then you can’t make informed decisions.
First up is Application Insights which provides a lot of data about how your application is performing. This is a service that I highly recommend due to the amount of functionality it offers. It’s an application performance management tool with the ability to run interactive queries and even easily create charts and graphs. There’s enough to say about Application Insights that it could be a course on its own. However, for now, just know that it’ll allow you to understand how your app is performing, and how users are interacting with it.
Next is the alert blade that gives you the ability to create alerts based on metrics. For example if you wanted to know if your CPU hits over 70% for the last 5 minutes, you could do that.
And then there’s the log data, which is important, however not all that interesting to look at in this example.
So, overall these are the features of Web, Mobile and API apps. However we still haven’t looked at Logic apps, so let’s see what they have to over at a high level in the next lesson.
Alright, if you’re ready to keep learning then I’ll see you in the next lesson!
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.