1
00:00:00,200 --> 00:00:02,000
Before we start our episode 
today. 

2
00:00:02,300 --> 00:00:04,900
I have an exciting news to share
with all of you. 

3
00:00:05,200 --> 00:00:08,100
I am having a massive giveaway 
of jetbrains. 

4
00:00:08,100 --> 00:00:11,000
All products pack, personal 
licenses for free. 

5
00:00:11,300 --> 00:00:14,600
Each personal license is worth 
two hundred forty nine US 

6
00:00:14,600 --> 00:00:15,900
dollar. 
Yes. 

7
00:00:16,100 --> 00:00:19,500
You heard it right jetbrains. 
All products pack personal 

8
00:00:19,500 --> 00:00:24,000
licenses, its 100% completely 
free to enter and I will choose 

9
00:00:24,000 --> 00:00:28,100
three lucky winners to win those
licenses, for more information 

10
00:00:28,100 --> 00:00:31,600
on how to participate, please. 
He's check out this URL Tech 

11
00:00:31,600 --> 00:00:35,300
lead, you know, that Dev slash 
jetbrains Dash giveaway. 

12
00:00:35,800 --> 00:00:38,900
Here's the link one more time. 
Tecla journal, the dev slash, 

13
00:00:38,900 --> 00:00:43,400
jetbrains Dash giveaway. 
I wish you all good luck with 

14
00:00:43,400 --> 00:00:45,300
infrastructure is code. 
You're not trying to kind of 

15
00:00:45,300 --> 00:00:48,700
reverse engineer. 
Understand what ended up somehow

16
00:00:48,700 --> 00:00:51,300
onto each system. 
You're actually saying, this is 

17
00:00:51,300 --> 00:00:54,600
how the system is built and 
because it built from that code.

18
00:00:54,600 --> 00:01:01,000
So there is no difference. 
Hey everyone. 

19
00:01:01,600 --> 00:01:03,700
My name is Henry Surya. 
Juan. 

20
00:01:05,000 --> 00:01:07,600
And you're listening to the 
tekhelet journal. 

21
00:01:08,300 --> 00:01:11,400
The show will be bringing you 
the greatest technical leaders 

22
00:01:11,700 --> 00:01:15,200
practitioners and thought 
leaders in the industry to 

23
00:01:15,200 --> 00:01:19,500
discuss about their Journey 
ideas and practices that we all 

24
00:01:19,500 --> 00:01:23,300
can learn and apply to build a 
highly performing technical team

25
00:01:23,500 --> 00:01:26,100
and to make an impact in your 
personal work. 

26
00:01:26,700 --> 00:01:33,700
So let's dive into our Journal. 
Hello everyone. 

27
00:01:34,100 --> 00:01:37,100
Welcome to another episode of 
the tekhelet journal with me 

28
00:01:37,100 --> 00:01:40,400
Ojos, Henry Surya. 
Without one tackle, a journal is

29
00:01:40,400 --> 00:01:42,800
also now available as a YouTube 
channel. 

30
00:01:43,100 --> 00:01:46,100
So for those of you who love 
listening your podcasts on 

31
00:01:46,100 --> 00:01:48,800
YouTube. 
Please know that these podcast 

32
00:01:48,800 --> 00:01:53,000
is also available for you to 
like And subscribe and if you 

33
00:01:53,000 --> 00:01:55,900
are enjoying and have been 
benefiting from these podcasts. 

34
00:01:55,900 --> 00:01:59,700
So much, consider becoming a 
patron of the Tecla Journal by 

35
00:01:59,700 --> 00:02:04,500
visiting the technology node. 
F / Patron, I will sincerely 

36
00:02:04,500 --> 00:02:07,800
appreciate your support so much 
and your valuable support will 

37
00:02:07,800 --> 00:02:10,300
help me a lot to make the 
production of the upcoming 

38
00:02:10,300 --> 00:02:13,900
episodes. 
Most sustainable and frequent as

39
00:02:13,900 --> 00:02:16,700
a patron. 
You also get exclusive access to

40
00:02:16,700 --> 00:02:18,900
Patron. 
Only contents, including direct 

41
00:02:18,900 --> 00:02:21,800
personal access to me. 
So, please, please, please 

42
00:02:21,800 --> 00:02:23,400
pledge your support at 
technology. 

43
00:02:23,400 --> 00:02:27,700
Know, the left / Patron. 
So, I'm very excited to have 

44
00:02:27,700 --> 00:02:29,800
Keith Morris for today's 
episode. 

45
00:02:30,200 --> 00:02:34,200
Kiev is the Cloud Technologies 
at thoughtworks and also the 

46
00:02:34,200 --> 00:02:36,800
author of The O'Reilly 
infrastructure as code book. 

47
00:02:37,100 --> 00:02:40,900
A book that I highly recommend 
if you're into devops cloud and 

48
00:02:40,900 --> 00:02:43,900
infrastructure Automation. 
In this episode. 

49
00:02:44,000 --> 00:02:47,500
I had an enjoyable in-depth 
discussion with Keith regarding 

50
00:02:47,500 --> 00:02:50,500
infrastructure as code. 
And I personally learned a lot 

51
00:02:50,500 --> 00:02:53,700
from his massive experience and 
expertise in this area. 

52
00:02:54,200 --> 00:02:56,400
We discuss things like 
infrastructure as code 

53
00:02:56,400 --> 00:03:01,900
principles patterns and the 
patterns pipeline pad versus And

54
00:03:01,900 --> 00:03:04,200
the latest infrastructures could
new tools. 

55
00:03:04,800 --> 00:03:08,200
We also discuss about his 
upcoming second edition of the 

56
00:03:08,200 --> 00:03:11,900
infrastructure as code book. 
So, without further Ado, let's 

57
00:03:11,900 --> 00:03:18,000
jump right into the episode. 
I give thanks so much for 

58
00:03:18,000 --> 00:03:21,700
joining me in this episode, or 
in the tekhelet journal podcast.

59
00:03:21,800 --> 00:03:23,000
I had drink. 
Thanks for having me on. 

60
00:03:23,200 --> 00:03:26,400
Yeah, so it's a pleasure to meet
you because I read your book few

61
00:03:26,400 --> 00:03:28,300
years back infrastructure as 
code. 

62
00:03:28,500 --> 00:03:31,200
I must say that it's one of my 
favorite technical books. 

63
00:03:31,300 --> 00:03:35,000
So I read it end to end and I 
got the opportunity to have the 

64
00:03:35,000 --> 00:03:37,000
book signed by you as well, 
serious back. 

65
00:03:37,200 --> 00:03:40,900
So before we go into the 
infrastructure as code, I want 

66
00:03:40,900 --> 00:03:42,500
to ask you about your career 
Journey. 

67
00:03:43,000 --> 00:03:46,200
How did you start your career? 
What are the major turning 

68
00:03:46,200 --> 00:03:49,600
points in your career? 
And what led you to dealing with

69
00:03:49,600 --> 00:03:52,500
infrastructure as code and ended
up writing the book? 

70
00:03:53,000 --> 00:03:55,600
Okay. 
So how far back we want to go? 

71
00:03:55,600 --> 00:04:00,300
I mean I started out not in it, 
but I was doing it as a hobby. 

72
00:04:00,300 --> 00:04:02,900
I was running a bullet. 
Board and doing that kind of 

73
00:04:02,900 --> 00:04:04,900
thing. 
And then decided I was enjoying 

74
00:04:04,900 --> 00:04:08,600
that more than what I was doing.
I was managing, like movie 

75
00:04:08,600 --> 00:04:10,600
cinemas. 
I was in a movie cinema company 

76
00:04:11,200 --> 00:04:14,700
and so I decided to go back to 
University and got my master's 

77
00:04:14,700 --> 00:04:18,300
degree in computer science. 
That was around the kind of mid 

78
00:04:18,300 --> 00:04:21,200
90s. 
The internet was a thing, but it

79
00:04:21,207 --> 00:04:24,200
was only just becoming a big 
thing in the u.s. 

80
00:04:24,200 --> 00:04:26,400
At least before it kind of 
started growing bigger. 

81
00:04:26,900 --> 00:04:29,400
So it's still quite knew it was 
still kind of a niche, but it 

82
00:04:29,400 --> 00:04:32,200
was a lot of fun. 
And so I learned about Out Unix.

83
00:04:32,600 --> 00:04:34,900
And I learned a bit of 
programming and all this kind of

84
00:04:34,900 --> 00:04:37,100
stuff. 
And so I worked, I got a job 

85
00:04:37,100 --> 00:04:39,600
actually in my computer science 
department in the the systems 

86
00:04:39,600 --> 00:04:42,400
Administration team. 
And so the same time that I was 

87
00:04:42,400 --> 00:04:44,700
taking classes and learning how 
to program an understanding 

88
00:04:44,700 --> 00:04:47,600
computer science. 
I was also getting to actually 

89
00:04:47,600 --> 00:04:52,100
work with our computer systems 
and because we had the vendors, 

90
00:04:52,100 --> 00:04:55,900
like, son and HP and all of the 
kind of particularly Unix 

91
00:04:55,900 --> 00:04:58,500
vendors would give us equipment.
And so, you know, we got to kind

92
00:04:58,500 --> 00:05:00,800
of do quite a lot of interesting
stuff and play around with lots 

93
00:05:00,800 --> 00:05:02,600
of stuff. 
That was kind of how I got 

94
00:05:02,600 --> 00:05:06,000
started in infrastructure in a 
way and coding was a big part of

95
00:05:06,000 --> 00:05:07,200
it. 
It was scripting like, the way I

96
00:05:07,200 --> 00:05:08,900
learned. 
And that team was very 

97
00:05:08,900 --> 00:05:12,300
old-school. 
We compiled applications to make

98
00:05:12,300 --> 00:05:14,500
them available to users. 
So we had to learn how to do 

99
00:05:14,500 --> 00:05:16,600
that, which meant we had to 
learn how to debug sometimes 

100
00:05:16,600 --> 00:05:18,700
code. 
It was a very kind of, I think 

101
00:05:18,700 --> 00:05:21,300
good introduction. 
So I wrote like Perl scripts and

102
00:05:21,300 --> 00:05:23,600
things like that to do systems 
Administration tasks. 

103
00:05:23,800 --> 00:05:29,100
And after that around 1998, I 
finished and I moved to London 

104
00:05:29,400 --> 00:05:33,000
and I got a job in an industry 
and This was the.com days were 

105
00:05:33,000 --> 00:05:35,000
just starting, especially in 
London. 

106
00:05:35,000 --> 00:05:38,900
It was a bit slower to pick up 
that and the us but then did 

107
00:05:38,900 --> 00:05:41,100
pick up and became a very big 
thing. 

108
00:05:41,200 --> 00:05:44,200
And so I worked in different 
companies over the probably 10, 

109
00:05:44,200 --> 00:05:47,000
12 years from there. 
I worked for several different 

110
00:05:47,000 --> 00:05:49,500
companies that were what I would
call like post startup. 

111
00:05:49,700 --> 00:05:53,400
So there are companies that were
maybe like 25 to 50 people when 

112
00:05:53,400 --> 00:05:57,000
I joined and then they grew to 
maybe a few hundred people. 

113
00:05:57,300 --> 00:05:59,900
So it's very much about taking 
something that was already kind 

114
00:05:59,900 --> 00:06:03,500
of established, but maybe not. 
Immature and then building it 

115
00:06:03,500 --> 00:06:05,400
out. 
So, even when I working across 

116
00:06:05,400 --> 00:06:09,100
roles in software development or
systems Administration, I might 

117
00:06:09,100 --> 00:06:12,000
work in either a role because it
was before devops before you 

118
00:06:12,000 --> 00:06:14,300
could do both of those things. 
But I always kind of found 

119
00:06:14,300 --> 00:06:17,200
myself drawn to the other side 
of things. 

120
00:06:17,200 --> 00:06:19,000
So if I was a systems 
administrator, I be looking. 

121
00:06:19,000 --> 00:06:21,100
Okay, how do we build and deploy
applications? 

122
00:06:21,400 --> 00:06:24,000
And then, if I was a software 
developer, I was looking at, 

123
00:06:24,000 --> 00:06:25,700
well, how do we kind of 
configure our environment? 

124
00:06:25,700 --> 00:06:27,900
So that the thing to stop 
breaking in one environment when

125
00:06:27,900 --> 00:06:29,200
they work in a different 
environment? 

126
00:06:29,200 --> 00:06:31,100
You know, how do we make our 
environments more consistent? 

127
00:06:31,300 --> 00:06:33,600
I was always kind of attracted 
to that kind of thing. 

128
00:06:33,600 --> 00:06:38,100
And then it was probably around 
2008 or so was I think when 

129
00:06:38,100 --> 00:06:40,900
devops became a thing and 
infrastructure as code became a 

130
00:06:40,900 --> 00:06:44,900
thing and when the cloud was 
very, very early on becoming a 

131
00:06:44,907 --> 00:06:47,600
thing AWS started up. 
So all these things kind of 

132
00:06:47,600 --> 00:06:51,200
converged and they were all like
right in my interest areas like,

133
00:06:51,200 --> 00:06:54,200
oh this is perfect. 
And then I came across the 

134
00:06:54,200 --> 00:06:55,600
continuous delivery book. 
Actually. 

135
00:06:55,600 --> 00:06:58,500
It was in the early release as 
we do and as we've done in 

136
00:06:58,500 --> 00:07:02,000
since, with my books, where you 
can go on to What was called 

137
00:07:02,000 --> 00:07:04,300
safari and is now called the 
Riley, an online learning 

138
00:07:04,300 --> 00:07:07,900
platform or something like that.
You can get a pre-release draft 

139
00:07:07,900 --> 00:07:09,900
of the book, basically, so I 
found that continuously every 

140
00:07:09,900 --> 00:07:12,600
book and I was like, wow, this 
is exactly such exciting stuff 

141
00:07:12,600 --> 00:07:13,900
for me. 
It was written by a couple of 

142
00:07:13,900 --> 00:07:16,800
guys just humble and day Farley,
who worked that works. 

143
00:07:16,900 --> 00:07:18,700
And so I said, hey, I want to go
work with that company. 

144
00:07:18,700 --> 00:07:20,700
I want to go work with the 
people who are doing this stuff.

145
00:07:20,700 --> 00:07:22,400
And so I joined thought works. 
I was about 10 years ago. 

146
00:07:22,400 --> 00:07:23,500
Now. 
I've been at thoughtworks ever 

147
00:07:23,500 --> 00:07:26,200
since right. 
It's very interesting history. 

148
00:07:26,200 --> 00:07:29,200
I didn't know that you actually 
interested in writing the book 

149
00:07:29,200 --> 00:07:31,200
because of the continuous 
delivery book both. 

150
00:07:31,300 --> 00:07:33,300
Both books are really awesome 
actually. 

151
00:07:33,600 --> 00:07:36,000
So yeah, it's one of those 
must-read books. 

152
00:07:36,000 --> 00:07:38,400
I must say. 
Yeah, I definitely inspired me. 

153
00:07:38,400 --> 00:07:40,400
I don't think at the time I had 
in mind that I would write a 

154
00:07:40,400 --> 00:07:42,100
book but it's one of those 
inspiring things. 

155
00:07:42,100 --> 00:07:44,000
And certainly know what I did 
decide to write a book. 

156
00:07:44,100 --> 00:07:46,200
That was one of the ones I 
looked at as well, as, 

157
00:07:46,200 --> 00:07:48,400
obviously, Martin Fowler's books
for inspiration. 

158
00:07:48,600 --> 00:07:51,600
So in terms of, you know, how 
the book kind of came about, 

159
00:07:51,700 --> 00:07:54,100
it's funny because, as I said, 
I've had all that interest in 

160
00:07:54,100 --> 00:07:57,000
this area and writing 
infrastructure as code and using

161
00:07:57,000 --> 00:08:00,000
cloud and virtualization and 
everything and working at 

162
00:08:00,000 --> 00:08:02,500
thoughtworks, I would go and 
work with Clients where they're 

163
00:08:02,500 --> 00:08:04,400
asking us to help them to do 
continuous delivery. 

164
00:08:04,500 --> 00:08:06,400
And so, we have to work with 
their infrastructure teams, 

165
00:08:06,400 --> 00:08:09,000
their operation teams to say, 
okay, we need to have 

166
00:08:09,000 --> 00:08:11,600
environments that are set up in 
a very consistent way and hey, 

167
00:08:11,900 --> 00:08:14,200
here's a cool thing. 
You can do to make that easier 

168
00:08:14,200 --> 00:08:15,800
for you. 
You could do infrastructure as 

169
00:08:15,800 --> 00:08:17,100
code. 
And so I would be trying to kind

170
00:08:17,100 --> 00:08:19,700
of persuade people to do that 
and I always thought oh, I was 

171
00:08:19,700 --> 00:08:21,600
waiting for one of the experts 
right because there are all the 

172
00:08:21,600 --> 00:08:23,900
people who are the well-known 
experts and infrastructure. 

