July 17, 2026
Azure Container Apps - Simply Explained
Azure Container Apps make it possible to run modern containerized applications without the operational complexity of managing Kubernetes clusters. Instead of worrying about virtual machines, node pools, upgrades, networking, or control planes, developers can focus entirely on building and deploying their applications while Microsoft manages the underlying infrastructure. Sitting between Azure Container Instances and Azure Kubernetes Service (AKS), Azure Container Apps provide an ideal balance of simplicity, scalability, and enterprise-grade capabilities. Whether you're building APIs, microservices, event-driven workloads, or background processing applications, the platform offers automatic scaling, built-in networking, secure deployments, and a true serverless experience that scales with demand.
WHY AZURE CONTAINER APPS EXIST
As software evolved from large monolithic applications to distributed microservices, developers needed a better way to package and deploy applications consistently across different environments. Containers solved the packaging challenge, but managing hundreds of containers introduced an entirely new level of complexity. Traditional Kubernetes provides incredible flexibility but also requires specialized knowledge, ongoing maintenance, and dedicated operations teams. Azure Container Apps were designed to eliminate this operational burden by delivering Kubernetes capabilities through a fully managed platform. Organizations gain automatic orchestration, load balancing, scaling, rolling updates, and high availability without ever touching the Kubernetes control plane. The result is faster deployments, lower operational costs, and significantly reduced infrastructure management.
HOW AZURE CONTAINER APPS WORK
Under the hood, Azure Container Apps are powered by Azure Kubernetes Service, but all cluster management is hidden from the customer. Applications are deployed into secure Container App Environments where multiple services can communicate securely while sharing networking and security settings. Every application supports revisions, allowing new versions to be deployed safely while keeping previous versions available for instant rollback or traffic splitting during blue-green deployments. The platform also supports multiple workload profiles, enabling businesses to choose between pay-per-use consumption pricing with scale-to-zero capabilities or dedicated compute for predictable performance. Combined with built-in HTTPS, automatic ingress, managed identities, secrets management, and deep Azure integration, Azure Container Apps provide nearly everything required to run cloud-native applications in production.
THE POWER OF KEDA, DAPR, AND SERVERLESS SCALING
One of the biggest advantages of Azure Container Apps is its integration with open-source technologies that normally require extensive Kubernetes configuration. KEDA enables event-driven autoscaling, allowing applications to grow and shrink automatically based on HTTP requests, queue messages, Event Hub events, Service Bus messages, or dozens of other triggers. Dapr adds powerful building blocks for microservices, including service discovery, state management, pub/sub messaging, distributed tracing, and resilient communication between services. Envoy manages networking, HTTPS certificates, traffic routing, and revision management automatically. Together, these technologies allow developers to build highly scalable cloud-native solutions while writing significantly less infrastructure code. Instead of managing the platform, teams can focus entirely on delivering business value.
WHEN TO CHOOSE AZURE CONTAINER APPS
Azure Container Apps are an excellent choice for REST APIs, backend services, event-driven processing, SaaS applications, internal business applications, AI services, and microservice architectures. They are particularly valuable for organizations that want Kubernetes functionality without hiring Kubernetes specialists. Small development teams benefit from simplified deployments, automatic scaling, integrated monitoring, and reduced operational overhead, while larger enterprises can accelerate cloud-native adoption with consistent deployment practices. However, organizations requiring deep Kubernetes customization, custom operators, Helm charts, Windows containers, or complete control over cluster networking should still consider Azure Kubernetes Service. For most modern application workloads, though, Azure Container Apps provide the ideal balance between simplicity and enterprise capabilities.
GETTING STARTED WITH AZURE CONTAINER APPS
Getting started with Azure Container Apps is surprisingly straightforward. First, create a Container Apps Environment and select the appropriate networking and workload profile. Next, deploy your container image from Azure Container Registry, Docker Hub, GitHub, or another OCI-compatible registry using the Azure Portal, Azure CLI, Visual Studio Code, or CI/CD pipelines. Finally, configure ingress, authentication, secrets, and scaling rules before publishing your application. From that point onward, Azure automatically handles scaling, infrastructure management, security updates, and platform maintenance. For developers looking to embrace containers without the complexity of Kubernetes administration, Azure Container Apps offer one of the fastest and most productive paths into modern cloud-native application development on Microsoft Azure.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
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.
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.
