Azure Container Apps - Simply Explained

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.