WEBVTT

1
00:00:00.080 --> 00:00:03.080
<v Speaker 1>Welcome back to the deep dive. Today, we're really getting

2
00:00:03.120 --> 00:00:05.360
<v Speaker 1>into the weeds of Azure cloud deployment.

3
00:00:05.519 --> 00:00:09.080
<v Speaker 2>Yeah, specifically how to make them wealth simpler and faster,

4
00:00:09.320 --> 00:00:11.000
<v Speaker 2>more robust too exactly.

5
00:00:11.599 --> 00:00:14.160
<v Speaker 1>And our guide for this is Selena Thresen's new book,

6
00:00:14.439 --> 00:00:17.320
<v Speaker 1>az Your Bicep Quick Start pro It just came out

7
00:00:17.600 --> 00:00:18.920
<v Speaker 1>July twenty twenty four.

8
00:00:19.120 --> 00:00:22.160
<v Speaker 2>Right. It covers everything from the basics you know, Jason

9
00:00:22.239 --> 00:00:25.120
<v Speaker 2>and air ARM all the way to advance the ICD

10
00:00:25.359 --> 00:00:26.480
<v Speaker 2>and environment management.

11
00:00:26.800 --> 00:00:29.679
<v Speaker 1>Our mission then really is to unlock what azure bicep

12
00:00:29.760 --> 00:00:31.839
<v Speaker 1>can do for you. We want to show how it

13
00:00:31.879 --> 00:00:36.119
<v Speaker 1>takes that often tangled mass of infrastructure management.

14
00:00:36.320 --> 00:00:38.000
<v Speaker 2>It can definitely feel like that, sometimes it.

15
00:00:38.039 --> 00:00:43.399
<v Speaker 1>Turns it into something streamlined, consistent and importantly secure. Absolutely,

16
00:00:43.679 --> 00:00:45.960
<v Speaker 1>And to kick things off, Selena actually starts her book

17
00:00:45.960 --> 00:00:47.159
<v Speaker 1>with a pretty compelling story.

18
00:00:47.439 --> 00:00:49.320
<v Speaker 2>Ah, the origin story, you could.

19
00:00:49.119 --> 00:00:51.560
<v Speaker 1>Say, kind of yeah. She talks about this high stage

20
00:00:51.640 --> 00:00:55.880
<v Speaker 1>project wrestling with those old Jason based AIRM templates. Just

21
00:00:56.119 --> 00:00:57.079
<v Speaker 1>sheer frustration.

22
00:00:57.280 --> 00:00:59.799
<v Speaker 2>I think many can relate to that feeling, the verbosity,

23
00:00:59.840 --> 00:01:01.399
<v Speaker 2>that complexity totally.

24
00:01:01.880 --> 00:01:05.200
<v Speaker 1>She mentions the fear of manual errors, tight deadlines, just

25
00:01:05.239 --> 00:01:08.200
<v Speaker 1>this sprawling list of Azure resources. It felt like there

26
00:01:08.200 --> 00:01:10.519
<v Speaker 1>had to be a better way. You know. Then during

27
00:01:10.560 --> 00:01:13.920
<v Speaker 1>this late night deployment issue, needing a really quick surgical fix,

28
00:01:14.680 --> 00:01:16.640
<v Speaker 1>she stumbled upon BICEP and that.

29
00:01:16.719 --> 00:01:18.560
<v Speaker 2>Was the light bulb moment exactly.

30
00:01:18.719 --> 00:01:21.560
<v Speaker 1>She found its modular approach let her just zero in

31
00:01:21.599 --> 00:01:24.840
<v Speaker 1>on the problem, changed one small reusable piece of code,

32
00:01:25.200 --> 00:01:26.840
<v Speaker 1>and push the fix super fast.

33
00:01:27.000 --> 00:01:29.400
<v Speaker 2>Wow. So it wasn't just fixing the bug. It changed

34
00:01:29.400 --> 00:01:31.640
<v Speaker 2>how she thought about deployments completely.

35
00:01:31.879 --> 00:01:37.359
<v Speaker 1>It showed her the path to automated, predictable deployments and well,

36
00:01:37.400 --> 00:01:40.640
<v Speaker 1>that experience ultimately inspired her to write this book.

37
00:01:41.280 --> 00:01:43.760
<v Speaker 2>Okay, so let's maybe rewind a bit. Start at the beginning.

38
00:01:43.959 --> 00:01:46.959
<v Speaker 2>What exactly is infrastructure as code I see, especially an

39
00:01:46.959 --> 00:01:51.079
<v Speaker 2>Azure and what role do those traditional ARM templates play?

40
00:01:51.200 --> 00:01:56.519
<v Speaker 1>Right? So, IC basically means managing your infrastructure, your VMS, databases, networks,

41
00:01:56.640 --> 00:01:59.879
<v Speaker 1>everything using code. Instead of clicking around in the Azure portal,

42
00:01:59.920 --> 00:02:01.719
<v Speaker 1>you to find it all in files.

43
00:02:01.680 --> 00:02:05.840
<v Speaker 2>And in Azure. The main engine for this is ARM,

44
00:02:05.920 --> 00:02:09.360
<v Speaker 2>the Azure Resource Manager. Think of it as the control plane.

