1
00:00:00,040 --> 00:00:02,520
Welcome to the deep dive. 
We're here to, you know, cut 

2
00:00:02,520 --> 00:00:04,600
through the noise and pull out 
the really crucial insights you 

3
00:00:04,600 --> 00:00:06,520
need. 
Today we're tackling something 

4
00:00:06,520 --> 00:00:09,440
that's completely changed the 
game for software DevOps. 

5
00:00:09,960 --> 00:00:13,520
We're diving into software 
engineering a modern approach by

6
00:00:13,520 --> 00:00:16,400
Marco Tulio Valente, 
specifically Chapter 10. 

7
00:00:17,000 --> 00:00:20,760
Our mission to unpack why DevOps
came about, what it actually 

8
00:00:20,760 --> 00:00:24,680
means for software projects 
today, and how it aims to turn 

9
00:00:24,680 --> 00:00:28,800
stressful deployments into, 
well, something smooth, almost 

10
00:00:28,840 --> 00:00:30,160
routine. 
Sounds good, right? 

11
00:00:30,160 --> 00:00:32,840
OK, let's dig in. 
So to really get why DevOps is 

12
00:00:32,840 --> 00:00:34,880
such a big deal, we kind of need
to step back a bit. 

13
00:00:35,160 --> 00:00:37,440
Think about how things used to 
be before DevOps. 

14
00:00:37,440 --> 00:00:40,120
Building software often felt 
like like you had these two 

15
00:00:40,120 --> 00:00:42,080
separate kingdoms almost. 
You had the development 

16
00:00:42,080 --> 00:00:44,240
department and then you had the 
operations department. 

17
00:00:44,560 --> 00:00:46,040
Completely different worlds 
sometimes. 

18
00:00:46,320 --> 00:00:47,520
That's a really good way to 
picture it. 

19
00:00:47,520 --> 00:00:49,480
Yeah. 
The development side, that's 

20
00:00:49,480 --> 00:00:51,960
where you found, you know, the 
developers, the analysts, the 

21
00:00:51,960 --> 00:00:54,720
architects. 
Their whole focus was creating 

22
00:00:54,720 --> 00:00:57,360
the software, building new 
features, making things work. 

23
00:00:57,360 --> 00:01:02,360
It was all about creation. 
But then the operations side, 

24
00:01:02,920 --> 00:01:05,720
they were the guardians, right? 
System admins, network folks, 

25
00:01:05,720 --> 00:01:09,640
DBOSSRES. 
Their job was the, let's say, 

26
00:01:09,640 --> 00:01:13,360
the heavy lifting, installing, 
configuring, keeping the lights 

27
00:01:13,360 --> 00:01:15,800
on for the infrastructure, 
servers, networks, databases, 

28
00:01:16,080 --> 00:01:18,960
making sure everything was up, 
running reliably and performing 

29
00:01:18,960 --> 00:01:20,520
well. 
Very different priorities. 

30
00:01:20,880 --> 00:01:23,720
Yeah, you can almost feel the 
friction just describing it. 

31
00:01:23,720 --> 00:01:25,680
Different goals, different 
languages even. 

32
00:01:25,920 --> 00:01:29,080
Imagine spending months crafting
a feature only to toss it over 

33
00:01:29,080 --> 00:01:32,880
the wall last minute to a team 
focused purely on stability that

34
00:01:33,040 --> 00:01:35,600
that disconnect must have caused
some serious headaches. 

35
00:01:35,600 --> 00:01:37,200
Oh. 
Absolutely crippling headaches 

36
00:01:37,200 --> 00:01:40,040
sometimes, and looking back, 
maybe predictable ones. 

37
00:01:40,360 --> 00:01:43,640
The OPS team, they'd often only 
find out about a new system or a

38
00:01:43,640 --> 00:01:45,600
major update. 
Like literally on the eve of 

39
00:01:45,600 --> 00:01:46,640
deployment. 
Seriously. 

40
00:01:46,840 --> 00:01:49,520
The night before. 
Yeah, it was like like being 

41
00:01:49,520 --> 00:01:53,720
handed the final exam paper with
0 prep time, just here you go, 

