Azure Container Apps: Is It Really That Good?

Introduction

Azure Container Apps is a serverless platform that allows you to maintain less infrastructure and save costs while running containerized applications. Instead of worrying about server configuration, container orchestration, and deployment details, Container Apps provides all the up-to-date server resources required to keep your applications stable and secure.

I did not write this! It was Microsoft, you can find more information here.

If you want me to put this service in layman’s terms, it is the eternal promise of a Kubernetes abstraction layer that will allow you to run your containers without having to be an orchestration expert or some kind of Kubernetes ninja.

Having spent some time working with Azure Container Apps, I’m impressed by its potential. While my experience doesn’t encompass every use case, I’ve identified both positive things and areas requiring improvement. This article provides a brief description of the service, and summarizes my findings; diving into both the service’s strengths and weaknesses.

The Good 👍

Easy to use
You can deploy your containers with a few clicks, and you can also use the Azure CLI, Bicep, ARM Templates, or Terraform to automate the deployments.

Integrated with Azure services
You can integrate it easily with Azure services like Azure Key Vault, Azure Log Analytics, Azure Container Registry, Service Bus and many more.

Flexible
You can run any containerized application, and you can use any programming language, framework, or tool. You can run jobs and scale your applications based on demand.

You have the option to choose which kind of Azure Container Apps Environment you want to use, there is the option to choose Workload Profiles with a Consumption Plan or a Dedicated one, and there is the option to use a Consumption Only environment. You can check the differences here.

In case your application needs an ingress, the integration is extremely easy, it will allow you to use TCP and HTTP/HTTPS, and a few months ago they added the option to use additional TCP ports, initially the only option was to use the ports 80 and 443.
It also supports Dapr to simplify the building and deployment of cloud-native applications, and KEDA for event-driven auto-scaling.

Cost-effective
You can pay for the resources you use, and you can scale your applications based on demand. If you compare it with GKS, EKS, or AKS, is cheaper as you don’t have to pay for the control plane.

Another cool thing about this service is how they price the Consumption Plan, Azure differentiates whether your container is idle or actively working, and applies a different CPU price to your workload, which is very useful if you have an application that is idle for some time and is not a good candidate to be scaled to zero.

Secure
You can seamlessly integrate with System-assigned and User-assigned managed identities, which allows you to access other Azure services securely without having to manage credentials.

There is the option to deploy the Azure Container Apps within an internal Azure Virtual Network, which is very useful if you want your application to be accessible only from within your network.

The Not So Good 😑

I needed the best Azure Virtual Network integration possible and wanted to pay only for what I used as my app scales from 1 to 30 containers during the day; in this case, the best option was to go for Workload Profiles Environments and use a Consumption Plan. Technically this is perfectly possible, but there is a big catch when using a Consumption Plan, there is an ephemeral storage limit which is kind of low for some use cases.

In some scenarios, you can get around this limitation by mounting an Azure File Share into the container, but what happens when your image takes most of the space once decompressed? It happened to me. But something was not right, the container was using almost all the disk space, and I’m sure the app and its artifacts didn’t need this much disk space.

I was forced to change the Azure Container Apps Environment plan to Dedicated and pay for resources I was not going to use, but this Dedicated Plan provides the additional storage I needed…

I was not happy about it, I opened a case with Microsoft and they told me that was just the way it was, I showed them that even the “hello world” image was taking almost all the space; we went back and forth then I decided to close the case feeling a little bit frustrated. How is it possible that the “hello world” container takes 76% of the available space? I was not able to find any information about it.

After some time, I checked again and now the “hello world” container was taking way less space. I tested with my image and VOILÁ💥! It was taking way less space now! I guess they fixed something on their end, I’m not sure, but it was definitively working for me now, I was getting less than 1G of available space before, now I have 9G.

It is worth mentioning that I also trimmed my image and the application a bit. But I honestly doubt I was able to reduce the size of the image that much; additionally, I checked the image with dive, and I was getting an efficiency score of 99%, and the same size every time.

Weird storage issues aside, I found some challenges when using Managed Identities, fortunately, these were already reported to the Azure Container Apps team, and there is a workaround for it.

The last thing I want to mention is that if you want KEDA to scale using a Managed Identity, there is no out-of-the-box solution for this yet, I ended up creating a microservice to overcome this limitation. If you are interested in this solution, I described what I did on this open issue in the azure-container-apps GitHub repository, I’ll probably write a post about it in the future.

Final Thoughts

I just wish that Microsoft offered the same ephemeral storage for the Consumption Plan in the Workload Profiles environments, they are already offering more storage for the Consumption Only Environments, so I don’t see why they can’t do it for the Workload Profiles Environments.

What is funny about my conversation with Microsoft Support, is that they gave me an URL to put a feature request on this website, but if you look for the Azure Container Apps forum, it does not exits, all the feature requests for Azure Container Apps are either within the Azure Kubernetes Service, the Azure App Service, or the Azure Container Instances forums. And apparently is going to take them some time. 😆

Conclusion

I think that Azure Container Apps is a great service, and it has a lot of potential, but it is not perfect. I would recommend it to anyone who wants to run containerized applications without having to worry about the infrastructure, and who wants to save costs by only paying for the resources they use. But I would also recommend to be careful with the ephemeral storage limit, and to test your application before going to production.