This article is more than 1 year old
Microsoft introduces Azure Container Apps with scale to zero
Kubernetes under the covers, with a Microsoft flavour
Interview At its recent Ignite event, Microsoft rolled out a preview of Azure Container Apps, a managed service for deploying containers with features including scale to zero.
It uses Kubernetes behind the scenes, supplemented by Dapr and KEDA.
The Azure cloud already provides various ways to run containers, including Azure Kubernetes Service (AKS) for a full Kubernetes deployment; Azure App Service, which can run both Linux and Windows containers; and Azure Container Instance, which can be used standalone or for adding burst capacity to AKS without adding servers. What is Container Apps offering that is new?
"The main reasoning with Container Apps is helping teams build microservice solutions where they can have containers discovering each other, talking to each other, and getting the benefits of an architecture that Kubernetes can provide, without having to understand, provision and manage the underlying Kubernetes cluster," Microsoft director of product for Azure Apps, Jeff Hollan tells us.
"Not all microservices have API or an HTTP endpoint," he says. "Often, microservices are using an event stream, a queue or a message bus to coordinate or provide more durability between their processes."
Kafka, an event stream processor, is a common pattern, he says. "If you deploy some containers, you can say these are listening to a Kafka topic and we will scale your container all the way down to zero, if the Kafka topic is empty, and if 10,000 Kafka events pop up we'll rapidly scale out your container as well."
Container Apps run on Kubernetes but this is hidden from users. "You can't go in and use the Kubernetes command line tool kubectl to poke around your cluster. You use the APIs and the management that we surface on top of it. We do bubble up a lot of Kubernetes features, but we optimize them for Container Apps," says Hollan.
The Containers Apps service makes use of two Microsoft-sponsored open source projects. KEDA (Kubernetes Event-driven Autoscaling) plays a role in the scaling capabilities, and Dapr (Distributed Application Runtime) provides additional APIs. Dapr runs as a "sidecar" alongside containerised applications providing services such as state stores, event bindings, and publish/subscribe.
"Dapr is currently in the voting stage for donation into the CNCF as an incubation project," says Hollan. "Dapr provides a bunch of the best practices for building microservices. For any Container App, you can enable Dapr and we will automatically hook up the Dapr sidecar… Dapr is going to layer on mTLS, resilient retries, a bunch of additional telemetry," he says.
If a Container App scales to zero, what is the latency when a new request comes in and it starts up again? "There's a ton of variables in code start," says Hollan. "Has the image been cached? How big is the image? It's something teams will want to consider in terms of their tolerance. If they want a millisecond response, that's fine, we let you say 'Never scale this down to zero.'"
This limitation is mitigated by special pricing for idle instances. Currently Container Apps is in preview and available only in the Canada Central and North Europe regions. Usage is charged per vCPU, per memory used, and per request, and when idle the vCPU charge is reduced by 87.5 per cent.
There is a free tier with 50 hours vCPU, 100 hours of 1GB memory, and 2 million requests per month. An instance with two vCPUs and 2GB memory would cost around £51 per month, plus £0.292 per million requests, at current pricing.
Container Apps is different from Azure Container Instances, which "isn't going to manage container to container communication, there's no concept of auto scale," says Hollan.
He says the new service is also very different from App Service, which is "a purpose built service for hosting web sites and web APIs… there's no concept of an environment of microservices, for them all to talk to each other."
In Container Apps, "Environment" is a specific feature providing an isolation boundary around a group of containers. Each environment is within the same virtual network.
Another Container Apps concept is called revisions. A revision is created every time a container app is updated. One use case is to allow admins to direct traffic to one or other version of a containerised application, such as for A/B testing where just a small portion of traffic is directed to a new version in order to assess its performance. "Inactive revisions remain as a snapshot of your container app in a certain state," the docs explain. "You are not charged for inactive revisions. Up to 100 revisions remain before being purged."
Run Windows containers? "At preview we will only be supporting Linux-based containers," Hollan tells us.
The date for general availability is not yet known, though Hollan said "some months after" the current public preview, which went live at Ignite.
From what we have seen, the intent of Container App Service is to provide just enough Kubernetes to enable cloud native applications, without having to tangle with the Kubernetes API itself. It competes with services like Google's Cloud Run and AWS Fargate. Its success will depend in part on how well developers take to Dapr, and the free tier and scale to zero features will assist experimentation. ®