42
00:01:53,720 --> 00:01:56,640
make it work. 
So this meant huge issues. 

43
00:01:56,640 --> 00:01:59,640
Things like not having enough 
hardware, unexpected performance

44
00:01:59,640 --> 00:02:02,480
drops, clashes with the 
production database, even major 

45
00:02:02,480 --> 00:02:04,200
security holes. 
They just weren't caught during 

46
00:02:04,200 --> 00:02:08,680
development and the result 
deployments could get pushed 

47
00:02:08,680 --> 00:02:11,120
back not just days, but months. 
Months. 

48
00:02:11,360 --> 00:02:14,360
Yeah, months, which obviously 
throws business plans completely

49
00:02:14,360 --> 00:02:17,120
out of whack. 
I remember this one project, a 

50
00:02:17,160 --> 00:02:21,040
tiny undocumented configuration 
change discovered literally 

51
00:02:21,040 --> 00:02:23,520
hours before go live. 
It just completely tanked. 

52
00:02:23,520 --> 00:02:26,840
A major application was a really
stark lesson, you know, about 

53
00:02:26,840 --> 00:02:28,280
the cost of working in those 
silos. 

54
00:02:28,600 --> 00:02:31,560
And in the absolute worst cases,
these kinds of problems, they 

55
00:02:31,560 --> 00:02:33,320
could be so bad that the 
deployment was cancelled 

56
00:02:33,320 --> 00:02:35,240
entirely. 
Sometimes even the whole project

57
00:02:35,240 --> 00:02:36,480
got scrapped. 
All that work. 

58
00:02:37,200 --> 00:02:38,400
Just gone. 
Exactly. 

59
00:02:38,400 --> 00:02:41,160
And this whole problem? 
It was often made much worse by 

60
00:02:41,160 --> 00:02:44,560
older monolithic architectures. 
Think of it like one giant 

61
00:02:44,600 --> 00:02:48,320
tangled ball of code. 
A small change here could cause 

62
00:02:48,320 --> 00:02:51,880
unexpected bugs way over there 
in parts that seem totally 

63
00:02:51,880 --> 00:02:53,760
unrelated. 
What's really key here? 

64
00:02:54,040 --> 00:02:55,680
It highlighted this fundamental 
clash. 

65
00:02:55,680 --> 00:02:58,760
Dev wants new stuff, OPS wants 
things stable. 

66
00:02:58,760 --> 00:03:01,840
Both vital goals obviously, but 
often pulling in opposite 

67
00:03:01,840 --> 00:03:03,120
directions in that old setup. 
Right. 

68
00:03:03,120 --> 00:03:06,280
So it wasn't just a tech issue, 
it was a human issue, a process 

69
00:03:06,280 --> 00:03:07,720
issue. 
Deeply frustrating. 

70
00:03:07,720 --> 00:03:10,000
I imagine all that potential 
wasted. 

71
00:03:10,200 --> 00:03:13,560
So OK, out of all this 
frustration, these delays, these

72
00:03:13,560 --> 00:03:16,240
canceled projects, something new
had to emerge. 

73
00:03:16,480 --> 00:03:18,680
Professionals started saying 
there has to be a better way. 

74
00:03:18,680 --> 00:03:20,400
And that way they called it 
DevOps. 

75
00:03:20,600 --> 00:03:22,400
Precisely. 
DevOps is. 

76
00:03:22,840 --> 00:03:24,360
It's a direct answer to that 
pain. 

77
00:03:24,360 --> 00:03:27,520
It's not just another buzzword. 
The book defines it really well.

78
00:03:27,520 --> 00:03:30,800
A movement, or more specifically
a set of concepts and practices 

79
00:03:31,160 --> 00:03:34,880
aimed at introducing agile 
principles in the last mile of a

80
00:03:34,880 --> 00:03:38,000
software project, IE when the 
system is entering production. 

81
00:03:38,560 --> 00:03:41,560
So it's about taking that agile 
collaboration we often see in 

82
00:03:41,560 --> 00:03:44,840
development and stretching it 
right through to deployment, 

83
00:03:44,920 --> 00:03:48,200
bringing OPS into the loop way, 
way earlier. 

