Compute & Hosting Models

Question 1. What is Azure App Service and what does an App Service Plan actually determine?

Answer

App Service is a fully managed PaaS for hosting web apps, REST APIs, and background jobs (WebJobs) without managing servers — it handles OS patching, load balancing, and scaling. You deploy code or containers and Azure runs them. An App Service Plan is the underlying compute: it defines the region, VM size/SKU (tier), and instance count, and is billed regardless of how many apps run on it. Multiple apps can share one plan (sharing its CPU/memory), so plan sizing is a cost/performance lever. Tiers range from Free/Shared (dev) through Basic, Standard, Premium v3 (production, more memory/features), to Isolated (App Service Environment — dedicated, VNet-injected).

Analogy

The App Service Plan is the apartment building you lease (size and number of floors); your apps are tenants sharing it. You pay for the building whether one tenant lives there or ten.

Question 2. How do deployment slots work, and why are they a safer way to release?

Answer

Deployment slots (available in Standard and above) are live, addressable copies of your app — e.g. a staging slot alongside production. You deploy to staging, warm it up, run smoke tests, then swap: Azure exchanges the slots so staging becomes production with no downtime and instant rollback (swap back). During swap the platform pre-warms the target so the first request isn't cold. Settings can be marked slot-specific (sticky) so connection strings or feature flags don't follow the swap. This enables blue-green deployments natively, and you can route a percentage of traffic to a slot for canary testing.

Example

az webapp deployment slot swap \
  --resource-group rg --name myapi \
  --slot staging --target-slot production

Analogy

It's a revolving stage: you set up the new scene backstage (staging), then rotate it into view (swap) with the audience never seeing a gap — and you can rotate back instantly if a prop falls over.

Question 3. How do you scale App Service, and how does autoscale differ from manual scaling?

Answer

Scale up/down changes the plan tier (more CPU/RAM per instance) — vertical. Scale out/in changes the instance count — horizontal, the usual lever for load. Manual scaling fixes the count; autoscale (Standard+) adjusts it against metric rules (CPU %, memory, HTTP queue length) or a schedule, within min/max bounds.

Configure autoscale to scale out aggressively, in conservatively (with cooldowns) to avoid flapping, and always set a sensible max to cap cost. Because instances are stateless and load-balanced, store session/state externally (Redis, DB), not in memory.

Analogy

Scale up is a stronger engine; scale out is more identical cars; autoscale is cruise control that adds or drops cars automatically based on traffic, between a floor and a ceiling you set.

Question 4. Give a decision framework for choosing among App Service, Functions, Container Apps, AKS, and ACI.

Answer

Match the workload's shape to the platform. App Service for traditional always-on web apps/APIs you deploy as code. Azure Functions for event-driven, bursty, serverless work with rich triggers/bindings. Container Apps for containerized microservices and event-driven workers wanting serverless scaling (incl. scale-to-zero) without managing Kubernetes. AKS when you need full Kubernetes control (operators, custom networking, service mesh). ACI for simple, short-lived, or burst single-container jobs. Axes that decide it: code vs container, always-on vs scale-to-zero, event-driven vs request/response, and how much infrastructure control you want. Most greenfield .NET work lands on App Service (web), Functions (events), or Container Apps (containerized services).

Example

Traditional web app / API (code) ...... App Service
Event-driven, bursty, triggers ........ Functions
Containerized microservices/workers ... Container Apps
Full Kubernetes control needed ........ AKS
One-off / burst single container ...... ACI

Analogy

It's choosing transport: App Service is a company car (always parked, ready), Functions are taxis (summoned per trip), Container Apps is a managed car fleet you spec yourself, AKS is owning the whole garage, ACI is renting one car for an hour.

Question 5. What is Azure Container Registry (ACR) and how does it fit a .NET container pipeline?

Answer

ACR is a managed private Docker/OCI registry for storing and distributing your container images and Helm charts, close to your Azure compute. CI builds an image and pushes it to ACR; App Service, Container Apps, or AKS pull from it using a managed identity (no registry passwords). It supports geo-replication (Premium), content trust, vulnerability scanning (via Defender), and ACR Tasks to build images in the cloud. Use AcrPull RBAC + managed identity for keyless pulls, tag images immutably (e.g. by build SHA), and enable retention policies to clean old images.

Example

az acr build -r myregistry -t api:$(git rev-parse --short HEAD) .

# Container App pulls via managed identity (no admin creds):
az role assignment create --assignee <app-mi> \
  --role AcrPull --scope <acr-resource-id>

Analogy

ACR is your private warehouse for shipping containers sitting next to the loading dock (your compute), so deployments grab images from across the yard instead of across the ocean.

Question 6. When would you still reach for Virtual Machines or Scale Sets instead of PaaS?

Answer

Choose IaaS (VMs / Virtual Machine Scale Sets) when you need full control of the OS and runtime, must run software PaaS can't host (legacy services, specific drivers, custom networking/ports), require lift-and-shift of an existing server, or have licensing/compliance constraints that demand OS-level access. VMSS adds autoscaling and load balancing over a fleet of identical VMs for large, customizable horizontal scale. The trade-off is operational responsibility: you own patching, hardening, and availability. Prefer PaaS/containers unless a concrete requirement forces IaaS — it's the most control but the most work.

Analogy

PaaS is renting a serviced apartment; a VM is buying a house — total freedom to renovate, but you fix the roof, mow the lawn, and call the plumber yourself.

Question 7. What is WebJobs and how does it relate to Azure Functions?

Answer

WebJobs is the background-processing feature of App Service — it runs scripts or programs (continuous or triggered) in the context of a Web App, sharing its plan. Azure Functions is actually built on top of the WebJobs SDK, generalizing it into a serverless, trigger/binding-rich, independently scalable service. Use WebJobs when you already run an App Service web app and want a simple co-located background task on the same plan. Prefer Functions for anything needing independent scaling, the full trigger/binding ecosystem, or scale-to-zero economics.

Analogy

WebJobs is a side task you give your existing employee (the web app); Functions is hiring specialized on-call contractors who scale up and down on their own.