173
00:08:23,900 --> 00:08:27,900
As code, those people like 
Andrew Klay Schaefer and Patrick

174
00:08:27,900 --> 00:08:29,600
DuBois and all these kind of 
people these devops people. 

175
00:08:29,600 --> 00:08:32,500
I was expecting one of them. 
It eventually write this book 

176
00:08:32,500 --> 00:08:34,500
that I could then give to these 
people that I'm working with to 

177
00:08:34,500 --> 00:08:35,700
explain. 
Now, here's how to manage your 

178
00:08:35,700 --> 00:08:37,799
environments in a nice 
consistent way so that you can 

179
00:08:37,799 --> 00:08:40,200
do continuous delivery and 
eventually at some point, I 

180
00:08:40,208 --> 00:08:42,700
think some excited, done some 
blog posts and editor approached

181
00:08:42,700 --> 00:08:45,400
me and asked me if I would want 
to write a book on devops and I 

182
00:08:45,408 --> 00:08:47,700
said, I tell you what, I know a 
book, I would like to try to 

183
00:08:47,700 --> 00:08:49,000
write and so that's what 
happened. 

184
00:08:49,000 --> 00:08:51,000
Yeah, I did that. 
Right, right. 

185
00:08:51,000 --> 00:08:55,000
The rest is history, right? 
They said, yeah, so during that 

186
00:08:55,000 --> 00:08:58,600
time, what kind of tools that 
actually exists that let into 

187
00:08:58,600 --> 00:09:01,900
the whole the creation of more 
than One tool. 

188
00:09:01,900 --> 00:09:04,700
So during that time when you set
about doing scripting post 

189
00:09:04,700 --> 00:09:08,100
scripting, are there any tools 
that stand out from the past 

190
00:09:08,100 --> 00:09:11,400
that led into the creation of 
multiple modern tool set that we

191
00:09:11,400 --> 00:09:14,000
see these days. 
I think the one the first one 

192
00:09:14,000 --> 00:09:16,700
that I really got a hold of. 
So I'll tell you that my source 

193
00:09:16,700 --> 00:09:19,500
of information for this stuff 
before infrastructure as code 

194
00:09:19,500 --> 00:09:21,400
was, a thing was a website 
called a chemical 

195
00:09:21,400 --> 00:09:23,800
infrastructures dot org or 
infrastructure dot-org with or 

196
00:09:23,808 --> 00:09:26,300
without an S, there different 
sites, but it's hasn't been 

197
00:09:26,300 --> 00:09:29,900
changed since I think 2007. 
So it's interesting just as all 

198
00:09:29,900 --> 00:09:32,400
this was taking off that Like 
whoever the maintainers were 

199
00:09:32,400 --> 00:09:35,000
didn't really kind of carry it 
on, but it talked about like, 

200
00:09:35,000 --> 00:09:37,300
automatically provisioning 
servers and automatically 

201
00:09:37,300 --> 00:09:39,800
configuring, the two tools. 
They talked about that I started

202
00:09:39,800 --> 00:09:41,500
using. 
When I read that, where one was 

203
00:09:41,500 --> 00:09:44,400
called Fai install, which was 
for Debian Linux. 

204
00:09:44,600 --> 00:09:46,100
I was using physical servers for
this. 

205
00:09:46,100 --> 00:09:47,500
We would take a server that was 
in a rack. 

206
00:09:47,500 --> 00:09:50,600
You would boot it would hit like
the depending on which brand of 

207
00:09:50,600 --> 00:09:52,200
Hardware. 
It was might be the F12 button 

208
00:09:52,200 --> 00:09:54,600
or the F2 button when it boots 
and you would have configured a 

209
00:09:54,600 --> 00:09:56,800
DHCP server. 
So that when you do that and it 

210
00:09:56,800 --> 00:09:59,200
boots, it would like download a 
little installer and then it 

211
00:09:59,200 --> 00:10:01,900
would install the OS and then 
the other two will You would use

212
00:10:01,900 --> 00:10:04,800
then was CF engine, which is 
written by a guy called Mark 

213
00:10:04,800 --> 00:10:07,100
Burgess, who's probably, you 
know, like the God for the 

214
00:10:07,100 --> 00:10:09,800
grandfather of infrastructure as
code again before it was called 

215
00:10:09,800 --> 00:10:11,300
that. 
And that was a server 

216
00:10:11,300 --> 00:10:14,000
configuration tool. 
Very much like so following on 

217
00:10:14,000 --> 00:10:16,500
from that came, kind of puppet 
and Chef and ansible all kind of

218
00:10:16,500 --> 00:10:18,300
followed in the footsteps of CF 
engine. 

219
00:10:18,800 --> 00:10:21,200
So that was kind of how I 
started doing this stuff. 

220
00:10:21,200 --> 00:10:23,900
And uncf engine was certainly 
one of the precursors to all 

221
00:10:23,900 --> 00:10:25,600
this. 
And then I discovered puppet 

222
00:10:25,600 --> 00:10:27,400
when that came out and I 
thought, oh, this is really 

223
00:10:27,400 --> 00:10:30,100
cool. 
And then later, on, and a team 

224
00:10:30,100 --> 00:10:32,700
that was working with one of my 
My colleagues found chef and 

225
00:10:32,700 --> 00:10:35,000
said, hey, let's try using this 
idiom OS and it just kind of 

226
00:10:35,000 --> 00:10:36,400
went from there. 
Right? 

227
00:10:36,400 --> 00:10:39,300
So let's start with what is 
infrastructure as code. 

228
00:10:39,300 --> 00:10:40,400
Then. 
OK? 

229
00:10:40,400 --> 00:10:43,100
Infrastructure is code. 
So you can divide different 

230
00:10:43,100 --> 00:10:44,100
ways. 
People to find different ways. 

231
00:10:44,100 --> 00:10:47,900
I think it's basically about the
idea that the way you manage 

232
00:10:47,900 --> 00:10:51,400
your infrastructure, you define.
It is kind of in files that you 

233
00:10:51,400 --> 00:10:53,200
can manage and treat like source
code. 

234
00:10:53,300 --> 00:10:56,000
And so, this is the idea that 
these things are external to the

235
00:10:56,000 --> 00:10:57,800
tool itself. 
You can put them in a source 

236
00:10:57,800 --> 00:11:00,300
control system. 
You can use any text editor, you

237
00:11:00,300 --> 00:11:03,500
can use any kind of Tools that 
manage and interact with text 

238
00:11:03,500 --> 00:11:05,600
files to do cool and interesting
stuff. 

239
00:11:05,800 --> 00:11:08,900
And then that enables you to do 
things like take software, 

240
00:11:08,900 --> 00:11:11,100
engineering practices. 
So things like test driven 

241
00:11:11,100 --> 00:11:13,600
development, continuous 
integration, continuous 

242
00:11:13,600 --> 00:11:16,300
delivery, you can start using 
these techniques for your 

243
00:11:16,300 --> 00:11:18,900
infrastructure. 
So that's kind of my basic 

244
00:11:18,900 --> 00:11:21,000
definition of it. 
And now I think these days 

245
00:11:21,000 --> 00:11:24,200
there's a big kind of, I'm not 
sure if controversy is the right

246
00:11:24,200 --> 00:11:25,800
word, but there's a big kind of 
movement around. 

247
00:11:25,800 --> 00:11:28,000
Well, should it be coder, or is 
it configuration? 

248
00:11:28,000 --> 00:11:30,200
So I'm working on the second 
edition of the infrastructure as

249
00:11:30,200 --> 00:11:32,300
code book, right now. 
Now, and one of the topics I'm 

250
00:11:32,300 --> 00:11:36,600
trying to kind of articulate in 
there is so we know what are the

251
00:11:36,600 --> 00:11:39,800
different types of languages you
can use and when are they may be

252
00:11:39,800 --> 00:11:42,900
appropriate because so tools, 
like starting with CF engine, 

253
00:11:43,100 --> 00:11:46,400
puppet, chef and then the more 
kind of cloud oriented tools, 

254
00:11:46,400 --> 00:11:48,000
like, terraform and 
cloudformation. 

255
00:11:48,100 --> 00:11:50,300
They're all declarative right 
before that. 

256
00:11:50,300 --> 00:11:53,100
We wrote scripts, where you 
mixed in, how to create the 

257
00:11:53,100 --> 00:11:54,500
infrastructure with what you 
want. 

258
00:11:54,500 --> 00:11:56,400
So you would have like the kind 
of Loops in the create the 

259
00:11:56,400 --> 00:11:59,400
thing, provision a server, and 
then you would loop on like is 

260
00:11:59,400 --> 00:12:01,000
it created yet? 
Wait for it to be created it. 

261
00:12:01,200 --> 00:12:02,900
An error and all those kind of 
things you had to do, all that 

262
00:12:02,900 --> 00:12:05,300
kind of logic around it, but 
these tools kind of separated 

263
00:12:05,300 --> 00:12:06,400
that out. 
So that the tool handle the 

264
00:12:06,400 --> 00:12:07,900
logic. 
You just say, I want my server 

265
00:12:07,900 --> 00:12:10,500
to look like this. 
I have this much RAM this many 

266
00:12:10,500 --> 00:12:12,700
CPUs and so on just declare 
that. 

267
00:12:12,800 --> 00:12:14,800
And now it's interesting that 
we're seeing an emergence of 

268
00:12:14,800 --> 00:12:18,800
tools like plumy and a double CD
K which are bringing in kind of 

269
00:12:18,808 --> 00:12:21,600
general purpose. 
Real programming languages that 

270
00:12:21,600 --> 00:12:24,100
you can use typescript, 
JavaScript python, whatever 

271
00:12:24,100 --> 00:12:27,200
Within These tools and that's 
interesting because in a way it 

272
00:12:27,200 --> 00:12:29,800
looks like it's going back to 
the old scripting of 

273
00:12:29,800 --> 00:12:32,200
infrastructure, but I don't 
think it really is. 

274
00:12:32,200 --> 00:12:34,400
And the reason these tools are 
popular, I think is because you 

275
00:12:34,408 --> 00:12:36,800
get these, if you work with much
of these infrastructure tools, 

276
00:12:36,800 --> 00:12:40,200
if you work with like terraform 
or ansible, you'll see people 

277
00:12:40,200 --> 00:12:42,800
trying to kind of turn them into
procedural languages. 

278
00:12:42,800 --> 00:12:45,500
You see the languages themselves
that the makers of the languages

279
00:12:45,500 --> 00:12:48,500
start adding in like, oh need to
have conditionals and loops and 

280
00:12:48,500 --> 00:12:50,700
and things like that. 
And then the code gets just 

281
00:12:50,700 --> 00:12:53,600
really terrible, really terrible
because it's kind of declarative

282
00:12:53,600 --> 00:12:58,200
and kind of not it's a big mess 
but my thinking on this is that 

283
00:12:58,300 --> 00:13:01,100
it's not so much that like one 
type of language or the other is

284
00:13:01,200 --> 00:13:03,400
The right language to use for 
infrastructure code. 

285
00:13:03,400 --> 00:13:05,600
I think it's that there are 
different concerns different 

286
00:13:05,600 --> 00:13:08,500
things going on in an 
infrastructure codebase and some

287
00:13:08,500 --> 00:13:11,300
of them are more appropriate use
of declarative language and some

288
00:13:11,300 --> 00:13:14,200
are more appropriate to use some
more kind of general purpose, 

289
00:13:14,300 --> 00:13:16,100
procedural and object-oriented 
language. 

290
00:13:16,100 --> 00:13:19,200
I think as a kind of field of 
infrastructure as code. 

291
00:13:19,200 --> 00:13:21,500
This is all still very new and I
don't think we've found the kind

292
00:13:21,500 --> 00:13:24,700
of right form this to say like, 
oh, okay, here's how to organize

293
00:13:24,700 --> 00:13:27,400
your code into different 
concerns and to use different 

294
00:13:27,400 --> 00:13:28,600
tools and different languages 
for each. 

295
00:13:28,600 --> 00:13:31,000
I think we're still discovering 
that which is quite exciting, 

296
00:13:31,000 --> 00:13:32,400
really? 
Really to be kind of doing this 

297
00:13:32,400 --> 00:13:34,800
at this time and kind of 
exploring and discovering an 

298
00:13:34,800 --> 00:13:37,500
industry. 
Yeah, so I find myself as well 

299
00:13:37,500 --> 00:13:41,300
like every few months, should I 
say probably that new things 

300
00:13:41,300 --> 00:13:44,000
coming up as well in terms of 
infrastructure as code. 

301
00:13:44,000 --> 00:13:47,700
So, previously, I used a lot of 
ansible scripts and over the 

302
00:13:47,700 --> 00:13:50,700
time move over to terraform and 
then with Cloud native 

303
00:13:50,700 --> 00:13:53,700
deployment manager, and so 
coming up with like kubernetes 

304
00:13:53,700 --> 00:13:56,500
config connector, and 
communities itself is also in a 

305
00:13:56,500 --> 00:13:58,500
way of format of infrastructure 
as code, right? 

306
00:13:58,500 --> 00:13:59,400
The yeah moans. 
Yep. 

307
00:13:59,900 --> 00:14:02,500
So in the book, you mentioned 
Infrastructure as code is like, 

308
00:14:02,500 --> 00:14:05,300
managing your infrastructure 
just like you're treating a 

309
00:14:05,300 --> 00:14:08,900
software and that's why you 
apply software development best 

310
00:14:08,900 --> 00:14:10,400
practices. 
So what kind of software 

311
00:14:10,400 --> 00:14:13,400
development best practices that 
normally applicable for 

312
00:14:13,400 --> 00:14:16,800
infrastructure as code? 
Is it all of them or just some 

313
00:14:16,800 --> 00:14:19,800
of them? 
Well, I think it kind of depends

314
00:14:19,800 --> 00:14:22,300
and it goes back a little bit to
that point of where the 

315
00:14:22,300 --> 00:14:24,200
different concerns in your code 
base. 

316
00:14:24,200 --> 00:14:27,300
So, I mean, typically the things
I talked about as practices to 

317
00:14:27,300 --> 00:14:29,700
bring into it, it very much 
draws from the kind of agile 

318
00:14:29,800 --> 00:14:32,200
software engineering. 
Practices of test-driven 

319
00:14:32,200 --> 00:14:34,900
development, continuous 
integration, continuous 

320
00:14:34,900 --> 00:14:37,800
delivery, pair programming, all 
those kind of things, as well. 

321
00:14:37,800 --> 00:14:40,500
As I think some of the design 
principles have had a design, 

322
00:14:40,500 --> 00:14:42,800
good software how to keep 
software kind of loosely 

323
00:14:42,800 --> 00:14:44,700
coupled. 
And so on that, we want that for

324
00:14:44,700 --> 00:14:47,400
infrastructure because I think 
what I've see a fair bit of 

325
00:14:47,408 --> 00:14:49,800
these days as people who've been
doing this for a little while to

326
00:14:49,800 --> 00:14:52,600
have very large code bases, for 
example, I work with the client 

327
00:14:52,600 --> 00:14:56,700
in London had a terraform 
project that when you run Tara 

328
00:14:56,700 --> 00:14:59,700
from apply, it could take two 
hours for it to finish. 

329
00:14:59,700 --> 00:15:01,000
So it just kind of this massive 
project. 

330
00:15:01,200 --> 00:15:03,100
It was exactly like we talked 
about software. 

331
00:15:03,100 --> 00:15:05,300
Monolith was a monolithic 
project. 

332
00:15:05,300 --> 00:15:08,900
And so what we helped them to do
was to break that apart into 

333
00:15:09,100 --> 00:15:11,100
smaller. 
So taking that kind of almost 

334
00:15:11,100 --> 00:15:13,400
microservices mentality of how 
can we make it into smaller 

335
00:15:13,400 --> 00:15:16,800
pieces that are Loosely coupled 
and independently, Deployable or

336
00:15:16,800 --> 00:15:19,900
a pliable as it were? 
So for people who are probably 

337
00:15:19,900 --> 00:15:21,400
new to this infrastructure as 
code. 

338
00:15:21,500 --> 00:15:24,700
Can you probably explain? 
Why should they even learn and 

339
00:15:24,700 --> 00:15:26,900
do this infrastructure as code? 
Sure. 

340
00:15:26,900 --> 00:15:31,000
I think the value of 
infrastructure is code is its 

341
00:15:31,100 --> 00:15:34,900
kind of in the reproducibility 
and in the consistency. 

342
00:15:34,900 --> 00:15:37,400
So most of the environment 
certainly that I've worked in 

343
00:15:37,400 --> 00:15:39,300
have been wonder where we're 
doing software delivery. 

344
00:15:39,300 --> 00:15:42,500
We have test environments may be
staging and pre-production, all 

345
00:15:42,500 --> 00:15:45,000
these kind of environments. 
And so one of the kind of first 

346
00:15:45,000 --> 00:15:47,900
things that infrastructure code 
can help you to do, is to make 

347
00:15:47,900 --> 00:15:50,600
sure that those are consistent. 
They're built the same way at 

