WEBVTT

1
00:00:00.080 --> 00:00:03.600
<v Speaker 1>You know that feeling you've got like a pile of articles,

2
00:00:03.640 --> 00:00:07.519
<v Speaker 1>maybe some research papers, notes scattered everywhere, all on a

3
00:00:07.559 --> 00:00:09.759
<v Speaker 1>topic you really need to get your head around fast.

4
00:00:09.880 --> 00:00:11.039
<v Speaker 2>Yeah, it happens all the time.

5
00:00:11.119 --> 00:00:13.960
<v Speaker 1>Well, imagine just handing that stack over to some experts

6
00:00:13.960 --> 00:00:17.800
<v Speaker 1>and like in minutes, getting the absolute essence those real

7
00:00:18.079 --> 00:00:23.120
<v Speaker 1>aha moments, feeling genuinely clued in, big nice. That's exactly

8
00:00:23.120 --> 00:00:26.000
<v Speaker 1>what we're doing in our deep dive today. We're plunging

9
00:00:26.120 --> 00:00:29.800
<v Speaker 1>right into the latest on building powerful apps on Microsoft Azure.

10
00:00:30.199 --> 00:00:33.159
<v Speaker 1>Our source is the brand new Azure for Developers, third

11
00:00:33.280 --> 00:00:38.200
<v Speaker 1>edition by Camille Murzagoud, just out from Packed Publishing, copyright

12
00:00:38.240 --> 00:00:41.240
<v Speaker 1>twenty twenty five, off the presses totally and it's it's

13
00:00:41.240 --> 00:00:43.920
<v Speaker 1>not just a book, right, It's packed with over a

14
00:00:44.000 --> 00:00:48.240
<v Speaker 1>decade of real world experience. Focuses on secure, scalable apps

15
00:00:48.320 --> 00:00:51.920
<v Speaker 1>using all the cool stuff Jenai, Serverla's DevOps pipelines. So

16
00:00:52.159 --> 00:00:54.719
<v Speaker 1>our goal for you today a shortcut, basically a shortcut

17
00:00:54.719 --> 00:00:57.560
<v Speaker 1>to getting good at cloud development on Azure. Whether you're

18
00:00:57.600 --> 00:00:59.920
<v Speaker 1>already a pro, looking to update your skills, or just

19
00:01:00.039 --> 00:01:02.159
<v Speaker 1>starting out, will pull up a key stuff to get

20
00:01:02.159 --> 00:01:04.439
<v Speaker 1>you up to speed. Thinking like a real Azure architect.

21
00:01:04.719 --> 00:01:06.359
<v Speaker 2>Yeah. And what's really cool about it, I think, is

22
00:01:06.359 --> 00:01:08.239
<v Speaker 2>that this book sort of meets you where you are,

23
00:01:08.760 --> 00:01:11.079
<v Speaker 2>but then it takes you deeper. You know, it's not

24
00:01:11.159 --> 00:01:13.680
<v Speaker 2>just the what. It explains, the why gives you that

25
00:01:13.719 --> 00:01:17.599
<v Speaker 2>bigger picture context that's frankly essential with how fast the

26
00:01:17.599 --> 00:01:19.640
<v Speaker 2>cloud changes, helps you connect the dots.

27
00:01:19.719 --> 00:01:22.280
<v Speaker 1>Okay, so let's unpack this starting with the practical stuff,

28
00:01:22.319 --> 00:01:25.680
<v Speaker 1>the foundations before you even think about code. The book

29
00:01:25.760 --> 00:01:27.400
<v Speaker 1>really hammers home getting your.

30
00:01:27.239 --> 00:01:29.680
<v Speaker 2>Local setup right super important.

31
00:01:29.359 --> 00:01:32.040
<v Speaker 1>Like choosing between a free Azure account or pay as

32
00:01:32.079 --> 00:01:35.439
<v Speaker 1>you go. It's not just about cost. It's about setting

33
00:01:35.439 --> 00:01:40.120
<v Speaker 1>yourself up for easy learning versus like full on production.

34
00:01:39.879 --> 00:01:41.760
<v Speaker 2>Scale, different mindset's different needs.

35
00:01:41.560 --> 00:01:45.760
<v Speaker 1>Exactly, and picking that local environment carefully early on. That

36
00:01:45.799 --> 00:01:48.640
<v Speaker 1>can save you so many headaches later with access problems

37
00:01:48.640 --> 00:01:53.599
<v Speaker 1>and whatnot now tools or our tools. The book really

38
00:01:53.640 --> 00:01:57.040
<v Speaker 1>pushes VS Code visual Studio code not just as an ide,

39
00:01:57.239 --> 00:01:59.680
<v Speaker 1>but like a central hub for Azure stuff.

40
00:02:00.000 --> 00:02:01.079
<v Speaker 2>It's pretty central these days.

41
00:02:01.239 --> 00:02:04.879
<v Speaker 1>It mentions, it's almost unlimited integration options with Azure and

42
00:02:04.959 --> 00:02:08.479
<v Speaker 1>plugins for tens of Azure services. Kind of makes it

43
00:02:08.479 --> 00:02:10.919
<v Speaker 1>a no brainer for a lot of workflows. Sure, obviously

44
00:02:10.960 --> 00:02:12.520
<v Speaker 1>a visual studio is still a big player.

45
00:02:12.560 --> 00:02:13.560
<v Speaker 2>Great integration too.

46
00:02:13.919 --> 00:02:16.560
<v Speaker 1>But then you've got the command line as your CLI,

47
00:02:16.759 --> 00:02:19.879
<v Speaker 1>as your PowerShell, your go to's for scripting.

48
00:02:20.599 --> 00:02:22.439
<v Speaker 2>Automation essential, and.

49
00:02:22.400 --> 00:02:25.719
<v Speaker 1>The CLI even installs extensions automatically, which is pretty neat.

50
00:02:25.919 --> 00:02:29.680
<v Speaker 1>Plus things like WSL the Window subsystem for Linux super

