This course provides the practical knowledge and expertise you will need to master the Design an Application Storage and Data Access Strategy section of the Microsoft Azure 70-534 certification exam. In this session, we will cover: Options for data storage, mobile application back-ends, push notifications, web API and web jobs and hybrid data access patterns. We will also discuss Azure Media Services (streaming, video on-demand and monitoring).
Welcome back. In this lesson, we're gonna talk about Web API and WebJobs.
Web API is a framework that allows us to create RESTful endpoints that we can use for just about any client we want. Let's jump right in and see how we can create and deploy a basic Web API shell. We're gonna start out in Visual Studio, and let's create a new web project. We'll give it a name and click Next. Alright, here we're going to select the Web API template. And we'll click Next again, and then it offers to create an app service for us inside of Azure. However, we already have one, so we're gonna click on Cancel. And the project will take just a moment to get everything configured. When it does, we can check out the values controller, which is a Web API controller.
Okay, here we are. Notice we have methods for common HTTP verbs. We have GET, POST, PUT, et cetera. So now if we compare this to an MVC controller, you can see that there's a bit of a difference there. Let's change the strings here that will be returned from our LIST and GET BY ID methods. And we'll change this one. Okay, great. Now let's start this up and test it out locally. It's gonna take just a moment to load.
Okay, there it is. Now we can see the results of our MVC home controller, though what we're interested in is our JSON API. So for that, let's fetch the results with PowerShell. We're gonna run the Invoke-RestMethod. And the first endpoint we'll hit is the LIST endpoint, and you can see that it's returned the Web API and Azure values. Now if we append a number to the end of the URL, we're going to see the string of Web API and Azure. And if we change the number again, we get the same string. Now remember, this is just a demo, so that ID that we passed in really doesn't correspond to anything, so it has no bearing on the results.
Now let's get this running inside of Azure. So we're going to right-click on the project and select Publish, and we need to import the publishing profile that I downloaded before the video started. Okay, if you wanted to download this for yourself, you can do that by clicking Download Profile in the Cloud Explorer pane. Now I need to verify the connection. And there we go, it's perfect. Everything looks good, so let's deploy.
What this is doing is packaging up the app, which basically means it's compiling it and putting the results in a ZIP file. Okay, now with this running in Azure, let's go back to our PowerShell, and we're gonna change the URL in our tester to see if we get the same results. And there they are. So Web API is a framework for creating REST-based APIs rather easily. Just about every device can speak HTTP, and that means we can integrate with just about everything.
Now when it comes to locking down our APIs, we can use Azure Active Directory for authentication should we need to, as well as our on-premises version of AD with AD Federation Services. And you can also use ACS. However, that was deprecated, and Microsoft's kind of rolled that functionality into Azure AD. So it's a versatile way to create APIs, and because we're running in-app services, we can scale up and out easily by increasing the size of the VM or adding additional VMs to handle the load.
Let's talk about scaling a bit more. Azure web apps provide multiple ways to scale web applications up and down. Azure web apps can be automatically scaled in or out, meaning the number of instances hosting the web app can be decreased and increased automatically based on a schedule or some metric. Now this enables us to increase the amount of instances during known busy periods for an application and remove those extra instances afterwards.
Though maybe your traffic just isn't that predictable, so for this, you can scale by metric. As an example, maybe the average CPU load. So if the average CPU is at or above 80 percent for more than 15 minutes, you can add another instance to the pool. Auto-scale by metric allows us to scale based on the current environment metrics. These include CPU, memory usage, disk and HTTP queue length, as well as data in and data out.
Metrics are aggregates across all of the running instances hosting our web app, and that's usually the average. And this means that if one has a CPU of 80 percent and another instance is at 20 percent, it's going to use the average of the two. Each scaling rule that we define requires that we choose a metric, such as CPU; a condition, that can be something like greater than or less than; and a threshold, such as a percentage.
You can also specify multiple rules using different conditions and metrics to combine them. To avoid instances being added and removed more often than they probably should be, we can also specify a cool down period when we create auto-scaling rules. And this lets the web app and the associated metrics settle down a bit, and helps to avoid frequent scaling events.
When it comes to scaling up, there are some considerations. An instance size determines the processing power, storage, and memory available to the app. It also defines the features set, such as deployment slots, the maximum number of instances, custom domains, automated backups, among other things. So the choice to scale up or down depends largely on the resources and features that are required. It's important to note that when you change the instance's size, you're changing the instance size for the app service plan rather than the individual app, and that change affects all of your web apps under that plan.
Okay, let's move on to WebJobs. Web API is great for REST APIs. However, it's not great for long-running tasks. And that's where WebJobs come in. A WebJob enables us to perform background processing tasks in an appropriate context. It allows us to run .NET console apps, scripts such as PowerShell or Windows Batch scripts, PHP, Python, and Node, among others. If you need to deploy more files than a single executable or script, you can also zip up all of the content and upload that. And we can deploy it directly from the portal or via FTP, as well as through Visual Studio.
Since you may want to run a job continuously, you can enable the Always On setting, which will avoid disposing of the WebJob while it's running. And while you can use the option to run it continuously, which will kick off the job, say, every 60 seconds or so, if you want the app to truly always run, you're going to wanna manage that with a loop inside of code and then have the thread sleep as needed. WebJobs scale the same way Web API does and run on all the instances deployed from Web API by default. And should you need more processing power, again, you can scale those instances up.
You should consider WebJobs when you have a task that needs to run on a schedule, or a task that will run continuously and will monitor the response to some trigger, maybe something like a file system launcher. Also, any long-running tasks that aren't suitable for short-lived requests, maybe something like a response to a life cycle event in a web app handler. Also, if you'd currently run a task via Scheduled Task on Windows or Cron Job on Linux, then WebJobs are probably the analogous option.
A classic example is a WebJob that retrieves and prepares data for a web app. For example, let's say you have a long-running SQL query that creates a large data set, and instead of having the query being kicked off by your Web API, you could have this WebJob run ahead of time, grab that information and cache it, and then your Web API could pick that up.
Okay, let's create a basic WebJob and then deploy it. We're here in Visual Studio, and we have this console app, and what it does is it outputs a string with the current date and time appended to the end. And that's it, it's nothing fancy. So if we run this locally, and we set this break point, you can see that we have a string. Alright, let's deploy this as a WebJob, and we can do that by right-clicking on the project and selecting Publish as WebJob. Okay, perfect. And now we have options here for how it's going to run. That's gonna be continuously on a schedule or on demand. We'll use the Continuous option, and we're gonna need to import our profile. If we jump into the Azure portal, we can refresh, and in a moment, it's gonna show up.
Alright, we have it here, and if we click on the logs, we can see what it's been up to. This is gonna take a moment to load, but when it does, we're gonna see a log with our output. Now what I'm gonna do is jump ahead to a few minutes from now after it's run a couple of times so you can see what the log looks like. Okay, welcome back. Here we have our log, and we have our strings with the date and time appended to it, and it kicks off every 60 seconds.
Alright, in our next lesson, let's talk about data access strategies for hybrid applications. So if you're ready to keep learning, then let's get started with 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.