84
00:03:48,240 --> 00:03:51,320
And there's this fantastic quote
that kicks off the chapter from 

85
00:03:51,320 --> 00:03:54,440
Jean Kim, Jess Humble, Patrick 
Dubois, and John Willis. 

86
00:03:54,440 --> 00:03:57,280
It really captures the spirit. 
Imagine a world where Product 

87
00:03:57,280 --> 00:04:00,880
Owners Development, QAIT 
operations, and Infosec work 

88
00:04:00,880 --> 00:04:03,560
together not just to aid each 
other, but to guarantee the 

89
00:04:03,560 --> 00:04:05,280
overall success of the 
organization. 

90
00:04:05,480 --> 00:04:07,200
That paints a powerful picture, 
doesn't it? 

91
00:04:07,360 --> 00:04:09,400
Moving from US versus them to 
what? 

92
00:04:09,520 --> 00:04:11,560
We're all in this together. 
It really does. 

93
00:04:11,560 --> 00:04:14,440
That quote perfectly nails the 
core idea. 

94
00:04:14,640 --> 00:04:17,959
It's about tearing down those 
walls of silos we talked about, 

95
00:04:17,959 --> 00:04:20,800
like the one Figure 10.1 in the 
book, and instead building this 

96
00:04:20,800 --> 00:04:24,560
closer, more symbiotic 
relationship between dev and 

97
00:04:24,560 --> 00:04:26,240
OPS. 
The whole point is making 

98
00:04:26,240 --> 00:04:29,520
deployment smoother, more 
predictable, less traumatic for 

99
00:04:29,520 --> 00:04:32,840
everyone, like you see in that 
integrated flow in Figure 10.2. 

100
00:04:33,400 --> 00:04:35,560
And it's really important to 
grasp this. 

101
00:04:35,960 --> 00:04:39,320
DevOps isn't about creating some
magical DevOps engineer who does

102
00:04:39,360 --> 00:04:41,080
everything. 
It's fundamentally about 

103
00:04:41,080 --> 00:04:43,960
fostering collaboration, getting
these different experts working 

104
00:04:43,960 --> 00:04:46,440
together from the start. 
Right, collaboration, not just a

105
00:04:46,440 --> 00:04:49,480
new job title. 
And this next idea really drives

106
00:04:49,480 --> 00:04:53,160
home the change DevOps enables, 
going for those panic driven 

107
00:04:53,240 --> 00:04:57,240
late night deployments to a 
world where updates just happen 

108
00:04:57,440 --> 00:05:00,320
seamlessly. 
Users barely notice, except for 

109
00:05:00,320 --> 00:05:02,880
the new features. 
Kim and the others describe it 

110
00:05:02,880 --> 00:05:04,880
like this. 
Instead of starting deployments 

111
00:05:04,880 --> 00:05:06,960
at midnight on Friday and 
spending the weekend working to 

112
00:05:06,960 --> 00:05:09,680
complete them, deployments occur
on any business day when 

113
00:05:09,680 --> 00:05:12,440
everyone is in the company and 
without customers noticing, 

114
00:05:12,800 --> 00:05:15,320
except when they encounter new 
features and bug fixes. 

115
00:05:16,240 --> 00:05:17,440
Right. 
That's a complete paradigm 

116
00:05:17,440 --> 00:05:19,600
shift, isn't it? 
It's a total game changer. 

117
00:05:19,600 --> 00:05:23,840
It turns deployment from this 
dreaded exhausting event into, 

118
00:05:24,120 --> 00:05:26,600
well, almost a boring everyday 
thing. 

119
00:05:26,640 --> 00:05:30,000
Which is exactly what you want. 
And this cultural shift, this 

120
00:05:30,000 --> 00:05:33,360
practical change means agile 
teams can actually embed an 

121
00:05:33,360 --> 00:05:36,360
operations person part time, 
full time, whatever works. 

122
00:05:36,920 --> 00:05:39,560
And they're not just sitting in 
meetings, they're in the sprints

123
00:05:39,760 --> 00:05:42,680
looking ahead. 
They're proactively spotting 

