Azure compute: App Service, Functions, Container Apps

Three ways to run a Python service on Azure, and the interview question is always which one and why.

The three options

App Service is the closest thing to “deploy my web app and stop thinking”. It hosts a Python ASGI or WSGI app, terminates TLS, manages certificates, and gives you deployment slots. The AWS analogue is Elastic Beanstalk or App Runner; the mental model is a managed VM you do not log into.

Azure Functions is the serverless option: a handler bound to a trigger, billed per execution, scaling to zero.

Container Apps runs containers on a managed Kubernetes underneath (KEDA for scaling, Dapr optionally) without exposing the cluster. It is where a containerised service goes when App Service is too restrictive and AKS is too much operational surface.

Choosing

• One web app, standard HTTP, no container requirement: App Service.
• Event-driven, spiky, or glue between services: Functions.
• Containerised, needs scale-to-zero or multiple revisions: Container Apps.
• You genuinely need cluster primitives - operators, CRDs, custom networking: AKS, and accept running it.

App Service, in practice

A Python app on App Service runs behind a front end that expects your process to bind the port it supplies.

# Azure sets PORT; bind it or the container is
# marked unhealthy and restarted.
gunicorn app:app \
  -k uvicorn.workers.UvicornWorker \
  --bind 0.0.0.0:$PORT

The two features that matter beyond hosting:

Deployment slots. A slot is a full parallel instance with its own hostname. Deploy to staging, warm it, then swap. The swap is a routing change, so rollback is swapping back rather than redeploying.

az webapp deployment slot swap \
  --slot staging --target-slot production

Settings marked as slot settings stay with the slot rather than travelling with the swap, which is how the staging database URL does not follow the app into production. Getting that wrong is the classic slot incident.

Always On. Without it the app is unloaded when idle and the next request pays a cold start. On any production tier, turn it on.

Functions, and the trap

The Python model is a handler plus a trigger binding:

import azure.functions as func

app = func.FunctionApp()

@app.timer_trigger(schedule="0 */5 * * * *",
                   arg_name="timer")
def sync(timer: func.TimerRequest) -> None:
    run_sync()

Triggers cover HTTP, timers, queues, blobs and Event Hubs, and the binding model means the queue plumbing is configuration rather than code.

The trap is the hosting plan, which decides behaviour more than the code:

On Consumption, a Python function that imports a large ML library can cold start in seconds. If latency matters, that is a Premium plan decision, not something to optimise in code. And Consumption caps execution duration, so long-running work belongs in a queue-triggered function or a container, not an HTTP handler.

Where the Python detail bites

Azure builds Python apps with Oryx, which installs from requirements.txt. Packages needing system libraries frequently fail there, and the fix is to deploy a container instead of source - which is the practical reason many teams land on Container Apps.

For anything with native dependencies, ship an image. See Multi-stage builds.

Related

• Azure for an AWS-shaped brain - the service map and AWS equivalents
• Key Vault, Storage and managed identity - config and secrets for these
• Comparing AWS Compute Services - the same decision on AWS