45
00:02:09.400 --> 00:02:14.840
<v Speaker 2>It handles deploying, updating, deleting all your Azure resources consistently.

46
00:02:15.120 --> 00:02:16.879
<v Speaker 1>The central nervous system you called it earlier.

47
00:02:17.039 --> 00:02:18.800
<v Speaker 2>Yeah, that's a good way to put it. It works

48
00:02:18.800 --> 00:02:22.400
<v Speaker 2>on a few core ideas. First, resource groups, you bundle

49
00:02:22.479 --> 00:02:26.879
<v Speaker 2>related resources together, like all the parts of your web app, servers, database,

50
00:02:26.960 --> 00:02:31.680
<v Speaker 2>storage go in one group. Makes management easier logical container exactly.

51
00:02:32.000 --> 00:02:34.919
<v Speaker 2>Then you use declarative templates. These are files where you

52
00:02:34.960 --> 00:02:37.159
<v Speaker 2>just describe what you want your end state to look like.

53
00:02:37.199 --> 00:02:39.120
<v Speaker 2>You don't list the steps, just the final setup.

54
00:02:39.159 --> 00:02:40.280
<v Speaker 1>Tell it the what, not the how.

55
00:02:40.439 --> 00:02:42.919
<v Speaker 2>Precisely. AIRM figures out the how. It talks to different

56
00:02:42.960 --> 00:02:45.599
<v Speaker 2>resource provider services that actually know how to create a

57
00:02:45.680 --> 00:02:47.479
<v Speaker 2>VM or a storage account and so on.

58
00:02:47.599 --> 00:02:47.879
<v Speaker 1>Got it.

59
00:02:48.280 --> 00:02:51.439
<v Speaker 2>And you also have things like tags for organization key

60
00:02:51.560 --> 00:02:56.240
<v Speaker 2>value pairs like environment dot prod or costcenter dot finance

61
00:02:56.639 --> 00:02:57.680
<v Speaker 2>helps you track things.

62
00:02:57.919 --> 00:03:01.960
<v Speaker 1>Okay, ARM sounds pretty foundational, but let's make it real.

63
00:03:02.400 --> 00:03:05.360
<v Speaker 1>How would this help manage something really complex, like say

64
00:03:05.680 --> 00:03:07.759
<v Speaker 1>a huge streaming service think Netflix.

65
00:03:08.039 --> 00:03:11.199
<v Speaker 2>That's a great example because it shows the scale ARM handles.

66
00:03:11.759 --> 00:03:15.039
<v Speaker 2>So for a Netflix like service, you'd probably define a

67
00:03:15.080 --> 00:03:19.759
<v Speaker 2>main resource group maybe streaming service right inside a single

68
00:03:20.080 --> 00:03:23.560
<v Speaker 2>ARM template, just one file. You could define all the bits,

69
00:03:23.960 --> 00:03:27.560
<v Speaker 2>the web server, vms, the databases for user info, the

70
00:03:27.599 --> 00:03:31.000
<v Speaker 2>CDN for video delivery, the authentication service.

71
00:03:31.319 --> 00:03:33.280
<v Speaker 1>Everything all in one definition yep.

72
00:03:33.520 --> 00:03:37.599
<v Speaker 2>And crucially, ARM gets the dependencies. It knows the database

73
00:03:37.680 --> 00:03:41.000
<v Speaker 2>needs to exist before the web servers that connect to it.

74
00:03:41.000 --> 00:03:42.560
<v Speaker 2>It orchestrates that automatically.

75
00:03:42.719 --> 00:03:45.439
<v Speaker 1>Ah. So no more manual sequencing errors hopefully not.

76
00:03:45.599 --> 00:03:49.879
<v Speaker 2>It simplifies bulk actions too, starting, stopping, maybe even replicating.

77
00:03:49.919 --> 00:03:52.680
<v Speaker 2>The whole environment becomes one operation. Plus it ties into

78
00:03:52.759 --> 00:03:55.759
<v Speaker 2>RBAC role based Access control for security.

79
00:03:55.319 --> 00:03:57.080
<v Speaker 1>So only the right people can touch the right.

80
00:03:56.960 --> 00:04:00.479
<v Speaker 2>Resources exactly, and you can enforce policies like naming rules

81
00:04:00.560 --> 00:04:03.280
<v Speaker 2>or which regions you're allowed to deploy into. It all

82
00:04:03.360 --> 00:04:07.560
<v Speaker 2>leads to consistent, automated and secure deployments, even for really

83
00:04:07.560 --> 00:04:08.479
<v Speaker 2>complex stuff.

84
00:04:08.719 --> 00:04:12.319
<v Speaker 1>Okay, that sounds powerful, but you mentioned earlier Selena's frustration.

85
00:04:13.240 --> 00:04:15.680
<v Speaker 1>If Aaron is so capable, what was the big deal

86
00:04:15.719 --> 00:04:17.360
<v Speaker 1>with writing these templates in Jason?

87
00:04:17.879 --> 00:04:21.920
<v Speaker 2>Ah? Yes. The Jason challenge see JSON itself is you know,

88
00:04:22.079 --> 00:04:25.040
<v Speaker 2>a standard data format, objects with curly braces, a raise

