Develop Azure compute solutions
Compute options and where they differ
App Service is the default choice for HTTP workloads. The App Service plan is the unit of compute: tier and instance count drive CPU, memory, and features, so two web apps on the same plan share resources. Scale up (change tier) and scale out (instance count, manual or autoscale rules) are different operations. Deployment slots exist at Standard tier and above; a swap warms the target slot, then switches. Any setting marked as a deployment slot setting travels with the slot instead of swapping - connection strings and app settings are the classic trap.
Azure Functions adds a hosting-plan decision. Consumption scales to zero, has a default 5-minute (max 10-minute) execution timeout, and no VNet integration. Premium gives pre-warmed instances, longer timeouts, and VNet. Dedicated (App Service plan) suits an already-underutilized plan. Triggers start execution; bindings are declarative input/output plumbing configured in function.json or attributes.
Durable Functions orchestrate long workflows. Orchestrator code is replayed, so it must be deterministic: no DateTime.Now, no Guid.NewGuid(), no I/O - use context.CurrentUtcDateTime and context.NewGuid(), and put real work in activity functions. The client starts orchestrations; CreateCheckStatusResponse powers status endpoints.
Traps
Consumption for a 30-minute job or VNet access; assuming a swap moves sticky settings; thinking scale-out changes the pricing tier; doing HTTP calls or writing state inside an orchestrator.
Rule of thumb
If the requirement says deterministic, replay, or long-running workflow, think Durable Functions with an orchestrator. If it says "runs 20 minutes" or "must join a VNet", the answer is a Premium plan.