348
00:15:50,600 --> 00:15:53,200
each point and then I think 
other things infrastructure as 

349
00:15:53,200 --> 00:15:56,900
code can help with is around, 
just making sure that you can 

350
00:15:56,900 --> 00:15:58,900
manage the amount of stuff you 
have. 

351
00:15:58,900 --> 00:16:01,300
So, one of the things that you 
see as you move from a The 

352
00:16:01,300 --> 00:16:04,500
center where all of your servers
are hardware and maybe virtual 

353
00:16:04,500 --> 00:16:07,200
machines, but they have kind of 
a physical limit. 

354
00:16:07,200 --> 00:16:08,700
There's only so many virtual 
machines. 

355
00:16:08,700 --> 00:16:10,700
You can cram onto the hardware 
that you have in your data 

356
00:16:10,700 --> 00:16:12,200
center. 
But then when you go onto the 

357
00:16:12,200 --> 00:16:15,700
cloud, you can create so many 
more and it get out of control. 

358
00:16:15,700 --> 00:16:17,500
And so, how do you manage all of
those things? 

359
00:16:17,500 --> 00:16:20,100
And I think infrastructure as 
code gives you a very good way 

360
00:16:20,100 --> 00:16:23,000
to manage that. 
So rather than using maybe an 

361
00:16:23,000 --> 00:16:25,800
automation tool that's like a 
gooey and then it has the 

362
00:16:25,800 --> 00:16:28,800
configuration information 
inside, an internal data files, 

363
00:16:28,900 --> 00:16:31,000
having it as code in the source 
control. 

364
00:16:31,100 --> 00:16:33,200
That says, this is what my 
infrastructure should look like,

365
00:16:33,200 --> 00:16:35,600
means anybody can look at it. 
So new members of the team can 

366
00:16:35,600 --> 00:16:37,700
join in and they can look at the
infrastructure code and say, oh,

367
00:16:37,700 --> 00:16:39,700
this is how we configure an 
application server. 

368
00:16:39,700 --> 00:16:43,000
This is what our databases look 
like, very easy to see that and 

369
00:16:43,000 --> 00:16:45,700
then also the processes Force. 
Okay, how do we provision a 

370
00:16:45,700 --> 00:16:47,700
system? 
How do we deploy software being 

371
00:16:47,700 --> 00:16:49,900
able to look at the code for 
that as quite a helpful and that

372
00:16:49,900 --> 00:16:52,100
helps as well with more 
controlled environments and we 

373
00:16:52,100 --> 00:16:54,500
have to worry about compliance. 
I can financial services and so 

374
00:16:54,500 --> 00:16:56,400
on. 
Because you know, that stuff can

375
00:16:56,400 --> 00:16:58,700
be auditable. 
You can show an auditor. 

376
00:16:58,700 --> 00:17:01,000
Look, here's the code that 
defines what our system. 

377
00:17:01,100 --> 00:17:04,200
Looks like here's where we 
Define our security rules. 

378
00:17:04,200 --> 00:17:06,400
Here's how changes are made. 
Here's what changes have been 

379
00:17:06,400 --> 00:17:09,000
made, because it's in our source
control history. 

380
00:17:09,400 --> 00:17:11,300
And if you're using something 
like a continuous delivery 

381
00:17:11,300 --> 00:17:13,900
pipeline, you can say, oh, 
here's the logs of, like, every 

382
00:17:13,900 --> 00:17:16,599
change that went through and was
made to our system and who made 

383
00:17:16,599 --> 00:17:18,000
it. 
And what test did we run? 

384
00:17:18,000 --> 00:17:20,800
So that becomes a very strong 
story for kind of compliance and

385
00:17:20,800 --> 00:17:22,300
auditing as well. 
Yeah. 

386
00:17:22,400 --> 00:17:26,300
So what kind of problems if 
let's say people do not adopt 

387
00:17:26,300 --> 00:17:29,300
this infrastructure as code. 
I mean, traditionally going back

388
00:17:29,300 --> 00:17:32,100
years we have seen without Out 
infrastructure as code. 

389
00:17:32,100 --> 00:17:34,800
People can still build and 
manage their infrastructure. 

390
00:17:34,800 --> 00:17:38,400
But what kind of problems that 
normally exists if they stay on 

391
00:17:38,400 --> 00:17:41,300
and do without infrastructure as
code, I think without 

392
00:17:41,300 --> 00:17:44,700
infrastructure as code, what you
often find is that especially 

393
00:17:44,700 --> 00:17:47,100
for a system of any significant 
size. 

394
00:17:47,500 --> 00:17:49,500
You end up with lots of 
different things and lots of 

395
00:17:49,500 --> 00:17:50,800
different versions of things 
running. 

396
00:17:50,900 --> 00:17:53,800
So if you're looking like patch 
levels and so on, you might have

397
00:17:53,800 --> 00:17:56,400
all kinds of different versions 
of say Java running across your 

398
00:17:56,400 --> 00:17:58,800
different systems. 
And then when there's a security

399
00:17:58,800 --> 00:18:01,000
vulnerability is published. 
How do you roll out the patch? 

400
00:18:01,100 --> 00:18:04,200
Is with infrastructure as code. 
Makes it very simple to roll out

401
00:18:04,200 --> 00:18:07,200
patches and keep everything at a
consistent level without that 

402
00:18:07,200 --> 00:18:09,200
you tend to have a little bit 
more of a chaotic environment 

403
00:18:09,200 --> 00:18:11,400
and then it can be difficult 
where you're like deploying an 

404
00:18:11,400 --> 00:18:13,800
application and it works in one 
environment and not another 

405
00:18:13,800 --> 00:18:16,300
environment because there are 
differences and it's hard to 

406
00:18:16,300 --> 00:18:18,200
kind of understand what those 
differences are because you have

407
00:18:18,200 --> 00:18:21,300
to maybe run some tools to try 
to analyze what's on versions of

408
00:18:21,308 --> 00:18:23,700
different things are on there. 
But with infrastructure as code,

409
00:18:23,700 --> 00:18:26,800
you're not trying to kind of 
reverse engineer or understand 

410
00:18:26,800 --> 00:18:29,600
what ended up somehow onto each 
system. 

411
00:18:29,600 --> 00:18:32,200
You're actually saying this is 
how this System is built, and 

412
00:18:32,200 --> 00:18:35,000
because it built from that code.
So, there is no difference. 

413
00:18:35,300 --> 00:18:37,000
Right? 
And also, I think the term 

414
00:18:37,000 --> 00:18:39,700
snowflake service is one of the 
challenge. 

415
00:18:39,800 --> 00:18:40,600
Yeah. 
Yeah, exactly. 

416
00:18:40,600 --> 00:18:42,500
The snowflake server. 
There's no fix the system is 

417
00:18:42,500 --> 00:18:44,400
like the one that everybody's 
afraid to touch or you can't 

418
00:18:44,400 --> 00:18:46,300
rebuild it. 
You're like, oh, nobody really 

419
00:18:46,300 --> 00:18:48,400
knows how to rebuild it. 
We've tried to kind of move off 

420
00:18:48,400 --> 00:18:50,600
of that and onto a new version 
of the operating system, but we 

421
00:18:50,600 --> 00:18:52,800
still have to run the old 
operating system version that 

422
00:18:52,800 --> 00:18:55,400
isn't supported anymore, because
he can't figure out how to 

423
00:18:55,400 --> 00:18:58,200
rebuild it. 
So there's this one term, very 

424
00:18:58,200 --> 00:19:00,200
commonly mentioned. 
When we talk about 

425
00:19:00,200 --> 00:19:02,900
infrastructure as code. 
Which is Pat versus Capital. 

426
00:19:03,000 --> 00:19:05,500
Can you explain to us? 
Like, what is Pat versus 

427
00:19:05,500 --> 00:19:06,500
Capital? 
Yeah. 

428
00:19:06,500 --> 00:19:09,400
So like a pet is like systems 
that you really love. 

429
00:19:10,500 --> 00:19:13,000
You've built them by hand very 
carefully and I used to love 

430
00:19:13,000 --> 00:19:16,400
this right back before, even the
early days where I was using 

431
00:19:16,400 --> 00:19:18,800
infrastructure code. 
Like I mentioned with Hardware 

432
00:19:18,800 --> 00:19:21,200
every server, like, we gave them
special names, we would have 

433
00:19:21,200 --> 00:19:25,400
like a theme and so, when one 
place, I worked all of our Linux

434
00:19:25,400 --> 00:19:28,400
servers were named for Planet, 
so we had, and we didn't have 

435
00:19:28,400 --> 00:19:31,700
very many right at Jupiter and 
Saturn and Pluto and So on, we 

436
00:19:31,700 --> 00:19:33,400
have some other servers that 
would be made me the names of 

437
00:19:33,408 --> 00:19:36,000
the moons Ganymede and Callisto.
And so and that was fun. 

438
00:19:36,000 --> 00:19:37,900
Right, you know, we love doing 
that, that you would work on 

439
00:19:37,900 --> 00:19:40,000
Saturn and make sure that it was
configured nicely, and 

440
00:19:40,000 --> 00:19:41,900
everything. 
And then it was somebody from my

441
00:19:41,900 --> 00:19:43,300
mentioned in the book and I 
can't remember the name of the 

442
00:19:43,300 --> 00:19:45,400
person somebody from. 
I think from CERN in 

443
00:19:45,400 --> 00:19:48,100
Switzerland, who did a talk. 
He says, where I learned. 

444
00:19:48,100 --> 00:19:51,200
It was a talk, they gave around 
treating your servers, like 

445
00:19:51,200 --> 00:19:53,200
cattle rather than pet. 
So cattle her like, you don't 

446
00:19:53,200 --> 00:19:55,600
have an emotional attachment to 
them because you have too many 

447
00:19:55,600 --> 00:19:58,000
of them, and you're going to 
this, kill him anyways and eat 

448
00:19:58,000 --> 00:20:00,200
them or whatever. 
So much, the idea that your 

449
00:20:00,200 --> 00:20:02,600
servers and other Part of your 
infrastructure, you should be 

450
00:20:02,600 --> 00:20:05,500
able to destroy it very easily, 
and recreate it and reproduce 

451
00:20:05,500 --> 00:20:07,400
it. 
And we talked about utility 

452
00:20:07,400 --> 00:20:09,800
computing or used to talk about 
utility computing in this kind 

453
00:20:09,800 --> 00:20:11,900
of like that. 
It's not especially hand-built 

454
00:20:11,900 --> 00:20:14,000
thing. 
It's more industrial era for 

455
00:20:14,000 --> 00:20:18,700
infrastructure, right? 
So when we adopt this, I see, do

456
00:20:18,700 --> 00:20:22,300
we have few principles in mind, 
for example, if you think that I

457
00:20:22,300 --> 00:20:25,100
can think of is in seems like 
infrastructure as code, is 

458
00:20:25,100 --> 00:20:28,400
supporting disposability. 
Like you also mentioned a couple

459
00:20:28,400 --> 00:20:31,100
of times a reproducible. 
So are there actually The 

460
00:20:31,100 --> 00:20:33,300
principles behind infrastructure
as code. 

461
00:20:33,500 --> 00:20:35,400
Yeah, so some of the principles 
as you mentioned, there's the 

462
00:20:35,400 --> 00:20:38,400
idea that you should treat all 
of your systems as disposable 

463
00:20:38,400 --> 00:20:41,300
and this helps with being able 
to kind of know that you can 

464
00:20:41,300 --> 00:20:43,200
rebuild something. 
So helps kind of a disaster 

465
00:20:43,200 --> 00:20:46,400
recovery and continuity to note.
If any part of my system is 

466
00:20:46,400 --> 00:20:48,400
destroyed or compromised or 
whatever. 

467
00:20:48,500 --> 00:20:50,100
I know I can just destroy it and
build it again. 

468
00:20:50,200 --> 00:20:52,300
That's an easy thing to do in a 
common thing to do. 

469
00:20:52,300 --> 00:20:54,700
So that's one of the principles 
and that could undermine the 

470
00:20:54,700 --> 00:20:57,500
idea of kind of unreliability. 
So originally, the idea of the 

471
00:20:57,500 --> 00:21:00,100
cloud was that the hardware 
might not be that reliable and 

472
00:21:00,100 --> 00:21:02,000
it shouldn't matter. 
You should be able to have run 

473
00:21:02,000 --> 00:21:04,800
reliable systems on top of 
anyways, and you see that if you

474
00:21:04,800 --> 00:21:08,000
have that mentality, when like 
there's a failure of a cloud, 

475
00:21:08,100 --> 00:21:10,300
like, when one of the Region's 
native, iOS has a failure. 

476
00:21:10,300 --> 00:21:12,900
You see some organizations are 
down and other organizations are

477
00:21:12,900 --> 00:21:14,100
not. 
Like, Netflix is the classic 

478
00:21:14,100 --> 00:21:16,600
example of, they're really good 
at making sure that they carry 

479
00:21:16,600 --> 00:21:19,400
on running, even if different 
parts of a SS go down. 

480
00:21:19,400 --> 00:21:20,500
And that's because of that 
mentality. 

481
00:21:20,500 --> 00:21:22,600
They treat everything is 
reproducible and assume the 

482
00:21:22,608 --> 00:21:25,700
system is unreliable as being 
able to reproduce everything 

483
00:21:25,700 --> 00:21:29,400
kind of on-demand. 
There's I think, consistency and

484
00:21:29,400 --> 00:21:30,900
kind of trying to reduce 
variability. 

485
00:21:31,000 --> 00:21:33,500
I don't think this is something 
I put necessarily in the first 

486
00:21:33,500 --> 00:21:35,800
edition of the book, but it's 
the idea that you try not to 

487
00:21:35,800 --> 00:21:37,900
have too many different versions
of things running. 

488
00:21:37,900 --> 00:21:40,400
You try to keep everything kind 
of minimized and this helps with

489
00:21:40,400 --> 00:21:43,400
things we saw this with. 
I think it was the Heartbleed 

490
00:21:43,400 --> 00:21:45,900
security vulnerability that got 
a lot of publicity but the 

491
00:21:45,908 --> 00:21:48,800
openssl the library that's 
installed on systems that people

492
00:21:48,800 --> 00:21:50,800
found that across their various 
servers. 

493
00:21:50,800 --> 00:21:53,700
They had like maybe six seven 
different versions of the 

494
00:21:53,700 --> 00:21:57,300
openssl libraries installed and 
that makes it difficult to kind 

495
00:21:57,300 --> 00:22:00,500
of keep everything a consistent.
And also just to make sure that 

496
00:22:00,500 --> 00:22:02,100
everything is Patched in the 
latest. 

497
00:22:02,100 --> 00:22:05,000
So I think that's another 
important principle, right? 

498
00:22:05,000 --> 00:22:08,000
When we say treating 
infrastructure as code just like

499
00:22:08,000 --> 00:22:10,400
any software development 
practices. 

500
00:22:10,400 --> 00:22:13,400
Are there any sort of patterns 
like in the software world? 

501
00:22:13,400 --> 00:22:16,600
We have design patterns or some 
kind of architectural patterns. 

502
00:22:16,700 --> 00:22:19,000
Are there any problems in? 
I see? 

503
00:22:19,600 --> 00:22:22,300
Yeah, there's definitely. 
So in both addition to the book 

504
00:22:22,300 --> 00:22:26,100
I use patterns for various parts
of the various concerns. 

505
00:22:26,100 --> 00:22:30,400
I've got a few patterns around 
how to provision servers, for 

506
00:22:30,400 --> 00:22:33,400
instance. 
It's so there's like the push 

507
00:22:33,400 --> 00:22:36,800
versus the pull idea. 
So the push idea is that you 

508
00:22:36,800 --> 00:22:39,600
have a tool and ansible tends to
be designed to work this way. 

509
00:22:39,600 --> 00:22:41,400
Although you can use the 
different Tools in different 

510
00:22:41,400 --> 00:22:43,100
ways. 
The idea is that you spin up a 

511
00:22:43,100 --> 00:22:46,100
new server in the cloud or on a 
virtual machine or what have 

512
00:22:46,100 --> 00:22:47,500
you. 
And then you have a process 

513
00:22:47,500 --> 00:22:50,100
sitting outside that connects 
in, Maybe by access logs into 

514
00:22:50,100 --> 00:22:51,700
the machine and then configures 
it. 

515
00:22:51,700 --> 00:22:54,500
So that's kind of a push to kind
of provision and configure a 

516
00:22:54,500 --> 00:22:57,000
machine. 
And then the pool pattern is 

517
00:22:57,000 --> 00:22:59,900
basically, where you say, when 
the machine boots up, it has 

518
00:22:59,900 --> 00:23:02,400
something already pre-installed.
On it that will trigger and 

519
00:23:02,400 --> 00:23:05,800
download configuration files. 
Latest configuration files and 

520
00:23:05,800 --> 00:23:08,000
apply it to itself when. 
So it basically pulls this 