89
00:04:25.079 --> 00:04:27.160
<v Speaker 2>with square brackets, key value pairs.

90
00:04:27.439 --> 00:04:30.160
<v Speaker 1>It works fine for simple data transfer, right.

91
00:04:30.240 --> 00:04:34.519
<v Speaker 2>But AIRM templates defining say dozens or hundreds of resources,

92
00:04:34.560 --> 00:04:39.839
<v Speaker 2>they become massive, really verbose, deeply nested structures, lots of

93
00:04:39.839 --> 00:04:43.120
<v Speaker 2>boilerplate code, brackets and commas everywhere.

94
00:04:42.680 --> 00:04:44.160
<v Speaker 1>Hard to read, hard to write.

95
00:04:43.920 --> 00:04:47.800
<v Speaker 2>Extremely it's like reading legal documents, almost very easy to

96
00:04:47.839 --> 00:04:50.800
<v Speaker 2>miss a comma or a bracket leading to errors. Debugging

97
00:04:50.879 --> 00:04:53.160
<v Speaker 2>was a nightmare, and just maintaining it over time that

98
00:04:53.240 --> 00:04:55.319
<v Speaker 2>sheer verbosity. It was a major pain point.

99
00:04:55.480 --> 00:04:58.399
<v Speaker 1>Okay, so Jason was the headache. Ter ash your BICEP.

100
00:04:58.920 --> 00:05:00.560
<v Speaker 1>What is it and why is it seen? Is such

101
00:05:00.560 --> 00:05:01.319
<v Speaker 1>a big improvement.

102
00:05:01.480 --> 00:05:04.480
<v Speaker 2>BICEP is what's called a domain specific language a DSL.

103
00:05:04.600 --> 00:05:08.079
<v Speaker 2>It was built specifically for deploying Azure resources. Its whole

104
00:05:08.120 --> 00:05:11.199
<v Speaker 2>reason for existing is to be simpler, more concise, and

105
00:05:11.319 --> 00:05:13.720
<v Speaker 2>way more readable than those Jason arm templates.

106
00:05:14.079 --> 00:05:16.600
<v Speaker 1>Designed from the ground up to fix those Jason issues.

107
00:05:16.879 --> 00:05:20.560
<v Speaker 2>Pretty much, it's all about improving the developer experience, reducing

108
00:05:20.600 --> 00:05:24.639
<v Speaker 2>that complexity, making it easier to write correct infrastructure code,

109
00:05:24.839 --> 00:05:26.439
<v Speaker 2>and catching errors earlier.

110
00:05:26.600 --> 00:05:29.680
<v Speaker 1>What's really interesting, then, is how it tackles those specific

111
00:05:29.800 --> 00:05:31.879
<v Speaker 1>limitations we just talked about, yea, how does it make

112
00:05:31.920 --> 00:05:32.600
<v Speaker 1>life easier?

113
00:05:32.839 --> 00:05:36.319
<v Speaker 2>The difference is stark, honestly. Readability is the first thing

114
00:05:36.360 --> 00:05:40.120
<v Speaker 2>you notice. Remember that Jason snippet for a simple storage

115
00:05:40.120 --> 00:05:43.839
<v Speaker 2>account maybe a dozen lines, lots of syntax noise, Yeah,

116
00:05:43.920 --> 00:05:47.279
<v Speaker 2>kind of dense. The equivalent BICEP code it's like five lines.

117
00:05:47.279 --> 00:05:50.720
<v Speaker 2>It looks much more like a simple declaration resource storage account,

118
00:05:50.759 --> 00:05:54.480
<v Speaker 2>Microsoft Dot Storage storage accounts. It's cleaner, more.

119
00:05:54.319 --> 00:05:58.800
<v Speaker 1>Intuitive, Okay, visually much simpler, but what about beyond just looks.

120
00:05:58.639 --> 00:06:02.000
<v Speaker 2>Oh huge improvements in the workflow, Type safety and intellisens

121
00:06:02.040 --> 00:06:04.959
<v Speaker 2>are big ones. As you type in tools like vs

122
00:06:04.959 --> 00:06:08.720
<v Speaker 2>code byStep understands the Azure resource types and properties. It

123
00:06:08.720 --> 00:06:11.639
<v Speaker 2>gives you autocompletion and flag errors right there.

124
00:06:11.600 --> 00:06:13.680
<v Speaker 1>Like having a spell checker for your infrastructure code.

125
00:06:13.759 --> 00:06:18.480
<v Speaker 2>Kind of yeah, but smarter. It catches structural errors, type mismatches,

126
00:06:18.519 --> 00:06:20.839
<v Speaker 2>things like that before you even try to deploy. Save

127
00:06:21.199 --> 00:06:21.879
<v Speaker 2>tons of time.

128
00:06:22.079 --> 00:06:26.199
<v Speaker 1>Nice. Then there's automatic dependency management. Often you don't even

129
00:06:26.240 --> 00:06:30.120
<v Speaker 1>need to explicitly say this depends on that. BICEP can

130
00:06:30.160 --> 00:06:33.639
<v Speaker 1>infer the order based on how you reference resources. Ah