51
00:02:29.719 --> 00:02:33.000
<v Speaker 1>helpful if you're mixing ocs. Need those Unix.

52
00:02:32.639 --> 00:02:34.759
<v Speaker 2>Tools right, keeps things consistent, and.

53
00:02:34.719 --> 00:02:37.400
<v Speaker 1>As your data studio for database work, So a whole

54
00:02:37.400 --> 00:02:38.680
<v Speaker 1>toolkit that's.

55
00:02:38.520 --> 00:02:40.919
<v Speaker 2>A good rundown. But there's this other piece the book

56
00:02:40.919 --> 00:02:46.039
<v Speaker 2>talks about for local dev emulators Azure emulators. They seem great, right,

57
00:02:46.520 --> 00:02:49.280
<v Speaker 2>develop locally, no costly Azure services running.

58
00:02:49.400 --> 00:02:50.240
<v Speaker 1>Yeah, sounds idea.

59
00:02:50.360 --> 00:02:54.000
<v Speaker 2>You get isolated testing, no shared databases interfering. But the

60
00:02:54.000 --> 00:02:56.599
<v Speaker 2>book pulls no punches, calls them error prone.

61
00:02:56.840 --> 00:02:59.000
<v Speaker 1>Ah okay, the catch.

62
00:02:58.960 --> 00:03:03.240
<v Speaker 2>Because they emulate, they don't perfectly replicate Azure. So thinking

63
00:03:03.280 --> 00:03:07.639
<v Speaker 2>about someone experienced, where do developers maybe misuse these or like,

64
00:03:07.919 --> 00:03:10.280
<v Speaker 2>rely on them too much? What's the book say about

65
00:03:10.280 --> 00:03:12.439
<v Speaker 2>when you really need a proper cloud sandbox.

66
00:03:12.639 --> 00:03:15.599
<v Speaker 1>That's a really good point because it is a common trap.

67
00:03:15.759 --> 00:03:18.439
<v Speaker 1>The book points out emulators are mostly for storage stuff

68
00:03:18.520 --> 00:03:21.759
<v Speaker 1>like Azu're right right, something like the Cosmos dB emulator.

69
00:03:21.840 --> 00:03:25.800
<v Speaker 1>Mainly Windows needs dock or elsewhere. So the real takeaway

70
00:03:25.840 --> 00:03:28.400
<v Speaker 1>is they're great for that initial deb cycle, saving some cash,

71
00:03:28.800 --> 00:03:31.000
<v Speaker 1>but they are not a replacement for testing in an

72
00:03:31.080 --> 00:03:34.560
<v Speaker 1>environment that actually behaves like production. The best bet, the

73
00:03:34.599 --> 00:03:38.879
<v Speaker 1>most reliable way. A dedicated cloud environment might cost more, sure,

74
00:03:39.000 --> 00:03:42.319
<v Speaker 1>but you get that fidelity exactly. It's that trade off

75
00:03:42.400 --> 00:03:45.240
<v Speaker 1>budget versus needing that one hundred percent match to the

76
00:03:45.240 --> 00:03:49.080
<v Speaker 1>real service. Okay, so local setup, sorted tools ready, next

77
00:03:49.080 --> 00:03:51.719
<v Speaker 1>big question. The book gets into where do your apps

78
00:03:51.719 --> 00:03:53.840
<v Speaker 1>actually live in Azure and that there's a whole spectrum

79
00:03:53.960 --> 00:03:56.879
<v Speaker 1>from the you know, the old reliables to newer serverlest

80
00:03:56.919 --> 00:03:57.599
<v Speaker 1>container options.

81
00:03:57.680 --> 00:03:58.560
<v Speaker 2>Yeah, lots of choices.

82
00:03:58.840 --> 00:04:01.919
<v Speaker 1>The classic the work course for web apps is as

83
00:04:01.960 --> 00:04:05.319
<v Speaker 1>your app service. The book breaks it down neatly. The

84
00:04:05.400 --> 00:04:08.000
<v Speaker 1>app service plan that's your compute power, and the web

85
00:04:08.039 --> 00:04:11.120
<v Speaker 1>app that's your code and config simple enough, but people

86
00:04:11.159 --> 00:04:15.159
<v Speaker 1>sometimes underestimate its power. You can easily scale up more

87
00:04:15.240 --> 00:04:18.959
<v Speaker 1>CPU memory or scale out more instances, all.

88
00:04:18.800 --> 00:04:21.360
<v Speaker 2>At the plan level right flexibility.

89
00:04:20.720 --> 00:04:24.160
<v Speaker 1>And you can do that manually or set up automatic rules.

90
00:04:24.560 --> 00:04:28.040
<v Speaker 1>It supports loads of runtimes, dot net Java no JS,

91
00:04:28.160 --> 00:04:31.519
<v Speaker 1>plus it plugs right into CICD pipelines. It's actually pretty

92
00:04:31.560 --> 00:04:34.399
<v Speaker 1>capable even for complex stuff. And then there's the rise

93
00:04:34.439 --> 00:04:37.519
<v Speaker 1>of static web apps, much simpler, often cheaper. If you're

94
00:04:37.519 --> 00:04:40.360
<v Speaker 1>building an SPA, a single page app that mostly runs

95
00:04:40.360 --> 00:04:41.319
<v Speaker 1>in the browser, a.

96
00:04:41.279 --> 00:04:43.399
<v Speaker 2>Full app service might be overg totally.

97
00:04:43.720 --> 00:04:46.600
<v Speaker 1>You could use Azure storage static website for really basic

98
00:04:46.639 --> 00:04:49.120
<v Speaker 1>things like a landing page, but the book really likes

99
00:04:49.160 --> 00:04:50.240
<v Speaker 1>Azure static.

100
00:04:49.879 --> 00:04:52.279
<v Speaker 2>Web apps and managed service Yeah, purpose.