521
00:23:08,000 --> 00:23:10,800
configuration down onto itself. 
And as with any kind of design 

522
00:23:10,800 --> 00:23:12,600
patterns and software 
engineering, there are 

523
00:23:12,600 --> 00:23:15,500
advantages and disadvantages of 
each, maybe where they're more 

524
00:23:15,500 --> 00:23:18,100
appropriate, a lot of people 
like the push pattern because 

525
00:23:18,100 --> 00:23:20,300
you don't have to pre install 
anything on your virtual 

526
00:23:20,300 --> 00:23:22,300
machines. 
So ansible can disconnect in. 

527
00:23:22,300 --> 00:23:25,600
As long as SSH is configured on 
there and you can connect into 

528
00:23:25,600 --> 00:23:26,900
it. 
You can then go and configure 

529
00:23:26,900 --> 00:23:30,000
that machine regardless of how 
it was before whereas the the 

530
00:23:30,000 --> 00:23:31,500
pull pattern. 
Tends to work. 

531
00:23:31,500 --> 00:23:34,800
Well with servers that are 
automatically provision say like

532
00:23:34,800 --> 00:23:37,700
auto-scaling because the 
platform decides to spin up a 

533
00:23:37,700 --> 00:23:39,200
new virtual machine 
automatically. 

534
00:23:39,200 --> 00:23:41,200
And so it's useful that the 
machine is able to configure 

535
00:23:41,200 --> 00:23:43,000
itself, rather than needing to 
have something else. 

536
00:23:43,000 --> 00:23:44,500
No. 
Oh, it's time to go and find 

537
00:23:44,500 --> 00:23:47,700
this new machine and figure it 
right from my personal 

538
00:23:47,700 --> 00:23:49,300
experience. 
Reading this infrastructure as 

539
00:23:49,300 --> 00:23:51,800
code. 
They are often times when people

540
00:23:51,800 --> 00:23:54,300
just learn the tools, like, for 
example, the most popular one, 

541
00:23:54,300 --> 00:23:57,100
obviously is terraformed and 
then afterwards, they learn it. 

542
00:23:57,100 --> 00:24:00,000
They did it, they applied it, 
and the infrastructure is set up

543
00:24:00,000 --> 00:24:02,900
nicely, but then, Over time, 
they go back to, maybe the 

544
00:24:02,900 --> 00:24:06,500
gooey, console-based kind of 
changes being made, or maybe 

545
00:24:06,500 --> 00:24:09,000
they even do like an SSH and go 
into the servers. 

546
00:24:09,100 --> 00:24:13,100
So, what are some of the tips to
avoid these kind of practices? 

547
00:24:13,200 --> 00:24:16,100
Yeah, that's quite common and 
it's certainly the way I tended 

548
00:24:16,100 --> 00:24:19,100
to start out was using the 
automation to build things but 

549
00:24:19,100 --> 00:24:21,900
not so much to change them 
afterwards. 

550
00:24:22,000 --> 00:24:24,800
And what would tend to happen is
you'll create a few different 

551
00:24:24,800 --> 00:24:27,100
application servers. 
They've all got Java and maybe 

552
00:24:27,100 --> 00:24:29,700
they're all running Tomcat, but 
then it's like a one of them is 

553
00:24:29,700 --> 00:24:32,400
getting higher traffic. 
Vanessa figuration needs to be 

554
00:24:32,400 --> 00:24:35,000
tweaked to an optimized to 
handle the traffic level. 

555
00:24:35,000 --> 00:24:38,900
So, maybe you write your ansible
code to go and make that change 

556
00:24:38,900 --> 00:24:41,800
to that server to configuration 
change that application server, 

557
00:24:41,800 --> 00:24:44,300
but you don't run it on the 
other application servers. 

558
00:24:44,300 --> 00:24:46,800
And then later on, you say, oh, 
I need to do an upgrade to 

559
00:24:46,800 --> 00:24:48,800
tomcat. 
And so, I make my ansible 

560
00:24:48,800 --> 00:24:51,700
playbook and I try to use it to 
go and upgrade the Tomcats, And 

561
00:24:51,700 --> 00:24:53,900
it breaks on some of them 
because you've made different 

562
00:24:53,900 --> 00:24:56,900
changes to them in the meantime.
And so, I think the kind of anti

563
00:24:56,900 --> 00:25:00,800
pattern here is using these 
configuration management tools. 

564
00:25:01,100 --> 00:25:04,600
Structures code tools kind of ad
hoc kind of like to make a 

565
00:25:04,600 --> 00:25:08,100
particular change and one of the
stronger patterns that we see to

566
00:25:08,100 --> 00:25:10,700
make it possible to manage 
changes to your infrastructure 

567
00:25:10,700 --> 00:25:13,300
more reliably and make the 
infrastructure code the way. 

568
00:25:13,300 --> 00:25:16,400
The easiest way to do that is 
the continuous synchronization 

569
00:25:16,400 --> 00:25:19,100
pattern and this is the idea 
that your tool just runs in a 

570
00:25:19,100 --> 00:25:21,800
loop and continuously looks at 
the version of the code that 

571
00:25:21,800 --> 00:25:24,200
should be applied. 
Your infrastructure and will 

572
00:25:24,200 --> 00:25:27,500
reapply it again and again, even
if nothing has changed and so 

573
00:25:27,500 --> 00:25:29,600
tools like puppet and Chef were 
designed to do this. 

574
00:25:29,600 --> 00:25:32,300
They have an agent that runs. 
Is on the server and poles, 

575
00:25:32,300 --> 00:25:35,200
maybe every hour or so, and make
sure that it has the latest 

576
00:25:35,200 --> 00:25:37,100
version of the code. 
If the code is changed, it gets 

577
00:25:37,100 --> 00:25:38,600
the latest version and it hasn't
changed. 

578
00:25:38,600 --> 00:25:40,500
It just reapply as the existing 
version. 

579
00:25:40,500 --> 00:25:42,500
And that kind of make sure that 
everything is kind of pulled in 

580
00:25:42,500 --> 00:25:44,200
to the same version all of the 
time. 

581
00:25:44,500 --> 00:25:46,700
When you do go and make a change
and you say, I want to change 

582
00:25:46,700 --> 00:25:49,600
this one server to optimize it 
for the high levels of traffic. 

583
00:25:49,600 --> 00:25:52,500
It forces you to figure out how 
to do that within the code to 

584
00:25:52,500 --> 00:25:52,900
say. 
Okay. 

585
00:25:52,900 --> 00:25:55,300
Maybe I'm going to make two 
different classes of application

586
00:25:55,300 --> 00:25:56,900
server. 
Now one is for high-traffic and 

587
00:25:56,900 --> 00:25:58,500
one is for low traffic. 
Or maybe I make the 

588
00:25:58,500 --> 00:26:01,300
configuration change, even on 
the other servers and Going to 

589
00:26:01,300 --> 00:26:03,300
all the servers will now be 
tuned for high performance. 

590
00:26:03,300 --> 00:26:04,700
Even if they don't necessarily 
need it. 

591
00:26:04,800 --> 00:26:07,200
And so that way it's all kind of
built in and all consistent 

592
00:26:07,300 --> 00:26:10,000
because I think the reason that 
people end up going and make 

593
00:26:10,000 --> 00:26:13,700
configuration changes by hand is
because, as lack of confidence 

594
00:26:13,700 --> 00:26:15,900
that the tools are really going 
to work, and that things might 

595
00:26:15,900 --> 00:26:17,200
break. 
It's what I call the kind of 

596
00:26:17,208 --> 00:26:20,100
automation fear spiral where the
more you're afraid that your 

597
00:26:20,100 --> 00:26:21,400
tool is going to break 
something. 

598
00:26:21,400 --> 00:26:24,500
The more likely you are to do 
something by hand, which means 

599
00:26:24,500 --> 00:26:26,300
that it's more likely. 
The next time that the 

600
00:26:26,300 --> 00:26:28,700
automation will break it. 
And so it just kind of goes 

601
00:26:28,700 --> 00:26:31,000
downhill from there. 
And this is also a Well, 

602
00:26:31,000 --> 00:26:33,800
actually of get Ops as well, 
which is one of the kind of 

603
00:26:33,800 --> 00:26:36,200
schools of thought around 
infrastructure as code, tends to

604
00:26:36,200 --> 00:26:38,100
be applied, more in the 
kubernetes world. 

605
00:26:38,100 --> 00:26:41,100
But this is a key part of that 
people often talk about less 

606
00:26:41,100 --> 00:26:43,900
extra people talk about get up. 
So I'm using git, branch has to 

607
00:26:43,900 --> 00:26:46,200
manage the different versions of
my infrastructure code for my 

608
00:26:46,200 --> 00:26:48,300
different environments. 
And I think okay, I'm doing good

609
00:26:48,300 --> 00:26:51,100
offs, but actually important 
component of get Ops is that 

610
00:26:51,100 --> 00:26:54,000
continuous synchronization, the 
fact that there is a process 

611
00:26:54,000 --> 00:26:56,300
somewhere and whether it's a 
tool like we've Works tool 

612
00:26:56,500 --> 00:26:59,100
supports this with a of working,
there's something there that is 

613
00:26:59,100 --> 00:27:00,800
just kind of continuously 
checking. 

614
00:27:01,000 --> 00:27:03,900
The code against the reality and
making sure that they match up. 

615
00:27:03,900 --> 00:27:05,800
So, that's an important thing. 
I think to do. 

616
00:27:06,100 --> 00:27:09,100
Yeah, you mentioned something 
around automation fear. 

617
00:27:09,100 --> 00:27:12,100
I think obviously, for example, 
your case with a customer where 

618
00:27:12,100 --> 00:27:15,000
the terraform apply runs for 
like, two hours and SEO 

619
00:27:15,000 --> 00:27:16,700
infrastructure as code gets 
bigger and bigger. 

620
00:27:16,700 --> 00:27:19,300
Obviously, there's this tendency
of fear coming in. 

621
00:27:19,300 --> 00:27:20,900
For example, one line of code of
change. 

622
00:27:20,900 --> 00:27:23,200
Sometimes you don't know, 
actually, my affect other 

623
00:27:23,200 --> 00:27:24,900
things. 
It might destroy the existing 

624
00:27:24,900 --> 00:27:26,500
infrastructure and recreate that
somehow. 

625
00:27:26,500 --> 00:27:29,500
So obviously this is one thing 
that is not so easy, and not so 

626
00:27:29,500 --> 00:27:32,200
straightforward, especially for 
people People knew learning 

627
00:27:32,200 --> 00:27:34,400
about the tools. 
I myself have seen it several 

628
00:27:34,400 --> 00:27:37,200
times when I made some changes 
and oh, it's going to destroy 

629
00:27:37,200 --> 00:27:40,200
this and recreate this. 
So obviously there's a lack of 

630
00:27:40,200 --> 00:27:43,400
Confidence from my part as well,
when I do that. 

631
00:27:43,600 --> 00:27:45,500
So, how do you overcome that 
kind of challenge? 

632
00:27:45,500 --> 00:27:47,400
So there's a number of things 
you can do for that. 

633
00:27:47,400 --> 00:27:50,500
One is so as we talked about, in
that case of the to our 

634
00:27:50,500 --> 00:27:52,800
terraform project. 
It's breaking it down into 

635
00:27:52,800 --> 00:27:55,700
smaller pieces. 
And so that when you're running 

636
00:27:55,700 --> 00:27:58,700
your Terror from apply, it's 
only running against a smaller 

637
00:27:58,700 --> 00:28:01,200
subset of the whole. 
And so that gives you A bit of a

638
00:28:01,208 --> 00:28:03,100
conference, you still kind of 
scared because you still, you 

639
00:28:03,108 --> 00:28:05,000
know, you can break that thing 
and maybe you can have a ripple 

640
00:28:05,000 --> 00:28:06,500
on effects, but it's a little 
bit more. 

641
00:28:06,500 --> 00:28:09,500
Is that blast radius people talk
about the blast radius of a 

642
00:28:09,500 --> 00:28:12,400
change, but how much could you 
break with the particular change

643
00:28:12,400 --> 00:28:15,000
that you're making right now? 
So that's one thing is reducing,

644
00:28:15,000 --> 00:28:17,500
the blast radius by shrinking 
the kind of scope of the pieces 

645
00:28:17,500 --> 00:28:19,300
of your system. 
Now another thing is in the 

646
00:28:19,300 --> 00:28:21,300
reasons. 
I talk a lot about automated 

647
00:28:21,300 --> 00:28:24,400
tests and pipeline for 
infrastructure as code which is 

648
00:28:24,400 --> 00:28:27,500
not really a mainstream things. 
Not many teams are really doing 

649
00:28:27,500 --> 00:28:30,100
this and anger for a couple of 
reasons we can talk about but 

650
00:28:30,100 --> 00:28:33,000
the idea of Why to do it is one 
of these conversations. 

651
00:28:33,000 --> 00:28:35,400
I have with these teams were 
trying to kind of break apart. 

652
00:28:35,400 --> 00:28:37,700
Their infrastructure is pick a 
pipeline for each piece of your 

653
00:28:37,700 --> 00:28:39,600
infrastructure. 
And it does a couple of things. 

654
00:28:39,600 --> 00:28:42,100
One is obviously you can run 
some automated tests to your 

655
00:28:42,100 --> 00:28:43,900
terraform so that you have some 
confidence. 

656
00:28:43,900 --> 00:28:45,500
Okay, we spun up this part of 
it. 

657
00:28:45,500 --> 00:28:48,200
Subset of the system that the 
terraformed thing manages, and 

658
00:28:48,200 --> 00:28:50,600
we ran some automatic test 
against it and they passed. 

659
00:28:50,600 --> 00:28:53,300
So we have more confidence that 
we can now apply this to 

660
00:28:53,300 --> 00:28:55,000
production with less chance of 
it failing. 

661
00:28:55,300 --> 00:28:56,800
The other thing that it does by 
having this pipeline. 

662
00:28:56,800 --> 00:29:00,400
Is it kind of forces you to keep
that Loosely coupled thing going

663
00:29:00,400 --> 00:29:03,400
with your Imparts, so what will 
often happen if you don't have 

664
00:29:03,400 --> 00:29:06,000
the pipeline but you break your 
system into multiple Parts is 

665
00:29:06,000 --> 00:29:08,500
it's like okay, we're going to 
make a change to our application

666
00:29:08,500 --> 00:29:11,600
server terraform code. 
Well in order to test that we 

667
00:29:11,600 --> 00:29:14,800
might have to create our 
networking stack in our database

668
00:29:14,800 --> 00:29:16,200
stack and all these other kind 
of parts. 

669
00:29:16,200 --> 00:29:19,600
So again that to our Terror form
project, I mentioned in order to

670
00:29:19,600 --> 00:29:22,400
test one part of it, might still
have to run two hours worth of 

671
00:29:22,400 --> 00:29:24,100
terraform, even though it's all 
a whole bunch of different 

672
00:29:24,100 --> 00:29:26,100
little projects, rather than one
big project. 

673
00:29:26,100 --> 00:29:27,800
We still have to do all of that 
to have all of the 

674
00:29:27,800 --> 00:29:29,800
infrastructure. 
That's the prerequisite for that

675
00:29:29,800 --> 00:29:32,600
one piece that were Ali wirthlin
changing and so having a 

676
00:29:32,600 --> 00:29:35,700
pipeline kind of forces you to 
think about what we did in the 

677
00:29:35,700 --> 00:29:38,100
software world of saying, how do
you do a unit test? 

678
00:29:38,100 --> 00:29:41,700
We design the components of our 
software so that we can create 

679
00:29:41,700 --> 00:29:44,000
an instance of it by itself to 
do a unit test. 

680
00:29:44,000 --> 00:29:46,200
You shouldn't need to spin up a 
database and connect to a 

681
00:29:46,208 --> 00:29:47,500
database. 
That was one of the kind of 

682
00:29:47,500 --> 00:29:50,500
things that people struggled 
with unit tests of software was 

683
00:29:50,500 --> 00:29:53,300
all, we have too much other 
stuff that we have to create in 

684
00:29:53,300 --> 00:29:55,800
order to run this one unit test 
on one component. 

685
00:29:55,800 --> 00:29:58,400
And so the answer was well to 
force you to kind of do better 

686
00:29:58,400 --> 00:30:00,200
design and say, okay. 
How can we redesign? 

687
00:30:00,200 --> 00:30:03,300
How can we Factor this component
so that it does the same thing, 

688
00:30:03,300 --> 00:30:05,200
but it doesn't need all those 
dependencies. 

689
00:30:05,200 --> 00:30:07,900
We can, maybe do some dependency
injection or other techniques. 

690
00:30:08,100 --> 00:30:11,400
We can use mocks and fakes and 
things like that to test just 

691
00:30:11,400 --> 00:30:13,600
the piece that we're working on 
and isolation. 

692
00:30:13,600 --> 00:30:15,200
And so, this kind of stuff comes
together. 

693
00:30:15,200 --> 00:30:17,000
I'd like to break things into 
small pieces. 

