Azure App Services is one of Azure's oldest services. In fact, it is considered to be Azure's original PaaS service. There is a lot going on under the hood with App Services, and that's what I'd like to discuss here.
Since it is a PaaS service, a lot of the underlying infrastructure is abstracted away from you. However, I feel its still important to know what's happening under the hood as it gives you a better idea of the service.
Note: This article will focus solely on the Multi-tenant (shared) App Services architecture. I will not be covering anything about the Single-tenant (private) App Services Environment (ASE) architecture.
High-level Architecture
App Services runs on a whole lot of VMs. The VMs are grouped together into what's called a "Scale Unit" (aka "Stamp"). Each Scale Unit can be comprised of thousands of servers. Each supported Azure Region contains multiple Scale Units.
The servers inside each Scale Unit are comprised mostly of Worker nodes, which are the servers that actually run your applications. But, each Scale Unit also includes other various types of servers that provide support services which are required for App Services to run. More on these support servers below.
There is one more component that I'd like to discuss in this high-level section and that is the Geo-Master. This is a component that holds information about every Scale Unit across every Azure Region worldwide. It is responsible for forwarding control plane (management) requests to the necessary Scale Unit. For example, say you created a brand new App Service in the Azure Portal. The request would eventually make its way to the Geo-Master. The Geo-Master would decide the best Scale Unit to use for the new App Service, and then forward the request directly to that Scale Unit.
Scale Unit Deep Dive
Pictured below is an example of a single App Service Scale Unit. You'll see it shows the worker nodes, as well as the various different support services, and finally, I threw in some networking IP addresses as well. Let's go over each component in more detail.
API Controller servers
Remember the Geo-Master component that we talked about earlier? When the Geo-Master needs to talk with a particular Scale Unit, it will talk to the API Controller servers inside that Scale Unit. The API Controller servers are the ones that actually perform any management actions against your App Service.
Front End servers
This is a load-balancing layer that distributes incoming HTTP requests to the backend Worker servers. Each Scale Unit has 1 shared Virtual IP Address for all incoming requests to all Apps hosted on this Scale Unit.
Workers
The Worker servers are what actually run your application. The Worker servers make up the majority of the servers in a Scale Unit. The way you interact with the Worker servers is by way of an App Service Plan. When you create an App Service Plan it defines multiple things:
The Operating System of the Worker servers (Linux or Windows)
The Azure Region where the Worker servers will reside
The pricing plan (free, shared, basic, standard, premium).
The pricing plan you pick is very important as it controls a lot of important settings, such as the following:
If your Apps are on shared Workers (they run apps from multiple customers), or if your Apps are on dedicated Workers (they run only your apps)
The specs (CPU/RAM) of the Worker servers
The maximum amount of storage your Apps can use
The maximum amount of Worker servers that you can scale out to (1, 3, 10, or 30)
Many more settings, including support for custom domains, support for autoscaling, support for Private Endpoints, and support for Virtual Network integration, to name a few.
File servers (and Azure Storage)
An App hosted on App Services will store its artifacts (html files, js files, images, etc.) in Azure Storage Blobs. However, the Worker servers don't interact directly with the Azure Storage. Instead, the Azure Storage Blobs are mounted to the File servers, and the Worker servers access the files by talking to the File servers. Any read or write operation performed by the App will go through the File servers.
Data Role servers (and Azure SQL Database)
Each Scale Unit utilizes Azure SQL Database to store various bits of data about every App running in that Scale Unit. This data is needed by many of the servers in the Scale Unit. The Worker servers need site configuration info, the Front End servers need to know which Apps are on which Worker servers, the API Controller servers need to read and update data in the database based on management actions you take. None of the servers access the SQL Database directly. Instead, they talk to the Data Role servers, which act as a caching layer for the database.
Publisher servers
The Publisher servers expose FTP functionality for your App. This allows you to use FTP to access your App's files and logs. You can also deploy your App using FTP, if you wish.
Outbound IP Address Pool
Each Scale Unit has a pool of Public IP Addresses that the Worker servers will use when they need to make an outbound connection. The IP that is used is picked randomly from the pool at runtime. The list of IP's in the pool can change over time, and in certain circumstances it can even change if you switch to a different pricing plan for your App Service Plan. Using the Azure Portal, you can view your App's full list of outbound IP addresses.
I'll quickly mention that certain Pricing Plans (basic, standard, premium) support Virtual Network Integration. This means your Worker servers will live in a dedicated Subnet inside your own Virtual Network. This allows the Worker servers to use private outbound connections to any other resource in your Virtual Network or connected to your Virtual Network (peerings, gateways, express routes). For outbound connections to the internet, the Worker servers will still use an IP from the Public IP pool mentioned above, by default. However, the VNet Integration feature lets you modify this behavior, by using either a NAT Gateway or a custom route to an NVA.
So that was a very quick deep-dive into the App Service Multi-tenant architecture. There are a few pieces of the architecture that can be configured for dedicated use, however, the majority of the architecture is still shared.
In a future article, I may discuss the Single-tenant option which is called App Service Environment (ASE). The ASE allows you to host all of the components of an entire Scale Unit inside your own private Virtual Network. In other words, no shared services! Stay tuned.