101
00:04:51.920 --> 00:04:55.120
<v Speaker 1>Built for these static first apps, usually paired with Azure

102
00:04:55.160 --> 00:04:58.399
<v Speaker 1>functions for any back end bits. It handles authentication smoothly,

103
00:04:58.439 --> 00:05:01.120
<v Speaker 1>integrates with on tri d at hub. Plus it has

104
00:05:01.160 --> 00:05:03.839
<v Speaker 1>a really nice local CLI tool for dev with off

105
00:05:03.959 --> 00:05:04.759
<v Speaker 1>mocks and stuff.

106
00:05:05.000 --> 00:05:08.519
<v Speaker 2>And if you connect that to the bigger picture, this

107
00:05:08.680 --> 00:05:12.600
<v Speaker 2>shift from app service towards static web apps, it reflects

108
00:05:12.600 --> 00:05:17.079
<v Speaker 2>that wider trend right optimizing hosting for specific architectures definitely.

109
00:05:17.079 --> 00:05:19.439
<v Speaker 2>The book does a good job showing those trade offs

110
00:05:20.079 --> 00:05:24.120
<v Speaker 2>back end integration versus cost and ease of use. Static

111
00:05:24.160 --> 00:05:26.480
<v Speaker 2>web apps are fantastic when the front end does the

112
00:05:26.480 --> 00:05:28.399
<v Speaker 2>heavy lifting and you just need a light back end.

113
00:05:28.759 --> 00:05:31.920
<v Speaker 2>App service is still the versatile beast, but static web

114
00:05:31.959 --> 00:05:34.639
<v Speaker 2>apps nail that specific growing niche.

115
00:05:34.759 --> 00:05:37.519
<v Speaker 1>Okay, now here's where it gets really interesting. I think

116
00:05:38.000 --> 00:05:42.040
<v Speaker 1>diving into serverless where you just focus on code on events,

117
00:05:42.279 --> 00:05:45.040
<v Speaker 1>not managing servers. It's a different way of thinking.

118
00:05:45.079 --> 00:05:46.920
<v Speaker 2>Big paradigm shift first up.

119
00:05:47.040 --> 00:05:50.279
<v Speaker 1>Azure functions the function as a service or phase platform. Yeah,

120
00:05:50.360 --> 00:05:52.720
<v Speaker 1>lets you write code snippets triggered by events, and you

121
00:05:52.759 --> 00:05:53.839
<v Speaker 1>mostly pay for when they run.

122
00:05:53.920 --> 00:05:54.519
<v Speaker 2>Simple model.

123
00:05:54.639 --> 00:05:56.879
<v Speaker 1>The book lays out the hosting plans really clearly. You've

124
00:05:56.879 --> 00:06:01.000
<v Speaker 1>got the consumption plan paper use great for a predictable loads,

125
00:06:01.120 --> 00:06:05.199
<v Speaker 1>but limitations like a ten minute max runtime, no vnet integration.

126
00:06:05.600 --> 00:06:09.959
<v Speaker 1>Then the Premium plan more predictable performance. You get vnet integration,

127
00:06:10.360 --> 00:06:13.199
<v Speaker 1>longer run times up to thirty months, but you pay

128
00:06:13.240 --> 00:06:16.360
<v Speaker 1>for the allocated resources. Can't always scale right down.

129
00:06:16.199 --> 00:06:19.680
<v Speaker 2>To zero right, more guarantees, more cost potentially.

130
00:06:19.279 --> 00:06:22.279
<v Speaker 1>And there's this newer one in preview. Still, the flex

131
00:06:22.360 --> 00:06:25.839
<v Speaker 1>consumption plan tries to blend the best of both supports.

132
00:06:25.920 --> 00:06:29.519
<v Speaker 1>V nets has always ready instances, but with consumption style

133
00:06:29.560 --> 00:06:31.279
<v Speaker 1>pricing and better scale limits one.

134
00:06:31.160 --> 00:06:33.399
<v Speaker 2>To watch interesting a hybrid approach, but.

135
00:06:33.399 --> 00:06:37.120
<v Speaker 1>The real magic of functions. The core idea is triggers

136
00:06:37.240 --> 00:06:41.480
<v Speaker 1>and binding. Functions are event driven a trigger only one

137
00:06:41.560 --> 00:06:44.920
<v Speaker 1>per function kicks it off an HTTP request, a message,

138
00:06:44.959 --> 00:06:48.800
<v Speaker 1>and a queue, a timer whatever, starting pistol exactly. Then

139
00:06:48.879 --> 00:06:52.079
<v Speaker 1>input bindings pull data in automatically from other services, and

140
00:06:52.120 --> 00:06:54.759
<v Speaker 1>output bindings push results out. It handles so much of

141
00:06:54.759 --> 00:06:55.920
<v Speaker 1>that integration plumbing for you.

142
00:06:56.040 --> 00:06:57.680
<v Speaker 2>Yeah, cutsound boilerplate.

143
00:06:57.160 --> 00:07:01.639
<v Speaker 1>Code super useful for quickipisackground jobs. Way better than web

144
00:07:01.680 --> 00:07:04.399
<v Speaker 1>apps for those actually, or even just acting as a

145
00:07:04.399 --> 00:07:08.360
<v Speaker 1>simple proxy. But okay, standard functions are stateless. They don't

146
00:07:08.360 --> 00:07:11.480
<v Speaker 1>remember anything between runs. What if you need to manage

147
00:07:11.639 --> 00:07:16.519
<v Speaker 1>complex process, something long running that needs state maybe over days.

148
00:07:16.839 --> 00:07:19.079
<v Speaker 2>Yeah, the stateless thing is limiting sometimes.

149
00:07:19.199 --> 00:07:22.439
<v Speaker 1>That's where durable functions come in. They're built on verager functions,

150
00:07:22.480 --> 00:07:26.560
<v Speaker 1>but add state management you get orchestrator functions the brains

