1 00:00:00,000 --> 00:00:01,140 Welcome to another episode. 2 00:00:01,140 --> 00:00:02,400 I'm your host, Mirko Peters. 3 00:00:02,400 --> 00:00:03,840 Today we're talking about containers, 4 00:00:03,840 --> 00:00:06,680 specifically the middle ground most people don't know exists. 5 00:00:06,680 --> 00:00:07,840 What if you could run containers 6 00:00:07,840 --> 00:00:11,040 with all the power of Kubernetes without managing any of it? 7 00:00:11,040 --> 00:00:13,000 No cluster setup, no node pools, 8 00:00:13,000 --> 00:00:15,080 no YAML files that read like a foreign language? 9 00:00:15,080 --> 00:00:17,640 Most people think containers work one of two ways. 10 00:00:17,640 --> 00:00:19,480 You either deploy something simple, 11 00:00:19,480 --> 00:00:21,160 a single container running one task, 12 00:00:21,160 --> 00:00:22,560 or you go all in on Kubernetes, 13 00:00:22,560 --> 00:00:24,800 which means hiring someone who actually understands it. 14 00:00:24,800 --> 00:00:26,760 But what if you wanted modern container features 15 00:00:26,760 --> 00:00:29,080 without becoming a Kubernetes admin overnight? 16 00:00:29,080 --> 00:00:31,480 That's exactly the gap as your container apps fills. 17 00:00:31,480 --> 00:00:34,560 Let me show you the problem first, then the solution. 18 00:00:34,560 --> 00:00:36,320 The container evolution problem. 19 00:00:36,320 --> 00:00:39,480 20 years ago, almost every application was a monolith. 20 00:00:39,480 --> 00:00:41,880 One big piece of software running on one server, 21 00:00:41,880 --> 00:00:43,120 the database, the front end, 22 00:00:43,120 --> 00:00:45,400 the business logic, all bundled together 23 00:00:45,400 --> 00:00:47,200 for a long time that worked fine. 24 00:00:47,200 --> 00:00:48,280 But as applications grew, 25 00:00:48,280 --> 00:00:51,000 developers started breaking them into smaller pieces, 26 00:00:51,000 --> 00:00:53,200 microservices, independent components 27 00:00:53,200 --> 00:00:55,640 that could be built, deployed, and scaled separately. 28 00:00:55,640 --> 00:00:57,280 That solved a lot of problems, 29 00:00:57,280 --> 00:00:59,280 but it created a new one. 30 00:00:59,280 --> 00:01:01,080 How do you manage all those pieces? 31 00:01:01,080 --> 00:01:02,640 How do you make sure they talk to each other, 32 00:01:02,640 --> 00:01:05,120 scale independently and don't crash when traffic spikes? 33 00:01:05,120 --> 00:01:07,600 Containers came along and solved the packaging problem. 34 00:01:07,600 --> 00:01:10,200 They let you bundle your app with everything it needs to run, 35 00:01:10,200 --> 00:01:12,560 libraries, dependencies, configuration, 36 00:01:12,560 --> 00:01:13,840 into one portable unit, 37 00:01:13,840 --> 00:01:16,640 but containers alone don't tell you how to run them at scale. 38 00:01:16,640 --> 00:01:19,000 That's where orchestration comes in, and here's the thing. 39 00:01:19,000 --> 00:01:20,840 The industry gave us two extremes. 40 00:01:20,840 --> 00:01:22,840 On one side, simple container hosting. 41 00:01:22,840 --> 00:01:24,640 Services like Azure Container instances 42 00:01:24,640 --> 00:01:27,000 let you spin up a single container, run a job, 43 00:01:27,000 --> 00:01:27,840 and shut it down. 44 00:01:27,840 --> 00:01:30,680 No orchestration, no scaling, no load balancing. 45 00:01:30,680 --> 00:01:33,200 On the other side, full blown Kubernetes. 46 00:01:33,200 --> 00:01:35,560 Azure Kubernetes service gives you complete control 47 00:01:35,560 --> 00:01:36,880 over everything. 48 00:01:36,880 --> 00:01:38,920 Nodes, networking, security policies, 49 00:01:38,920 --> 00:01:40,120 the whole kitchen sink. 50 00:01:40,120 --> 00:01:41,360 But it comes with the price. 51 00:01:41,360 --> 00:01:43,120 You need a dedicated team to manage it. 52 00:01:43,120 --> 00:01:44,720 Most people don't need either extreme. 53 00:01:44,720 --> 00:01:46,280 They want something in the middle, 54 00:01:46,280 --> 00:01:47,880 and that middle ground is exactly where 55 00:01:47,880 --> 00:01:49,360 Azure Container apps lives. 56 00:01:49,360 --> 00:01:52,320 The three options, a quick map. 57 00:01:52,320 --> 00:01:54,360 So what are your choices when you want to run containers 58 00:01:54,360 --> 00:01:55,200 on Azure? 59 00:01:55,200 --> 00:01:56,040 There are three main options, 60 00:01:56,040 --> 00:01:58,680 and knowing the difference is what helps you pick the right one. 61 00:01:58,680 --> 00:02:01,600 Option one, Azure Container instances or ACI. 62 00:02:01,600 --> 00:02:02,960 This is the simplest path. 63 00:02:02,960 --> 00:02:06,280 You take a container image, deploy it, and it runs. 64 00:02:06,280 --> 00:02:08,760 No scaling rules, no load balancing, no orchestration. 65 00:02:08,760 --> 00:02:10,760 Perfect for one-off jobs like batch processing, 66 00:02:10,760 --> 00:02:13,520 running a quick test, or processing a file, and shutting down. 67 00:02:13,520 --> 00:02:15,760 But if your app needs to stay running and handle traffic, 68 00:02:15,760 --> 00:02:17,440 ACI isn't built for that. 69 00:02:17,440 --> 00:02:20,200 Option two, Azure Kubernetes service, or AKS. 70 00:02:20,200 --> 00:02:21,960 This is the full Kubernetes experience. 71 00:02:21,960 --> 00:02:24,000 You get complete control over every layer, 72 00:02:24,000 --> 00:02:26,760 the nodes, the networking, the security policies, 73 00:02:26,760 --> 00:02:27,720 the upgrade strategy. 74 00:02:27,720 --> 00:02:29,480 You can do anything with AKS. 75 00:02:29,480 --> 00:02:30,880 But you also have to do everything. 76 00:02:30,880 --> 00:02:33,600 You need a dedicated operations team to manage the cluster, 77 00:02:33,600 --> 00:02:35,400 handle upgrades, monitor node health, 78 00:02:35,400 --> 00:02:37,280 and troubleshoot networking issues. 79 00:02:37,280 --> 00:02:40,480 Powerful, but expensive, both in compute costs, 80 00:02:40,480 --> 00:02:42,920 and in the engineering hours to keep it running. 81 00:02:42,920 --> 00:02:45,040 Option three, Azure Container apps. 82 00:02:45,040 --> 00:02:46,400 This sits right in the middle. 83 00:02:46,400 --> 00:02:48,280 You get Kubernetes level features, 84 00:02:48,280 --> 00:02:51,280 automatic scaling, load balancing, in-grass rolling updates, 85 00:02:51,280 --> 00:02:53,200 but Microsoft manages the cluster for you. 86 00:02:53,200 --> 00:02:54,640 You handle the application. 87 00:02:54,640 --> 00:02:56,720 Microsoft handles everything underneath. 88 00:02:56,720 --> 00:02:57,560 Here's the thing. 89 00:02:57,560 --> 00:02:59,360 For most container workloads, this is more than enough. 90 00:02:59,360 --> 00:03:01,760 Some estimates say container apps covers about 80% 91 00:03:01,760 --> 00:03:03,440 of what people typically need containers for. 92 00:03:03,440 --> 00:03:06,040 Think of it like renting a car versus buying a truck. 93 00:03:06,040 --> 00:03:07,880 ACI is a sedan for a quick errand. 94 00:03:07,880 --> 00:03:10,680 Gets the job done, but you wouldn't use it for heavy lifting. 95 00:03:10,680 --> 00:03:13,640 AKS is a fully loaded truck with a mechanic on retainer. 96 00:03:13,640 --> 00:03:15,880 You can haul anything, but you're paying for the truck, 97 00:03:15,880 --> 00:03:18,640 insurance, and mechanic, whether you're using it or not. 98 00:03:18,640 --> 00:03:20,160 Container apps is an SUV. 99 00:03:20,160 --> 00:03:22,480 Enough power for most jobs, and when you're done, 100 00:03:22,480 --> 00:03:24,480 you hand the keys back and stop paying. 101 00:03:24,480 --> 00:03:26,680 No maintenance, no storage costs, no mechanic. 102 00:03:26,680 --> 00:03:29,920 Now let's pop the hood and see what container apps is made of. 103 00:03:29,920 --> 00:03:32,280 What Azure Container Apps actually is. 104 00:03:32,280 --> 00:03:33,680 Here's the simplest definition. 105 00:03:33,680 --> 00:03:35,760 Azure Container Apps is a fully managed, 106 00:03:35,760 --> 00:03:37,360 serverless container platform 107 00:03:37,360 --> 00:03:39,720 built on top of Azure Kubernetes service. 108 00:03:39,720 --> 00:03:42,320 Microsoft spins up an AKS cluster behind the scenes. 109 00:03:42,320 --> 00:03:44,440 You never touch it, never see it, never patch it, 110 00:03:44,440 --> 00:03:45,720 never worry about it crashing. 111 00:03:45,720 --> 00:03:47,280 You just get the benefits of Kubernetes 112 00:03:47,280 --> 00:03:49,080 without writing a single YAML file. 113 00:03:49,080 --> 00:03:50,760 Three core building blocks make this work. 114 00:03:50,760 --> 00:03:52,480 Let's go through them one at a time. 115 00:03:52,480 --> 00:03:53,400 Environments. 116 00:03:53,400 --> 00:03:56,080 Think of an environment as your digital neighborhood. 117 00:03:56,080 --> 00:03:59,360 It's a secure boundary that groups your container apps together. 118 00:03:59,360 --> 00:04:01,800 All the apps inside one environment can talk to each other, 119 00:04:01,800 --> 00:04:05,080 share networking settings, and live under the same security rules. 120 00:04:05,080 --> 00:04:08,480 You can even deploy into a virtual network for extra protection, 121 00:04:08,480 --> 00:04:11,560 keeping your containers completely isolated from the public internet 122 00:04:11,560 --> 00:04:12,400 if you need to. 123 00:04:12,400 --> 00:04:16,080 Containers, these are your actual applications running inside the environment. 124 00:04:16,080 --> 00:04:18,480 Each container app can have multiple revisions. 125 00:04:18,480 --> 00:04:20,680 Think of revisions as version snapshots. 126 00:04:20,680 --> 00:04:22,640 You deploy a new version of your app, 127 00:04:22,640 --> 00:04:24,600 and Azure creates a new revision. 128 00:04:24,600 --> 00:04:25,720 The old one stays around. 129 00:04:25,720 --> 00:04:28,720 That means you can roll back instantly if something breaks. 130 00:04:28,720 --> 00:04:30,920 You can even split traffic between revisions, 131 00:04:30,920 --> 00:04:33,160 send 10% of users to the new version, 132 00:04:33,160 --> 00:04:34,560 while the rest stay on the old one. 133 00:04:34,560 --> 00:04:37,800 That's blue-green deployment built right in no extra tools required. 134 00:04:37,800 --> 00:04:40,640 Workload profiles, these are the underlying compute resources. 135 00:04:40,640 --> 00:04:41,720 You get two options. 136 00:04:41,720 --> 00:04:45,360 The consumption profile charges you per second for active CPU and memory, 137 00:04:45,360 --> 00:04:46,760 and it can scale to zero. 138 00:04:46,760 --> 00:04:48,520 No traffic means no cost. 139 00:04:48,520 --> 00:04:50,720 Perfect for apps that aren't running all the time. 140 00:04:50,720 --> 00:04:54,160 The dedicated profile gives you reserved VMs for predictable performance. 141 00:04:54,160 --> 00:04:57,240 You pay per hour, but you get consistent compute power. 142 00:04:57,240 --> 00:04:58,840 Choose whichever fits your workload. 143 00:04:58,840 --> 00:05:02,320 Now, everything runs on top of three open source technologies. 144 00:05:02,320 --> 00:05:04,200 Kubernetes is the orchestration engine. 145 00:05:04,200 --> 00:05:07,120 Handles scheduling, scaling, and keeping your containers running. 146 00:05:07,120 --> 00:05:09,160 Keda handles event-driven scaling. 147 00:05:09,160 --> 00:05:11,400 DAPER manages microservice communication, 148 00:05:11,400 --> 00:05:14,560 service discovery, state management, pub-sub messaging. 149 00:05:14,560 --> 00:05:16,720 Microsoft wraps all of this in a simple API. 150 00:05:16,720 --> 00:05:20,400 You just deploy your container and everything underneath works automatically. 151 00:05:20,400 --> 00:05:22,560 Those three technologies are worth a closer look. 152 00:05:22,560 --> 00:05:24,440 We'll dive into each one next. 153 00:05:24,440 --> 00:05:27,160 The secret source, Keda, DAPER, and Envoy. 154 00:05:27,160 --> 00:05:28,200 Let's start with Keda. 155 00:05:28,200 --> 00:05:30,640 It stands for Kubernetes Event-driven auto-scaling. 156 00:05:30,640 --> 00:05:35,200 And in plain English, it's probably the most useful feature of container apps for most people. 157 00:05:35,200 --> 00:05:35,920 Here's why. 158 00:05:35,920 --> 00:05:38,760 Traditional auto-scaling watches CPU or memory. 159 00:05:38,760 --> 00:05:41,720 If your CPU hits 80%, spin up another instance. 160 00:05:41,720 --> 00:05:43,080 That works, but it's reactive. 161 00:05:43,080 --> 00:05:46,360 By the time your CPU is high, your users have already felt the lag. 162 00:05:46,360 --> 00:05:47,480 Keda flips that model. 163 00:05:47,480 --> 00:05:49,240 It scales based on real events. 164 00:05:49,240 --> 00:05:51,160 More messages arriving in a queue. 165 00:05:51,160 --> 00:05:52,160 More containers spin up. 166 00:05:52,160 --> 00:05:53,480 A spike in HTTP traffic. 167 00:05:53,480 --> 00:05:54,480 Scale out. 168 00:05:54,480 --> 00:05:55,480 No traffic at all. 169 00:05:55,480 --> 00:05:56,480 Scale down to zero. 170 00:05:56,480 --> 00:05:57,480 You pay nothing when nothing is happening. 171 00:05:57,480 --> 00:06:01,720 Keda can watch queue length, HTTP request rate, custom metrics from Prometheus. 172 00:06:01,720 --> 00:06:02,720 Almost anything you can measure. 173 00:06:02,720 --> 00:06:06,240 It's the difference between preventing a problem and reacting to one. 174 00:06:06,240 --> 00:06:09,280 Now, think of DAPER as a toolkit for building microservices. 175 00:06:09,280 --> 00:06:12,280 It stands for distributed application runtime. 176 00:06:12,280 --> 00:06:14,680 But let's call it your microservices sidekick. 177 00:06:14,680 --> 00:06:17,840 DAPER handles the hard parts every distributed app needs. 178 00:06:17,840 --> 00:06:19,120 State management. 179 00:06:19,120 --> 00:06:21,200 Saving and retrieving data across services. 180 00:06:21,200 --> 00:06:22,520 Pub/Sub messaging. 181 00:06:22,520 --> 00:06:24,240 One service sends a message. 182 00:06:24,240 --> 00:06:25,640 Others receive it. 183 00:06:25,640 --> 00:06:26,800 Service discovery. 184 00:06:26,800 --> 00:06:29,840 Services finding and talking to each other without hard coded addresses. 185 00:06:29,840 --> 00:06:30,840 The best part? 186 00:06:30,840 --> 00:06:33,080 You don't need to rewrite your app to use it. 187 00:06:33,080 --> 00:06:34,880 DAPER runs as a sidecar. 188 00:06:34,880 --> 00:06:38,840 A separate container that sits alongside your application container. 189 00:06:38,840 --> 00:06:42,240 Your app talks to DAPER through simple HTTP or GRPC calls. 190 00:06:42,240 --> 00:06:46,080 So instead of writing complex code to save state to readers, your app just asks DAPER to do 191 00:06:46,080 --> 00:06:47,080 it. 192 00:06:47,080 --> 00:06:48,080 DAPER handles the rest. 193 00:06:48,080 --> 00:06:49,080 Then there's Envoy. 194 00:06:49,080 --> 00:06:50,280 Envoy is the traffic controller. 195 00:06:50,280 --> 00:06:51,560 It manages ingress. 196 00:06:51,560 --> 00:06:54,320 How requests get from the internet to your container? 197 00:06:54,320 --> 00:06:58,880 It handles TLS termination automatically so you don't need to manage certificates yourself. 198 00:06:58,880 --> 00:07:00,920 And it enables traffic splitting between revisions. 199 00:07:00,920 --> 00:07:04,280 One to send 5% of traffic to a new version to test it. 200 00:07:04,280 --> 00:07:07,840 Envoy turns that into a configuration setting, not a networking nightmare. 201 00:07:07,840 --> 00:07:11,520 These three together give you automatic scaling based on what actually matters. 202 00:07:11,520 --> 00:07:16,360 In micro service capabilities without writing micro service plumbing and secure manage traffic 203 00:07:16,360 --> 00:07:17,360 rooting. 204 00:07:17,360 --> 00:07:21,240 In raw Kubernetes, this would take months, months of reading documentation, configuring 205 00:07:21,240 --> 00:07:25,520 ingress controllers, setting up monitoring, debugging scaling issues. 206 00:07:25,520 --> 00:07:26,880 Container apps gives it to you for free. 207 00:07:26,880 --> 00:07:29,880 You just deploy your container and the platform handles the rest. 208 00:07:29,880 --> 00:07:33,960 Now you might have heard container apps described as Kubernetes without Kubernetes. 209 00:07:33,960 --> 00:07:35,440 Let's clear that myth up. 210 00:07:35,440 --> 00:07:37,600 The Kubernetes without Kubernetes myth. 211 00:07:37,600 --> 00:07:39,000 It's a popular phrase. 212 00:07:39,000 --> 00:07:40,600 Kubernetes without Kubernetes. 213 00:07:40,600 --> 00:07:42,000 But it needs some qualification. 214 00:07:42,000 --> 00:07:45,680 There's a big difference between what it actually means and what people assume it means. 215 00:07:45,680 --> 00:07:46,680 Here's what's true. 216 00:07:46,680 --> 00:07:50,000 You get the power of Kubernetes orchestration without managing clusters. 217 00:07:50,000 --> 00:07:54,360 Scaling, load balancing, ingress, rolling updates, all handled automatically. 218 00:07:54,360 --> 00:07:55,840 You don't need to know what a CUBALATE is. 219 00:07:55,840 --> 00:08:00,480 You don't need to worry about ETCD clusters or control plane availability or node drain operations. 220 00:08:00,480 --> 00:08:03,120 That stuff just works behind the scenes and you never think about it. 221 00:08:03,120 --> 00:08:04,520 But here's what's not true. 222 00:08:04,520 --> 00:08:06,720 You do not get full Kubernetes flexibility. 223 00:08:06,720 --> 00:08:07,800 And that distinction matters. 224 00:08:07,800 --> 00:08:09,840 You can't install custom Kubernetes plugins. 225 00:08:09,840 --> 00:08:11,440 There's no access to the control plane. 226 00:08:11,440 --> 00:08:13,000 It's completely locked down. 227 00:08:13,000 --> 00:08:16,880 You're limited to about 10 to 12 VM sizes for your workload profiles. 228 00:08:16,880 --> 00:08:21,480 No help charts, which is a big one if your team already uses help to manage deployments. 229 00:08:21,480 --> 00:08:24,320 And no custom resource definitions or CRDs. 230 00:08:24,320 --> 00:08:29,200 If your application depends on a Kubernetes operator that adds custom resources to the cluster, 231 00:08:29,200 --> 00:08:30,320 container apps won't support it. 232 00:08:30,320 --> 00:08:31,520 So what does this mean for you? 233 00:08:31,520 --> 00:08:36,600 For most web apps, APIs and microservices, container apps gives you more than enough power. 234 00:08:36,600 --> 00:08:41,560 You get auto scaling, ingress, revision management, secrets, environment variables, everything 235 00:08:41,560 --> 00:08:44,040 you need for a modern application in production. 236 00:08:44,040 --> 00:08:47,280 But for specialized or complex scenarios, AKS might still be necessary. 237 00:08:47,280 --> 00:08:51,000 If you need full control over how Kubernetes behaves at every layer, container apps isn't 238 00:08:51,000 --> 00:08:52,000 designed for that. 239 00:08:52,000 --> 00:08:53,920 Here's a practical rule of thumb. 240 00:08:53,920 --> 00:08:55,400 Ask yourself three questions. 241 00:08:55,400 --> 00:08:58,920 Do you need full control over nodes, networking and security policies? 242 00:08:58,920 --> 00:08:59,920 Go with AKS. 243 00:08:59,920 --> 00:09:03,480 Do you want a hassle free way to run modern containerized applications? 244 00:09:03,480 --> 00:09:04,880 Container apps is your answer. 245 00:09:04,880 --> 00:09:09,000 You just need to run one container occasionally for a batch job or a quick test, stick with 246 00:09:09,000 --> 00:09:11,920 ACI, most people land in that middle bucket. 247 00:09:11,920 --> 00:09:13,960 And that's exactly where container apps shines. 248 00:09:13,960 --> 00:09:16,440 Let's make this concrete with real scenarios. 249 00:09:16,440 --> 00:09:18,440 When you should actually use it. 250 00:09:18,440 --> 00:09:23,520 Today we're walking through four scenarios where container apps truly shines and a couple 251 00:09:23,520 --> 00:09:25,280 where you should look elsewhere. 252 00:09:25,280 --> 00:09:26,480 First scenario. 253 00:09:26,480 --> 00:09:28,160 You're building a public API. 254 00:09:28,160 --> 00:09:30,800 You want something that handles traffic spikes automatically. 255 00:09:30,800 --> 00:09:34,480 Deploys updates without downtime, manages HTTPS certificates for you. 256 00:09:34,480 --> 00:09:36,680 There are apps handles all of that out of the box. 257 00:09:36,680 --> 00:09:38,840 Auto scaling kicks in when traffic spikes. 258 00:09:38,840 --> 00:09:42,720 Traffic splitting between revisions means you can roll out a new version to a small percentage 259 00:09:42,720 --> 00:09:44,720 of users, watch it, then ramp up. 260 00:09:44,720 --> 00:09:48,240 Built in TLS termination means you don't have to mess with certificate management. 261 00:09:48,240 --> 00:09:52,720 No lets encrypt scripts, no renewal reminders, it just works. 262 00:09:52,720 --> 00:09:53,720 Second scenario. 263 00:09:53,720 --> 00:09:55,320 You need event-driven processing. 264 00:09:55,320 --> 00:09:59,240 Maybe you have files landing in blob storage that need to be processed or messages arriving 265 00:09:59,240 --> 00:10:01,120 in a queue that need to be handled. 266 00:10:01,120 --> 00:10:05,560 Container apps through KIDA watches those events and spins containers up or down automatically. 267 00:10:05,560 --> 00:10:10,080 A file arrives, a container processes it and when the queue is empty the container scales 268 00:10:10,080 --> 00:10:11,080 to zero. 269 00:10:11,080 --> 00:10:12,880 You only pay for the seconds it was actually working. 270 00:10:12,880 --> 00:10:16,680 That's a real game changer for background processing workloads. 271 00:10:16,680 --> 00:10:17,680 Third scenario. 272 00:10:17,680 --> 00:10:18,720 You're running microservices. 273 00:10:18,720 --> 00:10:21,520 DAPR handles service to service communication. 274 00:10:21,520 --> 00:10:22,520 State management. 275 00:10:22,520 --> 00:10:23,520 Pub/sub messaging. 276 00:10:23,520 --> 00:10:24,520 Retrieves with back off. 277 00:10:24,520 --> 00:10:25,520 It's all built in. 278 00:10:25,520 --> 00:10:29,080 Each microservice scales independently based on its own traffic patterns. 279 00:10:29,080 --> 00:10:32,400 The payment service doesn't need to scale just because the catalog service is getting hammered. 280 00:10:32,400 --> 00:10:36,200 They each do their own thing and because DAPR runs as a sidecar you don't have to change 281 00:10:36,200 --> 00:10:38,200 your application code to get these features. 282 00:10:38,200 --> 00:10:39,200 Fourth scenario. 283 00:10:39,200 --> 00:10:40,200 Small team. 284 00:10:40,200 --> 00:10:41,200 Big ambitions. 285 00:10:41,200 --> 00:10:42,200 This is the one I hear about most often. 286 00:10:42,200 --> 00:10:45,560 A team of two or three developers who want to build modern applications but don't have 287 00:10:45,560 --> 00:10:47,680 a dedicated DevOps person. 288 00:10:47,680 --> 00:10:49,600 Container apps doesn't require one. 289 00:10:49,600 --> 00:10:52,840 Developers can deploy directly from Visual Studio or VS code. 290 00:10:52,840 --> 00:10:56,720 The infrastructure team, if they even is one, doesn't need to be involved in every container 291 00:10:56,720 --> 00:10:59,720 deployment. 292 00:10:59,720 --> 00:11:02,040 There are times when container apps isn't the right fit. 293 00:11:02,040 --> 00:11:03,760 Need Windows containers not supported? 294 00:11:03,760 --> 00:11:05,040 Linux only for now. 295 00:11:05,040 --> 00:11:09,240 Need full control over Kubernetes features like custom operators or advanced networking policies? 296 00:11:09,240 --> 00:11:10,320 AKS is your answer. 297 00:11:10,320 --> 00:11:12,840 Have existing Helm charts that your team relies on? 298 00:11:12,840 --> 00:11:14,440 Container apps doesn't support Helm. 299 00:11:14,440 --> 00:11:16,680 Need specific custom resource definitions? 300 00:11:16,680 --> 00:11:17,680 Same limitation. 301 00:11:17,680 --> 00:11:20,560 These are real constraints and they matter for certain workloads. 302 00:11:20,560 --> 00:11:21,840 But here's the bottom line. 303 00:11:21,840 --> 00:11:24,840 If you're asking yourself should I use Azure Container apps? 304 00:11:24,840 --> 00:11:27,320 The answer is probably yes for most new projects. 305 00:11:27,320 --> 00:11:28,320 Start there. 306 00:11:28,320 --> 00:11:31,280 Move to AKS only if you hit a wall that container apps can't handle. 307 00:11:31,280 --> 00:11:32,880 And most people never hit that wall. 308 00:11:32,880 --> 00:11:34,920 Let's talk about the part everyone cares about. 309 00:11:34,920 --> 00:11:35,920 Cost. 310 00:11:35,920 --> 00:11:36,920 The cost story. 311 00:11:36,920 --> 00:11:38,640 Predictable and often cheaper. 312 00:11:38,640 --> 00:11:42,480 As your container apps gives you two pricing plans and the one you pick depends on how 313 00:11:42,480 --> 00:11:44,000 your app behaves. 314 00:11:44,000 --> 00:11:46,160 First is the consumption plan, pay per use. 315 00:11:46,160 --> 00:11:48,920 You're charged per second for active CPU and memory. 316 00:11:48,920 --> 00:11:51,440 If your container is processing a request, you pay. 317 00:11:51,440 --> 00:11:54,200 If it's sitting idle, you pay a lower idle rate. 318 00:11:54,200 --> 00:11:57,360 If it scales to zero, which it can, you pay nothing at all. 319 00:11:57,360 --> 00:11:58,640 No traffic, no cost. 320 00:11:58,640 --> 00:12:01,640 The first two million requests per month are free per subscription. 321 00:12:01,640 --> 00:12:06,000 That's enough to run a small API or development environment without spending a dime. 322 00:12:06,000 --> 00:12:10,000 This plan is perfect for low traffic apps, batch jobs that run occasionally or development 323 00:12:10,000 --> 00:12:13,040 and testing where you don't want to pay for always on compute. 324 00:12:13,040 --> 00:12:14,440 Then there's the dedicated plan. 325 00:12:14,440 --> 00:12:19,160 You commit to a workload profile with specific VMs, general purpose, memory optimized, that 326 00:12:19,160 --> 00:12:20,160 kind of thing. 327 00:12:20,160 --> 00:12:23,600 You pay per hour for that reserved compute whether your containers are using it or not. 328 00:12:23,600 --> 00:12:27,840 The tradeoff is predictable performance, no cold starts, no contention for resources. 329 00:12:27,840 --> 00:12:31,760 This plan is better for steady production workloads where you need consistent response times 330 00:12:31,760 --> 00:12:33,400 and you know your traffic patterns. 331 00:12:33,400 --> 00:12:36,360 So how does container apps compare to the alternatives? 332 00:12:36,360 --> 00:12:40,400 App service has similar pricing for simple apps, but container apps scales better. 333 00:12:40,400 --> 00:12:43,280 App service always keeps at least one instance running. 334 00:12:43,280 --> 00:12:46,920 You're paying for that idle instance even when no one is visiting your site. 335 00:12:46,920 --> 00:12:48,480 Container apps can scale to zero. 336 00:12:48,480 --> 00:12:50,600 AKS is cheaper per unit of compute. 337 00:12:50,600 --> 00:12:52,480 The raw VM costs are lower. 338 00:12:52,480 --> 00:12:56,920 If you pay cluster management fees on top and more importantly, you pay in engineering hours. 339 00:12:56,920 --> 00:12:58,920 Someone has to manage that cluster. 340 00:12:58,920 --> 00:13:00,640 A common real world example. 341 00:13:00,640 --> 00:13:06,240 A small SAS application running on AKS with Azure SQL costs around $300 per month in infrastructure 342 00:13:06,240 --> 00:13:10,840 plus 20 plus hours of engineering time per month just to keep it running. 343 00:13:10,840 --> 00:13:14,520 Container apps can run that same workload for a fraction of the cost with almost zero 344 00:13:14,520 --> 00:13:16,360 operational overhead. 345 00:13:16,360 --> 00:13:21,400 Studies on serverless containers show they deliver 38 to 57% lower total cost compared 346 00:13:21,400 --> 00:13:25,280 to traditional server based setups once you factor in the labor savings. 347 00:13:25,280 --> 00:13:28,160 For small businesses and solo developers, that's the real game changer. 348 00:13:28,160 --> 00:13:29,560 You're not just saving on compute. 349 00:13:29,560 --> 00:13:32,480 You're saving on the time you'd otherwise spend managing infrastructure. 350 00:13:32,480 --> 00:13:33,920 So how do you actually get started? 351 00:13:33,920 --> 00:13:35,560 Let's keep it simple. 352 00:13:35,560 --> 00:13:36,600 Getting started. 353 00:13:36,600 --> 00:13:38,040 The three step process. 354 00:13:38,040 --> 00:13:40,720 Today we're getting your first container app up and running. 355 00:13:40,720 --> 00:13:41,800 It's actually pretty simple. 356 00:13:41,800 --> 00:13:43,440 Three main steps and you'll be live. 357 00:13:43,440 --> 00:13:45,560 First, you need a container apps environment. 358 00:13:45,560 --> 00:13:46,920 This is a one time setup. 359 00:13:46,920 --> 00:13:51,360 Pick your Azure region, then choose your workload profile, consumption or dedicated. 360 00:13:51,360 --> 00:13:53,120 And decide on your networking options. 361 00:13:53,120 --> 00:13:56,720 Do you want public access or private networking inside a virtual network? 362 00:13:56,720 --> 00:14:00,280 This environment acts like the secure boundary for all your container apps. 363 00:14:00,280 --> 00:14:02,640 Think of it as the neighborhood where your containers live. 364 00:14:02,640 --> 00:14:04,400 Second, deploy your container. 365 00:14:04,400 --> 00:14:07,840 You pull your container image from a registry like Azure container registry, 366 00:14:07,840 --> 00:14:10,960 Docker Hub or any other registry that supports OCI images. 367 00:14:10,960 --> 00:14:15,560 If you're using the container app build feature, you can even deploy directly from source code. 368 00:14:15,560 --> 00:14:19,320 You have choices for how to do the deployment through the Azure portal with guided 369 00:14:19,320 --> 00:14:23,800 visits through the Azure CLI with a single command through the VS code extension 370 00:14:23,800 --> 00:14:25,840 or through a CICD pipeline. 371 00:14:25,840 --> 00:14:27,200 Pick whatever works for you. 372 00:14:27,200 --> 00:14:29,440 Third, configure ingress and scaling. 373 00:14:29,440 --> 00:14:33,320 Turn on HTTP ingress to make your app accessible from the internet. 374 00:14:33,320 --> 00:14:35,320 Or keep it internal for private services. 375 00:14:35,320 --> 00:14:39,480 Decide whether traffic comes from anywhere or only from within your virtual network. 376 00:14:39,480 --> 00:14:40,960 Then set your scaling rules. 377 00:14:40,960 --> 00:14:44,360 Minimum and maximum replicas, CPU or memory thresholds or 378 00:14:44,360 --> 00:14:46,920 let Keta handle it automatically based on events. 379 00:14:46,920 --> 00:14:47,520 That's it. 380 00:14:47,520 --> 00:14:48,920 Your container app is live. 381 00:14:48,920 --> 00:14:50,120 Here's the thing. 382 00:14:50,120 --> 00:14:53,720 The Azure portal handles most of the complexity with step-by-step wizards. 383 00:14:53,720 --> 00:14:58,960 If you prefer command line tools, the Azure CLI can have you up and running in under 10 minutes. 384 00:14:58,960 --> 00:15:01,840 Once it's deployed, you don't think about the infrastructure again. 385 00:15:01,840 --> 00:15:03,040 Azure handles the rest. 386 00:15:03,040 --> 00:15:04,520 So let's wrap this up. 387 00:15:04,520 --> 00:15:08,240 Azure container apps gives you modern container deployment without needing to become a Kubernetes 388 00:15:08,240 --> 00:15:09,240 expert. 389 00:15:09,240 --> 00:15:12,680 It sits right between simple container hosting and full cluster management. 390 00:15:12,680 --> 00:15:17,320 For most new projects, whether it's an API, a microservice or an event-driven app, it's 391 00:15:17,320 --> 00:15:18,800 the smart default. 392 00:15:18,800 --> 00:15:22,760 It's with a container, deploy it to an environment and let Azure handle the rest. 393 00:15:22,760 --> 00:15:26,000 If you've been avoiding containers because of the complexity, this is your green light. 394 00:15:26,000 --> 00:15:29,440 Subscribe for more plain English breakdowns and share this with someone just starting 395 00:15:29,440 --> 00:15:30,240 their cloud journey.