Scaling and Resilience
This course will show you how to design and create web applications using the Azure App Service.
By the end of this course, you'll have gained a firm understanding of the key components that comprise the Azure App Service. Ideally, you will achieve the following learning objectives:
- A solid understanding of the foundations of Azure web app development and deployment.
- The use cases of Azure Web Jobs and how to implement them.
- How to design and scale your applications and achieve consistent resiliency.
This course is intended for individuals who wish to pursue the Azure 70-532 certification.
You should have work experience with Azure and general cloud computing knowledge.
This Course Includes
- 1 hour and 35 minutes of high-definition video.
- Expert-led instruction and exploration of important concepts surrounding Azure Web Apps.
What You Will Learn
- How to deploy and configure Azure web apps.
- How to implement Azure Web Jobs.
- Scaling and resilience with Azure web apps.
Hello and welcome back. In this section we'll be covering the topics of WebJobs. WebJobs can be run on-demand, whenever the user triggers them to run manually, or when triggered by an external request, like through the Azure Management REST API. WebJobs can also run continuously, or on a pre-defined schedule. Finally, WebJobs methods can be triggered by external events, such as when a new file is created in Blob storage, or when a message arrives on an Azure cue.
A good example of this is an image processing job, a WebJob method that can be registered to be invoked whenever a new image is uploaded to Blob storage to perform the required image processing. We'll have a look at a similar example in a moment.
The WebJobs software development kit, or SDK, is a .net library that simplifies the creation of common tasks in a WebJob. For example, you can set-up a simple job that will register a method to be invoked when a file is uploaded to Blob storage, just by decorating the arguments of one of the methods using WebJob SDK attributes. The library also contains key classes and methods that you'll be expected to know for the certification exam. This includes JobHost and the run and block method that we'll see in the following example.
This is a simple example of a WebJob that creates a job of a file when the file is uploaded to Blob storage. Firstly, let's look at the main method, the program entry point. We create a new JobHost and invoke the run and block and method. This is the standard way of creating a continuously running WebJob. This is a common block of code that you will see featured in certification material.
Now let's have a look at the static method, copy file. The parameters to this method are decorated with WebJob SDK attributes. The first attribute is BlobTrigger, provided with an argument. This trigger tells the WebJob SDK that we want this method invoked whenever a file with the TXT extension arrives in the files container. The handle to this file is provided to us as a stream named Input. The second argument defines a reference to a Blob in the container named Copies, with the file name being whatever the trigger file name was minus the extension, plus underscore dot TXT. We also receive this Blob reference as a stream in this case.
In this example, we're going to copy the input stream, being the file that has just arrived, to the output stream, being our new file. This is all we had to do to create a simple Blob Copy WebJob. This was a very simple example and you are encouraged to explore the library and functionality provided.
The only thing left to note is the configuration of the storage count that our WebJob will use. WebJob SDK expects two connection strings, Azure WebJob's dashboard, and Azure WebJob Storage, as shown in this example. The connection strings should be configured using the appropriate storage count name and secret count key that you can retrieve from the portal.
With Visual Studio 2013 and Azure SDK 2.4 or newer, it is possible to deploy a WebJob without leaving Visual Studio. Secondly, a WebJob can be deployed alongside a Web App. This can be convenient and simplified deployment, but two things should be noted. Firstly, coupling the WebJob with a Web App can make it difficult to scale these independently. The Web App and the WebJob may have completely different resource requirements, and resource usage patterns, and scaling each optimally becomes difficult if they're deployed together. Secondly, given the different resource usage patterns, it's possible that resource contention issues will occur with the WebJob impacting the functionality of the Web App, or vice versa.
Let's see this in action now in Visual Studio. I'm here in Visual Studio, and we've got a sample project here which we can deploy as a WebJob on Azure. It's really easy to deploy to Azure. All we have to do is right-click on the project, and select to publish as Azure WebJob. When we do this, a wizard will appear and we can select values from some of the selections here available, or some of those will be pre-selected for us. We've made sure that we select the right subscription. When we're ready, we should click publish. We can see the logs as it starts to deploy our service up to Azure. Now it's been published successfully. We can check our WebJobs to see if our WebJob is listed under the WebJobs. As we can see, our sample WebJob has been listed.
WebJobs can run on-demand as described previously. They can run continuously, as we've just covered. They can also be scheduled to run on a specific date and time or at recurring intervals within a specified date range. Jobs that are run occasionally might best be suited for an on-demand schedule. Continuous jobs are best for responding to certain actions, such as Blob file upload in the previous example. However, other jobs may require a specific date and time or interval. For example, a daily housekeeping job that might need to be run during quiet hours to clear out temporary files.
There are two ways to schedule a job. You can edit the WebJob publish-settings.json file directly. Visual Studio provides IntelliSense for this file making it easy. However, a simpler way of specifying the schedule is in the publishing wizard. Here we can see the scheduling wizard when deploying the WebJob for the first time. As you can see, we're able to select the recurrence, start, and end times, time zones, and can pick the appropriate dates from the calendar. Edits in the .json file directly, is fairly straightforward and self-explanatory, though perhaps not as friendly as the wizard. The WebJob publish settings .json is created following the first deployment, based on the schedule input into the wizard. Subsequent deployments use this file and may skip the wizard.
In this section, we covered the topics of creating, packaging, deploying, and scheduling WebJobs. We discussed a type of workloads that WebJobs are built for, in contrast to Web Apps. Most importantly, we touched on the WebJob SDK and demonstrated a basic WebJob creation example, which is a key competency tested on this difficult path. We encourage you to explore the WebJob SDK and get to know the key WebJob building blocks.
Stay tuned for the next section. We'll be discussing how we can scale and make our Web Apps resilient.
About the Author
Isaac has been using Microsoft Azure for several years now, working across the various aspects of the service for a variety of customers and systems. He’s a Microsoft MVP and a Microsoft Azure Insider, as well as a proponent of functional programming, in particular F#. As a software developer by trade, he’s a big fan of platform services that allow developers to focus on delivering business value.