151
00:07:26.639 --> 00:07:30.959
<v Speaker 1>managing the workflow saving state, and they coordinate activity functions

152
00:07:31.040 --> 00:07:32.800
<v Speaker 1>the actual workhorses.

153
00:07:32.279 --> 00:07:34.480
<v Speaker 2>So it remembers where it got to precisely.

154
00:07:34.680 --> 00:07:37.360
<v Speaker 1>If the workflow crashes, you can restart it from the

155
00:07:37.439 --> 00:07:41.879
<v Speaker 1>last checkpoint. No loss work, no rerunning completed steps enables

156
00:07:41.920 --> 00:07:46.040
<v Speaker 1>cool patterns like asnc httpapi's user kicks off a long

157
00:07:46.120 --> 00:07:48.000
<v Speaker 1>report check status latter.

158
00:07:48.079 --> 00:07:49.480
<v Speaker 2>Ah the fire and forget.

159
00:07:49.480 --> 00:07:53.240
<v Speaker 1>But check back pattern exactly, or human interaction workflows that

160
00:07:53.319 --> 00:07:56.399
<v Speaker 1>pause maybe for weeks waiting for approval and the crazy

161
00:07:56.439 --> 00:07:59.360
<v Speaker 1>thing on the consumption plan you don't pay while it's

162
00:07:59.399 --> 00:07:59.879
<v Speaker 1>just sitting now.

163
00:08:00.040 --> 00:08:02.639
<v Speaker 2>Wow, okay, that's powerful.

164
00:08:02.839 --> 00:08:05.800
<v Speaker 1>Plus they have things like critical sections to avoid race

165
00:08:05.839 --> 00:08:09.839
<v Speaker 1>conditions when talking to external systems and durable entities for

166
00:08:09.920 --> 00:08:13.759
<v Speaker 1>modeling stateful business objects, really sophisticated stuff.

167
00:08:14.480 --> 00:08:15.000
<v Speaker 2>And then for.

168
00:08:15.079 --> 00:08:20.439
<v Speaker 1>Totally different approach, more visual, low code. There's Azure logic apps.

169
00:08:20.360 --> 00:08:22.040
<v Speaker 2>Right, the Dragon draw workflow builder.

170
00:08:22.160 --> 00:08:26.120
<v Speaker 1>Yeah, you build workflows with a visual designer or using JSON.

171
00:08:26.800 --> 00:08:30.720
<v Speaker 1>Great for integrating different services, even things like SAP scales automatically,

172
00:08:31.040 --> 00:08:35.600
<v Speaker 1>plus good error handling, retry policies for API calls, steps

173
00:08:35.639 --> 00:08:37.559
<v Speaker 1>that only run if a previous one failed.

174
00:08:37.960 --> 00:08:40.159
<v Speaker 2>That kind of thing which brings up that common question,

175
00:08:40.240 --> 00:08:44.039
<v Speaker 2>doesn't it? Durable functions versus logic apps, code first power

176
00:08:44.279 --> 00:08:45.360
<v Speaker 2>versus low code speed?

177
00:08:45.480 --> 00:08:46.559
<v Speaker 1>Yeah, when do you pick which?

178
00:08:46.799 --> 00:08:48.679
<v Speaker 2>And the book stress is it's not about which is better,

179
00:08:48.720 --> 00:08:52.679
<v Speaker 2>It's about fit. What's your team comfortable with? Code? Visual tools?

180
00:08:52.840 --> 00:08:55.399
<v Speaker 2>How complex is the custom logic? How fast do you

181
00:08:55.399 --> 00:08:57.759
<v Speaker 2>need to build it? Both are great for orchestration, just

182
00:08:58.039 --> 00:08:59.159
<v Speaker 2>different ways to get there.

183
00:08:59.320 --> 00:09:04.159
<v Speaker 1>Right makes sense. Okay, let's switch gears, security, managing, secrets,

184
00:09:04.399 --> 00:09:10.240
<v Speaker 1>configuration supercritical. Azure's got dedicated services here. First as your

185
00:09:10.320 --> 00:09:12.679
<v Speaker 1>key vault, your digital vault.

186
00:09:12.320 --> 00:09:14.200
<v Speaker 2>In the cloud, the strong box.

187
00:09:14.000 --> 00:09:20.039
<v Speaker 1>Exactly store secrets, connection strings, passwords, API keys plus crypto keys, certificates,

188
00:09:20.480 --> 00:09:23.840
<v Speaker 1>the book flags that old instrumentation keys are being deprecated.

189
00:09:24.039 --> 00:09:27.080
<v Speaker 1>Use connection strings now. Good tip and for using it

190
00:09:27.120 --> 00:09:30.320
<v Speaker 1>with app service, the best practice is key vault references

191
00:09:30.360 --> 00:09:34.279
<v Speaker 1>combined with managed identities way more secure, easier to manage

192
00:09:34.279 --> 00:09:36.360
<v Speaker 1>than passing around admin credentials.

193
00:09:36.399 --> 00:09:38.799
<v Speaker 2>Definitely avoids hard coding secrets.

194
00:09:38.840 --> 00:09:42.039
<v Speaker 1>You can also grab secrets directly in your code using SDKs,

195
00:09:42.240 --> 00:09:45.679
<v Speaker 1>more flexible sometimes, especially if you deploy across different platforms.

196
00:09:45.960 --> 00:09:49.000
<v Speaker 1>There's this handy default is your credential object that figures

197
00:09:49.039 --> 00:09:51.919
<v Speaker 1>out credentials automatically, whether you're running locally or in Azure,

198
00:09:51.960 --> 00:09:55.279
<v Speaker 1>smooth things out nice. Then there's Azure App Configuration, a

199
00:09:55.320 --> 00:09:59.440
<v Speaker 1>separate service just for application settings and importantly feature flags.

200
00:09:59.519 --> 00:10:00.919
<v Speaker 2>Centralize can fix YEP.

