App Service and App Service Plans provide a platform as a service model for deploying applications without managing full Windows or Linux operating systems.
App Service Plans allocate resources, while App Services provide the runtime environments where applications run.
App Services support application types such as web apps, mobile apps, function apps, and logic apps.
Runtime Support and Compatibility
Azure App Service supports current major runtime stacks such as .NET, ASP.NET, and PHP, but older applications may still run if deprecated calls are not required.
Microsoft gives advance notice before deprecating supported runtime versions, allowing time for evaluation or code updates.
An App Service name must be globally unique because it becomes part of a public Azure website URL, though DNS CNAME records can map it to a custom name.
Deployment Slots
Deployment slots are available depending on the App Service Plan tier: free, shared, and basic have none; standard includes five; premium includes twenty.
Slots support common environments such as dev, test, QA, staging, and production, helping move code through release stages.
Deployment slot swapping allows warmed-up code to move into production quickly and be swapped back if problems occur.
Slots can manage environment variables, connection strings, credentials, and identities so settings change appropriately between environments.
Deployment slots support testing approaches such as blue-green testing, A-B testing, and canary testing by routing traffic to specific slots.
Identity, Domains, and Backup
App Services include identity provider integration, including Microsoft Entra ID and third-party identity providers.
Custom domain names can be configured for App Services in addition to the default Azure website domain.
Built-in App Service backup capabilities exist, but they do not replace an organization's own backup strategy.
Scaling App Service Plans
Scaling up or down changes the App Service Plan tier, resources, and available features such as deployment slots.
Scaling in or out changes the number of App Service Plan instances.
Autoscale rules can be based on metrics, operators, thresholds, time windows, cooldowns, minimums, maximums, and schedule-based conditions.
When multiple autoscale rules apply, Azure uses the greatest required instance count produced by the rules.
Slot Swap Demonstration
The demo shows a production slot with one web app page and a staging slot with a Hello World page under the same App Service Plan.
The staging slot is swapped with production, causing the production URL to show the Hello World code without changing the URL.
The swapped slots can be quickly swapped back if needed.
Resource Planning
Multiple App Services can share one App Service Plan, but one app can consume shared resources and affect other apps in the same plan.
When an App Service Plan scales because one app consumes resources, the entire plan scales, including other apps inside it.
In many cases, an App Service Plan should align closely with the App Service it hosts, except when apps need to be deployed together.
Conclusion
App Service Plans provide resources and services, while App Services provide runtime environments and feature sets for modern application development.
App Services can host monolithic applications but are especially well suited for microservice deployments.
Actiepunten
Investigate whether older applications can run on current supported runtimes by testing for deprecated or breaking changes.
Use an organizational backup strategy in addition to built-in App Service backups.
Watch other videos in the course or explore Microsoft Learn at aka.ms/learn to continue learning.