694
00:30:17,000 --> 00:30:19,600
You need to design them to be 
Loosely coupled and then the 

695
00:30:19,600 --> 00:30:22,100
pipeline kind of forces you to 
prove that that design works by 

696
00:30:22,100 --> 00:30:24,100
make a change to my 
infrastructure code. 

697
00:30:24,200 --> 00:30:26,800
For my application server. 
I push that into the pipeline. 

698
00:30:26,800 --> 00:30:29,300
If I've made a dependency a 
hard-coded dependency on some 

699
00:30:29,300 --> 00:30:30,700
other component, it will fail in
the pipe. 

700
00:30:30,800 --> 00:30:33,200
Pipeline because the pythons is 
what I'm testing it by itself. 

701
00:30:33,300 --> 00:30:36,400
And so then you have to go back.
Okay, how can I redesign my 

702
00:30:36,400 --> 00:30:38,600
change so that it keeps it 
Loosely coupled. 

703
00:30:38,700 --> 00:30:41,900
So people talk about test-driven
development as not so much about

704
00:30:41,900 --> 00:30:45,200
the tests necessarily. 
As about design, forcing you to 

705
00:30:45,200 --> 00:30:47,700
have a better design and it's 
the same is true for 

706
00:30:47,700 --> 00:30:50,200
infrastructure as for software, 
right? 

707
00:30:50,200 --> 00:30:52,900
So before we go deep into the 
pipeline design and things like 

708
00:30:52,900 --> 00:30:55,100
that, that's one thing that I 
want to ask as well because you 

709
00:30:55,100 --> 00:30:58,500
just mention it refactoring. 
How do you actually refactor 

710
00:30:58,500 --> 00:31:00,700
infrastructure as code? 
Because sometimes it involves 

711
00:31:00,900 --> 00:31:04,800
State, what has been created and
how do you actually reflect 

712
00:31:04,800 --> 00:31:06,500
that? 
Yeah, it's really good question.

713
00:31:06,500 --> 00:31:09,500
And it's one of the things that 
adding into the second edition 

714
00:31:09,500 --> 00:31:12,700
of the book as a topic because 
it is one of these big things as

715
00:31:12,700 --> 00:31:15,500
we get as we mature and do more 
of the infrastructure code. 

716
00:31:15,500 --> 00:31:17,500
We're finding a lot more of 
these sort of the hard Parts. 

717
00:31:17,500 --> 00:31:20,100
This is one of the hard parts. 
So there's a couple of things 

718
00:31:20,100 --> 00:31:23,500
and I think again it comes from 
looking at the software world. 

719
00:31:23,500 --> 00:31:26,000
There's a few techniques of 
things like doing Bluegreen 

720
00:31:26,000 --> 00:31:29,000
deployments and so on and 
feature Flags to say that, like,

721
00:31:29,000 --> 00:31:31,500
I'm going to make a change. 
Every time I am For structure 

722
00:31:31,500 --> 00:31:33,500
and I can push it through into 
production. 

723
00:31:33,500 --> 00:31:35,000
But either it is necessarily 
lives. 

724
00:31:35,000 --> 00:31:38,300
Maybe I'm doing kind of a dark 
launch or Canary release or I'm 

725
00:31:38,300 --> 00:31:39,900
using a feature flag or 
whatever. 

726
00:31:39,900 --> 00:31:42,300
And then also maybe if I'm going
to change the infrastructure for

727
00:31:42,300 --> 00:31:45,600
my application server, maybe I'm
not going to just apply 

728
00:31:45,600 --> 00:31:47,300
terraform to that. 
Maybe I'm going to create a new 

729
00:31:47,300 --> 00:31:49,500
instance of that infrastructure 
and bring up a new application 

730
00:31:49,500 --> 00:31:51,800
server. 
And then to test that before I 

731
00:31:51,800 --> 00:31:53,100
flip it over. 
So that's like some of the 

732
00:31:53,100 --> 00:31:55,300
options you have. 
And then with State you 

733
00:31:55,300 --> 00:31:57,300
mentioned stay because it's like
a terraformed thing in 

734
00:31:57,300 --> 00:31:59,400
particular, especially when you 
refactoring and say, I'm going 

735
00:31:59,400 --> 00:32:02,300
to pull apart for example. 
Use as where you've got like a 

736
00:32:02,300 --> 00:32:04,600
tariff on networking project 
that down AWS. 

737
00:32:04,600 --> 00:32:07,700
It creates like a V PC and some 
subnets and so on and you've got

738
00:32:07,700 --> 00:32:10,000
other projects, which create 
application servers, which are 

739
00:32:10,000 --> 00:32:12,600
deployed into those subnets. 
And then you say, oh, actually 

740
00:32:12,700 --> 00:32:16,100
the way we created our subnets 
in the first place is not quite 

741
00:32:16,100 --> 00:32:18,000
right. 
We need to change the size of 

742
00:32:18,000 --> 00:32:19,900
them, or whatever. 
At that can really break things.

743
00:32:19,900 --> 00:32:21,200
Right? 
So, one of the things I've seen 

744
00:32:21,200 --> 00:32:25,000
people do is they basically use 
the expand and contract pattern 

745
00:32:25,000 --> 00:32:27,800
from database schema changes. 
So, this is something if you're 

746
00:32:27,800 --> 00:32:29,200
not familiar with it's worth 
looking at. 

747
00:32:29,200 --> 00:32:32,200
But it's like, where do you use?
Julia to like say fly away, or 

748
00:32:32,200 --> 00:32:36,100
DB deploy, where it uses scripts
to make changes to a database 

749
00:32:36,100 --> 00:32:38,300
table structure. 
And how do you do that in a way?

750
00:32:38,300 --> 00:32:40,300
That is safer. 
And so we can do the same thing 

751
00:32:40,300 --> 00:32:42,000
for infrastructure. 
So, the example for 

752
00:32:42,000 --> 00:32:44,700
infrastructure with that 
networking example, so let me 

753
00:32:44,700 --> 00:32:47,100
first say like what I think is 
probably not the right way to do

754
00:32:47,100 --> 00:32:48,900
it, but it's kind of common is 
to say, I'm going to edit the 

755
00:32:48,908 --> 00:32:50,700
state file. 
I'm going to kind of go and you 

756
00:32:50,708 --> 00:32:53,000
can use the telephone command or
maybe other tools. 

757
00:32:53,000 --> 00:32:55,400
Or maybe you can even use a text
editor because it's like a Json 

758
00:32:55,400 --> 00:32:57,100
file. 
You can go and edit that scares 

759
00:32:57,100 --> 00:32:58,100
me. 
I've been calling that 

760
00:32:58,100 --> 00:33:00,000
infrastructure surgery. 
It's like when you're doing 

761
00:33:00,000 --> 00:33:02,100
brain surgery. 
Something and you're at risk of 

762
00:33:02,100 --> 00:33:04,200
killing the patient. 
So it's very scary and 

763
00:33:04,200 --> 00:33:05,900
especially in an emergency 
situation. 

764
00:33:06,000 --> 00:33:08,600
So the expand contract patterns 
and say, actually, this is known

765
00:33:08,600 --> 00:33:10,800
as a series of commits. 
It's not a single change. 

766
00:33:10,800 --> 00:33:12,600
What we'll do is we'll say, 
well, first, we'll make a commit

767
00:33:12,600 --> 00:33:15,700
that adds new subnets that are 
in this structure that maybe we 

768
00:33:15,700 --> 00:33:18,200
needed a bigger address range in
there. 

769
00:33:18,200 --> 00:33:20,800
Maybe we can add new subnets or 
whatever to be adding the new 

770
00:33:20,800 --> 00:33:22,200
subnet. 
But we keep the existing subnets

771
00:33:22,200 --> 00:33:24,400
are still there and the servers 
are still in the existing 

772
00:33:24,400 --> 00:33:27,000
subnets. 
Then we can push through changes

773
00:33:27,300 --> 00:33:30,100
to the things, like those 
servers to change them into the 

774
00:33:30,100 --> 00:33:31,100
other. 
Yet. 

775
00:33:31,100 --> 00:33:34,300
And so, that's a more tractable 
change in some cases. 

776
00:33:34,300 --> 00:33:35,700
You might be able to do it, 
depending on what you're 

777
00:33:35,800 --> 00:33:38,400
actually changing without 
interrupting, any kind of 

778
00:33:38,400 --> 00:33:40,900
service or anything, and some 
cases, it might mean, okay, that

779
00:33:40,900 --> 00:33:43,300
server is going to get rebuilt. 
But you can manage it kind of 

780
00:33:43,300 --> 00:33:45,500
one-by-one rather than having to
do everything at once because I 

781
00:33:45,508 --> 00:33:48,100
first we'll change this one 
server Which is less scary. 

782
00:33:48,100 --> 00:33:50,100
Maybe it's not public. 
Facing will change that to make 

783
00:33:50,100 --> 00:33:50,300
sure. 
Okay. 

784
00:33:50,300 --> 00:33:51,900
Yeah, that work. 
Now we'll go on to the kind of 

785
00:33:51,908 --> 00:33:54,500
scarier ones one by one and you 
do each of those changes by 

786
00:33:54,500 --> 00:33:57,400
pushing again, pushing the 
infrastructure code change 

787
00:33:57,400 --> 00:33:59,000
through your pipeline with 
tests. 

788
00:33:59,000 --> 00:34:00,300
So that you're more comfortable.
Yes. 

789
00:34:00,300 --> 00:34:02,400
This is going You okay? 
And then after you've made all 

790
00:34:02,400 --> 00:34:05,100
those changes and everything is 
moved over into the new subnets,

791
00:34:05,100 --> 00:34:08,000
then you can push the change to 
delete the old subnets to clean 

792
00:34:08,000 --> 00:34:09,100
them out. 
That's the contract, you've 

793
00:34:09,100 --> 00:34:12,000
expanded it by creating new 
subnets, moved everything over 

794
00:34:12,000 --> 00:34:14,900
and then contracted by removing 
the old subnets. 

795
00:34:15,000 --> 00:34:17,800
So, that's a pattern of seen 
people using with infrastructure

796
00:34:17,800 --> 00:34:19,800
as code. 
That can work quite nicely 

797
00:34:20,100 --> 00:34:22,900
right, so that the common case 
of refactoring, which I find 

798
00:34:22,900 --> 00:34:24,000
sometimes it's difficult. 
Again. 

799
00:34:24,000 --> 00:34:26,500
This is based on Tara phone, 
when you create something and 

800
00:34:26,500 --> 00:34:29,100
then you realize, oh, we can 
create a module that can be 

801
00:34:29,100 --> 00:34:31,900
reusable, for other use case. 
And that's when you actually 

802
00:34:31,900 --> 00:34:35,300
create like this abstraction, or
we need to add the module name, 

803
00:34:35,400 --> 00:34:38,100
+. 
Something and that ends up in 

804
00:34:38,100 --> 00:34:40,100
changing the state. 
Using some commands. 

805
00:34:40,100 --> 00:34:43,800
Sometimes, it can be very scary.
Yeah, so that kind of situation.

806
00:34:43,800 --> 00:34:47,199
I still could not find a way of 
how to solve that. 

807
00:34:47,199 --> 00:34:48,699
You have some experience around 
that. 

808
00:34:48,800 --> 00:34:50,699
There's a few things here. 
And so I don't know if it's 

809
00:34:50,699 --> 00:34:52,300
related exactly to what you're 
talking to. 

810
00:34:52,300 --> 00:34:54,800
What are you talking about? 
Like we have terraform projects 

811
00:34:54,800 --> 00:34:56,500
that are getting their 
dependencies from other 

812
00:34:56,500 --> 00:34:58,800
terraform State files in another
project. 

813
00:34:58,800 --> 00:35:03,300
So let's say we have a terror 
Like pure just without module 

814
00:35:03,300 --> 00:35:06,100
and then we can see a pattern 
emerges like, oh, we can 

815
00:35:06,200 --> 00:35:08,800
actually create a module out of 
this few resources. 

816
00:35:08,900 --> 00:35:11,900
And then that's when we extract 
that out as a module. 

817
00:35:12,000 --> 00:35:14,600
But then when you have already 
applied that to an environment, 

818
00:35:14,600 --> 00:35:17,700
the state actually doesn't 
recognize the idea of module. 

819
00:35:17,700 --> 00:35:19,800
And then after that, when you 
make that change, when you 

820
00:35:19,800 --> 00:35:22,600
introduce that module, you kind 
of need to apply that to the 

821
00:35:22,600 --> 00:35:26,100
state introducing this naming of
the module as part of their 

822
00:35:26,100 --> 00:35:28,600
insults. 
I think that might be an example

823
00:35:28,600 --> 00:35:31,500
where you could use depending on
exactly the Specific situation. 

824
00:35:31,500 --> 00:35:33,600
You might be able to use to 
expand the contract for that, 

825
00:35:33,600 --> 00:35:36,900
where you introduce the module 
into your project and create the

826
00:35:36,900 --> 00:35:38,300
thing. 
But you don't necessarily right 

827
00:35:38,300 --> 00:35:40,600
away move, the old thing into 
the module. 

828
00:35:40,600 --> 00:35:44,500
And then then make a series of 
code changes that you apply one 

829
00:35:44,500 --> 00:35:47,500
by one that kind of move things 
over to using the module. 

830
00:35:47,600 --> 00:35:50,700
So possibly, that would help. 
I mean, it may also end up that 

831
00:35:50,700 --> 00:35:52,900
you need to do those State file 
changes. 

832
00:35:53,000 --> 00:35:55,700
It's one of those things that 
like I said is scary and we like

833
00:35:55,700 --> 00:35:58,500
to avoid if we at all can, but 
sometimes end up having to do 

834
00:35:58,500 --> 00:36:00,000
that. 
I think you can potentially 

835
00:36:00,000 --> 00:36:01,500
script though. 
Things. 

836
00:36:01,500 --> 00:36:04,500
So if you think about it again 
like database Delta's where you 

837
00:36:04,500 --> 00:36:07,000
say, okay, I'm going to have a 
script that makes that state 

838
00:36:07,000 --> 00:36:09,100
file edit, but it's going to be 
a script and I'm going to first 

839
00:36:09,100 --> 00:36:11,400
do it in a test environment and 
then I'm going to come on little

840
00:36:11,400 --> 00:36:13,900
test that says did it work and 
then push the change on the next

841
00:36:13,900 --> 00:36:15,400
environment. 
So it's a hands-off thing. 

842
00:36:15,400 --> 00:36:17,400
At least you're not doing the 
surgery by hand. 

843
00:36:17,500 --> 00:36:18,100
Right? 
Right. 

844
00:36:18,100 --> 00:36:20,900
So yeah, let's go into the 
design of this pipeline. 

845
00:36:20,900 --> 00:36:23,300
Obviously, we have application 
code and now we have 

846
00:36:23,300 --> 00:36:25,800
infrastructure code. 
How do we structure our 

847
00:36:25,800 --> 00:36:27,100
repository? 
That's the first thing. 

848
00:36:27,100 --> 00:36:29,500
Do you put them all together in 
one repository or do you 

849
00:36:29,500 --> 00:36:32,000
separate them? 
How Do you actually design the 

850
00:36:32,200 --> 00:36:35,100
CI CD pipeline? 
Are they separate pipeline that 

851
00:36:35,100 --> 00:36:37,500
will converge at some point in 
time, because there are 

852
00:36:37,500 --> 00:36:40,400
different versions of Interest 
code and there's a version of 

853
00:36:40,400 --> 00:36:43,400
application code as well. 
And then lastly about the 

854
00:36:43,400 --> 00:36:45,500
testing. 
So how do you apply the testing 

855
00:36:45,500 --> 00:36:47,900
in between like, you have a set 
of infrastructure as code? 

856
00:36:47,900 --> 00:36:51,400
You have a set of application 
code and they merge into one. 

857
00:36:51,400 --> 00:36:53,400
And then how do you apply the 
testing on that? 

858
00:36:53,600 --> 00:36:56,600
Okay, good questions. 
So, start with a code base 

859
00:36:56,600 --> 00:36:58,500
design. 
I think this is one of those 

860
00:36:58,500 --> 00:37:00,600
things where there are patterns 
not necessarily a right. 

861
00:37:00,700 --> 00:37:03,200
Wrong answer or best practice or
would have you. 

862
00:37:03,200 --> 00:37:07,100
So I tend to think in terms of 
there's the Conway's law thing 

863
00:37:07,100 --> 00:37:09,900
of your system design is going 
to reflect your team design or 

864
00:37:09,900 --> 00:37:13,500
they should align. 
And so I think I tend to kind of

865
00:37:13,500 --> 00:37:15,600
start from thinking about what 
are the applications and the 

866
00:37:15,607 --> 00:37:17,900
system structure, the 
infrastructure architecture that

867
00:37:17,900 --> 00:37:19,900
you want and your team 
structures. 

868
00:37:19,900 --> 00:37:21,400
You should kind of line those 
up. 