201
00:10:01.440 --> 00:10:04.679
<v Speaker 1>It plays nicely with keyvol you can reference secrets stored there,

202
00:10:04.720 --> 00:10:09.200
<v Speaker 1>and integrates with web apps functions aks, all the usual suspects.

203
00:10:09.480 --> 00:10:12.440
<v Speaker 1>The killer feature I think is labels. Let's you have

204
00:10:12.559 --> 00:10:16.240
<v Speaker 1>different sets of config values for dev tests, prad whatever.

205
00:10:16.399 --> 00:10:19.639
<v Speaker 1>Using the same keys makes managing environments so much easier.

206
00:10:19.960 --> 00:10:24.080
<v Speaker 2>Yeah, that combo keyvolt for the actual secrets app configuration

207
00:10:24.200 --> 00:10:27.320
<v Speaker 2>for the settings and flags. That's really powerful for modern apps.

208
00:10:27.720 --> 00:10:33.080
<v Speaker 2>Centralizes everything. Helps with secure deployments, dynamic feature rollouts, big improvements.

209
00:10:33.120 --> 00:10:35.639
<v Speaker 2>But as the book points out, you still need good

210
00:10:35.679 --> 00:10:39.360
<v Speaker 2>access control discipline and don't make your labels too complicated

211
00:10:39.759 --> 00:10:41.639
<v Speaker 2>or you create a different kind of mess for your

212
00:10:41.639 --> 00:10:44.320
<v Speaker 2>op steam use the power wisely good point.

213
00:10:44.399 --> 00:10:47.039
<v Speaker 1>Okay, containers they're everywhere. I just got a whole ecosystem

214
00:10:47.120 --> 00:10:51.600
<v Speaker 1>charting with Azure Container Registry ACR your private Docker hut. Basically,

215
00:10:51.679 --> 00:10:55.120
<v Speaker 1>it's rivit image store, right simple to set up, manage images,

216
00:10:55.320 --> 00:10:58.799
<v Speaker 1>use repositories and tags for versioning, has scope maps for

217
00:10:58.879 --> 00:11:03.360
<v Speaker 1>granular permissions, plugs right into CICD pipelines, supports different off

218
00:11:03.399 --> 00:11:07.120
<v Speaker 1>methods like federated identity for GitHub actions. The book even

219
00:11:07.120 --> 00:11:11.000
<v Speaker 1>gets into performance stuff like artifact caching and multi arch images.

220
00:11:11.480 --> 00:11:15.799
<v Speaker 1>Important detail usual for efficient pipelines then for quick maybe

221
00:11:15.799 --> 00:11:20.080
<v Speaker 1>one off container jobs. Azure Container Instances ACI. The book

222
00:11:20.120 --> 00:11:22.440
<v Speaker 1>describes it as run a piece of code for a

223
00:11:22.440 --> 00:11:24.799
<v Speaker 1>moment and then discard obsolete infrastructure.

224
00:11:24.879 --> 00:11:27.000
<v Speaker 2>Serverlest containers effectively.

225
00:11:26.480 --> 00:11:29.759
<v Speaker 1>Pretty much pay for use, isolated run time. Great for

226
00:11:29.799 --> 00:11:33.440
<v Speaker 1>those bursty tasks batch jobs. You can set restart policies

227
00:11:33.600 --> 00:11:36.960
<v Speaker 1>always never on failure, depending on the job, and you

228
00:11:36.960 --> 00:11:41.240
<v Speaker 1>can control it all via SDKs, start stop containers, run commands, insides,

229
00:11:41.360 --> 00:11:42.320
<v Speaker 1>stream logs.

230
00:11:42.919 --> 00:11:45.840
<v Speaker 2>Very flexible for automation, handy for specific use cases.

231
00:11:45.919 --> 00:11:48.720
<v Speaker 1>Now for the more serious micro services stuff, there's Azure

232
00:11:48.759 --> 00:11:51.840
<v Speaker 1>Container Apps ACA. The book really leans into this as

233
00:11:52.000 --> 00:11:56.120
<v Speaker 1>a modern and flexible platform for containerized apps, especially micro services.

234
00:11:56.240 --> 00:11:58.799
<v Speaker 2>Kind of like Kubernetes light but managed sort of.

235
00:11:58.919 --> 00:12:01.639
<v Speaker 1>Yeah, it DIDs a lot of the K eight's complexity

236
00:12:01.679 --> 00:12:05.240
<v Speaker 1>but gives you similar benefits. It's great at handling multiple

237
00:12:05.240 --> 00:12:08.480
<v Speaker 1>revisions versions of your app side by side. Uses something

238
00:12:08.480 --> 00:12:11.759
<v Speaker 1>called a k TO scaler for smart event driven scaling

239
00:12:12.039 --> 00:12:16.080
<v Speaker 1>like scale based on Q length not just CPU often

240
00:12:16.240 --> 00:12:17.720
<v Speaker 1>way better for micro services.

241
00:12:17.919 --> 00:12:19.519
<v Speaker 2>That event driven scaling is key.

242
00:12:19.679 --> 00:12:23.919
<v Speaker 1>Yeah, it handles ingress storage mounts. It's really geared towards

243
00:12:23.960 --> 00:12:27.360
<v Speaker 1>that microservice architecture. But you can also run containers and

244
00:12:27.440 --> 00:12:30.559
<v Speaker 1>Azure App service which sounds confusing.

245
00:12:30.159 --> 00:12:32.200
<v Speaker 2>Maybe filled Yeah, when would you do that.

246
00:12:32.320 --> 00:12:34.240
<v Speaker 1>It's a good option if you've already got stuff inn

247
00:12:34.240 --> 00:12:36.600
<v Speaker 1>app service and want to containerize it without a huge

248
00:12:36.600 --> 00:12:40.159
<v Speaker 1>re architecture. App service even supports multi container apps with

249
00:12:40.200 --> 00:12:42.919
<v Speaker 1>doctor composed, so you can do sidecar patterns like a