131
00:06:33.720 --> 00:06:37.720
<v Speaker 1>less manual wiring exactly. It also has much better modularity

132
00:06:37.759 --> 00:06:42.639
<v Speaker 1>built in. Creating reusable components is straightforward, air messages are clearer,

133
00:06:42.959 --> 00:06:46.399
<v Speaker 1>debugging is easier, and it integrates smoothly with the Azure

134
00:06:46.480 --> 00:06:51.120
<v Speaker 1>Cli PowerShell vs code all the standard tools.

135
00:06:51.199 --> 00:06:53.680
<v Speaker 2>Seems like a much smoother experience overall. How easy is

136
00:06:53.680 --> 00:06:56.000
<v Speaker 2>it to actually get started with it?

137
00:06:56.079 --> 00:06:59.759
<v Speaker 1>Surprisingly easy. If you use visual Studio code, just install

138
00:06:59.800 --> 00:07:05.000
<v Speaker 1>the extension and that gives you all the good stuff syntax, highlighting, IntelliSense, validation.

139
00:07:05.160 --> 00:07:06.920
<v Speaker 2>Okay, just an extension install yep.

140
00:07:07.240 --> 00:07:09.160
<v Speaker 1>And if you already have a bunch of JSON armed

141
00:07:09.160 --> 00:07:13.040
<v Speaker 1>templates lying around, there's a command as bi sep decompile.

142
00:07:13.279 --> 00:07:15.480
<v Speaker 1>It'll convert your jason files into BICEP.

143
00:07:15.680 --> 00:07:18.199
<v Speaker 2>That's handy, so you can migrate existing stuff exactly.

144
00:07:18.240 --> 00:07:20.319
<v Speaker 1>It gives you a starting point, lets you leverage what

145
00:07:20.360 --> 00:07:21.000
<v Speaker 1>you've already built.

146
00:07:21.040 --> 00:07:23.120
<v Speaker 2>All right, so we know why BICEP is better. Now

147
00:07:23.160 --> 00:07:25.519
<v Speaker 2>how do we actually use it? What are the main

148
00:07:25.680 --> 00:07:28.360
<v Speaker 2>parts of a BICEP file, the building blocks. Well, it

149
00:07:28.399 --> 00:07:31.439
<v Speaker 2>still uses that declarative approach. You define the end state

150
00:07:31.480 --> 00:07:33.600
<v Speaker 2>you want and Azure figures out how to make it

151
00:07:33.600 --> 00:07:36.680
<v Speaker 2>happen till the what not the how exactly. The core

152
00:07:36.720 --> 00:07:40.720
<v Speaker 2>elements you'll see are parameters, which are your inputs, things

153
00:07:40.759 --> 00:07:44.519
<v Speaker 2>like resource names, locations, maybe VM sizes. You can give

154
00:07:44.560 --> 00:07:49.920
<v Speaker 2>them default values, allowed values, descriptions, make them flexible.

155
00:07:50.279 --> 00:07:53.360
<v Speaker 1>PRAM location string westis.

156
00:07:52.800 --> 00:07:55.680
<v Speaker 2>Sort of thing precisely. Then you have variables. These are

157
00:07:55.680 --> 00:07:59.279
<v Speaker 2>for storing values you reuse within the template, maybe constructing

158
00:07:59.279 --> 00:08:01.600
<v Speaker 2>a unique name or a common setting.

159
00:08:01.360 --> 00:08:03.639
<v Speaker 1>Like var storage skews standard RS.

160
00:08:04.240 --> 00:08:07.000
<v Speaker 2>Then the main part resources. This is where you define

161
00:08:07.000 --> 00:08:09.600
<v Speaker 2>the actual Azure services you want to deploy, the storage accounts,

162
00:08:09.600 --> 00:08:15.199
<v Speaker 2>the virtual networks, the databases. You specify the type, API, version, name, location.

163
00:08:14.839 --> 00:08:17.079
<v Speaker 1>And properties the actual infrastructure bits right.

164
00:08:17.519 --> 00:08:21.160
<v Speaker 2>And finally, outputs. These are values that the template returns

165
00:08:21.199 --> 00:08:24.160
<v Speaker 2>after deployment, maybe the public IP address of a VM

166
00:08:24.560 --> 00:08:27.759
<v Speaker 2>or the connection string for a database. Useful for connecting

167
00:08:27.800 --> 00:08:28.600
<v Speaker 2>deployments together.

168
00:08:28.920 --> 00:08:34.320
<v Speaker 1>Okay, parameters, variables, resources, outputs seem straightforward, but how do

169
00:08:34.399 --> 00:08:38.639
<v Speaker 1>we make templates you know, more dynamic handle different situations.

170
00:08:38.720 --> 00:08:41.840
<v Speaker 2>That's where the more advanced features come in. You've got conditions.

171
00:08:42.120 --> 00:08:45.320
<v Speaker 2>Using an if keyword, you can say, deploy this resource

172
00:08:45.480 --> 00:08:47.200
<v Speaker 2>only if this parameter is true.

173
00:08:47.519 --> 00:08:50.600
<v Speaker 1>Ah, so like only deploy monitoring tools.