869
00:37:21,400 --> 00:37:24,700
And I think code based design 
will tend to come out of that. 

870
00:37:24,700 --> 00:37:27,800
So you don't really want to have
a code base where multiple 

871
00:37:27,800 --> 00:37:29,500
different teams are all making 
changes to it. 

872
00:37:29,500 --> 00:37:32,000
Unless you've got good kind. 
Of tooling around that to manage

873
00:37:32,000 --> 00:37:33,300
that. 
So you kind of have to think 

874
00:37:33,300 --> 00:37:34,600
about how you manage changes to 
that. 

875
00:37:34,600 --> 00:37:37,800
So a typical kind of thing to do
is to have separate code. 

876
00:37:37,800 --> 00:37:40,500
Repositories may be based on 
teams. 

877
00:37:40,500 --> 00:37:43,200
And then the question of should 
my infrastructure code, and my 

878
00:37:43,200 --> 00:37:44,900
application code being the same 
repository. 

879
00:37:44,900 --> 00:37:47,100
It's like, well, is the same 
team managing both of those, 

880
00:37:47,100 --> 00:37:49,400
which they might be, you might 
have OK an application. 

881
00:37:49,400 --> 00:37:52,000
Team owns its own infrastructure
or parts of the infrastructure 

882
00:37:52,000 --> 00:37:53,600
that are relevant to the 
application. 

883
00:37:53,800 --> 00:37:56,000
Think that's often a good way to
look at it and then maybe other 

884
00:37:56,000 --> 00:37:58,900
teams manage infrastructure. 
That's more shared mind so you 

885
00:37:58,900 --> 00:38:00,500
can organize your repositories 
that way. 

886
00:38:00,500 --> 00:38:04,100
So Pretty common pattern. 
There's a mono repo pattern, 

887
00:38:04,100 --> 00:38:06,800
which is where, like everything 
is in one big repository and 

888
00:38:06,800 --> 00:38:08,300
famously. 
Some of the companies like 

889
00:38:08,300 --> 00:38:11,200
Google and Facebook use this. 
And I was writing about this 

890
00:38:11,200 --> 00:38:13,200
actually in the second edition 
been trying to define the mono 

891
00:38:13,200 --> 00:38:14,500
repo. 
And one of the things that 

892
00:38:14,500 --> 00:38:16,900
occurred to me that I realized, 
as I was talking about this and 

893
00:38:16,900 --> 00:38:19,900
talking to some people about it,
was that mono repo isn't really 

894
00:38:19,900 --> 00:38:22,400
about is having all of your code
in one repository. 

895
00:38:22,400 --> 00:38:24,900
What it's really about is how 
you build your code. 

896
00:38:24,900 --> 00:38:28,100
So with Facebook and Google, 
they use tools which basically 

897
00:38:28,100 --> 00:38:30,600
just run your build and it runs 
the build across the entire. 

898
00:38:30,700 --> 00:38:32,400
Pause ettore all the projects 
that are in it and it's 

899
00:38:32,400 --> 00:38:34,500
obviously, they're very 
intelligent tools that work out.

900
00:38:34,500 --> 00:38:37,100
Okay, you only change the very 
small part of the code in the 

901
00:38:37,107 --> 00:38:39,400
repository not everything. 
So it doesn't rebuild everything

902
00:38:39,400 --> 00:38:42,200
from scratch every time and 
similarly, like it runs tests 

903
00:38:42,200 --> 00:38:44,600
then based on what's actually 
changed and that's the kind of 

904
00:38:44,600 --> 00:38:46,100
key thing. 
I've seen people put all of 

905
00:38:46,100 --> 00:38:48,100
their code into a single 
repository, but then each of the

906
00:38:48,100 --> 00:38:50,700
projects was still separate 
would still like compile and 

907
00:38:50,700 --> 00:38:53,800
build and as separate builds and
separate pipelines. 

908
00:38:53,800 --> 00:38:56,800
And so I don't think that's the 
true mono repo because I think 

909
00:38:56,800 --> 00:38:59,500
the mono repo thing is really 
it's a build strategy rather 

910
00:38:59,500 --> 00:39:01,600
than a code organization. 
Valerie necessarily. 

911
00:39:01,800 --> 00:39:04,500
So then I think you're asking 
about pipelines and how kind of 

912
00:39:04,508 --> 00:39:08,000
pipelines map on from that, but 
I think it's really about the 

913
00:39:08,000 --> 00:39:11,000
different pieces that you have 
and then how they come together.

914
00:39:11,000 --> 00:39:13,700
So I see a pipeline as there's a
couple of things. 

915
00:39:13,700 --> 00:39:16,500
When you go from left to right, 
the start, and then going to the

916
00:39:16,500 --> 00:39:18,300
right of later stages in the 
pipeline. 

917
00:39:18,400 --> 00:39:20,000
There's a couple of different 
things that are happening. 

918
00:39:20,100 --> 00:39:22,800
So the classic thing is that 
like the early stages are the 

919
00:39:22,800 --> 00:39:26,100
things that run fast, fast, 
test, like unit tests and so on,

920
00:39:26,200 --> 00:39:29,500
and I think that's true. 
And then the slower tests and 

921
00:39:29,500 --> 00:39:32,300
the broader scope. 
Tests like Journey tests that go

922
00:39:32,300 --> 00:39:35,500
across the user interface of a 
fully integrated application 

923
00:39:35,500 --> 00:39:37,200
tend to run later in the 
pipeline. 

924
00:39:37,300 --> 00:39:39,200
And then I think another 
dimension of that is it's the 

925
00:39:39,207 --> 00:39:41,900
components. 
So I think what you tend to want

926
00:39:41,900 --> 00:39:45,600
to do is you're trying to break 
your system apart into small 

927
00:39:45,600 --> 00:39:48,100
pieces and to be able to test 
each of those pieces 

928
00:39:48,100 --> 00:39:51,600
individually. 
And so, early pipeline stages, 

929
00:39:51,900 --> 00:39:55,000
will tend to be a first build, a
component on its own and test it

930
00:39:55,000 --> 00:39:58,700
and make sure it's good and then
promoted along and then later 

931
00:39:58,700 --> 00:40:01,300
pipeline stages, my aggregate 
some of those Components 

932
00:40:01,300 --> 00:40:02,900
together, and the components can
be various things. 

933
00:40:02,900 --> 00:40:05,000
They can be like application, 
code, libraries Java. 

934
00:40:05,000 --> 00:40:05,800
Libraries. 
For instance. 

935
00:40:05,800 --> 00:40:08,300
I'm going to test my Java 
Library, first with unit tests 

936
00:40:08,300 --> 00:40:10,000
and so on. 
And then I'm going to test an 

937
00:40:10,000 --> 00:40:12,700
application that builds a war 
file by pulling different 

938
00:40:12,700 --> 00:40:14,800
Library files jar files 
together. 

939
00:40:14,900 --> 00:40:16,000
Then similar with 
infrastructure. 

940
00:40:16,000 --> 00:40:19,300
You might have I've got some 
code which is going to install 

941
00:40:19,300 --> 00:40:22,600
Java and Tomcat onto a server. 
It's ansible Playbook. 

942
00:40:22,600 --> 00:40:24,700
And so you probably want to have
like a pipeline stage was just 

943
00:40:24,700 --> 00:40:27,600
test that Playbook on its own. 
And it can do that very quickly 

944
00:40:27,600 --> 00:40:29,700
because it doesn't need to 
necessarily create a server in 

945
00:40:29,700 --> 00:40:32,200
the cloud. 
It can unlike a Docker instance 

946
00:40:32,200 --> 00:40:36,100
or something like that where it 
just says simple Linux image run

947
00:40:36,100 --> 00:40:38,800
the Playbook and then test did 
it install Java and Tomcat 

948
00:40:38,800 --> 00:40:41,300
correctly to do what I want 
there before you then progress 

949
00:40:41,300 --> 00:40:44,300
that on and say okay now I've 
got something which is like an 

950
00:40:44,300 --> 00:40:47,200
answerable role of an 
application server and that 

951
00:40:47,200 --> 00:40:50,700
takes in not just the Java and 
the Tomcat but it also puts on 

952
00:40:50,700 --> 00:40:53,500
the monitoring agent and sets up
user accounts and whatever else 

953
00:40:53,500 --> 00:40:55,000
we want for an application 
server. 

954
00:40:55,100 --> 00:40:57,200
And so it says, okay, now I'm 
going to test those all those 

955
00:40:57,200 --> 00:40:59,800
playbooks together and see does 
that create a server, the way I 

956
00:40:59,808 --> 00:41:01,700
would want and Test at that 
level. 

957
00:41:02,100 --> 00:41:04,200
And then you might have the code
whether its tariff or more 

958
00:41:04,200 --> 00:41:05,400
handsome or whatever, which 
says. 

959
00:41:05,400 --> 00:41:06,900
Now I'm going to create the 
infrastructure for my 

960
00:41:06,900 --> 00:41:09,000
application server. 
It's going to create obvious 

961
00:41:09,000 --> 00:41:11,600
going to provision a virtual 
machine or an auto scaling 

962
00:41:11,600 --> 00:41:15,300
group, the load balancer, some 
networking, roots and security 

963
00:41:15,300 --> 00:41:17,500
groups that open porch to it and
all the kind of things around 

964
00:41:17,500 --> 00:41:19,500
the application server. 
So I'll provision that on the 

965
00:41:19,500 --> 00:41:20,500
cloud. 
And then, I'll bring the other 

966
00:41:20,500 --> 00:41:22,000
things in and test those 
together. 

967
00:41:22,000 --> 00:41:23,900
So, you can see the each of 
these kind of like aggregating 

968
00:41:23,900 --> 00:41:27,300
piece by piece putting the 
pieces together step by step and

969
00:41:27,300 --> 00:41:29,200
then testing that they work 
together. 

970
00:41:29,200 --> 00:41:31,500
Integration testing and I kind 
of Incremental way. 

971
00:41:31,600 --> 00:41:33,800
So that's the kind of classic 
thing to do that kind of fan in 

972
00:41:33,800 --> 00:41:35,400
and say, we're going to bring 
all these kind of pieces 

973
00:41:35,400 --> 00:41:37,700
together, and then, once we've 
tested them all together, we 

974
00:41:37,700 --> 00:41:39,500
might progress them to a later 
stage. 

975
00:41:39,500 --> 00:41:40,900
Maybe after doing the automated 
tests. 

976
00:41:40,900 --> 00:41:44,500
We make it available to human 
Q&A to do exploratory testing or

977
00:41:44,508 --> 00:41:47,000
what have you or you 80. 
So users are going to look at 

978
00:41:47,000 --> 00:41:48,200
it. 
And then we approve it to go on 

979
00:41:48,200 --> 00:41:50,400
into production. 
That doesn't necessarily scale 

980
00:41:50,400 --> 00:41:53,300
very well at very large scale. 
So if you've got like a dozens 

981
00:41:53,300 --> 00:41:56,300
of teams much less hundreds of 
teams all building stuff having 

982
00:41:56,300 --> 00:41:58,900
all their work trying to come 
together and run a massive 

983
00:41:58,900 --> 00:42:00,500
integration tests across 
everything. 

984
00:42:00,600 --> 00:42:02,900
Becomes unwieldy and 
intractable. 

985
00:42:02,900 --> 00:42:05,300
So what you can do there 
instead? 

986
00:42:05,300 --> 00:42:08,300
And this is kind of draws from 
the microservices way of 

987
00:42:08,300 --> 00:42:11,300
thinking, is this, actually, we 
can push different parts of our 

988
00:42:11,300 --> 00:42:14,200
system straight into production.
We might do some contract 

989
00:42:14,200 --> 00:42:16,900
testing or we might test against
instances of other parts of the 

990
00:42:16,900 --> 00:42:19,400
system to make sure it's okay, 
but we're not going to try to 

991
00:42:19,400 --> 00:42:22,300
couple the releases. 
So as an example, let's say you 

992
00:42:22,300 --> 00:42:24,700
have a team working on shared 
networking infrastructure, those

993
00:42:24,700 --> 00:42:27,000
V PCS and subnets and so on. 
And that's a terraforming 

994
00:42:27,000 --> 00:42:29,300
project and you've got another 
team which is building an 

995
00:42:29,300 --> 00:42:31,600
application servers and The 
infrastructure for the 

996
00:42:31,600 --> 00:42:34,300
applications, you might say that
the networking team can go ahead

997
00:42:34,300 --> 00:42:36,700
and push changes to the 
terraform code for the 

998
00:42:36,700 --> 00:42:39,600
networking through the pipeline 
into production on their own. 

999
00:42:39,600 --> 00:42:41,500
And they don't have to make sure
that they can run a 

1000
00:42:41,508 --> 00:42:44,200
comprehensive test across 
everything in the organization 

1001
00:42:44,400 --> 00:42:46,900
and then simply the application 
server team can push their 

1002
00:42:46,900 --> 00:42:48,700
applications through with and 
change it to their 

1003
00:42:48,700 --> 00:42:51,400
infrastructure, but it's 
decoupled and that just means 

1004
00:42:51,400 --> 00:42:53,600
you need to do a little bit more
thinking about the contracts 

1005
00:42:53,600 --> 00:42:55,900
between those different pieces. 
And how to test that. 

1006
00:42:55,900 --> 00:42:57,300
They're, you're not breaking 
anything. 

1007
00:42:57,300 --> 00:42:59,500
I'm not making a change to my 
networking that's going to break

1008
00:42:59,500 --> 00:43:01,900
other people, but you Do that? 
And I think again, this comes 

1009
00:43:01,900 --> 00:43:03,900
down to the good design thing it
forces you to kind of think 

1010
00:43:03,900 --> 00:43:04,300
about. 
Okay. 

1011
00:43:04,300 --> 00:43:07,200
So what are people depending on 
in my networking infrastructure 

1012
00:43:07,200 --> 00:43:09,800
rather than people just kind of 
hard coding dependencies to 

1013
00:43:09,800 --> 00:43:11,000
wherever they want. 
It's like, no. 

1014
00:43:11,000 --> 00:43:13,200
No, I'm going to say I'm going 
to publish the subnets. 

1015
00:43:13,200 --> 00:43:15,000
Maybe to a registry or 
somewhere. 

1016
00:43:15,000 --> 00:43:17,300
These are the subnets that I 
create and you make sure that 

1017
00:43:17,300 --> 00:43:19,800
you use those and then I can 
change anything else as long as 

1018
00:43:19,800 --> 00:43:22,200
I keep those subnet ID is 
consistent, right? 

1019
00:43:22,200 --> 00:43:25,700
But when you say breaking out 
these component or different 

1020
00:43:25,700 --> 00:43:28,100
parts of the whole giant system,
you mentioned something in the 

1021
00:43:28,107 --> 00:43:31,200
book called stack is this 
referring to That kind of 

1022
00:43:31,200 --> 00:43:32,200
pattern. 
Yeah. 

1023
00:43:32,200 --> 00:43:34,900
So the stack this is a turn that
I've used because the tool 

1024
00:43:34,900 --> 00:43:37,400
vendors don't tend to have a 
consistent terms of the cloud 

1025
00:43:37,400 --> 00:43:39,400
formation and AWS. 
They talk about a stack and 

1026
00:43:39,400 --> 00:43:44,000
plumy also used the same term 
terraform has a project and I'm 

1027
00:43:44,000 --> 00:43:46,200
not sure the answer was 
necessarily has a term to refer 

1028
00:43:46,200 --> 00:43:49,500
to it, but it's basically it's 
like the unit of stuff on say a 

1029
00:43:49,500 --> 00:43:52,600
cloud or virtualization platform
like the unit of change. 

1030
00:43:52,700 --> 00:43:55,300
So it's like you've got blob of 
code that you can change when 

1031
00:43:55,300 --> 00:43:57,600
you apply it, as kind of the 
scope of what might change 

1032
00:43:57,600 --> 00:44:00,200
within that piece of code. 
So, terraformers a project and 

1033
00:44:00,200 --> 00:44:02,100
there's In the state file 
associated with it. 

1034
00:44:02,100 --> 00:44:03,600
And like I said with 
cloudformation, it's a bit more 

1035
00:44:03,600 --> 00:44:06,300
concrete because they actually 
used that term stack as well. 

1036
00:44:06,400 --> 00:44:08,400
So that a big part of especially
in the second edition. 

1037
00:44:08,400 --> 00:44:11,900
I think I've expanded a lot more
on this and how to do things 

1038
00:44:11,900 --> 00:44:15,500
like integrate between Stacks 
nicely and patterns for 

1039
00:44:15,508 --> 00:44:18,200
Designing stack so that they're 
kind of loosely coupled and 

1040
00:44:18,200 --> 00:44:20,000
everything. 
And we're two breaks tax apart. 

1041
00:44:20,100 --> 00:44:21,800
Because as that becomes a bigger
than, when I wrote the first 

1042
00:44:21,800 --> 00:44:24,300
edition of the book, most people
were still focus on servers. 

1043
00:44:24,300 --> 00:44:26,600
And now, this level of stuff has
become what we tend to work with

