Azure Container Apps: This Is What You Need to Know

HTTP-based autoscaling and scale to zero capability on a serverless platform

Nov. 24, 2021, 1:26 a.m.

TL;DR

Microsoft, on November 8, 2021, announced the release of Azure Container Apps. It is a Kubernetes platform that lets users deploy, develop, scale microservices and containerized applications on a serverless platform.

With Azure Container Apps, users can enable HTTPS Ingress directly from the platform.

Key Facts

1
It uses Kubernetes as its underlying infrastructure, supplemented by DAPR and KEDA.
2
Azure Container Apps joins the five options for building, deployment of cloud-native and containerized applications offered by Microsoft.
3
With Azure Container Apps, managing cloud infrastructure is not a burden for the developer.
4
Azure Container Apps handles complex container orchestrators like Kubernetes.

Details

Designing a cloud-native application in an environment would most times be an arduous task, probably all of the time. There are a lot of specificities involved in knowing the exact underlying virtual infrastructure and providing the complimentary servers to match the predicted scaling. Then this would be followed up with setting up a service mesh for networking and security. Simply put, cloud-native applications demand a lot of infrastructure and compatibility requirements down to node level. There are too many significant components needed in the managed environment, Kubernetes, or any other container orchestrator; most companies cannot match this budget.

Why serverless?

It is a different situation, however, if all these are done in a prepared environment. Azure is inviting prospective Azure Container Apps users to leverage their multipurpose servers compatible with microservices and containerized applications with features that can scale to zero in a serverless database.

Microsoft announced a preview of this service at its recent Ignite event. It uses Kubernetes as its underlying infrastructure; it is further improved by open source projects such as Distributed Application Runtime (DAPR) and Kubernetes Event-Driven Autoscaling (KEDA). Azure Container Apps allows users to run application code bundled in any container, regardless of the runtime or programming model.

Container Apps is the only serverless container solution offering a combination of both built-in HTTP-based autoscaling, including scaled to zero, and event-driven-based autoscaling to run containers that may be processing messages from queues, streams, or databases. In addition, it supports microservices architectures, built with containers using any language, framework, or runtime - and provides native access to powerful open-source projects and frameworks
Jeff Hollan
Principal Program Manager for Microsoft Azure

How is Azure Container Apps different?

Azure Container Apps joins Azure App Services, Azure Functions, Azure Kubernetes Service (AKS), Azure Spring Cloud, and Azure Container Instances (ACI) on the list of options for building, managing, and deployment of cloud-native and containerized applications offered by Microsoft. What use cases make it not an option but a necessity?

Applications built on Azure Container Apps can scale based on the supply of metrics like HTTP traffic, any KEDA-supported scaler, event-driven processing, and CPU or memory load.

With Azure Container Apps, users can write code using their preferred programming language. This eliminates the limitation of using a single mandatory code which could deter proficiency.

With Azure Container Apps, users can enable HTTPS Ingress directly from the platform.

Users can autoscale apps based on KEDA-supported scale triggers. Most apps can scale to zero, except those on CPU or memory load. This service enables traffic splitting across separate versions of an application for Blue/Green deployments and A/B testing scenarios, retaining control of the pace while rolling out features.

Users can enjoy DAPR's rich stream of APIs and build container-based applications with it. ACA can manage apps through Azure CLI extensions and autonomously handle building, deployment, and development.

Users can run multiple revisions without having to run them on extensions.

Users do not have to deploy containers from registries; they can run them directly, private, public, or hybrid registries and use internal ingress.