Scenarios for Azure Container Apps

Building and integrating them with existing solutions to rip maximum benefits

Published in

Microsoft Azure

6 min readSep 19, 2022

Azure container apps usage scenarios. #AzureBackToSchool 2022 — Photo by Per Lööv from Unsplash. #AzureBackToSchool community event 2022

TL;DR; You will find comprehensive list of usage scenarios for Azure Container Apps(ACA) for brown and green field projects. I will mention pros and cons and extend this links to detailed articles per scenario, so you can choose the applicable one. Visit azurebacktoschool for more content.

Killer features

Yes, under the hood, you can find well-known Azure Kubernetes Service(AKS), Kubernetes Event-driven Autoscaler(KEDA), The Distributed Application Runtime(DAPR), and Envoy for ingresses. And, of course, Azure Container registry for storing and publishing your images.

But ACA provides a great way to abstract everything above and allows you to concentrate on business features and delivery.

Container orchestration without Kubernetes complexity
Application revisions supported by ingresses
Distributed tracing for your services
The event-driven scale of application
Serverless containers scaled by HTTP requests
Managed identities to connect with all Azure services
Easy local development and debugging with DAPR
Health probes, metrics, and alerts
Reliable actors from DAPR(based on Service Fabric actors and Orleans)

Use it when you have to tackle the initial complexity of your application. From my perspective, 90% percent of Kubernetes-enabled microservices apps can be safely lifted to container apps to lower ownership costs and speed up delivery.

The plan

Existing solution migration to Container apps

Why migrate?
Existing web apps/web API scenarios
Existing Kubernetes/AKS cluster with simple networking
Containerization of existing Azure Functions.

Integration of a new service with an existing application

Container Apps complimenting the existing AKS cluster
Container Apps with a mix of the different Azure services

The new project scenario and evolution

Microservices via Container Apps instead of Kubernetes
Preparing your Container App for migration to AKS with DAPR
Migration from AKS to full-fledged Kubernetes
Batch job that can have a huge scale inside a private network

Existing solution migration to Container Apps

Why migrate?

There are a lot of benefits in migration beyond basic ones like scalability and becoming host agnostic. The new services in Azure have better support, faster issue resolutions, and the new features and integration are also coming faster.

Existing web apps/web API based on Azure App Service.

While existing app service provides scalability and even container support, the first-class citizens are still .NET application without docker, while other languages and frameworks are supported, but docker-compose on app services are not reliable, scale-out and scale-in base on virtual machine scale sets(VMSS) can be troublesome, especially on scaling-in.

Some features for Web Apps have been in preview for more than 4 years, and seems like they will never make it out of preview. Blue-green deployments and app service slots can be easily replaced with multiple versions of your containers hosted as Container Apps

Containerizing existing application combos like Web API + SPA + Identity Server auth can future-proof your application, and converting this combo to Container Apps with 3 ingresses will allow you to easily host many versions of your app with scalability and reliability.

Existing Kubernetes/AKS cluster with simple networking

Azure Kubernetes Service is a super popular platform to host microservices and has great adoption. But my observation is that around 80% of projects leverage 3 VMs in the VMSS cluster as nodes without enabling auto-scale at all :). Moreover, these projects have around 2–3 teams of developers and DevOps engineers with 0.25 FTE to support AKS clusters in Dev/Test/Prod environments. Which is suboptimal, in my opinion.

Moving these solutions from AKS to container Apps will lower maintenance costs for the customer and can speed up the delivery of business features because there will be no additional effort to maintain and upgrade AKS in all environments.

Containerization of existing Azure Functions.

Azure functions have become a backbone for many projects in recent years, but projects tend to grow, and sometimes companies want to pack(containerize) their project as a SaaS platform to leverage private networking and isolation without the usage of azure functions premium plan.

Microsoft provided a great way to containerize functions and dynamically switch pub/sub triggers according to the needs. But this path was connected with the usage of Kubernetes as a backbone platform for container orchestration.

With Azure Container Apps, it is easier than ever to containerize Functions applications, switch Azure Service Bus to RabbitMQ and isolate entire processing pipelines behind Azure Container Apps with only one ingress open for the admin panel of the customer application.

New service integration with an existing solution

Container Apps complimenting the existing AKS cluster

Sometimes your existing system relies on multiple integrations and gateways with an external system, and the number of teams implementing changes continues to grow. This is also a good scenario for the extension of the existing Kubernetes cluster with Container Apps hosted services for isolation and aggregation. i.e., implement the Edge service pattern to build client-specific gateways to your product that support easy versioning and very specific client contracts.

And this Edge service will have the same scalability features as AKS without a maintenance burden increase.

Container Apps with a mix of the different Azure services

This scenario allows extending your existing applications and services with pluggable Container services without the need for isolated Container Instances services to host single docker images for specific payloads that don't need to be scaled at all.

Project start from scratch. And its Evolution

Starting the project from scratch can be the best possible idea because Microsoft prepared the logical evolution way of your application, which can be made more complex as it grows.

Microservices via Container Apps instead of Kubernetes

Starting with the pilot version of your application with the goal of a short time to market can be a hard task, so making it more complex with maintenance Kubernetes cluster.

This approach also follows YAGNI(You aren’t gonna need it) principle because the scalability, integrations, and networking of Container Apps might be enough for the coming 5 years. But you should load test your application properly to understand the limitation.
I will post an article with a GitHub repo on October 4th.

Preparing your Container App for migration to AKS with DAPR

As your company application continues to grow, sometimes you need to comply with more policies, take control over your infrastructure configuration, and fine-tune it. Microsoft gets you covered and allows you to extend your application with DAPR, so you can control cross-service communications and make your services portable and agnostic of service brokers and etc.

You can easily add DAPR as a developer-oriented service mesh solution to your containers, run them locally, and deploy them back to the existing Container Apps environments. And when the time comes, set up the AKS cluster, configure DAPR there, and just deploy your application there.

Migration from AKS to full-fledged Kubernetes

The cloud-agnostic approach is still popular as of now, though I`m not a fan of it :), so you might need to deploy your application to a client with a special need for an on-premises Kubernetes cluster.

And to do this, you just need to set up a local server farm, hire a DevOps engineer to support deployed unmanaged Kubernetes setup KEDA and DAPR, and ship containers with your application there.

What is next?

In the next article, I will cover the migration of two existing Web App applications to Azure Container Apps with in-depth details, starting from a setup of a local environment and all the way to a production-like configuration. Stay tuned :).

The summary

As you can see, Azure Container Apps is a long-awaited move toward serverless container orchestration that will lower the maintenance burden and allow teams to deliver products faster without a need for DevOps engineers.

While there are some minor issues and hiccups, the solution will be fully mature in the coming months, and from my perspective, it will replace Azure App Service as the default starting option in Azure. And AKS would be something for big projects with extensive compliance policies, more control, and complex network integrations.

That’s it, thanks for reading. Cheers!