Exploring Azure App Service
Azure App Service is an HTTP-based PaaS service on which you can host web applications, RESTful APIs, and mobile backends, as well as automate business processes with WebJobs. With App Service, you can code in some of the most common languages, including .NET, Java, Node.js, and Python. With WebJobs, you can run background automation tasks using PowerShell scripts, Bash scripts, and more. With App Service being a PaaS service, you get a fully managed service, with infrastructure maintenance and patching managed by Azure, so you can focus on development activities.
If your app runs in a Docker container, you can host the container on App Service as well. You can even run multi-container applications with Docker Compose. We’ll cover containers and Docker in Chapter 3, Implementing Containerized Solutions. The previous chapter, Chapter 1, Azure and Cloud Fundamentals, mentioned that App Service allows you to scale, automatically or manually, with your application being hosted anywhere within the global Azure infrastructure while providing high-availability options.
In addition to the features covered in this chapter, App Service also provides App Service Environments (ASEs), which offer a fully isolated environment for securely running apps when you need very high-scale, secure, isolated network access and high compute utilization.
From a compliance perspective, App Service is International Organization for Standardization (ISO), Payment Card Industry (PCI), and System and Organization Control (SOC) compliant. A good resource on compliance and privacy is the Microsoft Trust Center (https://packt.link/S4bsb).
App Service also provides continuous integration and continuous deployment (CI/CD) capabilities by allowing you to connect your app to Azure DevOps, GitHub, Bitbucket, FTP, or a local Git repository. App Service can then automatically sync with code changes you make, based on the source control repository and branch you specify.
App Service is charged according to the compute resources (the VMs behind the scenes on which your apps run) you allocate for your apps. Those resources are determined by the App Service plan on which you run your applications. App Service apps always run in an App Service plan, so this seems like the logical point at which to introduce App Service plans.
App Service Plans
If you’re familiar with the concept of a server farm or cluster, where a collection of powerful servers provide functionality beyond that of a single machine, App Service plans should make sense (in fact, the resource type for App Service plans is Microsoft.Web/serverfarms). As briefly mentioned before, an App Service plan defines the compute resources allocated for your web apps. The plural context is used because, just like in a server farm, you can have multiple apps using the same pool of compute resources, which is defined by the App Service plan. App Service plans define the operating system of the underlying VM(s), the region in which the resources are created, the number of VM instances, and the pricing tier (which also defines the size of those VMs).
As you might be used to by now, some pricing tiers will provide access to features that aren’t available in others. For example, the Free and Shared tiers run on the same VM(s) as other App Service apps (including other customers’ apps) and are intended for testing and development scenarios. These tiers also allocate resource quotas for the VM(s), meaning you can’t scale out and you only get a certain allowance of minutes each day during which your app can run and use those resources. All remaining tiers other than Isolated and Isolated v2 have dedicated VMs on which your apps can run unless you specifically place multiple apps within the same App Service plan. The Isolated and Isolated v2 tiers run on dedicated VMs, but they also run on dedicated Azure virtual networks (VNets), providing network and compute isolation as well as the maximum scaling-out capabilities. Azure Function apps also have the option to run in an App Service plan, which will be explored in Chapter 4, Implementing Azure Functions.
A common misunderstanding is that you need to have one App Service plan per App Service. This is not always necessary (you can’t mix Windows and Linux apps within the same App Service plan, so you’d need multiple plans if you have that). Remember that an App Service plan defines a set of resources that can be used by one or more applications. If you have multiple applications that aren’t resource intensive and you have compute to spare within an App Service plan, by all means, consider adding those applications to the same App Service plan.
One way to think of an App Service plan is as the unit of scale for app services. If your App Service plan has five VM instances, your application(s) will run across all five of those instances. If you configured your App Service plan with autoscaling, all the applications within that App Service plan will scale together based on those auto scale settings.
One final point to note is that once you create an App Service plan, you are allocating those VM instances and are therefore paying for those resources regardless of how many App services are running on the plan. Even if you do not have any App services running on an App Service plan, you still have to pay for the allocated resources. If you scale the App Service plan out (horizontally), you are increasing the number of VM instances, which will cost you more because you are allocating more VMs.
Within the Azure portal, App Service plans are described as representing the collection of physical resources that are used to host your apps:
Figure 2.1: The Azure portal description of App Service plans
