This is the first post of a series on Azure App Service Architecture. This one introduces the concepts of Apps, and Plans, what are the Pricing Tiers and Instance Sizes. The second post will give some more details on how I understand the service plan are architected. The 3rd post looks at how Microsoft implemented App Service on Linux.
Azure App Services is a Platform-as-a-Service (PaaS) cloud service offering by Microsoft focused on providing superior developer productivity without compromising on the need to deliver applications at cloud scale. It also provides the features and frameworks necessary to compose enterprise applications while supporting developers with the most popular development languages (.NET, Java, PHP, Node.JS and Python). With App Service developers can:
- Build highly scalable Web Apps
- Quickly build Mobile App back-ends with a set of easy to use mobile capabilities such as data back-ends, user authentication and push notifications with Mobile Apps.
- Implement, deploy and publish APIs with API Apps.
- Tie business applications together into workflows and transform data with Logic Apps.
To be able to deploy any App on Azure App Service you’ll need an App Service Plan:
App Service Plans
An App Service Plan represents a set of features and capacity (compute, storage) that you can share across multiple apps. in Azure you deploy a Web App on an App Service Plan, which is formed of one or more (VM) Instance.
App Service Plans are specified by two characteristics:
- The Pricing Tier: from Free, Shared, Basic, Standard to Premium
- The Instance Size: from Small, Medium, Large to Extra Large
The Instance sizes define some compute and storage characteristics of the underlying VM instances that will form the App Service Plan. The CPU and Ram is the same for every Pricing Tier (Basic, Standard or Premium. In Free or Shared you can’t select the Instance Size). Here are the size available at the time of this writing:
The Pricing Tier define some other capacity characteristics as well as features and services that will be available to the App that we deploy in the Plan.
Note that in the Free and Shared tier, the VM Instances are shared in a multitenant fashion (possibly with other customers), while from Basic to Premium tiers, the VM Instances are dedicated.
Internally (in API documentation,…), App Service Plan are actually called “hosting Plan” or “serverFarm”, which reveal the true nature of what they really are.
Deployment model
From a deployment perspective, Apps in the same subscription and geographic location can share a plan. All the apps that share a plan can use all the capabilities and features that are defined by the plan’s tier. All apps that are associated with a plan run on the resources (VM Instances) that the plan defines:
Scalability Up & Out
Scalability of the App Service Plan is achieve either horizontally by adding more VM Instances to the Plan (Scale-Out), or vertically, by changing to a larger Instance Size (Scale-Up).
Scaling-Up is a manual action, which occurs without service impact. Scaling-Out can be done manually, scheduled to happen periodically, or automated based on some performance metrics (from the Plan itself, or other resources like the Storage, Service Bus,…).
I’ve dedicated a whole post to how Azure achieves Scalability of the App Service Plans.
Watch out for my next post where I’ll explain how App Service Plans are architected internally.