250
00:12:42.960 --> 00:12:46.759
<v Speaker 1>separate container for logging or monitoring alongside your main app,

251
00:12:46.879 --> 00:12:48.879
<v Speaker 1>all within that familiar app service model.

252
00:12:48.960 --> 00:12:51.679
<v Speaker 2>Uh okay, So that distinction the book makes is important.

253
00:12:52.039 --> 00:12:56.799
<v Speaker 2>ACA is really designed for micro services, greenfield event driven scaling.

254
00:12:57.200 --> 00:13:00.840
<v Speaker 2>APP Service for containers is more like bring containers to

255
00:13:00.960 --> 00:13:02.480
<v Speaker 2>the existing app service.

256
00:13:02.200 --> 00:13:05.279
<v Speaker 1>World exactly a pathway for containerizing existing workloads.

257
00:13:05.320 --> 00:13:09.600
<v Speaker 2>Perhaps right. Choosing between them really shapes your architecture and

258
00:13:09.639 --> 00:13:12.600
<v Speaker 2>what you have to manage. Getting that right early is

259
00:13:12.679 --> 00:13:14.240
<v Speaker 2>key for scaling and cost.

260
00:13:14.360 --> 00:13:18.159
<v Speaker 1>Definitely okay. Data can have an app without data. Azure's

261
00:13:18.200 --> 00:13:20.559
<v Speaker 1>got tons of options. The book walks through the choices

262
00:13:20.600 --> 00:13:23.480
<v Speaker 1>really well. Take Azure storage the Swiss Army knife, right,

263
00:13:23.559 --> 00:13:25.720
<v Speaker 1>there's a bit of everything for no seqel. You've got

264
00:13:25.799 --> 00:13:29.120
<v Speaker 1>table storage good when you don't need complex joints. Schema

265
00:13:29.159 --> 00:13:32.559
<v Speaker 1>might change and you know how you'll partition it indexes

266
00:13:32.559 --> 00:13:35.159
<v Speaker 1>on partition key and ro key, So design matters a

267
00:13:35.159 --> 00:13:39.200
<v Speaker 1>lot for performance and cost. Interestingly, the book says data

268
00:13:39.240 --> 00:13:42.039
<v Speaker 1>duplication is actually one of the viable patterns here to

269
00:13:42.200 --> 00:13:43.159
<v Speaker 1>optimize reads.

270
00:13:43.240 --> 00:13:46.480
<v Speaker 2>Yeah, denormalization basically common in no SQL.

271
00:13:46.519 --> 00:13:50.519
<v Speaker 1>Then blob storage for just dot files objects. Key things

272
00:13:50.559 --> 00:13:54.080
<v Speaker 1>here are the access tiers hot cool, cold archive to

273
00:13:54.120 --> 00:13:56.919
<v Speaker 1>save money based on how often you access stuff. Archive

274
00:13:56.960 --> 00:13:59.519
<v Speaker 1>is super cheap. It takes hours to rehydrate data. Got

275
00:13:59.559 --> 00:14:02.559
<v Speaker 1>a plan for the latency and blob types. Block append

276
00:14:02.879 --> 00:14:05.879
<v Speaker 1>page choose based on usage block for general files, a

277
00:14:06.000 --> 00:14:09.320
<v Speaker 1>pen for logs, page for virtual discs, and crucially you

278
00:14:09.360 --> 00:14:10.759
<v Speaker 1>pick the type when you create it.

279
00:14:10.799 --> 00:14:12.879
<v Speaker 2>Can't change it later important constraint.

280
00:14:13.039 --> 00:14:15.879
<v Speaker 1>And for reacting to changes you can use the change

281
00:14:15.919 --> 00:14:19.679
<v Speaker 1>feed or event grid. Events different ways to get notified now.

282
00:14:19.840 --> 00:14:24.600
<v Speaker 1>Queues essential for decoupling services, handling load spikes, making sure

283
00:14:24.639 --> 00:14:28.080
<v Speaker 1>messages don't get lost. But which queue service? The book

284
00:14:28.120 --> 00:14:29.320
<v Speaker 1>clarifies the landscape.

285
00:14:29.399 --> 00:14:30.480
<v Speaker 2>Yeah, there are a few options.

286
00:14:30.639 --> 00:14:34.000
<v Speaker 1>Queue storage the basic one part of Azure storage simple

287
00:14:34.000 --> 00:14:35.080
<v Speaker 1>message passing.

288
00:14:34.879 --> 00:14:35.960
<v Speaker 2>The entry level cube.

289
00:14:35.960 --> 00:14:39.080
<v Speaker 1>How's your event hubs? Are you built for massive ingestion?

290
00:14:39.440 --> 00:14:44.120
<v Speaker 1>Think IoT data streams millions of events. Kofka compatible has

291
00:14:44.159 --> 00:14:47.960
<v Speaker 1>schema registry, auto scales. It's about volume high throughput and

292
00:14:48.120 --> 00:14:51.559
<v Speaker 1>Azure Service Bus. This is for enterprise grade queues when

293
00:14:51.600 --> 00:14:55.679
<v Speaker 1>you need guarantees. It has advanced filters sekl Booleon correlation

294
00:14:55.759 --> 00:14:59.039
<v Speaker 1>that look at message properties, sessions for guaranteed first in,

295
00:14:59.200 --> 00:15:01.759
<v Speaker 1>first out ordering, built in duplicate detection.

296
00:15:01.840 --> 00:15:05.559
<v Speaker 2>It's the heavy duty option, so reliability in features overraw throughput.

297
00:15:05.639 --> 00:15:08.879
<v Speaker 1>Sometimes exactly knowing when you need those enterprise features is

298
00:15:08.919 --> 00:15:13.000
<v Speaker 1>the key. Insight and relational databases, Azure manages the popular

299
00:15:13.039 --> 00:15:17.519
<v Speaker 1>ones Azure SQL, postgrescool Myseql, though Maria dB is being retired.