124
00:05:42,840 --> 00:05:46,320
potential performance issues, 
security concerns, system 

125
00:05:46,320 --> 00:05:49,720
incompatibilities early, not the
night before launch. 

126
00:05:50,120 --> 00:05:52,840
And they're Co creating the 
scripts needed for installation,

127
00:05:52,840 --> 00:05:55,640
administration, monitoring, 
making sure everything's aligned

128
00:05:55,640 --> 00:05:58,120
long before it hits production. 
And driving all of this, making 

129
00:05:58,120 --> 00:06:01,280
that smooth delivery actually 
possible, is automation. 

130
00:06:01,760 --> 00:06:04,760
That's key, right? 
DevOps strongly advocates for 

131
00:06:04,760 --> 00:06:07,800
automating all necessary steps 
to put a system into production 

132
00:06:07,920 --> 00:06:10,760
and to monitor its operation. 
So it builds on things like 

133
00:06:10,760 --> 00:06:13,120
automated testing, which many 
teams do. 

134
00:06:13,240 --> 00:06:15,160
But then it has crucial 
practices like continuous 

135
00:06:15,160 --> 00:06:18,080
integration, constantly merging 
and testing code, and continuous

136
00:06:18,080 --> 00:06:20,320
deployment, automating the 
release right into production. 

137
00:06:20,560 --> 00:06:22,840
These aren't just nice to haves,
they're the engines making 

138
00:06:22,840 --> 00:06:24,360
DevOps work. 
Absolutely. 

139
00:06:24,360 --> 00:06:26,880
Automation is fundamental and 
that's why you see things like 

140
00:06:27,040 --> 00:06:29,440
infrastructure as code becoming 
so important. 

141
00:06:29,440 --> 00:06:31,960
Managing your servers, your 
networks, everything just like 

142
00:06:31,960 --> 00:06:35,360
application code, versioned, 
automated, repeatable. 

143
00:06:35,400 --> 00:06:38,080
It takes those principles to the
next level, really ensuring 

144
00:06:38,080 --> 00:06:41,800
consistency. 
And just as a quick aside, that 

145
00:06:41,800 --> 00:06:45,400
term, DevOps, it actually came 
out of the very first conference

146
00:06:45,400 --> 00:06:49,560
on the topic, DevOps days back 
in Belgium, November 2009. 

147
00:06:49,560 --> 00:06:52,360
Patrick Dubois organized it. 
That was really the formal 

148
00:06:52,360 --> 00:06:55,160
starting gun for the movement. 
Interesting bit of history. 

149
00:06:55,560 --> 00:06:59,000
OK, so DevOps is this mix of 
culture change and practical 

150
00:06:59,000 --> 00:07:02,120
tools driven by automation. 
But what are the core 

151
00:07:02,120 --> 00:07:04,160
principles? 
What guides teams trying to 

152
00:07:04,160 --> 00:07:06,480
actually do this? 
For that, we can look at some 

153
00:07:06,480 --> 00:07:09,000
foundational ideas from Jez 
Humble and David Farley. 

154
00:07:09,200 --> 00:07:11,680
Their work really maps out the 
territory for modern software 

155
00:07:11,680 --> 00:07:13,080
delivery. 
Exactly. 

156
00:07:13,280 --> 00:07:16,440
Their principles really capture 
the essence of DevOps, even 

157
00:07:16,440 --> 00:07:18,920
though some predate the term 
becoming mainstream. 

158
00:07:19,400 --> 00:07:23,040
So the first one is create a 
repeatable and reliable process 

159
00:07:23,040 --> 00:07:26,280
for software delivery. 
The idea here is simple but 

160
00:07:26,280 --> 00:07:29,360
powerful. 
Make delivery predictable, not 

161
00:07:29,360 --> 00:07:32,120
this stressful manual surprise 
filled ordeal. 

162
00:07:32,440 --> 00:07:34,840
It should be ideally as 
straightforward as pressing a 

163
00:07:34,840 --> 00:07:37,160
button. 
Fewer manual steps mean fewer 

164
00:07:37,160 --> 00:07:40,560
chances for things to go wrong. 
OK, simple goal, maybe not 

