Azure App Service Plans have been a key PaaS offering in Azure since 2015 and a service that I use frequently. Microsoft extended these adding Linux containers in 2017 and later Windows container support in 2020 under the name Web App for Containers. Azure Container Apps (ACA) on the other hand, is a relatively new PaaS offer, becoming generally available in 2022 providing an appealing easy-to-use Kubernetes-backed service.

With both services supporting containers in this post I wanted to look at the similarities and differences that may help us choose one over the other. This has been an interesting journey and through this, I discovered many new features of both services, so I hope you find it an interesting read.

It is worth noting that both services are being actively developed with new features being added all the time. This post is based on the state of the services as of June 2024, so it is always worth checking the documentation for updates.

Azure App Service Plans

Before we get into the feature comparison, let’s take a quick look at the basics of Azure App Service Plans.

The App Service Plan is a PaaS service that allows you to host web applications, APIs, functions etc. You can create either a Windows or Linux App Service Plan, which defines both the size of the compute resource and the number of instances you wish to scale to. You then add one or more Web App under this plan, which will share the resources of the plan, with all apps being scaled together. They support uploading your code directly, via an automated DevOps process or more relevant to this post, via containers.

Azure Container Apps

Azure Container Apps allows you to host applications wrapped in containers. It is a Kubernetes-backed PaaS service that abstracts away the complexity of managing Kubernetes clusters. This removes the need to learn helm, networking or perform maintenance on the underlying cluster.

To begin you create a Container Apps Environment which is a Kubernetes cluster that is managed by Microsoft. You can then add Apps to this environment, which are containers that run on the cluster.

Service Similarities

Being both PaaS services, you don’t need to worry about the underlying infrastructure or patching it. However, there are several other similarities between the two services in the way they work. These near-identical features include:

• VNET (ACA gets a VNet by default, though App Service Plan needs to be configured)
• Support for Managed Identities
• Custom Domains and SSL
• Adding Authentication Identity Providers
• Azure Function Support
• CORS Configuration
• Secrets with KeyVault References and Environment Settings (ACA also can store its own secrets)
• A Pricing Tier for Single Tenancy Guarantee

Key Differences

There are several key differences between the two services that may help you decide which one to use. Some of these are in the terminology used, however, others are fundamental differences in how they work, are priced and perform.

Scaling

One of the biggest differences between the two services is how they scale. Both support various auto-scaling rules, but how they perform the scaling, and the overall effect is different.

Azure App Service Plan scales by adding more server instances to the App Service Plan. This means that all apps running on the plan will scale together and use the load of the new instance.

Azure Container Apps on the other hand scales by creating replicas (note the different terminology to Kubernetes). This means that Azure Container Apps can scale more granularly, as you can scale individual apps rather than the whole environment.

One of the big advantages of Azure Container Apps is the ability to scale to zero. When you have scaled to zero, you are not paying for any resources, which can be a big cost saving. Azure App Service Plan does not support scaling to zero, so you will always be paying for at least one instance while the plan exists.

Available Host OS

Although most containers will be Linux, there are still times when you will want a Windows container. Azure App Service Plan supports both Windows and Linux containers (like AKS and ACA), whereas Azure Container Apps only supports Linux containers.

Health End Points

Kubernetes commonly has 3 configurable probe locations used to determine the health of your app; Live, Ready and Startup, using either HTTP or TCP. Azure Container Apps support these out of the box and they can be configured with many different options.

Azure App Service Plans on the other hand, only support a single HTTP health endpoint defined in the Health Check Path on the Web App. The frequency of checks are fixed at every minute rather than being configurable as they are with ACA.

The overall behaviors are similar, the endpoints are checked regularly and if a non-2XX status code is received the app is unhealthy and removed from the load balancer. Although the finer details of how frequently and when unhealthy apps are added and removed from the load balancers are different, so it’s worth reading the documentation for more details.

Sidecars and Init Containers

Sidecars and Init Containers are a common pattern in Kubernetes, allowing you to run additional containers alongside your main container. Azure Container Apps supports both of these options.