300
00:15:17.600 --> 00:15:21.279
<v Speaker 1>The book notes for Azure SQL you've got choices SQL

301
00:15:21.360 --> 00:15:27.039
<v Speaker 1>on VMS, Managed Instance pay or Azure sql Database dBase.

302
00:15:27.559 --> 00:15:30.200
<v Speaker 1>The book suggests Azure SQLDB is often the go to

303
00:15:30.320 --> 00:15:33.480
<v Speaker 1>for new apps because it's fully managed. Let's admin overhead

304
00:15:33.600 --> 00:15:36.519
<v Speaker 1>right scaling up or down causes a brief connection blip,

305
00:15:36.600 --> 00:15:39.720
<v Speaker 1>something to be aware of. Backups are automated or on demand.

306
00:15:40.320 --> 00:15:44.600
<v Speaker 1>Need to think about replication LRSCRS for nonprod grs, r

307
00:15:44.639 --> 00:15:48.840
<v Speaker 1>AGRs for production resilience and your Recovery Point Objective RPO.

308
00:15:49.039 --> 00:15:50.840
<v Speaker 2>Standard database considerations and.

309
00:15:50.759 --> 00:15:54.200
<v Speaker 1>Security databases are private by default. You need firewall rules,

310
00:15:54.279 --> 00:15:58.279
<v Speaker 1>IP whitelists or ideally use Azure private endpoints for access

311
00:15:58.320 --> 00:15:59.759
<v Speaker 1>only within your virtual network.

312
00:16:00.159 --> 00:16:02.240
<v Speaker 2>Private endpoints are generally the way to go, now, you know,

313
00:16:02.279 --> 00:16:04.519
<v Speaker 2>going through all these data options, it really hits home

314
00:16:04.559 --> 00:16:08.000
<v Speaker 2>that principle. There's rarely just one right way to store

315
00:16:08.080 --> 00:16:09.200
<v Speaker 2>data in Azure.

316
00:16:08.960 --> 00:16:09.799
<v Speaker 1>So many choices.

317
00:16:09.960 --> 00:16:13.600
<v Speaker 2>It's all about picking the right tool for your specific job,

318
00:16:13.919 --> 00:16:18.000
<v Speaker 2>understanding those trade offs chem of flexibility, indexing, access patterns,

319
00:16:18.120 --> 00:16:22.399
<v Speaker 2>cost reliability, features like choosing service bus over event hubs.

320
00:16:22.759 --> 00:16:25.120
<v Speaker 2>It's not just features, it's about whether you need strict

321
00:16:25.200 --> 00:16:29.799
<v Speaker 2>ordering and transactions versus just handling huge volume. The book

322
00:16:29.840 --> 00:16:31.360
<v Speaker 2>really helps make those informed decisions.

323
00:16:31.399 --> 00:16:35.080
<v Speaker 1>Yeah. Absolutely, Okay, nearly there. Let's talk visibility and intelligence,

324
00:16:35.480 --> 00:16:38.879
<v Speaker 1>keeping apps healthy, making them smart. Azure Application Insights is

325
00:16:38.919 --> 00:16:42.120
<v Speaker 1>your main health monitor essential service, and the book makes

326
00:16:42.120 --> 00:16:46.600
<v Speaker 1>a crucial distinction. Logs don't provide any specific value as

327
00:16:46.639 --> 00:16:49.440
<v Speaker 1>opposed to metrics. Logs tell you why a metric is

328
00:16:49.440 --> 00:16:51.480
<v Speaker 1>what it is. Metrics tell you what's happening, good way

329
00:16:51.480 --> 00:16:54.279
<v Speaker 1>to put it. App insights streamlines all this again that

330
00:16:54.440 --> 00:16:58.039
<v Speaker 1>change instrumentation keys are out, use connection strings with newer

331
00:16:58.120 --> 00:17:04.039
<v Speaker 1>SDKs key features. Dependency monitoring automatically tracks calls to databases.

332
00:17:04.160 --> 00:17:10.359
<v Speaker 1>External APIs various sampling methods to control costs, rich data types, metrics, dependencies,

333
00:17:10.400 --> 00:17:11.920
<v Speaker 1>page views, traces.

334
00:17:11.559 --> 00:17:13.640
<v Speaker 2>Requests, lots of data points.

335
00:17:13.680 --> 00:17:17.400
<v Speaker 1>And you query it all with Custo query language KQL,

336
00:17:18.400 --> 00:17:22.319
<v Speaker 1>super powerful for digging into behavior. Cost control features like

337
00:17:22.400 --> 00:17:26.079
<v Speaker 1>daily caps and sampling are vital, Otherwise telemetry costs can

338
00:17:26.160 --> 00:17:26.960
<v Speaker 1>sneak up on you.

339
00:17:27.240 --> 00:17:30.480
<v Speaker 2>Yeah, monitoring is definitely not an afterthought. It's core and

340
00:17:30.599 --> 00:17:33.599
<v Speaker 2>app INSIGHT's ability to autotract dependencies and give you that

341
00:17:33.680 --> 00:17:37.400
<v Speaker 2>fine grained control over sampling. That's huge. You get deep

342
00:17:37.480 --> 00:17:41.480
<v Speaker 2>visibility without drowning in data or managing logging infrastructure yourself.

343
00:17:41.680 --> 00:17:44.720
<v Speaker 2>It really shifts you from being reactive to proactive.

344
00:17:44.960 --> 00:17:49.039
<v Speaker 1>Massive win agreed. And finally, the really exciting stuff, generative

345
00:17:49.039 --> 00:17:52.160
<v Speaker 1>AI with Azure Open Ai service the hot topic. This

346
00:17:52.240 --> 00:17:54.880
<v Speaker 1>service gives you managed access to those powerful open AI

347
00:17:55.000 --> 00:17:58.960
<v Speaker 1>models gpt DL, whisper embeddings, but hosted with an Azure