174
00:08:50.360 --> 00:08:54.039
<v Speaker 2>In production exactly, or maybe deploy a specific type of

175
00:08:54.120 --> 00:08:58.240
<v Speaker 2>VM based on an environment parameter. Very useful for tailoring deployments.

176
00:08:58.279 --> 00:08:58.759
<v Speaker 1>Makes sense.

177
00:08:58.840 --> 00:09:01.639
<v Speaker 2>Then you have loops using four if you need, say

178
00:09:02.120 --> 00:09:05.360
<v Speaker 2>five identical storage accounts instead of copying the resource block

179
00:09:05.399 --> 00:09:07.519
<v Speaker 2>five times, you just loop over an array of names

180
00:09:07.559 --> 00:09:08.399
<v Speaker 2>or configurations.

181
00:09:08.519 --> 00:09:10.360
<v Speaker 1>Much cleaner, less repetition.

182
00:09:10.000 --> 00:09:14.720
<v Speaker 2>Way cleaner now dependency handling. While BICEP is smart about dependencies,

183
00:09:14.799 --> 00:09:17.200
<v Speaker 2>sometimes you do need to explicitly tell it. The order

184
00:09:17.279 --> 00:09:18.600
<v Speaker 2>using dependsen.

185
00:09:18.600 --> 00:09:21.519
<v Speaker 1>When would you need that. If it's often automatic.

186
00:09:21.279 --> 00:09:24.879
<v Speaker 2>Sometimes it's subtle. Maybe resource B doesn't technically block resource

187
00:09:24.919 --> 00:09:27.759
<v Speaker 2>A from being created, but resource A needs a value

188
00:09:27.759 --> 00:09:32.200
<v Speaker 2>from resource B during its configuration. Explicit depends on insures

189
00:09:32.200 --> 00:09:36.159
<v Speaker 2>B finishes completely first. It also helps prevent weird stuff

190
00:09:36.480 --> 00:09:40.000
<v Speaker 2>like circular dependencies A depends on B and B depends

191
00:09:40.039 --> 00:09:40.279
<v Speaker 2>on A.

192
00:09:40.639 --> 00:09:41.799
<v Speaker 1>Right, avoiding those loops.

193
00:09:41.960 --> 00:09:45.440
<v Speaker 2>Yeah, and managing complex chains like VM needs an NIC,

194
00:09:45.639 --> 00:09:48.399
<v Speaker 2>which needs a subnet, which needs a VNT depends on

195
00:09:48.440 --> 00:09:51.240
<v Speaker 2>clarifies those multi level relationships one needed.

196
00:09:51.320 --> 00:09:53.639
<v Speaker 1>Got it crucial for complex setups.

197
00:09:53.200 --> 00:09:58.080
<v Speaker 2>Absolutely and maybe most critical. Securely managing secrets never ever

198
00:09:58.200 --> 00:10:01.559
<v Speaker 2>hard code passwords, apike is or connection strings in your templates.

199
00:10:01.679 --> 00:10:02.919
<v Speaker 1>Big no, no, huge.

200
00:10:03.399 --> 00:10:05.519
<v Speaker 2>The way to do it is with Azure key volt.

201
00:10:05.879 --> 00:10:08.639
<v Speaker 2>You store your secrets securely in key volt, then in

202
00:10:08.679 --> 00:10:11.399
<v Speaker 2>your BICEP template you reference them. You can define a

203
00:10:11.399 --> 00:10:13.519
<v Speaker 2>parameter with a at secure decorator like.

204
00:10:13.480 --> 00:10:14.840
<v Speaker 1>Peram admin password string.

205
00:10:14.879 --> 00:10:18.039
<v Speaker 2>It's secure exactly, that tells bise up. In Azure this

206
00:10:18.120 --> 00:10:21.440
<v Speaker 2>is sensitive during deployment. The value is fetched securely from

207
00:10:21.519 --> 00:10:24.360
<v Speaker 2>key volt The secret itself never lives in your code

208
00:10:24.399 --> 00:10:25.320
<v Speaker 2>or your source control.

209
00:10:25.399 --> 00:10:27.759
<v Speaker 1>Much safer centralized secret management.

210
00:10:27.679 --> 00:10:30.759
<v Speaker 2>And you control who or what like your deployment pipeline

211
00:10:30.840 --> 00:10:34.320
<v Speaker 2>can access which secrets in key vault granular control.

212
00:10:34.600 --> 00:10:37.759
<v Speaker 1>Okay, and what about when things go wrong? Errors? Debugging?

213
00:10:38.120 --> 00:10:41.399
<v Speaker 2>BISUP tooling really helps here. The vs code extension gives

214
00:10:41.399 --> 00:10:44.639
<v Speaker 2>you that real time validation, catching syntax errors as you type.

215
00:10:44.840 --> 00:10:47.960
<v Speaker 2>Intell a sense helps you avoid typos in resource types or.

216
00:10:47.879 --> 00:10:49.360
<v Speaker 1>Properties, catching things early.

217
00:10:49.559 --> 00:10:52.279
<v Speaker 2>Yeah, and before you deploy for real. You can use

218
00:10:52.320 --> 00:10:56.399
<v Speaker 2>the Azure cli command as deployment group validated. It basically

