This is the first of four articles about Azure Container Apps. Here we answer the fundamental question: is it worth switching from App Service to Container Apps? In the following parts, we cover configuration and scaling rules, Dapr integration, and the complete CI/CD pipeline with GitHub Actions.
What you already have with App Service
If you have followed the series so far, your application is probably running on Azure App Service: stateless, with externalized configuration, Managed Identity for resources, and Key Vault for secrets. App Service is an excellent PaaS — simple deployment, automatic scaling, managed certificates, slots for blue-green deployments. For many applications, it is the right choice and remains so.
The question is not "which is better absolutely," but "what specific problem do I have that App Service does not solve well." Without such a problem, migration is complexity without benefit.
What is Azure Container Apps
Azure Container Apps (ACA) is a managed service for running containers, built on Kubernetes and KEDA, but without exposing you to Kubernetes complexity. It gives you containers, event-based scaling (including scale-to-zero), revisions for controlled deployments, and Dapr integration — all without managing a cluster.
Practically, it is in between App Service (simple but limited to its model) and AKS (maximum power but full cluster management). ACA gives you much of Kubernetes power without the operational cost.
Direct comparison
| Criterion | App Service | Container Apps |
|---|---|---|
| Deployment unit | Code or container | Container (mandatory) |
| Scale-to-zero | No (minimum 1 instance) | Yes (0 instances without traffic) |
| Event-based scaling | HTTP/CPU/RAM metrics | KEDA: queues, HTTP, CPU, custom |
| Microservices | One service per plan | Multiple apps in the same environment |
| Internal service discovery | Not native | Yes (internal DNS between apps) |
| Dapr | No | Yes, built-in |
| Revisions / traffic split | Slots | Revisions with percentage split |
| Complexity | Minimal | Medium |
| Cost at low traffic | Fixed (allocated plan) | Variable (can go down to 0) |
When it makes sense to switch
- You already have containers — if the application is containerized (or you want it to be), ACA is a natural fit. If you run code directly on App Service and are satisfied, forced containerization just for ACA is extra effort.
- Intermittent or bursty traffic — scale-to-zero means you don't pay for inactive instances. A job that runs a few hours a day or an API with sporadic traffic benefits directly.
- Event-based scaling — you want to scale based on the length of a queue (Service Bus, Storage Queue), not just CPU/RAM. KEDA does this natively.
- Microservices architecture — multiple services communicating with each other, with internal service discovery and optionally Dapr for pub/sub and state management.
- Deployments with traffic splitting — you want real canary releases (10% traffic on the new revision), not just slot swaps.
When it does NOT make sense
- A simple monolithic application with constant traffic — App Service serves it perfectly, and scale-to-zero brings no benefit if you have continuous traffic anyway.
- The team has no experience with containers — ACA adds a layer of Docker, registry, images to manage. If this is new complexity, evaluate if the benefit justifies it.
- You depend on specific App Service features — certain integrations, extensions, or WebJobs that have no direct equivalent in ACA.
- You want the simplest possible operating model — App Service remains simpler to manage for standard scenarios.
What you keep from what you already have
Good news: if you have followed the cloud-native principles from this series, migration is easier than it seems. Everything you built transfers:
- Managed Identity — Container Apps supports both system-assigned and user-assigned identity, just like App Service.
DefaultAzureCredentialworks identically. - Key Vault —
AddAzureKeyVaultand secrets work the same; ACA also has its own app-level secrets mechanism. - Externalized configuration — environment variables are set on the container app, just like Application Settings.
- Stateless design — it is even more important in ACA, where scale-to-zero and rapid scaling assume no instance retains state.
- Health checks — ACA uses liveness and readiness probes, exactly the
/health/liveand/health/readyendpoints you already built.
In other words, the cloud-native discipline you applied on App Service is exactly what makes migration to Container Apps almost trivial at the code level. The difference is more in infrastructure and deployment.
What’s next
In part two we move to practice: creating a Container Apps environment, deploying a containerized .NET application, configuring scaling rules with KEDA (including scale-to-zero and queue-based scaling).
Then, in parts 3 and 4, Dapr integration for service-to-service communication and the complete CI/CD pipeline with GitHub Actions to Container Registry and Container Apps.
Questions? Write me at contact@ludoprogramming.com.
