When to use Azure Container Apps?

There are many different types of container services in Azure, and Azure Container Apps (ACA) is the last born. It differs from other container services in that it includes both Dapr (Distributed Application Runtime) and KEDA (Kubernetes Event-Driven Autoscaling), and Microsoft fully manages these. The exact K8s ecosystem solutions can be installed on AKS, but you are fully responsible for their upgrade, availability, etc. The value proposition of ACA is to keep the level of operations for the Cloud consumer shallow.

ACA is part of the serverless offering because it allows scaling containers from 0 to N, thanks to KEDA, ensuring one can optimize costs. ACA is mainly suited for the following scenarios:

• Hosting microservices-based solutions
• Hosting event-driven solutions
• Hosting websites, in general

Microservices are made easy thanks to Dapr, which ships with a service discovery feature and asynchronous-based communication across services. You can seamlessly plug different message brokers (Azure Service Bus, RabbitMQ, etc.) into the application code. Container Apps also have exciting features such as traffic split, which consist of having multiple versions of a given container and letting them run parallel to accommodate blue/green and A/B testing scenarios. Ingress traffic is also made easy thanks to the built-in ingress feature. Regarding logging and monitoring, each container app is linked to a container app environment related to a Log Analytics workspace.

At this stage (10/2022), there are, however, still a few caveats:

• The isolation level between container apps sharing the same environment is almost non-existent, at least from a network perspective. Also, because Dapr isn't fully supported yet, you can't add explicit service-based authorizations using Dapr Access Controls (i.e., service A can talk to B but not C). In the absence of network segregation, this is a must-have feature.

• From a network perspective, the service does not yet support all integration scenarios with NVAs, etc., which could be a show-stopper in some organizations.

• A single container app environment requires at least a /23 subnet, meaning 510 IP addresses, which is a lot. Each ACA environment is based on an underlying K8s cluster with Azure CNI. Some folks compare an ACA environment to a K8s namespace, but I've never seen a single namespace running 510 pods so far…

• Troubleshooting a non-working ACA is difficult because Microsoft filters out logs available in Logs Analytics.

I would therefore recommend only hosting applications belonging to the same business line and likely to interact with each other. I recommend using AKS over ACA if you require higher isolation between workloads. Alternatively, you could host a single application, but this should be of a decent size to avoid wasting many IPs. ACA is attractive but requires some improvements from Microsoft to be enterprise-ready. That said, ACA is undoubtedly already a good option for smaller companies who do not want to invest too much money, do not have vital security requirements, and want to get started quickly.