YouTube Summarize
Open YouTube

Configure Azure App Service plans | AZ-104 | Episode 22

autoenpublicupdated

Introduction to App Service Plans

  1. App Service plans and App Services are part of Azure platform as a service and can help organizations move application hosting responsibilities to the cloud.
  2. An App Service plan is the parent object, while App Services are separate child resources that run inside the plan.
  3. The plan controls the shared resources, performance, price, and available features for the App Services it contains.

PaaS Infrastructure Model

  1. Unlike virtual machines, where administrators build, patch, and maintain operating systems, App Service plans use Microsoft-managed infrastructure.
  2. Microsoft maintains prebuilt Windows and Linux hosting environments, so organizations can focus on deploying applications and consuming allocated resources.
  3. Apps can run in protected memory on shared or dedicated infrastructure, with allocated CPU and memory guaranteed by Microsoft.

Pricing Tiers and Features

  1. App Service plan tiers differ by resources, pricing, and features such as autoscaling and deployment slots.
  2. Free, Shared, and Basic plans do not include deployment slots; Standard supports up to five, while Premium and Isolated support up to twenty.
  3. Autoscaling is not available in Free, Shared, or Basic tiers, but is supported in Standard, Premium, and Isolated tiers.

Scaling Concepts

  1. Scaling up or down changes the amount of CPU and memory, while scaling out or in changes the number of running instances.
  2. Autoscaling uses rules and conditions based on metrics such as CPU utilization, network throughput, disk capacity, scheduled time periods, or application metrics.
  3. Microsoft recommends having at least one scale-out rule and one scale-in rule so resources can both expand and contract.
  4. Scaling conditions include minimum, maximum, and default instance values, and scaling never goes below or above those limits.

Autoscale Rule Behavior

  1. Multiple scale-out conditions can be configured, such as increasing by a fixed count or by a percentage; Azure chooses the result that avoids under-provisioning.
  2. Cooldown periods prevent immediate repeated scaling decisions and allow the environment to stabilize before another evaluation.
  3. Poorly chosen scale-in and scale-out thresholds can create a race condition where scaling in immediately triggers scaling out again.
  4. When multiple scaling conditions are evaluated, the condition that results in the largest number of required resources is selected.

Portal Configuration

  1. An App Service plan can be created before deploying an App Service or created during App Service deployment.
  2. Creating a plan requires selecting a subscription, resource group, plan name, operating system, region, and pricing plan.
  3. Pricing plan details show allocated vCPUs, memory, remote storage, scaling availability, backups, and deployment slot support.
  4. App Services require globally unique names and must use supported runtime stacks such as .NET, ASP.NET, Java, Node, PHP, or Python.
  5. Runtime choice determines whether the App Service must run on Windows, Linux, or either platform.
  6. App Service plans are regional resources; apps deployed to another region require an App Service plan in that region.

Closing Summary

  1. App Service plans reduce the need to deploy, maintain, secure, and patch operating systems for application runtime environments.
  2. The module concludes that App Service plans can reduce operational cost and overhead while supporting enterprise applications and data.

Actiepunten

  1. Get operating system and runtime requirements from application developers before configuring the App Service plan.
  2. Watch the related video for the detailed scaling and deployment slot demonstration.
  3. Continue learning by watching other course videos or exploring Microsoft Learn.