At Ignite-2021 conference, Microsoft announced the preview launch of Azure Container Apps, a new fully managed serverless container service.
Azure Container Apps (ACA) provide a serverless hosting service that sits on top of an AKS service, allowing you to deploy multiple containers without dealing with the underlying infrastructure.
Let see a current Kubernetes landscape in Azure:
| Service | Azure Container Apps | Azure Kubernetes Service (AKS) | Azure Container Instances | Web App for Containers |
|---|---|---|---|---|
| Sample usage | Build and deploy modern apps and microservices | Deploy and scale containers on managed Kubernetes | Launch containers with hypervisor isolation | Run containerized web apps |
| Autoscale | Yes (KEDA) | Yes (config) | No | Yes (App Service plan) |
| HTTPS ingress | Yes (Envoy) | Yes(may need additional infrastructure) | Yes | Yes |
| Split traffic | Yes | Manual | No | Yes (deployment slots) |
| Dapr | Yes | Manual | No | No |
| Long-running jobs | Yes | Yes | No | No |
What new service brings to the table?
Kubernetes is hard. It is true even in managed K8s environments like AKS and Google Kubernetes Engine (GKE). It is true for newcomers or developers who want to focus on solving business requirements instead of tackling and mastering the underlying application platform.
ACA offers worry-free deployment and auto-management of many aspects of the containerized applications including service discovery and traffic splitting, support of long running processes, open-source technologies like Dapr, KEDA, and Envoy, It is optimized for running applications that span many microservices deployed in containers.
Azure Portal
Azure Portal at the moment looks pretty bare. You can create ACA, configure monitoring, secrets and view revisions but auto-scaling and other details are managed via configurations.
Currently, the maximum available container size is 2 cores / 4 GiB of memory (while other services support up to 16 GiB)
You can also configure internal or external ingress:
Microservices
Multiple ACA can be deployed into a single environment. You can think of environments as similar to Kubernetes Pods.
By doing so, they will be put under the same virtual network and isolated from the outside world. Each environment also has its own Log Analytics workspace to provide monitoring.
When you deploy your container app a new revision is created. A revision is an immutable snapshot of a container app. Revisions allow you to have the old and new versions running simultaneously and use the traffic splitting functionality to direct traffic to old or new versions of the application.
Dapr
Dapr (Distributed Application Runtime) is a runtime that helps build resilient, stateless, and stateful microservices.
Azure Container Apps offers a fully managed version of the Dapr APIs when building microservices. When you use Dapr in Azure Container Apps, you can enable sidecars to run next to your microservices that provide a rich set of capabilities. Available Dapr APIs include Service to Service calls, Pub/Sub, Event Bindings, State Stores, and Actors.
There is an excellent example created by Jeff Hollan showing how
multi-container communication can use direct calls as well as be proxied by Dapr. Dapr can provide mTLS, auto-retries, and additional telemetry.
This example also shows how to deploy the app using GitHub Actions and Azure BICEP.
Google Cloud
GCP's similar technology, GKE Autopilot mode is intended to be a hands-off fully managed Kubernetes experience that allows users to focus more on the workloads and less on managing cluster infrastructure. The difference is that Azure team chose a very opinionated route, supporting selected open-source technologies at the expense of choice.
Conclusion
Azure Container Apps is a perfect addition to Azure's container landscape. By using this ACA, you don't spend time managing Kubernetes clusters and can focus on building and deploying your application.
The biggest pros for Container Apps are the serverless container orchestration, ability to scale to 0, and usage-based pricing. Autoscaling, HTTPS ingress and Dapr take away major headaches of running your application on Kubernetes.
The possible downside is that when deploying to ACA, you are buying the way the MS built this service such as using Dapr for service mesh, KEDA for scaling, Envoy for ingress and Log Analytics for monitoring. The deployment is also performed using Azure tools so you may not bring in your beloved Helm charts. And, as of now, Windows containers are not supported.
However teams facing a modernization and planning their move to Azure Kubernetes Service may be very interested in Azure Container Apps due to simplicity and abstraction of the complex Kubernetes system.
Thanks for reading, here is a containerized cat for you, a next step in containerization :)
Top comments (4)
Currently ACA does not support HTTP url based routing , you could implementing via Envoy proxy but It's not a native feature .
The azure ACA team is developing HTTP url based routing functionality with ETA End of June 2023
for more info , check this out github.com/orgs/microsoft/projects...
Why are you comparing Azure Container Apps with GKE Autopilot, and not with Google Cloud Run (which MS seems to have copied)?
Google Could Run, while having autoscaling, can be more directly compared to Azure Container Instances in that it can run stateless containerized apps that can fit into request-response model (with a max running time of 60 min). There is no concepts of side-cars or service mesh, making both of them a poor fit for complex applications, IMO.
I agree with that , ACA is also compared with AWS ECS