165
00:07:40,560 --> 00:07:43,360
simple to achieve initially. 
Right, which leads directly to 

166
00:07:43,360 --> 00:07:45,760
the second principle, Automate 
as much as possible. 

167
00:07:45,760 --> 00:07:47,800
This isn't just a nice idea, 
it's basically essential for 

168
00:07:47,800 --> 00:07:50,280
that first principle. 
Automate everything involved in 

169
00:07:50,280 --> 00:07:53,120
delivery, building the software,
running all the tests, setting 

170
00:07:53,120 --> 00:07:56,040
up the environments, VMS, 
containers, whatever, even 

171
00:07:56,040 --> 00:07:57,720
creating and setting up the 
databases. 

172
00:07:58,080 --> 00:08:00,680
And crucially, it's not just 
automating the everything works 

173
00:08:00,680 --> 00:08:03,360
perfectly scenario. 
The real win, where you banish a

174
00:08:03,360 --> 00:08:06,480
lot of the stress, is automating
error handling, rollbacks, 

175
00:08:06,480 --> 00:08:08,920
recovery, making the whole 
process resilient. 

176
00:08:09,040 --> 00:08:11,800
The dream scenario? 
Press a button, software goes 

177
00:08:11,800 --> 00:08:14,200
live smoothly. 
That really does sound like the 

178
00:08:14,200 --> 00:08:18,120
dream, but practically speaking,
getting to that one button 

179
00:08:18,120 --> 00:08:21,640
deploy that feels like a huge 
leap for many places. 

180
00:08:22,160 --> 00:08:24,760
What's the biggest cultural 
hurdle you've seen when teams 

181
00:08:25,040 --> 00:08:27,040
try to implement that level of 
automation? 

182
00:08:27,160 --> 00:08:29,840
How do they even start? 
That's a great point, because 

183
00:08:29,840 --> 00:08:31,600
it's rarely just about the 
technology. 

184
00:08:32,200 --> 00:08:34,600
Often the biggest hurdle is, 
well, fear. 

185
00:08:35,080 --> 00:08:38,080
Fear of losing control, fear of 
the automation messing up, 

186
00:08:38,280 --> 00:08:40,840
sometimes even fear of jobs 
changing or disappearing. 

187
00:08:41,320 --> 00:08:43,159
The way to tackle it? 
Start small. 

188
00:08:43,760 --> 00:08:46,360
Automate something obviously 
painful and manual first, 

189
00:08:46,760 --> 00:08:48,240
something everyone agrees is 
awful. 

190
00:08:48,680 --> 00:08:51,280
Show a quick win. 
Demonstrate the benefit. 

191
00:08:51,520 --> 00:08:54,080
Build trust in the automation 
and in the team's ability to 

192
00:08:54,080 --> 00:08:57,240
manage it step by step. 
It often means shifting focus 

193
00:08:57,240 --> 00:09:00,000
from manual checking after the 
fact to building automated 

194
00:09:00,000 --> 00:09:02,800
checks before and during 
guardrails, not just 

195
00:09:02,800 --> 00:09:04,800
inspections. 
OK, build trust incrementally. 

196
00:09:04,800 --> 00:09:06,760
Makes sense. 
What's next on the principal's 

197
00:09:06,760 --> 00:09:09,120
list, right? 
The third principle is quite 

198
00:09:09,120 --> 00:09:12,320
insightful. 
If a step causes pain, execute 

199
00:09:12,320 --> 00:09:14,400
it frequently and as early as 
possible. 

200
00:09:14,680 --> 00:09:18,360
This is about tackling problems 
head on before they snowball. 

201
00:09:18,840 --> 00:09:21,240
Don't avoid the difficult stuff,
do it more often. 

202
00:09:21,640 --> 00:09:24,200
The classic example is 
continuous integration. 

203
00:09:24,360 --> 00:09:27,200
If developers work alone for 
weeks, merging their code 

204
00:09:27,200 --> 00:09:29,120
becomes this massive, painful 
nightmare. 

205
00:09:29,120 --> 00:09:30,680
Only I'll merge hell, been 
there. 

206
00:09:30,680 --> 00:09:32,800
Exactly. 
So the solution? 