1044
00:44:26,600 --> 00:44:28,900
a lot, if you're not working 
with kind of kubernetes and the 

1045
00:44:28,900 --> 00:44:32,100
layer above that, even, right. 
We covered a lot of things about

1046
00:44:32,100 --> 00:44:34,200
testing. 
So what are some of the tools 

1047
00:44:34,200 --> 00:44:37,100
normally people use to do this 
infrastructure test? 

1048
00:44:37,100 --> 00:44:39,500
I don't even know whether you 
can do unit tests. 

1049
00:44:39,500 --> 00:44:41,600
Like, how do you unit test? 
Terraform? 

1050
00:44:42,200 --> 00:44:43,200
It's a hard one. 
Right? 

1051
00:44:43,200 --> 00:44:46,000
And this is, I think something 
we're still in a lot of churn in

1052
00:44:46,000 --> 00:44:49,600
the industry about what type of 
tests are appropriate and useful

1053
00:44:49,600 --> 00:44:52,600
and valuable and therefore what 
tools to use for them. 

1054
00:44:52,600 --> 00:44:55,300
So that our unit tests useful. 
Well, one of the things I'm 

1055
00:44:55,300 --> 00:44:58,400
realizing with looking at the 
newer tools, like, plumy and 

1056
00:44:58,400 --> 00:45:00,400
cdk, which are using regular 
language. 

1057
00:45:00,600 --> 00:45:02,700
Is that there's a kind of a 
couple of different types of 

1058
00:45:02,700 --> 00:45:04,300
projects really that you can 
think about. 

1059
00:45:04,300 --> 00:45:07,200
So the typical again, the stack 
where you're defining 

1060
00:45:07,200 --> 00:45:09,600
infrastructure and you're using 
a language. 

1061
00:45:09,600 --> 00:45:12,000
If using something like 
terraform your tend to be 

1062
00:45:12,000 --> 00:45:15,000
defining, the elements of the 
infrastructure at a pretty 

1063
00:45:15,000 --> 00:45:16,700
granular level. 
You're saying, I want a virtual 

1064
00:45:16,700 --> 00:45:18,600
machine. 
Here's my subnets. 

1065
00:45:18,600 --> 00:45:20,900
Here's my roots. 
Gateways. 

1066
00:45:20,900 --> 00:45:23,200
All the individual pieces are 
all right there and you have the

1067
00:45:23,207 --> 00:45:26,200
code directly reflects those. 
And again, it goes back to that 

1068
00:45:26,200 --> 00:45:28,200
thing of its declarative code. 
It tends to declare. 

1069
00:45:28,200 --> 00:45:29,900
I want these pieces to be in 
place. 

1070
00:45:30,100 --> 00:45:33,900
And so Declarative code tends to
have a little bit less value or 

1071
00:45:33,900 --> 00:45:37,100
for testing in that. 
If you're saying if your code 

1072
00:45:37,100 --> 00:45:39,600
says make a subnet and give it 
this IP address range. 

1073
00:45:39,600 --> 00:45:41,400
What is your test going to say? 
It's going to say, is there a 

1074
00:45:41,400 --> 00:45:42,700
subnet? 
It doesn't have that IP address 

1075
00:45:42,700 --> 00:45:45,200
range and it's like well, with 
test, you have to be very 

1076
00:45:45,200 --> 00:45:47,600
pragmatic and think about like 
what's the value of this test? 

1077
00:45:47,600 --> 00:45:49,800
What's the risk? 
I'm trying to address here. 

1078
00:45:50,200 --> 00:45:52,700
So when is that test of that? 
Subnet going to fail? 

1079
00:45:52,800 --> 00:45:55,700
Well, you could have a syntax 
error, which you can catch 

1080
00:45:55,700 --> 00:45:57,400
beforehand. 
A lot of the errors that you 

1081
00:45:57,400 --> 00:45:59,500
would catch are actually going 
to fail when you apply the tool 

1082
00:45:59,500 --> 00:46:01,800
when you run Ply. 
It's going to tell you. 

1083
00:46:01,800 --> 00:46:04,300
Oh, you can't create that subnet
because the address range is not

1084
00:46:04,300 --> 00:46:06,700
a valid address range. 
So you never gonna run the test.

1085
00:46:07,100 --> 00:46:09,900
So I think that the declarative 
code level, there's not so much 

1086
00:46:09,900 --> 00:46:12,500
value in test particular that 
unit test level. 

1087
00:46:12,700 --> 00:46:15,700
It's more when you Aggregate and
you say, okay, I've declared by 

1088
00:46:15,700 --> 00:46:18,100
subnet and I've declared 
gateways and roots and other 

1089
00:46:18,100 --> 00:46:20,700
things now, it's like well can I
actually make a connection 

1090
00:46:20,700 --> 00:46:22,800
through all that stuff and get 
to where I need to get to you if

1091
00:46:22,800 --> 00:46:24,700
that's where you want to test 
because that tends to be what 

1092
00:46:24,700 --> 00:46:27,000
goes wrong when you apply your 
tariff own code and you point 

1093
00:46:27,000 --> 00:46:29,800
your web browser at it and it's 
like connection refused normal. 

1094
00:46:29,800 --> 00:46:30,400
Where was it? 
Free? 

1095
00:46:30,500 --> 00:46:32,700
Fused was it my subnet? 
Was it, my security group? 

1096
00:46:32,700 --> 00:46:34,800
So that's where you want to have
the tests I think is when you 

1097
00:46:34,800 --> 00:46:36,200
kind of aggregate those things 
together. 

1098
00:46:36,200 --> 00:46:37,400
So that's for the declarative 
code. 

1099
00:46:37,500 --> 00:46:39,900
And then I think the interesting
thing, when you look at using a 

1100
00:46:39,900 --> 00:46:42,900
tool like blue me or the cdk. 
You're probably not using it for

1101
00:46:42,900 --> 00:46:44,500
the same thing. 
And this was kind of a 

1102
00:46:44,500 --> 00:46:46,900
realization. 
I had where my first assumption 

1103
00:46:46,900 --> 00:46:48,800
when I saw these tools coming 
out was like, oh you're just 

1104
00:46:48,800 --> 00:46:51,100
going to click the same kind of 
project to make for terraform, 

1105
00:46:51,100 --> 00:46:53,400
but it's going to be different 
language to declared all those 

1106
00:46:53,400 --> 00:46:56,100
subnets and things and so on. 
But I think actually those tools

1107
00:46:56,100 --> 00:46:59,000
are probably more appropriate 
for the ReUse and you mentioned 

1108
00:46:59,000 --> 00:47:01,500
the example, the terraform Are 
you make modules? 

1109
00:47:01,500 --> 00:47:03,600
Because you identify, there's 
more reusable code? 

1110
00:47:03,600 --> 00:47:06,000
I think often that's the 
situation where you find what 

1111
00:47:06,000 --> 00:47:07,900
the code in. 
Those modules is the code that 

1112
00:47:07,900 --> 00:47:09,700
you want to say. 
I want to actually pass in some 

1113
00:47:09,700 --> 00:47:11,600
parameters and maybe do 
different things. 

1114
00:47:11,600 --> 00:47:14,600
Maybe I want to make a different
number of subnets, depending on 

1115
00:47:14,600 --> 00:47:17,100
their AWS region. 
How many subnets are available 

1116
00:47:17,100 --> 00:47:18,600
there? 
You want to do more Dynamic 

1117
00:47:18,600 --> 00:47:21,300
things, or I want to assign 
security groups and this and 

1118
00:47:21,300 --> 00:47:22,600
that based on what you've 
created. 

1119
00:47:22,600 --> 00:47:25,000
So that's where I think logic 
comes in and I think that's 

1120
00:47:25,000 --> 00:47:28,500
where you see the kind of really
terrible terraform code of 

1121
00:47:28,500 --> 00:47:30,300
putting in loops and 
conditionals and stuff. 

1122
00:47:30,500 --> 00:47:33,100
Into your HCL, which is 
essentially a declarative 

1123
00:47:33,100 --> 00:47:36,100
language and trying to make it 
procedural. 

1124
00:47:36,200 --> 00:47:38,400
It's because we're trying to 
actually do a different type of 

1125
00:47:38,400 --> 00:47:39,700
thing. 
And so this is where I want you 

1126
00:47:39,700 --> 00:47:41,400
to elect blue me to make a 
library. 

1127
00:47:41,800 --> 00:47:44,600
That's where I think testing 
becomes more powerful, more 

1128
00:47:44,600 --> 00:47:46,900
useful because it's like, okay, 
I'm making a library and it's 

1129
00:47:46,900 --> 00:47:49,400
going to create subnets for me. 
It's going to create subnets 

1130
00:47:49,400 --> 00:47:52,900
depending on what? 
Parameters, I passed in again. 

1131
00:47:52,900 --> 00:47:56,100
The number of availability zones
that are in a region or maybe 

1132
00:47:56,100 --> 00:47:58,200
the use cases, is it a public 
facing thing? 

1133
00:47:58,200 --> 00:48:01,300
Is that internally facing thing 
is These kind of things where 

1134
00:48:01,300 --> 00:48:02,900
you might want to have some 
variations. 

1135
00:48:02,900 --> 00:48:05,400
So you have this code, which can
do different things. 

1136
00:48:05,400 --> 00:48:07,300
And so that's where you want, 
some unit tests and say, okay, 

1137
00:48:07,400 --> 00:48:11,000
Make an instance of my little 
Palou me library, for subnets, 

1138
00:48:11,100 --> 00:48:13,600
and pass in different parameters
and then see, does it do the 

1139
00:48:13,600 --> 00:48:15,100
things? 
That's also, the kind of thing 

1140
00:48:15,100 --> 00:48:18,500
that you can probably do more 
with kind of mocks and the kind 

1141
00:48:18,500 --> 00:48:21,200
of offline kind of things to 
where it really is. 

1142
00:48:21,200 --> 00:48:23,100
Proper unit test that will run 
quickly. 

1143
00:48:23,100 --> 00:48:25,600
So I think that's kind of where 
my thinking is coming to of 

1144
00:48:25,600 --> 00:48:27,300
where these different things 
come into play and where the 

1145
00:48:27,300 --> 00:48:30,000
testing becomes more important, 
right? 

1146
00:48:30,100 --> 00:48:34,000
If mention a lot of times about 
plumy and cdk like many times 

1147
00:48:34,000 --> 00:48:36,800
now are they like the 
up-and-coming tools that we have

1148
00:48:36,800 --> 00:48:38,800
to explore? 
I think so. 

1149
00:48:38,800 --> 00:48:43,000
Yeah, what are some of the good 
things from those tools again, 

1150
00:48:43,000 --> 00:48:45,700
to kind of recap a little bit 
about what they do is basically 

1151
00:48:45,700 --> 00:48:47,900
they let you use a regular 
programming language and 

1152
00:48:47,900 --> 00:48:50,500
off-the-shelf programming 
language and they tend to 

1153
00:48:50,500 --> 00:48:54,500
support a JavaScript and 
typescript by popular python for

1154
00:48:54,500 --> 00:48:55,900
some, I think maybe Java for 
cdk. 

1155
00:48:55,900 --> 00:48:58,100
I'm not sure this is different 
languages that they look kind of

1156
00:48:58,100 --> 00:49:00,900
support. 
And so I think the value is When

1157
00:49:00,900 --> 00:49:05,300
you're writing reusable code 
basically it's where you're not 

1158
00:49:05,300 --> 00:49:07,000
saying. 
I'm writing the code, for this 

1159
00:49:07,000 --> 00:49:08,900
one environment. 
And I know what that environment

1160
00:49:08,900 --> 00:49:10,600
you look like, but it's like I'm
writing code that different 

1161
00:49:10,600 --> 00:49:13,000
people might use or that I might
reuse across different 

1162
00:49:13,000 --> 00:49:15,200
environments which are different
and so it needs to have a bit 

1163
00:49:15,200 --> 00:49:17,800
more logic going on. 
So I think that's a valuable 

1164
00:49:17,800 --> 00:49:19,400
thing about it, the other 
valuable thing. 

1165
00:49:19,400 --> 00:49:21,500
So we talked about you asked me 
like what tools there are four 

1166
00:49:21,500 --> 00:49:22,700
tests. 
I don't think I specifically 

1167
00:49:22,700 --> 00:49:25,300
like list any tools other than 
to say that there's not as many 

1168
00:49:25,300 --> 00:49:27,100
out there. 
There are tools out there, but 

1169
00:49:27,100 --> 00:49:29,600
it's not as mature, which is one
of the reasons why people don't 

1170
00:49:29,600 --> 00:49:31,700
do a lot of Any of 
infrastructure, I think. 

1171
00:49:31,700 --> 00:49:33,600
But the thing, when you're using
one of these other tools, like a

1172
00:49:33,607 --> 00:49:36,000
plumeria cdk, and it's like, oh,
what testing? 

1173
00:49:36,000 --> 00:49:37,600
Tools are available to write 
unit tests. 

1174
00:49:37,600 --> 00:49:39,400
Will all the tools that you have
for your language. 

1175
00:49:39,400 --> 00:49:41,700
If you're running JavaScript, 
there's loads of tools, right 

1176
00:49:41,700 --> 00:49:44,300
and then simply for packaging up
your code and versioning it, and

1177
00:49:44,300 --> 00:49:46,100
promoting it and like an 
artifact repository. 

1178
00:49:46,100 --> 00:49:48,600
It's like suddenly you have 
access to that full ecosystem 

1179
00:49:48,600 --> 00:49:51,800
and the things you can do in an 
IDE with the JavaScript code to 

1180
00:49:51,800 --> 00:49:54,100
kind of navigate and refactor 
your code and all of that is 

1181
00:49:54,100 --> 00:49:57,300
just Way Beyond what you can do 
with more infrastructure Focus 

1182
00:49:57,300 --> 00:50:00,000
language like HCL, which 
although there's support out 

1183
00:50:00,000 --> 00:50:01,800
there. 
HCL and similar languages, it's 

1184
00:50:01,800 --> 00:50:05,300
not nearly as wide as it is with
the general purpose languages. 

1185
00:50:05,300 --> 00:50:07,300
I think that's a powerful thing.
That's useful thing. 

1186
00:50:07,600 --> 00:50:09,700
Right? 
Obviously in your career. 

1187
00:50:09,700 --> 00:50:12,200
You have dealt a lot with 
infrastructure as code. 

1188
00:50:12,400 --> 00:50:14,900
Can you probably share it as 
what are some of the most 

1189
00:50:14,900 --> 00:50:18,700
horrendous and D patterns or 
code smells in infrastructure as

1190
00:50:18,700 --> 00:50:19,800
code? 
Yes. 

1191
00:50:19,800 --> 00:50:21,900
I think the other big projects 
is one thing. 

1192
00:50:21,900 --> 00:50:23,800
This is massive project which 
has kind of grown and grown and 

1193
00:50:23,800 --> 00:50:25,800
grown over time. 
So I think one of the other 

1194
00:50:25,800 --> 00:50:29,600
things that we see with tariff 
on projects and similar projects

1195
00:50:29,600 --> 00:50:33,300
is with Well environments. 
So it's like how do you define 

1196
00:50:33,300 --> 00:50:35,700
but Dev environment test 
environment, staging 

1197
00:50:35,700 --> 00:50:38,100
environment, production, 
environment with terraform? 

1198
00:50:38,100 --> 00:50:40,500
And I think one thing that you 
see people do at the beginning 

1199
00:50:40,500 --> 00:50:42,300
common thing to do when you're 
first starting out is I can't 

1200
00:50:42,300 --> 00:50:45,100
one project that has all the 
environments in that one project

1201
00:50:45,100 --> 00:50:46,800
and then you break the project 
and it breaks all your 

1202
00:50:46,800 --> 00:50:48,900
environments or you're making a 
change your test environment you

1203
00:50:48,908 --> 00:50:50,500
Britt production and then you 
realize that that's not a good 

1204
00:50:50,500 --> 00:50:52,000
thing to do. 
Let's separate them out. 

1205
00:50:52,000 --> 00:50:54,600
Then the next thing that people 
do, which I still think is not 

1206
00:50:54,700 --> 00:50:57,200
quite right and I described it 
as an anti-pattern is really 

1207
00:50:57,200 --> 00:50:59,200
have a separate project. 
It's like a separate Tara from 

1208
00:50:59,200 --> 00:51:01,400
project for each environment. 
Even though it's meant to be the

1209
00:51:01,400 --> 00:51:03,900
same environment. 
There are the same system that 

1210
00:51:03,900 --> 00:51:06,200
you're kind of replicating. 
So it's like I'm going to make 

1211
00:51:06,200 --> 00:51:08,800
an infrastructure change my test
environment, I make it there and

1212
00:51:08,808 --> 00:51:11,800
I apply it and then I copy the 
code change over to my staging 

1213
00:51:11,800 --> 00:51:13,900
environment and over to my 
production environment. 

1214
00:51:13,900 --> 00:51:16,600
This is like copy and pasting is
never really a good thing to do 

