CloudAcademy
  1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Getting Started: Azure App Service Web Apps

Introduction to Microsoft Azure App Service

play-arrow
Start course
Overview
DifficultyBeginner
Duration1h 16m
Students334

Description

In this course, we will explore the new Platform as a Service (PaaS) offering from Microsoft Azure, Azure App Service. Azure App Service is a developer focused platform within Microsoft Azure that enables developers to easily build, deploy, and maintain cloud-based solutions that connect web, mobile, and any other devices. We'll explore what it's like to create/deploy/manage web apps from the Azure portal, Visual Studio using the Azure SDK, and how to utilize Microsoft Azure's new ARM Templates to provision an environment.

Azure Web Apps are packed with features, such as continuous deployments, deployment slots, background jobs, remote debugging, and additional monitoring and troubleshooting features. We will also explore code-based demos that showcase the features.

Do you have questions on this course? Contact our cloud experts in our community forum.

Transcript

Hi. My name is Tim Gabrhel. Welcome to the Introduction of Microsoft Azure App Service Web Apps. In this lecture, we will be introducing Azure App Service, detailing what an App Service plan is, what makes a web app, and a legacy platform as a service offering called Cloud Services.

First, what is Azure App Service? Azure App Service is a platform within the Azure environment that enables you as a developer to develop web and mobile applications. There are four key product offerings, web apps for hosting web-based applications, mobile apps for providing cloud-based services to your mobile apps, API apps provide you with a rich set of features on top of your hosted API applications, and logic apps that help you automate business processes and connect to your App Service applications.

Some key features to point out with App Services are multi-language support, such as Microsoft.Net, Node.js, PHP, and Python, continuous deployments with Visual Studio Team Services and Git, fine-grained scaling control, whether it's up or down, and paying for only what you use.

First and foremost, an App Service plan is a set of resources and capacity available to deploy your App Service apps into. These resources are actually virtual machines that have a set amount of CPU and memory. What this means is that you decide how your applications are hosted, grouped together, what resources are available to what applications, how many instances of each application there are, and how much you are charged for them. App Service plans come in five tiers of pricing, Free, Shared, Basic, Standard, and Premium, all varying in their features and capacity offerings.

While you can deploy an unlimited number of applications into an App Service plan, it highly depends on the types of applications deployed and their required resources and CPU utilization. You can use the App Service plan blade in the Azure Portal to visualize your CPU and member utilization to help determine your needs for scaling or moving applications into another App Service plan.

To understand this further, consider a scenario. Start with a resource group in your Azure subscription. Within, you can deploy one or more App Service plans. Within your App Service plan, you can deploy one or more apps into the App Service plan. In this scenario we're allocating two cores, three and a half gigs of RAM to four separate applications. In the other App Service plan, we're providing one single application with double the resources, as we mentioned in the first App Service plan.

If we wanted to deploy a new application, maybe for development and testing purposes, we can do that and have it share the resources with the other four applications. But you'll need to be careful and be sure to keep an eye on the resources available to the App Service plan, as all the applications will suffer in performance.

So what's in a web app? Well, now that we understand what our App Service plan is, let's talk about what web apps are. Start with our App Service plan. If you recall, we just covered that an App Service plan is a virtual machine and its root. Within that virtual machine, our application code is deployed into IIS. Web apps provide other features and resources to use, such as app settings, which allow us to configure settings per application, and web jobs, which allow us to execute background processing operations at scale.

If you scale your App Service plan to contain multiple instances, Azure App Service will manage a routing traffic to your application by way of the load balancer. As the developer, you have the option to enable Round Robin, which means the load balancer routes users based on a load of each virtual machine or with sticky sessions, which are the default. Sticky sessions will return users to the same virtual machine instance for the lifetime of their session. This can simplify your application development and deployment scenarios, as you don't have to manage something like a user's session, such as a shopping cart across postbacks. As a reminder, other App Service apps, such as web, mobile, API, and logic apps are living side by side your web app.

The pace of development and feature iteration of the Azure Cloud has quickened and can be intimidating to new users. It's important to help clarify the offerings and explain some of the overlap when it comes to hosted web and API-based applications.

The Legacy Platform as a service offering from Azure is Cloud Services, which has been around almost as long as the inception of Azure itself. A Cloud Service is comprised of web and worker roles, that is virtual machines that run your web-based applications and a worker role that runs your background-based worker code. The platform offers you access to actually connect to and remote desktop into virtual machines your application is running on. This can be useful to deploy and manage advanced scenarios, such as modifying settings in IIS that web apps don't allow. This model is less cost-effective to deploy multiple applications, as only one web app can be deployed to a web role and only one worker Visual Studio project can be deployed to the worker role. Every new application means another new cost. This model allows more control, but lacks in some features in automation that we'll cover in later sections.

About the Author

Tim is an application developer focused on the Microsoft stack. He has architected and developed enterprise applications with SharePoint, Azure, and more. He has a passion for developing mobile applications on the Windows Platform and and an eye for clean modern design.