219
00:10:56.399 --> 00:10:59.759
<v Speaker 2>does a dry run checks your template and parameters against Azure,

220
00:11:00.200 --> 00:11:04.080
<v Speaker 2>finds potential issues like naming conflicts or missing dependencies, but

221
00:11:04.200 --> 00:11:05.679
<v Speaker 2>doesn't actually create anything.

222
00:11:05.799 --> 00:11:08.320
<v Speaker 1>A pre flight check. That sounds incredibly useful.

223
00:11:08.399 --> 00:11:10.559
<v Speaker 2>It saves a lot of failed deployment cycles.

224
00:11:10.720 --> 00:11:14.039
<v Speaker 1>Okay. So as these deployments get bigger, maybe across multiple

225
00:11:14.080 --> 00:11:19.240
<v Speaker 1>teams or projects, how do we avoid just massive unmanageable

226
00:11:19.399 --> 00:11:22.000
<v Speaker 1>BICEP files. You mentioned modules earlier.

227
00:11:22.279 --> 00:11:25.720
<v Speaker 2>Yes, BISEEP modules are absolutely key for scaling. Think back

228
00:11:25.720 --> 00:11:29.120
<v Speaker 2>to Selena's challenge with that plethora of resources. Modules are

229
00:11:29.120 --> 00:11:31.519
<v Speaker 2>how you break that down? A module is just another

230
00:11:31.600 --> 00:11:35.440
<v Speaker 2>BICEP file that defines a logical unit of infrastructure, like

231
00:11:35.480 --> 00:11:38.679
<v Speaker 2>a standard virtual network setup or maybe a web app

232
00:11:38.799 --> 00:11:40.720
<v Speaker 2>with its associated app service plan.

233
00:11:40.879 --> 00:11:43.120
<v Speaker 1>So like creating your own reusable building.

234
00:11:42.919 --> 00:11:47.200
<v Speaker 2>Blocks exactly, they offer encapsulation. The main template doesn't need

235
00:11:47.240 --> 00:11:49.720
<v Speaker 2>to know the messy details inside the module, just its

236
00:11:49.720 --> 00:11:53.600
<v Speaker 2>inputs and outputs. Reusability is obvious. Define at once, use

237
00:11:53.639 --> 00:11:57.320
<v Speaker 2>it everywhere. They take parameters so you can customize each instance,

238
00:11:57.600 --> 00:11:59.600
<v Speaker 2>and they provide outputs so you can chain them. A

239
00:11:59.639 --> 00:12:02.759
<v Speaker 2>network module outputs a subnet ID, which a VM module

240
00:12:02.799 --> 00:12:03.279
<v Speaker 2>then uses.

241
00:12:03.399 --> 00:12:04.679
<v Speaker 1>How do you actually use them in code?

242
00:12:04.799 --> 00:12:07.480
<v Speaker 2>You just create your module as a separate dot BISEEP file,

243
00:12:07.519 --> 00:12:10.759
<v Speaker 2>say network dot bicep. Then in your main template use

244
00:12:10.759 --> 00:12:13.720
<v Speaker 2>the module keyword, give it a symbolic name, point to

245
00:12:13.759 --> 00:12:16.399
<v Speaker 2>the filepath, and pass in any required parameters.

246
00:12:16.639 --> 00:12:19.480
<v Speaker 1>Module myv net dot network, dot bi SEP motor.

247
00:12:19.240 --> 00:12:21.519
<v Speaker 2>Sort of thing precisely, and you can nest them too.

248
00:12:21.679 --> 00:12:24.279
<v Speaker 2>Maybe you have a compute module that itself uses a

249
00:12:24.399 --> 00:12:26.679
<v Speaker 2>VM module and a DISC module. You can build up

250
00:12:26.759 --> 00:12:31.039
<v Speaker 2>really complex solutions from these smaller, manageable, reusable pieces.

251
00:12:31.399 --> 00:12:34.960
<v Speaker 1>That sounds much more organized. So with modules in these

252
00:12:35.000 --> 00:12:38.080
<v Speaker 1>advanced features, how do we handle different configurations for say,

253
00:12:38.320 --> 00:12:42.440
<v Speaker 1>dev staging in production. We don't want the same settings everywhere, right.

254
00:12:42.440 --> 00:12:45.480
<v Speaker 2>That's where parameter files come in. Instead of putting environment

255
00:12:45.519 --> 00:12:48.639
<v Speaker 2>specific values directly in the BICEP file or passing them

256
00:12:48.679 --> 00:12:51.120
<v Speaker 2>one by one on the command line, you create separate

257
00:12:51.159 --> 00:12:54.840
<v Speaker 2>JSON files, maybe Maine dot parameters, dot dev dot json,

258
00:12:55.000 --> 00:12:58.440
<v Speaker 2>Main dot parameters, dot staging dot Json, Maine dot parameters,

259
00:12:58.440 --> 00:12:59.919
<v Speaker 2>dot prod dot json.

260
00:13:00.200 --> 00:13:03.759
<v Speaker 1>So each file has the specific values for that environment exactly.

261
00:13:04.240 --> 00:13:06.919
<v Speaker 2>The dev file might point to a small VM size

