Introduction to Azure Container Apps (ACA)
At Microsoft Ignite 2021 in November, Microsoft announced their new serverless container platform, Azure Container Apps (ACA). ACA runs on top of a hidden Azure Kubernetes Service (AKS) to provide an easy way run containers in a Kubernets environment without the complexity of managing the Kubernetes infrastructure. Pricing for ACA is usually also better than the alternatives. You could see ACA as a Platform as a Service (PaaS) layer on top of AKS.
Azure already has multiple options for running containers. This blog post will discuss what's new with Azure Container Apps and where it differs from other options.
Let's first do a quick intro on how to get started so you can try it yourself.
Getting started with Azure Container Apps
Azure Container Apps can easily be deployed in the Azure Portal. Search for "container app" and then Create.
Now choose a name, and a Container App environment.
If this is your first Container App, you'll need to create an environment.
The Container App environment is for grouping your Container Apps. The Container Apps within the same environment will be able to communicate with each other.
In the app settings, you can use the quickstart image to test, or you can point to an actual container image (such as ).
Enable the ingress to be able to access your container. Make it public to allow access from the internet. Otherwise make it private to allow access from other containers inside the same App Container environment.
Review your settings and click Create. Wait for your deployment to complete.
Now you should be able to access your newly created container through the Application Url shown in the portal.
Differences between Azure Container Instances (ACI) and Azure Container Apps (ACA)
What really is new? Doesn't Azure already have Azure Container Instances and support for running containers in Azure App Services.
Although there are alternatives for running containers, Azure Containers Apps has more features:
Azure Containers Instances can be seen as a low-level building block for running containers. If you for example need multiple replicas of your container, you will need to create them one by one.
Azure App Services is a good option for running web apps, but for microservice scenarios Azure Container Apps are better.
Still there is the option of creating your own Kubernetes cluster, but that requires quite a bit more maintenance and knowledge (Linux, Docker, Kubernetes, Istio, Prometheus, Fleet, Traefik, Jaeger, etc).
Here's a look more in detail into the differences.
Azure Container Apps can easily autoscale. It can even scale down to 0 replicas when idle so you won't be charged unnecessary costs. This makes it serverless and often cheaper than Azure Container Instances or Azure App Services.
You can also manually set the amount of CPU and memory allocated per replica. This will be fixed per revision and not affected by autoscaling.
You can update the scaling by creating a new revision. Then you define KEDA rules for triggering the scaling.
Dapr (Distributed Application Runtime) enhances your containers with rich functionality such as mutual TLS, automatic retries, pub/sub, observability, etc. It runs as a sidecar container that takes care of many of these challenges, while you can focus on writing code.
Envoy / traffic splitting
Incoming requests are handled by an Envoy proxy. This enables load balancing/splitting traffic (for example A/B testing scenarios). The envoy proxy is mostly hidden from users, but powers the revision traffic settings.
Azure Container Apps is a very useful new service for running containers in a PaaS simplified Kubernetes environment, letting developers focus on writing code. The pricing is also attractive, which means it is a very good choice for many scenarios.