At Ignite, Azure Container Apps was introduced!  According to the announcement, Container Apps is a serverless application centric hosting service where users do not see or manage any underlying VMs, orchestrators, or other cloud infrastructure. Azure Container Apps enables executing application code packaged in any container and is unopinionated about runtime or programming model. Applications can scale in response to HTTP requests, events (e.g. storage queue messages, Kafka topics, etc.), or simply run as always-on background jobs. Azure Container Apps addresses specific requirements for microservices including encrypted service to service communication and the independent versioning and scaling of services.

Where does this fit in?

You might wonder how this fits in the existing range of Azure compute resources.  I would position this new container service at the border between Platform as a Service technology and Functions as a Service (serverless).  On one hand, it feels more PaaS, because you are not forced into a specific programming model and you can control the rules on which to scale out / scale in.  On the other hand, it has quite some serverless characteristics like scaling to zero, event-driven scaling, per second pricing and the ability to leverage Dapr’s event-based bindings.

There is certainly some overlap with Web Apps for Containers, that runs on Azure App Service.  Once Container Apps will be out of preview and will support more enterprise-grade features, I am pretty sure it will supersede the existing Web Apps for Containers offer, which didn’t get much attention throughout the last years.  I am really thrilled about this announcement and will follow its evolutions closely!

Why do we need this?

Throughout the last years, I have seen way too many customers using Azure Kubernetes Service to run a few web applications with a more-or-less microservices architecture.  While AKS certainly has its perfect use cases, it’s not your silver bullet.  AKS comes with an infrastructural and operational overhead, so it requires a skilled team to maintain and manage the cluster.  In organizations where Kubernetes is introduced from the developer side, I often encounter poorly managed clusters that lead to insecure and unstable applications.  This is where Container Apps would be a perfect fit.  You get many goodies from the Kubernetes ecosystem, but you don’t get the complexity that it brings.  It is a developer-centric application platform, that gives you an incredible jumpstart to build cloud-native and scalable applications.

What do we get?

Container Apps is built on top of Azure Kubernetes Service, including a deep integration with KEDA (event-driven auto scaling for Kubernetes), Dapr (distributed application runtime) and Envoy (a service proxy designed for cloud-native applications).  Luckily, the underlying complexity is completely abstracted for the end-user.  So no need to configure your K8S service, deployment, ingress, volume manifests…  You get a very simple API and user interface to configure the desired configuration for your containerized application.  This simplification means also less control, hence the difference with AKS.

The following features are included in the preview:

• Revisions: automatic versioning that helps to manage the application lifecycle of your container apps
• Traffic control: split incoming HTTP traffic across multiple revisions for Blue/Green deployments and A/B testing
• Ingress: simple HTTPS ingress configuration, without the need to worry about DNS and certificates
• Autoscaling: leverage all KEDA-supported scale triggers to scale your app based on external metrics
• Secrets: deploy secrets that are securely shared between containers, scale rules and Dapr sidecars
• Monitoring: the standard output and error streams are automatically written to Log Analytics
• Dapr: through a simple flag, you can enable native Dapr integration for your Container Apps

How is Kubernetes abstracted?

Container Apps introduce the following concepts:

• Environment: this is a secure boundary around a group of Container Apps.  They are deployed in the same virtual network, these apps can easily intercommunicate easily with each other and they write logs to the same Log Analytics workspace.  An environment can be compared with a Kubernetes namespace.
• Container App: this is a group of containers (pod) that is deployed and scale together.  They share the same disk space and network.
• Revision: this is an immutable snapshot of a Container App,  New revisions are automatically created and are valuable for HTTP traffic redirection strategies, such as A/B testing.

Conclusion

Container Apps is a really nice addition to the Azure compute family!  Be aware that this service is brand new, so still in preview.  There’s a great team behind this service, so I am pretty confident that it will become a first-class Azure service pretty soon!

Stay tuned for more!
Toon