348
00:17:59.160 --> 00:18:02.200
<v Speaker 1>so you get Azure sexcurity, private networking content filtering, all

349
00:18:02.200 --> 00:18:04.839
<v Speaker 1>that good stuff. Abstracting away the infrastructure pain makes it

350
00:18:04.960 --> 00:18:09.920
<v Speaker 1>enterprise ready. Key concept tokens basically chunks of textra code,

351
00:18:10.319 --> 00:18:12.960
<v Speaker 1>billing model limits. It's all based on tokens, you need

352
00:18:13.000 --> 00:18:16.759
<v Speaker 1>to understand them. There are SDKs for different languages to

353
00:18:16.799 --> 00:18:21.000
<v Speaker 1>talk to. The APIs chat completions API for building chatbots

354
00:18:21.119 --> 00:18:24.960
<v Speaker 1>uses system user assistant messages, but you gotta handle storing

355
00:18:25.000 --> 00:18:26.480
<v Speaker 1>the conversation history yourself.

356
00:18:26.720 --> 00:18:28.319
<v Speaker 2>Right, it's stateless by default.

357
00:18:28.359 --> 00:18:31.200
<v Speaker 1>There's a newer response API that can stream long answers

358
00:18:31.240 --> 00:18:34.839
<v Speaker 1>back better UX speech to text using models like Whisper

359
00:18:34.960 --> 00:18:38.960
<v Speaker 1>image generation with Deli creating images from text prompts, often

360
00:18:39.039 --> 00:18:40.759
<v Speaker 1>saving results to Blob storage.

361
00:18:40.920 --> 00:18:43.000
<v Speaker 2>Cool use cases and embeddings.

362
00:18:43.079 --> 00:18:46.759
<v Speaker 1>This is interesting. Turns data, text, audio, whatever into vectors.

363
00:18:46.839 --> 00:18:51.960
<v Speaker 1>These mathematical representations lets you calculate cosigine similarity basically how

364
00:18:52.000 --> 00:18:54.400
<v Speaker 1>related things are, and you can use this with specialized

365
00:18:54.680 --> 00:18:57.079
<v Speaker 1>vector databases for similarity searches.

366
00:18:57.160 --> 00:19:00.920
<v Speaker 2>Opens up semantic search recommendations lots of possible abilities.

367
00:19:00.640 --> 00:19:03.799
<v Speaker 1>And if just prompting better or using ag retrival augmented

368
00:19:03.839 --> 00:19:06.960
<v Speaker 1>generation isn't quite cutting it for your specific needs, you

369
00:19:06.960 --> 00:19:09.440
<v Speaker 1>can fine tune the models with your own data, usually

370
00:19:09.440 --> 00:19:12.920
<v Speaker 1>in Jason format, to make them better at very specific tasks.

371
00:19:13.160 --> 00:19:16.200
<v Speaker 2>Yeah, fine tuning is the next level of customization. This

372
00:19:16.359 --> 00:19:20.680
<v Speaker 2>Azure Open AI service really makes integrating powerful AI accessible.

373
00:19:20.920 --> 00:19:24.160
<v Speaker 2>It lets you build much richer apps, automate complex stuff,

374
00:19:24.440 --> 00:19:27.880
<v Speaker 2>find hidden patterns. It's genuinely a game changer for cloud

375
00:19:27.880 --> 00:19:31.440
<v Speaker 2>applications right now. But like the book mentions, you really

376
00:19:31.480 --> 00:19:33.559
<v Speaker 2>need to nail your prompt engineering and keep an eye

377
00:19:33.559 --> 00:19:35.759
<v Speaker 2>on those token limits for performance and cost.

378
00:19:35.920 --> 00:19:39.240
<v Speaker 1>Definitely Wow. Okay, what a tour. We went from setting

379
00:19:39.319 --> 00:19:42.079
<v Speaker 1>up your local machine, figuring out hosting for web apps

380
00:19:42.079 --> 00:19:46.440
<v Speaker 1>and static sites, designing server lists, workflows, locking down secrets.

381
00:19:46.039 --> 00:19:47.319
<v Speaker 2>Powered a lot of ground.

382
00:19:47.079 --> 00:19:51.200
<v Speaker 1>Then into the huge world of data storage, queues, databases,

383
00:19:51.759 --> 00:19:55.480
<v Speaker 1>and finally monitoring and adding that AI magic with Azure

384
00:19:55.559 --> 00:20:00.359
<v Speaker 1>Open Ai. This Azure for Developers third edition really is hacked.

385
00:20:00.400 --> 00:20:02.279
<v Speaker 1>We've only scratched the surface here.

386
00:20:02.319 --> 00:20:03.720
<v Speaker 2>It's a comprehensive guide for sure.

387
00:20:03.960 --> 00:20:05.880
<v Speaker 1>So the final thought for you listening, what does all

388
00:20:05.960 --> 00:20:08.319
<v Speaker 1>this mean? We've seen Azure is constantly changing right more

389
00:20:08.359 --> 00:20:10.640
<v Speaker 1>and more specialized services, sometimes they even.

390
00:20:10.440 --> 00:20:12.440
<v Speaker 2>Overlap a bit, always evolving, which.

391
00:20:12.279 --> 00:20:16.680
<v Speaker 1>Gives you incredible power, But also it's a challenge. How

392
00:20:16.680 --> 00:20:19.519
<v Speaker 1>do you as a developer keep navigating this? How do

393
00:20:19.559 --> 00:20:22.039
<v Speaker 1>you consistently pick not just a solution, but the best

394
00:20:22.079 --> 00:20:24.880
<v Speaker 1>solution for what you need right now? Especially knowing that

395
00:20:24.880 --> 00:20:28.799
<v Speaker 1>today's shiny new thing might be legacy tomorrow. It's just

396
00:20:28.839 --> 00:20:31.839
<v Speaker 1>a continuous deep dive, isn't it, Always learning, always evaluating,