1215
00:51:16,600 --> 00:51:18,200
with code. 
Is the whole idea of code is 

1216
00:51:18,200 --> 00:51:20,200
that it's reusable and 
consistent so on and so on. 

1217
00:51:20,300 --> 00:51:24,100
So I much prefer having a single
piece of infrastructure code 

1218
00:51:24,100 --> 00:51:27,500
that defines your environment 
that you apply in one test it 

1219
00:51:27,500 --> 00:51:29,800
and then push the same code to 
the next environment. 

1220
00:51:29,800 --> 00:51:31,000
Which requires To do some 
things. 

1221
00:51:31,000 --> 00:51:33,100
You have to think about. 
How do you configure parameters?

1222
00:51:33,100 --> 00:51:34,500
Because in different 
environments, you might need 

1223
00:51:34,500 --> 00:51:35,900
like different numbers of 
servers. 

1224
00:51:35,900 --> 00:51:38,100
If your load balance pool, for 
instance, but they are, there 

1225
00:51:38,100 --> 00:51:40,300
are ways to do that. 
And I think it's important to do

1226
00:51:40,300 --> 00:51:42,400
that right throughout this 
conversation. 

1227
00:51:42,400 --> 00:51:44,800
You have mentioned a lot about 
second edition of your book. 

1228
00:51:44,900 --> 00:51:49,300
I personally didn't know about 
that and I research about you 

1229
00:51:49,400 --> 00:51:52,500
before this podcast. 
So can you tell us what makes 

1230
00:51:52,500 --> 00:51:55,600
you write the second edition? 
And what are the major changes 

1231
00:51:55,600 --> 00:51:57,200
that we should be looking 
forward to? 

1232
00:51:57,300 --> 00:51:59,100
Yeah, so things have moved on a 
bit. 

1233
00:51:59,100 --> 00:52:02,100
It's been about 45 years. 
Now, I think and it's 

1234
00:52:02,100 --> 00:52:04,400
interesting. 
So the focus has changed the 

1235
00:52:04,400 --> 00:52:07,100
subtitle of the first edition of
the book was something like 

1236
00:52:07,100 --> 00:52:09,900
managing servers in the cloud 
because like servers all about 

1237
00:52:09,900 --> 00:52:11,700
servers. 
In fact, now we're talking about

1238
00:52:11,700 --> 00:52:14,300
stacks and I mentioned Stacks or
I think equivalent Concept in 

1239
00:52:14,308 --> 00:52:16,600
the first edition of the book, 
but it's become much more of a 

1240
00:52:16,600 --> 00:52:18,000
thing. 
We're spending a lot more time 

1241
00:52:18,000 --> 00:52:21,700
now, on that level of the terror
for more the block of stuff in 

1242
00:52:21,700 --> 00:52:23,800
the cloud that you're managing 
block statement pieces, and 

1243
00:52:23,800 --> 00:52:25,300
they'll all that. 
And so, I think that's become 

1244
00:52:25,300 --> 00:52:26,500
important. 
I think a lot of the topics we 

1245
00:52:26,500 --> 00:52:29,500
talked about today are how to 
manage that infrastructure and 

1246
00:52:29,500 --> 00:52:31,700
keep it loose. 
Be coupled in smaller pieces and

1247
00:52:31,700 --> 00:52:33,600
more manageable. 
So it's less scary to change. 

1248
00:52:33,600 --> 00:52:35,800
I've learned a lot since I wrote
the book, right? 

1249
00:52:36,600 --> 00:52:38,500
I think as an industry we've 
moved on in terms of what we 

1250
00:52:38,500 --> 00:52:40,000
know and what challenges were 
facing. 

1251
00:52:40,200 --> 00:52:41,800
So I felt like that really needs
to come in there. 

1252
00:52:41,900 --> 00:52:44,800
So I think that's probably the 
biggest change is a lot more 

1253
00:52:44,800 --> 00:52:49,100
focus on that level of stuff. 
And there's a fair bit on those 

1254
00:52:49,100 --> 00:52:52,100
kind of almost design and 
architecture type patterns for 

1255
00:52:52,100 --> 00:52:54,500
infrastructure stack type 
projects. 

1256
00:52:54,500 --> 00:52:56,800
How do you integrate the 
different Stacks by talk? 

1257
00:52:56,800 --> 00:52:59,500
A little bit about codebase 
organization, the mono repo, and

1258
00:52:59,500 --> 00:53:01,500
those kind of things? 
I talked a little bit about the 

1259
00:53:01,500 --> 00:53:03,900
refactoring stuff that we talked
about because again, that's one 

1260
00:53:03,900 --> 00:53:06,400
of those things that we've run 
into a lot more or something. 

1261
00:53:06,400 --> 00:53:08,000
I've seen a lot more that need 
covering. 

1262
00:53:08,000 --> 00:53:10,500
So it's a pretty substantial 
rewrite. 

1263
00:53:10,500 --> 00:53:13,000
I would say, one of the things 
I'd like to do if I can is find 

1264
00:53:13,000 --> 00:53:15,900
one of those tools that like 
compares to see, like how much 

1265
00:53:16,000 --> 00:53:17,700
commonality there is between two
Tech's. 

1266
00:53:17,700 --> 00:53:19,200
I want to see how much of the 
book has changed. 

1267
00:53:19,200 --> 00:53:20,800
I would say. 
It's probably quite a lot, 

1268
00:53:21,300 --> 00:53:23,500
right? 
When can we expect to see the 

1269
00:53:23,500 --> 00:53:26,300
book being published? 
It should be out around the end 

1270
00:53:26,300 --> 00:53:29,800
of the year or maybe the 
beginning of next year and you 

1271
00:53:29,800 --> 00:53:33,600
can Get access to the draft of, 
most of the book, I think on the

1272
00:53:33,600 --> 00:53:35,900
O'Reilly's learning platform, 
which is formerly known as 

1273
00:53:35,900 --> 00:53:37,800
Safari. 
So, if you're a member of that 

1274
00:53:37,800 --> 00:53:40,000
platform, if you have access to 
that platform, you can find it 

1275
00:53:40,000 --> 00:53:42,200
on there. 
So I'll just ask one question. 

1276
00:53:42,200 --> 00:53:44,400
We stifle that to us throughout 
my experience as well. 

1277
00:53:44,400 --> 00:53:47,400
There are many people interested
with infrastructure as code, but

1278
00:53:47,400 --> 00:53:50,500
they have already had 
infrastructure setup since the 

1279
00:53:50,500 --> 00:53:53,500
beginning and some of them 
actually dream about having a 

1280
00:53:53,500 --> 00:53:55,900
reverse engineering Tools in 
which that from an 

1281
00:53:55,900 --> 00:53:59,000
infrastructure being set up. 
Can you actually come up with 

1282
00:53:59,100 --> 00:54:01,600
automatically? 
Generated code. 

1283
00:54:02,000 --> 00:54:04,500
So is there such tool that you 
know of I think there are a 

1284
00:54:04,508 --> 00:54:07,500
couple of tools that you can 
generate terraform code. 

1285
00:54:07,600 --> 00:54:10,100
I don't know the top my head, 
what the tools are. 

1286
00:54:10,100 --> 00:54:12,700
But I know there are tools to 
pointed at the cloud and it will

1287
00:54:12,700 --> 00:54:14,200
spit out code that you can then 
edit. 

1288
00:54:14,200 --> 00:54:16,400
And so on. 
I tend not to recommend that 

1289
00:54:16,400 --> 00:54:18,900
approach and maybe do it as a 
kind of a learning exercise to 

1290
00:54:18,900 --> 00:54:21,100
kind of learn a little bit about
your existing infrastructure. 

1291
00:54:21,500 --> 00:54:24,600
But what I tend to recommend is 
essentially taking piece by 

1292
00:54:24,600 --> 00:54:27,800
piece to existing infrastructure
and rebuilding it by writing the

1293
00:54:27,800 --> 00:54:31,300
code clean and well structured 
because The reverse-engineered 

1294
00:54:31,300 --> 00:54:33,100
code, I don't think is 
necessarily going to be well, 

1295
00:54:33,100 --> 00:54:35,300
structured. 
Well, factored won't include 

1296
00:54:35,300 --> 00:54:36,600
tests and all those kinds of 
things. 

1297
00:54:36,600 --> 00:54:39,900
So I recommend starting by take 
one piece, write the code for 

1298
00:54:39,900 --> 00:54:42,200
it, right test for right 
pipeline for it. 

1299
00:54:42,200 --> 00:54:44,400
Put it out there. 
And then using one of the kind 

1300
00:54:44,400 --> 00:54:46,900
of things that we've talked 
about around expander and 

1301
00:54:46,900 --> 00:54:49,100
contract or other kind of 
refactoring, patterns of to 

1302
00:54:49,100 --> 00:54:51,500
move, things over to the newly 
built thing. 

1303
00:54:51,500 --> 00:54:53,700
And then just do that piece by 
piece and replace your 

1304
00:54:53,700 --> 00:54:55,500
infrastructure with kind of new 
clean stuff. 

1305
00:54:55,500 --> 00:54:57,300
The same way you do with 
application code, when you have 

1306
00:54:57,300 --> 00:54:59,500
a model left and you're trying 
to maybe turn it into a more 

1307
00:54:59,500 --> 00:55:02,100
kind of micro. 
Sword, just better factored 

1308
00:55:02,100 --> 00:55:04,900
system right before we end our 
conversation. 

1309
00:55:04,900 --> 00:55:09,500
Keith as always, I ask my guests
to share it as the three 

1310
00:55:09,500 --> 00:55:11,100
technical leadership. 
Wisdoms. 

1311
00:55:11,100 --> 00:55:13,600
Can you share with us? 
What are your technical 

1312
00:55:13,600 --> 00:55:15,200
leadership wisdoms? 
Yeah. 

1313
00:55:15,200 --> 00:55:18,100
I think my biggest one is kind 
of like harnessing and trusting 

1314
00:55:18,100 --> 00:55:21,100
the power of your team and the 
people around you, one of things

1315
00:55:21,100 --> 00:55:23,600
that we didn't really talk about
in my career journey, is that I 

1316
00:55:23,600 --> 00:55:24,700
particularly before thought 
works. 

1317
00:55:24,700 --> 00:55:27,600
I did manage teams attended to 
manage teams of systems 

1318
00:55:27,600 --> 00:55:30,400
administrators or developers or 
sometimes both and one of Of the

1319
00:55:30,408 --> 00:55:33,300
kind of most powerful things. 
I found was not thinking that I 

1320
00:55:33,308 --> 00:55:36,100
had to kind of manage everything
and decide everything and know 

1321
00:55:36,100 --> 00:55:37,900
everything that's going on, but 
just kind of like trust the 

1322
00:55:37,900 --> 00:55:39,500
people and be there to support 
them. 

1323
00:55:39,500 --> 00:55:41,100
So that's that's like the 
number-one thing is one of those

1324
00:55:41,100 --> 00:55:43,400
lessons that I can I can relearn
this is, I know that and I 

1325
00:55:43,400 --> 00:55:45,800
learned it and then I'll be in a
new situation where I'm kind of 

1326
00:55:45,800 --> 00:55:48,000
not necessarily doing it. 
And then I realized, oh wait, if

1327
00:55:48,000 --> 00:55:51,300
I just tell the people and let 
them kind of decide, then it 

1328
00:55:51,300 --> 00:55:53,400
works out much better. 
It's much more, scalable and 

1329
00:55:53,400 --> 00:55:56,200
less stressful as well. 
The second thing is to support 

1330
00:55:56,200 --> 00:55:59,500
that really you need to kind of 
work out the right level of 

1331
00:55:59,500 --> 00:56:02,100
guidance and support. 
To provide to people and that 

1332
00:56:02,100 --> 00:56:05,400
can vary in different situations
and maybe I'll cheat a little 

1333
00:56:05,400 --> 00:56:08,700
bit and call that my third one 
as well, is to be aware of the 

1334
00:56:09,000 --> 00:56:11,000
different situations. 
You're in, might call for 

1335
00:56:11,000 --> 00:56:13,400
different approaches depending 
on things like the, maybe the 

1336
00:56:13,400 --> 00:56:15,800
skill level of the team. 
So, if you're coming into a team

1337
00:56:15,900 --> 00:56:18,600
and it's not really going well 
at the start like they're 

1338
00:56:18,600 --> 00:56:21,000
struggling, you might need to 
take a bit more of a Hands-On 

1339
00:56:21,000 --> 00:56:24,200
approach and a bit more close 
involvement and provide more 

1340
00:56:24,200 --> 00:56:27,000
direct support to people and 
understand what that is and sit 

1341
00:56:27,000 --> 00:56:29,500
down with them and work through 
things or what have you whereas 

1342
00:56:29,900 --> 00:56:32,200
with With a team that's more 
experience and everything is 

1343
00:56:32,200 --> 00:56:34,300
flowing. 
Well the level of guidance and 

1344
00:56:34,300 --> 00:56:37,400
support you may need to provide 
is maybe more around the kind of

1345
00:56:37,400 --> 00:56:40,400
prioritization and maybe even 
around higher level stuff. 

1346
00:56:40,400 --> 00:56:42,700
Look, these are the challenges 
that as an organization were 

1347
00:56:42,700 --> 00:56:44,600
facing. 
So if I'm the one going into 

1348
00:56:44,800 --> 00:56:47,300
management team meetings and 
we're focused on cost 

1349
00:56:47,300 --> 00:56:49,300
management, or maybe we're not 
focusing cost management. 

1350
00:56:49,300 --> 00:56:51,900
We need more opportunities for 
growth or whatever it is. 

1351
00:56:52,100 --> 00:56:53,900
He can take that back to your 
team and say, hey, these are the

1352
00:56:53,900 --> 00:56:55,800
things that were struggling with
never focus on as an 

1353
00:56:55,800 --> 00:56:57,800
organization. 
And so with decisions that 

1354
00:56:57,800 --> 00:57:00,900
you're making with the work that
you do day by day. - no need to 

1355
00:57:00,908 --> 00:57:02,600
come in and help you make those 
decisions. 

1356
00:57:02,600 --> 00:57:05,000
But like this is what you need 
to know that might help you with

1357
00:57:05,000 --> 00:57:07,200
that. 
So I think being there to 

1358
00:57:07,200 --> 00:57:10,500
support I guess the 123 is one. 
Don't over manage the people and

1359
00:57:10,500 --> 00:57:13,500
think that you need to think for
them, but do provide the right 

1360
00:57:13,500 --> 00:57:16,200
level of support that they need 
to know what they should be 

1361
00:57:16,200 --> 00:57:18,700
working on and when they need 
help to be able to bring that 

1362
00:57:18,700 --> 00:57:22,200
into them and then the third is 
to tailor that to the situation 

1363
00:57:22,200 --> 00:57:23,700
and their needs. 
Right? 

1364
00:57:23,700 --> 00:57:27,300
What can people find you online?
I'm mostly on Twitter. 

1365
00:57:27,300 --> 00:57:29,400
That's at Keith K. 
IE F. 

1366
00:57:29,400 --> 00:57:31,900
You can see my mirror. 
Lot, I do some stuff on LinkedIn

1367
00:57:32,300 --> 00:57:34,700
but Twitter's by the best. 
I've got a couple of websites 

1368
00:57:34,700 --> 00:57:37,800
that I almost never post to 
infrastructure as code.com with 

1369
00:57:37,800 --> 00:57:40,300
hyphens between the words as 
where I tend to post things 

1370
00:57:40,300 --> 00:57:42,400
about the book. 
I'll probably start posting more

1371
00:57:42,400 --> 00:57:45,400
as I finish up the book and get 
more into going out there and 

1372
00:57:45,400 --> 00:57:47,900
talking about it to the world 
mode, right? 

1373
00:57:48,100 --> 00:57:50,800
So yeah, I'm looking forward to 
the new book and thank you so 

1374
00:57:50,800 --> 00:57:51,900
much for your time. 
Keith. 

1375
00:57:51,900 --> 00:57:54,500
Nice talking to you learning 
more about infrastructure as 

1376
00:57:54,500 --> 00:57:55,400
code. 
Thanks a lot. 

1377
00:57:55,400 --> 00:57:56,400
Rodney. 
Henry has been good fun. 

1378
00:57:57,900 --> 00:58:01,600
Thank you so much for listening.
I hope you enjoy this episode, 

1379
00:58:01,800 --> 00:58:04,600
share it with your friends and 
colleagues who would benefit 

1380
00:58:04,600 --> 00:58:08,500
from listening to this episode. 
And if you liking this podcast, 

1381
00:58:08,600 --> 00:58:11,100
I would love if you subscribe 
and leave me your valuable 

1382
00:58:11,100 --> 00:58:14,000
review and feedback. 
It really helps me a lot. 

1383
00:58:14,400 --> 00:58:17,000
Stay tuned for the next 
technology, you know, episode. 

1384
00:58:17,100 --> 00:58:18,700
And until then. 
Goodbye.