207
00:09:33,440 --> 00:09:36,360
If integration hurts, integrate 
constantly, every day. 

208
00:09:36,360 --> 00:09:39,680
Ideally, find the problems when 
they're tiny and easy to fix, 

209
00:09:39,920 --> 00:09:41,560
not when they've grown into 
monsters. 

210
00:09:41,560 --> 00:09:43,800
Makes perfect sense to deal with
the pain early and often. 

211
00:09:43,960 --> 00:09:46,360
Then we have #4 which is about 
shared understanding. 

212
00:09:46,640 --> 00:09:50,200
Done means ready for delivery. 
This tackles that classic 

213
00:09:50,200 --> 00:09:53,440
problem where a developer says, 
Yep, story's done, but it's not 

214
00:09:53,440 --> 00:09:55,400
really done. 
Maybe it hasn't been tested with

215
00:09:55,400 --> 00:09:57,600
realistic data. 
Maybe the documentation isn't 

216
00:09:57,600 --> 00:09:59,200
there. 
Maybe it's not hooked up to that

217
00:09:59,200 --> 00:10:02,600
third party service it needs. 
This principle forces clarity. 

218
00:10:03,160 --> 00:10:05,520
Done means actually ready to go 
out to users. 

219
00:10:05,560 --> 00:10:08,720
All the boxes ticked, no more 
done, but not really done. 

220
00:10:08,880 --> 00:10:11,240
Setting a clear high bar for 
completion. 

221
00:10:11,240 --> 00:10:13,200
I like it. 
And finally, the fifth 

222
00:10:13,200 --> 00:10:16,040
principle, which kind of 
underpins everything everyone is

223
00:10:16,040 --> 00:10:17,640
responsible for software 
delivery. 

224
00:10:17,960 --> 00:10:20,360
This hits directly at those old 
silos. 

225
00:10:20,400 --> 00:10:23,400
No more dev team throwing code 
over the wall to OPS at the last

226
00:10:23,400 --> 00:10:25,440
minute. 
The success or failure of 

227
00:10:25,440 --> 00:10:28,600
getting software out there and 
keeping it running well is a 

228
00:10:28,600 --> 00:10:32,800
shared responsibility. 
Everyone, product, dev, QA, OPS,

229
00:10:32,800 --> 00:10:36,440
security, everyone owns it. 
It creates a shared destiny 

230
00:10:36,680 --> 00:10:39,040
which is incredibly powerful for
alignment A. 

231
00:10:39,400 --> 00:10:42,240
Shared fate. 
That sums it up well, yeah. 

232
00:10:42,560 --> 00:10:46,240
OK, so wrapping this up, what's 
the big picture here we've seen 

233
00:10:46,240 --> 00:10:49,480
DevOps emerge from the sheer 
frustration of the old way, the 

234
00:10:49,480 --> 00:10:51,960
silos, the delays, the late 
night crises. 

235
00:10:52,240 --> 00:10:54,920
It pushes for this radical shift
towards collaboration and heavy 

236
00:10:54,920 --> 00:10:56,560
automation. 
And the goal is 

237
00:10:56,560 --> 00:10:59,960
transformational, turning those 
nightmare midnight Friday 

238
00:10:59,960 --> 00:11:02,520
deployments into, well, just 
another part of the work day. 

239
00:11:02,840 --> 00:11:05,800
Smooth, frequent, almost boring.
It's really about making the 

240
00:11:05,800 --> 00:11:09,120
entire life cycle from idea to 
production more efficient, much 

241
00:11:09,120 --> 00:11:11,480
more reliable, and ultimately 
way more successful for 

242
00:11:11,480 --> 00:11:12,600
everybody. 
Absolutely. 

243
00:11:12,600 --> 00:11:15,040
Thank you for joining us on this
deep dive into the world of dev 

244
00:11:15,040 --> 00:11:16,600
OPS. 
It's a fascinating and crucial 

245
00:11:16,600 --> 00:11:18,880
area. 
We hope this deep dive is giving

246
00:11:18,880 --> 00:11:21,480
you some valuable insights. 
Thanks for listening.