262
00:13:06.960 --> 00:13:09.679
<v Speaker 2>and a dev database tier, while the prod file points

263
00:13:09.720 --> 00:13:12.799
<v Speaker 2>to larger sizes and production tiers. When you deploy, you

264
00:13:12.879 --> 00:13:15.120
<v Speaker 2>just tell Azure which parameter file to use for that

265
00:13:15.200 --> 00:13:16.200
<v Speaker 2>specific deployment.

266
00:13:16.320 --> 00:13:18.600
<v Speaker 1>Keeps the main BICEP template generic.

267
00:13:18.200 --> 00:13:22.360
<v Speaker 2>And reusable totally, and you can pass complex types like

268
00:13:22.559 --> 00:13:25.639
<v Speaker 2>arrays and objects as parameters too often defined in these

269
00:13:25.679 --> 00:13:28.879
<v Speaker 2>parameter files, maybe in a ray of subnet configurations or

270
00:13:28.879 --> 00:13:32.759
<v Speaker 2>an object describing VM settings, And again for sensitive stuff

271
00:13:32.799 --> 00:13:35.840
<v Speaker 2>in production parameter files you'd reference as your key vault secrets,

272
00:13:35.919 --> 00:13:38.240
<v Speaker 2>not put the actual secret in the JSON file.

273
00:13:38.600 --> 00:13:41.039
<v Speaker 1>Okay, this is starting to feel really systematic. Let's connect

274
00:13:41.039 --> 00:13:44.039
<v Speaker 1>it all up. How do we integrate BICEP into a

275
00:13:44.080 --> 00:13:49.320
<v Speaker 1>proper CICD pipeline. Continuous integration, continuous deployment. That feels like

276
00:13:49.360 --> 00:13:50.200
<v Speaker 1>the end goal here.

277
00:13:50.360 --> 00:13:54.480
<v Speaker 2>Absolutely, CICD is about automating that whole flow. Code check

278
00:13:54.519 --> 00:13:59.080
<v Speaker 2>in triggers, builds, tests and deployments reduces human error speeds

279
00:13:59.120 --> 00:14:01.799
<v Speaker 2>things up. Takes a boring, which is good exactly by

280
00:14:01.840 --> 00:14:04.200
<v Speaker 2>SEP works great with tools like GitHub Actions or az

281
00:14:04.200 --> 00:14:07.240
<v Speaker 2>your DevOps pipelines. The typical flow is you push your

282
00:14:07.240 --> 00:14:10.080
<v Speaker 2>BICEP code changes to your repository like GitHub or as

283
00:14:10.080 --> 00:14:11.039
<v Speaker 2>your repos.

284
00:14:10.759 --> 00:14:12.240
<v Speaker 1>That kicks off the pipeline YEP.

285
00:14:12.919 --> 00:14:15.519
<v Speaker 2>The pipeline then usually runs steps to set up the

286
00:14:15.519 --> 00:14:19.759
<v Speaker 2>Azure CLI logs into Azure securely using service principles or

287
00:14:19.799 --> 00:14:23.159
<v Speaker 2>managed identities stored as secrets in the CICD platform, and

288
00:14:23.200 --> 00:14:26.519
<v Speaker 2>then runs the as deployment group create command pointing to

289
00:14:26.559 --> 00:14:30.159
<v Speaker 2>your BICEP file and the correct environment specific parameter file,

290
00:14:30.320 --> 00:14:30.759
<v Speaker 2>and it can.

291
00:14:30.679 --> 00:14:33.480
<v Speaker 1>Deploy to different environments based on say the.

292
00:14:33.440 --> 00:14:37.200
<v Speaker 2>Branch name Yeah, easily. You can have conditions in your pipeline,

293
00:14:37.240 --> 00:14:39.840
<v Speaker 2>like if the push was to the main branch, deploy

294
00:14:40.039 --> 00:14:43.360
<v Speaker 2>using parameters dot pro dot json to the production resource group.

295
00:14:43.559 --> 00:14:46.039
<v Speaker 2>If it was the develop branch, use parameters dot dev

296
00:14:46.080 --> 00:14:49.159
<v Speaker 2>dot json for the dev environment. Ensures consistency.

297
00:14:49.360 --> 00:14:52.519
<v Speaker 1>Nice. What about safety nets. If a deployment goes bad.

298
00:14:53.159 --> 00:14:56.840
<v Speaker 2>Critical point, you need roll back and roll forward strategies.

299
00:14:57.120 --> 00:14:59.919
<v Speaker 2>Rollback means quickly reverting to the last known good state.

300
00:15:00.559 --> 00:15:03.600
<v Speaker 2>Maybe your pipeline detects a failure or monitoring catches an

301
00:15:03.600 --> 00:15:07.320
<v Speaker 2>issue immediately after deployment. You might trigger another deployment using

302
00:15:07.320 --> 00:15:10.919
<v Speaker 2>the previous version of the code or a specific rollback parameter.

303
00:15:10.519 --> 00:15:12.000
<v Speaker 1>File get back to safety quickly.

304
00:15:12.200 --> 00:15:16.080
<v Speaker 2>Right roll forward means you quickly fix the issue in