However, Azure App Service Plans does not support sidecars or init containers fully at this time. Sidecars are currently in preview for Linux apps but can only be configured during initial creation. You could however use web jobs to achieve similar functionality with a non-container approach.

Dapr

Dapr is a great tool to add an abstraction layer between your code and the infrastructure. Azure Container Apps support Dapr by using the sidecar process and can be enabled in the portal.

As mentioned above sidecar support is only just being added to Azure App Service Plan and is currently in preview. Dapr does not have a documented use with Azure App Service Plan that I can find at this time.

Private Apps

Setting some of your apps to be private is a common requirement, especially when you are building backend microservices.

By default Web Apps under an app service plan are publicly accessible. You can lock these down using Private Endpoints however there is an additional cost for the inbound and outbound data plus the endpoint itself. To access a private app you will need to use a VNet and configure DNS correctly.

Azure Container Apps on the other hand supports Private Apps out of the box, with no additional cost or complicated setup.

Versions and Revisions

Azure App Service Web Apps have the concept of deployment slots (with tiers beyond Free and Shared), you set up slots in advance and choose the slot you wish to deploy to. We can deploy a new version to a slot and then route some or all of the traffic to it. When switching over it will check the app is healthy and ready before routing traffic to it. We can swap back to the previous slot if there are issues. The number of slots depends on the pricing tier but can range from five to unlimited on the isolated tier.

Azure Container Apps take a different approach with the concept of Revisions. Unlike deployment slots, these are immutable and versioned. They are also automatically created each time a new version is provided. It allows you to keep up to 100 revisions per app, rolling back if need be. You can set up auto removal of old revisions.

Both services support having multiple versions of the app running at the same time splitting the traffic which can be useful for canary testing.

Storage

We can attach additional persistent storage with both services, however, each offers different options.

In Azure App Services you can set the environment variable of WEBSITES_ENABLE_APP_SERVICE_STORAGE to true. This will enable the /home directory to be shared across scaled instances and not be cleared on restart. You can then use a docker-compose to mount a volume that points at this. You can view the amount of storage and usage in the Azure Portal under the app service plan. If you want to use Azure Files or ReadOnly Blob Storage you can do so using this guide.

Azure Container Apps supports both container-scoped and persistent storage out of the box, with Azure Files being used for the persistent storage.

Pricing Models

The Azure Container Apps consumption plan is charged based on the amount of vCPU and Memory per hour. On top of this, you are then billed for every million requests. As you scale your apps the cost will also scale. This can give you more flexibility as different apps have different resource requirements.

The Azure App Service Plan pay-as-you-go is charged based on the size and number of servers that back the instances. Each server will give you a fixed amount of vCPU and Memory. You can then scale the number of instances up and down, scaling the costs to match. Multiple apps can be placed on the same plan and they will share the resources, the maximum number of recommended apps is determined by the plan size.

Azure Container Apps has a Dedicated plan tier, while Azure App Service Plan has an App Service Environment plan, both providing dedicated hardware and a fully isolated environment. These mirror the same price model as their respective consumption plans, with App SErvices being based on the server size and ACA based on the vCPU and Memory usage.

Both services offer a free tier. More, and up-to-date details can be found on the pricing pages for Azure Container Apps and Azure App Service Plan.

Summary

Both services are great for hosting containerized applications and seem to be expanding their feature sets.

App Service Plans support Windows containers and in some cases may be more cost-effective. They are also easier to get started with and have a more straightforward scaling model. Overall the service is more mature. However by supporting both container and non-container applications maybe it is being held back.

Azure Container Apps, on the other hand, is a more modern service that is built with a container-first approach. Being based on Kubernetes it has many advantages but without the complexity and management of a full Kubernetes cluster. It has a more granular scaling model, supports private apps out of the box and has a more advanced health check system.

Both services have different pricing models so different use cases would benefit from each service differently. That said overall if you are looking for a PaaS cloud native host for your containerized applications Azure Container Apps will often be the way to go.

Title Photo by Valdas Miskinis from Pixabay