Azure Container Apps - Simply Explained

Welcome to another episode. I'm your host, Mirko Peters. Today we're talking about containers, specifically the middle ground most people don't know exists. What if you could run containers with all the power of Kubernetes without managing any of it? No cluster setup, no node pools, no YAML files that read like a foreign language? Most people think containers work one of two ways. You either deploy something simple, a single container running one task, or you go all in on Kubernetes, which means hiring someone who actually understands it. But what if you wanted modern container features without becoming a Kubernetes admin overnight? That's exactly the gap as your container apps fills. Let me show you the problem first, then the solution. The container evolution problem. 20 years ago, almost every application was a monolith. One big piece of software running on one server, the database, the front end, the business logic, all bundled together for a long time that worked fine. But as applications grew, developers started breaking them into smaller pieces, microservices, independent components that could be built, deployed, and scaled separately. That solved a lot of problems, but it created a new one. How do you manage all those pieces? How do you make sure they talk to each other, scale independently and don't crash when traffic spikes? Containers came along and solved the packaging problem. They let you bundle your app with everything it needs to run, libraries, dependencies, configuration, into one portable unit, but containers alone don't tell you how to run them at scale. That's where orchestration comes in, and here's the thing. The industry gave us two extremes. On one side, simple container hosting. Services like Azure Container instances let you spin up a single container, run a job, and shut it down. No orchestration, no scaling, no load balancing. On the other side, full blown Kubernetes. Azure Kubernetes service gives you complete control over everything. Nodes, networking, security policies, the whole kitchen sink. But it comes with the price. You need a dedicated team to manage it. Most people don't need either extreme. They want something in the middle, and that middle ground is exactly where Azure Container apps lives. The three options, a quick map. So what are your choices when you want to run containers on Azure? There are three main options, and knowing the difference is what helps you pick the right one. Option one, Azure Container instances or ACI. This is the simplest path. You take a container image, deploy it, and it runs. No scaling rules, no load balancing, no orchestration. Perfect for one-off jobs like batch processing, running a quick test, or processing a file, and shutting down. But if your app needs to stay running and handle traffic, ACI isn't built for that. Option two, Azure Kubernetes service, or AKS. This is the full Kubernetes experience. You get complete control over every layer, the nodes, the networking, the security policies, the upgrade strategy. You can do anything with AKS. But you also have to do everything. You need a dedicated operations team to manage the cluster, handle upgrades, monitor node health, and troubleshoot networking issues. Powerful, but expensive, both in compute costs, and in the engineering hours to keep it running. Option three, Azure Container apps. This sits right in the middle. You get Kubernetes level features, automatic scaling, load balancing, in-grass rolling updates, but Microsoft manages the cluster for you. You handle the application. Microsoft handles everything underneath. Here's the thing. For most container workloads, this is more than enough. Some estimates say container apps covers about 80% of what people typically need containers for. Think of it like renting a car versus buying a truck. ACI is a sedan for a quick errand. Gets the job done, but you wouldn't use it for heavy lifting. AKS is a fully loaded truck with a mechanic on retainer. You can haul anything, but you're paying for the truck, insurance, and mechanic, whether you're using it or not. Container apps is an SUV. Enough power for most jobs, and when you're done, you hand the keys back and stop paying. No maintenance, no storage costs, no mechanic. Now let's pop the hood and see what container apps is made of. What Azure Container Apps actually is. Here's the simplest definition. Azure Container Apps is a fully managed, serverless container platform built on top of Azure Kubernetes service. Microsoft spins up an AKS cluster behind the scenes. You never touch it, never see it, never patch it, never worry about it crashing. You just get the benefits of Kubernetes without writing a single YAML file. Three core building blocks make this work. Let's go through them one at a time. Environments. Think of an environment as your digital neighborhood. It's a secure boundary that groups your container apps together. All the apps inside one environment can talk to each other, share networking settings, and live under the same security rules. You can even deploy into a virtual network for extra protection, keeping your containers completely isolated from the public internet if you need to. Containers, these are your actual applications running inside the environment. Each container app can have multiple revisions. Think of revisions as version snapshots. You deploy a new version of your app, and Azure creates a new revision. The old one stays around. That means you can roll back instantly if something breaks. You can even split traffic between revisions, send 10% of users to the new version, while the rest stay on the old one. That's blue-green deployment built right in no extra tools required. Workload profiles, these are the underlying compute resources. You get two options. The consumption profile charges you per second for active CPU and memory, and it can scale to zero. No traffic means no cost. Perfect for apps that aren't running all the time. The dedicated profile gives you reserved VMs for predictable performance. You pay per hour, but you get consistent compute power. Choose whichever fits your workload. Now, everything runs on top of three open source technologies. Kubernetes is the orchestration engine. Handles scheduling, scaling, and keeping your containers running. Keda handles event-driven scaling. DAPER manages microservice communication, service discovery, state management, pub-sub messaging. Microsoft wraps all of this in a simple API. You just deploy your container and everything underneath works automatically. Those three technologies are worth a closer look. We'll dive into each one next. The secret source, Keda, DAPER, and Envoy. Let's start with Keda. It stands for Kubernetes Event-driven auto-scaling. And in plain English, it's probably the most useful feature of container apps for most people. Here's why. Traditional auto-scaling watches CPU or memory. If your CPU hits 80%, spin up another instance. That works, but it's reactive. By the time your CPU is high, your users have already felt the lag. Keda flips that model. It scales based on real events. More messages arriving in a queue. More containers spin up. A spike in HTTP traffic. Scale out. No traffic at all. Scale down to zero. You pay nothing when nothing is happening. Keda can watch queue length, HTTP request rate, custom metrics from Prometheus. Almost anything you can measure. It's the difference between preventing a problem and reacting to one. Now, think of DAPER as a toolkit for building microservices. It stands for distributed application runtime. But let's call it your microservices sidekick. DAPER handles the hard parts every distributed app needs. State management. Saving and retrieving data across services. Pub/Sub messaging. One service sends a message. Others receive it. Service discovery. Services finding and talking to each other without hard coded addresses. The best part? You don't need to rewrite your app to use it. DAPER runs as a sidecar. A separate container that sits alongside your application container. Your app talks to DAPER through simple HTTP or GRPC calls. So instead of writing complex code to save state to readers, your app just asks DAPER to do it. DAPER handles the rest. Then there's Envoy. Envoy is the traffic controller. It manages ingress. How requests get from the internet to your container? It handles TLS termination automatically so you don't need to manage certificates yourself. And it enables traffic splitting between revisions. One to send 5% of traffic to a new version to test it. Envoy turns that into a configuration setting, not a networking nightmare. These three together give you automatic scaling based on what actually matters. In micro service capabilities without writing micro service plumbing and secure manage traffic rooting. In raw Kubernetes, this would take months, months of reading documentation, configuring ingress controllers, setting up monitoring, debugging scaling issues. Container apps gives it to you for free. You just deploy your container and the platform handles the rest. Now you might have heard container apps described as Kubernetes without Kubernetes. Let's clear that myth up. The Kubernetes without Kubernetes myth. It's a popular phrase. Kubernetes without Kubernetes. But it needs some qualification. There's a big difference between what it actually means and what people assume it means. Here's what's true. You get the power of Kubernetes orchestration without managing clusters. Scaling, load balancing, ingress, rolling updates, all handled automatically. You don't need to know what a CUBALATE is. You don't need to worry about ETCD clusters or control plane availability or node drain operations. That stuff just works behind the scenes and you never think about it. But here's what's not true. You do not get full Kubernetes flexibility. And that distinction matters. You can't install custom Kubernetes plugins. There's no access to the control plane. It's completely locked down. You're limited to about 10 to 12 VM sizes for your workload profiles. No help charts, which is a big one if your team already uses help to manage deployments. And no custom resource definitions or CRDs. If your application depends on a Kubernetes operator that adds custom resources to the cluster, container apps won't support it. So what does this mean for you? For most web apps, APIs and microservices, container apps gives you more than enough power. You get auto scaling, ingress, revision management, secrets, environment variables, everything you need for a modern application in production. But for specialized or complex scenarios, AKS might still be necessary. If you need full control over how Kubernetes behaves at every layer, container apps isn't designed for that. Here's a practical rule of thumb. Ask yourself three questions. Do you need full control over nodes, networking and security policies? Go with AKS. Do you want a hassle free way to run modern containerized applications? Container apps is your answer. You just need to run one container occasionally for a batch job or a quick test, stick with ACI, most people land in that middle bucket. And that's exactly where container apps shines. Let's make this concrete with real scenarios. When you should actually use it. Today we're walking through four scenarios where container apps truly shines and a couple where you should look elsewhere. First scenario. You're building a public API. You want something that handles traffic spikes automatically. Deploys updates without downtime, manages HTTPS certificates for you. There are apps handles all of that out of the box. Auto scaling kicks in when traffic spikes. Traffic splitting between revisions means you can roll out a new version to a small percentage of users, watch it, then ramp up. Built in TLS termination means you don't have to mess with certificate management. No lets encrypt scripts, no renewal reminders, it just works. Second scenario. You need event-driven processing. Maybe you have files landing in blob storage that need to be processed or messages arriving in a queue that need to be handled. Container apps through KIDA watches those events and spins containers up or down automatically. A file arrives, a container processes it and when the queue is empty the container scales to zero. You only pay for the seconds it was actually working. That's a real game changer for background processing workloads. Third scenario. You're running microservices. DAPR handles service to service communication. State management. Pub/sub messaging. Retrieves with back off. It's all built in. Each microservice scales independently based on its own traffic patterns. The payment service doesn't need to scale just because the catalog service is getting hammered. They each do their own thing and because DAPR runs as a sidecar you don't have to change your application code to get these features. Fourth scenario. Small team. Big ambitions. This is the one I hear about most often. A team of two or three developers who want to build modern applications but don't have a dedicated DevOps person. Container apps doesn't require one. Developers can deploy directly from Visual Studio or VS code. The infrastructure team, if they even is one, doesn't need to be involved in every container deployment. There are times when container apps isn't the right fit. Need Windows containers not supported? Linux only for now. Need full control over Kubernetes features like custom operators or advanced networking policies? AKS is your answer. Have existing Helm charts that your team relies on? Container apps doesn't support Helm. Need specific custom resource definitions? Same limitation. These are real constraints and they matter for certain workloads. But here's the bottom line. If you're asking yourself should I use Azure Container apps? The answer is probably yes for most new projects. Start there. Move to AKS only if you hit a wall that container apps can't handle. And most people never hit that wall. Let's talk about the part everyone cares about. Cost. The cost story. Predictable and often cheaper. As your container apps gives you two pricing plans and the one you pick depends on how your app behaves. First is the consumption plan, pay per use. You're charged per second for active CPU and memory. If your container is processing a request, you pay. If it's sitting idle, you pay a lower idle rate. If it scales to zero, which it can, you pay nothing at all. No traffic, no cost. The first two million requests per month are free per subscription. That's enough to run a small API or development environment without spending a dime. This plan is perfect for low traffic apps, batch jobs that run occasionally or development and testing where you don't want to pay for always on compute. Then there's the dedicated plan. You commit to a workload profile with specific VMs, general purpose, memory optimized, that kind of thing. You pay per hour for that reserved compute whether your containers are using it or not. The tradeoff is predictable performance, no cold starts, no contention for resources. This plan is better for steady production workloads where you need consistent response times and you know your traffic patterns. So how does container apps compare to the alternatives? App service has similar pricing for simple apps, but container apps scales better. App service always keeps at least one instance running. You're paying for that idle instance even when no one is visiting your site. Container apps can scale to zero. AKS is cheaper per unit of compute. The raw VM costs are lower. If you pay cluster management fees on top and more importantly, you pay in engineering hours. Someone has to manage that cluster. A common real world example. A small SAS application running on AKS with Azure SQL costs around $300 per month in infrastructure plus 20 plus hours of engineering time per month just to keep it running. Container apps can run that same workload for a fraction of the cost with almost zero operational overhead. Studies on serverless containers show they deliver 38 to 57% lower total cost compared to traditional server based setups once you factor in the labor savings. For small businesses and solo developers, that's the real game changer. You're not just saving on compute. You're saving on the time you'd otherwise spend managing infrastructure. So how do you actually get started? Let's keep it simple. Getting started. The three step process. Today we're getting your first container app up and running. It's actually pretty simple. Three main steps and you'll be live. First, you need a container apps environment. This is a one time setup. Pick your Azure region, then choose your workload profile, consumption or dedicated. And decide on your networking options. Do you want public access or private networking inside a virtual network? This environment acts like the secure boundary for all your container apps. Think of it as the neighborhood where your containers live. Second, deploy your container. You pull your container image from a registry like Azure container registry, Docker Hub or any other registry that supports OCI images. If you're using the container app build feature, you can even deploy directly from source code. You have choices for how to do the deployment through the Azure portal with guided visits through the Azure CLI with a single command through the VS code extension or through a CICD pipeline. Pick whatever works for you. Third, configure ingress and scaling. Turn on HTTP ingress to make your app accessible from the internet. Or keep it internal for private services. Decide whether traffic comes from anywhere or only from within your virtual network. Then set your scaling rules. Minimum and maximum replicas, CPU or memory thresholds or let Keta handle it automatically based on events. That's it. Your container app is live. Here's the thing. The Azure portal handles most of the complexity with step-by-step wizards. If you prefer command line tools, the Azure CLI can have you up and running in under 10 minutes. Once it's deployed, you don't think about the infrastructure again. Azure handles the rest. So let's wrap this up. Azure container apps gives you modern container deployment without needing to become a Kubernetes expert. It sits right between simple container hosting and full cluster management. For most new projects, whether it's an API, a microservice or an event-driven app, it's the smart default. It's with a container, deploy it to an environment and let Azure handle the rest. If you've been avoiding containers because of the complexity, this is your green light. Subscribe for more plain English breakdowns and share this with someone just starting their cloud journey.