305
00:15:16.120 --> 00:15:20.600
<v Speaker 2>your BICEP code, test it, and deploy the new, corrected version.

306
00:15:21.320 --> 00:15:24.360
<v Speaker 2>The key is having automated ways to do either rather

307
00:15:24.399 --> 00:15:28.960
<v Speaker 2>than scrambling manually. Makes sense and for really minimizing deployment

308
00:15:29.039 --> 00:15:32.759
<v Speaker 2>risk and downtime, especially for user facing applications. You can

309
00:15:32.879 --> 00:15:34.360
<v Speaker 2>use blue green deployments.

310
00:15:34.519 --> 00:15:37.840
<v Speaker 1>Ah, I've heard of this. Two identical environments exactly.

311
00:15:37.919 --> 00:15:40.519
<v Speaker 2>Let's say your live environment is blue. You deploy the

312
00:15:40.559 --> 00:15:44.000
<v Speaker 2>new version of your application and infrastructure using BICEP, of course,

313
00:15:44.320 --> 00:15:47.720
<v Speaker 2>to an identical but currently idle green environment.

314
00:15:48.360 --> 00:15:49.440
<v Speaker 1>Deploy to the side.

315
00:15:49.720 --> 00:15:54.159
<v Speaker 2>You test green thoroughly, smoke tests, integration tests, maybe even

316
00:15:54.279 --> 00:15:56.240
<v Speaker 2>route a tiny bit of life traffic to it. Once

317
00:15:56.279 --> 00:15:59.200
<v Speaker 2>you're confident, flip the switch. Flip the switch using something

318
00:15:59.240 --> 00:16:02.600
<v Speaker 2>like Azure Traffic Manager as your front door. You redirect

319
00:16:02.639 --> 00:16:05.960
<v Speaker 2>all live user traffic from blued green. Green is now live,

320
00:16:06.080 --> 00:16:07.440
<v Speaker 2>Blue becomes idle.

321
00:16:07.240 --> 00:16:09.840
<v Speaker 1>And if something goes wrong with Green after the switch.

322
00:16:09.720 --> 00:16:12.320
<v Speaker 2>You just flip the switch back. Traffic goes back to

323
00:16:12.360 --> 00:16:16.080
<v Speaker 2>the stable blue environment almost instantly. It dramatically reduces the

324
00:16:16.200 --> 00:16:18.960
<v Speaker 2>risk and impact of a bad deployment. You just need

325
00:16:19.000 --> 00:16:22.480
<v Speaker 2>to be careful about state management databases, user sessions during

326
00:16:22.480 --> 00:16:24.879
<v Speaker 2>the switch. Hashtag tashtag outro.

327
00:16:25.320 --> 00:16:28.120
<v Speaker 1>Wow. Okay, that was definitely a deep dive. We went

328
00:16:28.159 --> 00:16:31.399
<v Speaker 1>from the pains of JSON ARM templates, uh huh.

329
00:16:31.240 --> 00:16:35.039
<v Speaker 2>The verbosity, the complexity to really unpacking as your BICEP

330
00:16:35.399 --> 00:16:40.120
<v Speaker 2>it's clean syntax conditions, loops those crucial modules for reuse,

331
00:16:40.240 --> 00:16:45.480
<v Speaker 2>and then connecting it all into automated, reliable CICD pipelines.

332
00:16:45.080 --> 00:16:48.799
<v Speaker 1>Right with strategies like parameter files keyvolt for secrets and

333
00:16:48.840 --> 00:16:52.559
<v Speaker 1>even advanced techniques like blue Green deployments for resilience.

334
00:16:52.080 --> 00:16:56.000
<v Speaker 2>Exactly, and the core takeaway for you the listener is

335
00:16:56.039 --> 00:16:59.240
<v Speaker 2>hopefully that you can now approach AJUT deployments with more confidence.

336
00:16:59.519 --> 00:17:02.440
<v Speaker 2>You can manage your infrastructure as code efficiently, ensuring things

337
00:17:02.480 --> 00:17:07.240
<v Speaker 2>are consistent, reliable, and secure across dev, staging, production, all

338
00:17:07.279 --> 00:17:08.119
<v Speaker 2>your environments.

339
00:17:08.160 --> 00:17:11.519
<v Speaker 1>It's about moving away from manual clicks and potential errors

340
00:17:11.519 --> 00:17:14.039
<v Speaker 1>towards automated, predictable infrastructure.

341
00:17:14.079 --> 00:17:16.519
<v Speaker 2>That's the goal, less firefighting, more building.

342
00:17:16.759 --> 00:17:19.079
<v Speaker 1>So to leave you with something to think about building

343
00:17:19.079 --> 00:17:21.920
<v Speaker 1>on what we've discussed today from Selena Thresen's work, what's

344
00:17:22.000 --> 00:17:25.880
<v Speaker 1>one piece of your own current infrastructure deployment process, maybe

345
00:17:25.920 --> 00:17:29.119
<v Speaker 1>something manual, error prone or inconsistent that you could start

346
00:17:29.160 --> 00:17:33.759
<v Speaker 1>simplifying and securing today by adopting biceps declarative power and

347
00:17:33.839 --> 00:17:35.680
<v Speaker 1>a more modular automated approach