Demystifying Azure App Services
Azure App Services is a platform for hosting web applications and services in the cloud. If your software listens for connections over HTTP/S, then App Services can be your host. App Services is a managed platform, so you don’t need to know a lot to get started. But, like everything in software, the more you know about a technology, the more effective you can be with the technology. In this first article of a series dedicated to learning more about App Services, we’ll be talking about the physical characteristics of App Services. I assume you already know some of the basics about App Services, so we will jump into more advanced topics.
Every App Service in Azure requires an App Service plan. We will talk about plans in more detail in a future article, but you can think of a plan as the virtual server you’ve reserved inside of Azure to run your app. A plan can also reserve multiple servers, if your application is busy enough to require multiple instances. Because a plan reserves one or more servers, you need to specify an Azure region for each plan. The region could be South India, or West US 2, or any one of the 54 regions Azure currently makes available across the globe.
Inside each Azure region is a data center with one or more App Service scale units inside. A scale unit is a cluster of servers dedicated to a specific role, like running App Services, or running Azure Storage. Microsoft also uses the term “stamp” to refer to a scale unit, as in an “App Service stamp”. Every stamp will have some set of servers dedicated to administrative tasks, like providing internal API endpoints for management, or offering public FTP endpoints for publishing apps, or providing resources for storing and caching your configuration data and coordinating with Azure SQL. These administrative jobs are all automatic and nothing we need to worry about. From our perspective, there are only two important server roles inside of each scale unit.
The first significant role is the web worker role. A server in the worker role is dedicated to run customer applications. So your apps, and my apps all run on these workers. Not surprisingly, most of the servers in a scale unit are in the worker role. The second significant role is the front-end role. The front end is a layer 7 load balancer that understands the HTTP protocol. The front end terminates SSL connections, routes connections to workers, and provides simple round-robin load balancing when you have multiple instances in a plan.
You should have realized by now that scale units are cost effective at scale because scale units are multi-tenanted. If you want to use App Services to host an application in a highly regulated industry, the thought of having a frontend server terminating your SSL connections and sending your customer’s work into a shared worker pool sounds terrifying. For this reason, Azure offers two types of App Service plans. The first set of plans will use the shared resources describe above. The second set of plans, known as the isolated plans and sometimes referred to as App Service Environments (ASEs), effectively gives you a dedicated scale unit. You’ll pay more for isolated plans, but this is the price to pay for compliance.
When you use the regular app service plans, you can’t pick your neighbors in the same scale unit. But, you can get some idea of who your neighbors are. My site, OdeToCode.com, is hosted in Azure App Services. If I use nslookup to find the IP address for OdeToCode (which you can also reach as odetocode.azurewebsites.net), you’ll find the virtual IP address for the scale unit my site lives in.
If I take the IP address to the website IP Neighbor, I can find over 1,100 other websites hosted at the same IP address. There are probably even more websites than the ones listed here, because many small web sites will front themselves with proxy services like CloudFlare.
Now that we’ve learned a bit about how Azure physically organizes App Services, we can take a closer look at the logical organization of App Services in the next article.