Azure Container Apps: Serverless Containers & Revisions

Azure Container Apps

Azure Container Apps is a managed, serverless container platform on Azure. It runs containerized web apps, APIs, and background workers with automatic scaling — without requiring you to operate Kubernetes directly. Under the hood it's built on Kubernetes and KEDA, but it hides that operational surface so you can focus on shipping containers.

It's the natural middle ground on Azure: more flexible than App Service (you bring any container), far less operational overhead than AKS. Treat it like serverless — stateless instances, state pushed elsewhere.

TL;DR

Container packaging without AKS overhead.
Use it for HTTP APIs, background workers, and event-driven services.
Treat it like serverless: stateless instances, externalize state.
Scales to zero and on events/metrics (KEDA-style triggers).

Quick Example

Deploy a container as a Container App from the CLI:

Key Concepts

Container App — your deployed service.
Revisions — immutable versions of a deployment; enable gradual rollout and traffic splitting (blue/green, canary).
Ingress — public or internal HTTP exposure.
Scaling — scales to zero, and scales on events/metrics via KEDA-style triggers (queue length, HTTP load, CPU).

Common Use Cases

REST APIs
Background workers (queue consumers)
Scheduled jobs (where supported)
Internal microservices

When to Choose Container Apps vs AKS vs App Service

Best Practices

Stateless design — no local file persistence; use managed DB/storage.
Secrets — never bake secrets into images; use the platform's secret store + environment variables (see Secrets Management).
Use revisions for safe rollouts — split traffic to canary a new version before full cutover.
Scale on the right signal — HTTP concurrency for APIs, queue depth for workers.
Observability — structured logs, metrics/alerts, request tracing across services.

Common Mistakes

Assuming local disk persists

Scaling a queue worker on CPU

FAQ

How is Container Apps different from AKS?

AKS gives you a full Kubernetes cluster — maximum control and ecosystem (operators, service mesh, custom controllers) but you own cluster upgrades, node pools, and networking. Container Apps is built on Kubernetes/KEDA but abstracts all of that away: you deploy containers and configure scaling/ingress without touching the cluster. Choose Container Apps unless you specifically need raw Kubernetes APIs.

Does it really scale to zero?

Yes — Container Apps can scale down to zero instances when there's no traffic or events, so you pay nothing for idle. The trade-off is cold-start latency on the next request; set a minimum replica count above zero for latency-sensitive services to keep a warm instance.

How does event-driven scaling work?

Container Apps uses KEDA (Kubernetes Event-Driven Autoscaling) under the hood, so you can scale on signals like HTTP concurrency, CPU/memory, or external sources such as queue length (Azure Service Bus, Storage Queues). This makes it well-suited to background workers that should scale with backlog rather than CPU.

What are revisions used for?

A revision is an immutable snapshot of your app at deploy time. You can run multiple revisions simultaneously and split traffic between them — enabling blue/green and canary deployments. Roll forward by shifting traffic to a new revision, and roll back instantly by shifting it back, without rebuilding.