WEBVTT

1
00:00:00.080 --> 00:00:04.000
<v Speaker 1>You ever feel like software development is just this relentless treadmill,

2
00:00:04.639 --> 00:00:09.400
<v Speaker 1>you know, new releases, features, patches, It just never stops. Yeah, absolutely,

3
00:00:09.720 --> 00:00:11.759
<v Speaker 1>And for so many teams it feels less like build

4
00:00:11.800 --> 00:00:15.080
<v Speaker 1>ship learn and more like build ship burnout.

5
00:00:15.160 --> 00:00:16.280
<v Speaker 2>That burnout is real.

6
00:00:16.640 --> 00:00:19.839
<v Speaker 1>But what if there was like a shortcut, a way

7
00:00:19.879 --> 00:00:22.800
<v Speaker 1>to make things smoother, faster, more reliable.

8
00:00:23.039 --> 00:00:25.160
<v Speaker 2>That's the million dollar question, isn't it.

9
00:00:25.239 --> 00:00:29.480
<v Speaker 1>Well, today we're diving deep into Roman Verrel's book New Ops.

10
00:00:29.480 --> 00:00:33.759
<v Speaker 1>How AI agents are reinventing DevOps and software. It's pretty

11
00:00:33.759 --> 00:00:37.200
<v Speaker 1>insightful stuff. Our mission here is to sort of unpack

12
00:00:37.280 --> 00:00:39.759
<v Speaker 1>that journey. How do we get from these you know,

13
00:00:39.799 --> 00:00:43.240
<v Speaker 1>fragmented systems we have today to a future where software

14
00:00:43.280 --> 00:00:44.119
<v Speaker 1>almost runs.

15
00:00:43.920 --> 00:00:46.600
<v Speaker 2>Itself, freeing up people for the really interesting.

16
00:00:46.280 --> 00:00:48.960
<v Speaker 1>Work, exactly, freeing you up to focus on what only

17
00:00:49.039 --> 00:00:51.920
<v Speaker 1>humans can do, which is innovate. So we'll explore why

18
00:00:51.920 --> 00:00:55.679
<v Speaker 1>traditional DevOps well sometimes it just isn't enough, how standardization

19
00:00:55.759 --> 00:00:59.119
<v Speaker 1>kind of leads the groundwork, and then crucially, how generative

20
00:00:59.159 --> 00:01:05.079
<v Speaker 1>AI steps in to revolutionize pretty much everything, coding, infrastructure,

21
00:01:05.159 --> 00:01:07.959
<v Speaker 1>the works. It's a big shift, it really is. So Okay,

22
00:01:08.040 --> 00:01:11.319
<v Speaker 1>let's unpack this. How can we actually get there. How

23
00:01:11.400 --> 00:01:12.920
<v Speaker 1>does the drudgery melt away?

24
00:01:13.079 --> 00:01:16.159
<v Speaker 2>The foundation from DevOps evolution to standardization.

25
00:01:16.439 --> 00:01:20.200
<v Speaker 1>Okay, before we jump into like reinventing the future, let's

26
00:01:20.200 --> 00:01:23.319
<v Speaker 1>glance back for a second. Remember the old days, the

27
00:01:23.439 --> 00:01:25.359
<v Speaker 1>rigid walls between devs and ops.

28
00:01:25.439 --> 00:01:28.319
<v Speaker 2>Oh yeah, that thrown over the wall, mentality.

29
00:01:27.879 --> 00:01:31.400
<v Speaker 1>Role nightmare, right, Yeah, long release cycles, constant finger pointing.

30
00:01:31.519 --> 00:01:35.000
<v Speaker 2>It really was. Now Agile started breaking down those silos

31
00:01:35.040 --> 00:01:37.159
<v Speaker 2>within development, which was a good start.

32
00:01:36.879 --> 00:01:39.799
<v Speaker 1>But OPS was still often the bottleneck, definitely.

33
00:01:39.879 --> 00:01:42.879
<v Speaker 2>And then you know, DevOps as a term started gaining traction.

34
00:01:43.159 --> 00:01:46.400
<v Speaker 2>Patrick de Bois, the DevOps Days conferences.

35
00:01:45.920 --> 00:01:49.439
<v Speaker 1>And that flicker talk ten plus deployees per day back

36
00:01:49.480 --> 00:01:51.040
<v Speaker 1>in two thousand and nine, right.

37
00:01:51.239 --> 00:01:53.719
<v Speaker 2>All spaw and Hammond. That was like a real light

38
00:01:53.760 --> 00:01:55.079
<v Speaker 2>bulb moment for a lot of people.

39
00:01:55.120 --> 00:01:57.239
<v Speaker 1>And then the Phoenix project came along in boom. It

40
00:01:57.319 --> 00:02:01.280
<v Speaker 1>really brought CICD, shared responsibility, all that stuff into the mainstream.

41
00:02:01.439 --> 00:02:06.760
<v Speaker 2>Yeah, collaboration, automation, measurement, learning, those became the core ideas.

42
00:02:06.480 --> 00:02:08.360
<v Speaker 1>And the results. I mean, look at the door reports,

43
00:02:08.840 --> 00:02:11.280
<v Speaker 1>elite teams deploying hundreds of times a day.

44
00:02:11.479 --> 00:02:14.360
<v Speaker 2>It's incredible. Think Amazon, Netflix, It's.

45
00:02:14.199 --> 00:02:16.240
<v Speaker 1>Not just faster. It's a whole different way of operating,

46
00:02:16.520 --> 00:02:18.719
<v Speaker 1>adapting almost in real time exactly.

47
00:02:19.280 --> 00:02:23.000
<v Speaker 2>But here's the catch. Despite all that promise, so many

48
00:02:23.120 --> 00:02:25.039
<v Speaker 2>organizations are still struggling to get there.

49
00:02:25.240 --> 00:02:27.759
<v Speaker 1>Yeah, why is that? If the path is clear, why

50
00:02:27.800 --> 00:02:28.560
<v Speaker 1>are people stuck?

51
00:02:29.120 --> 00:02:32.120
<v Speaker 2>Well, the book points to a few things, new pressures

52
00:02:32.159 --> 00:02:35.719
<v Speaker 2>and emerging challenges, like cultural resistance. That's a big one.

53
00:02:36.000 --> 00:02:38.960
<v Speaker 2>Up to forty five percent of initiative stalled just on culture.

54
00:02:39.199 --> 00:02:40.719
<v Speaker 1>Wow, nearly half.

55
00:02:40.639 --> 00:02:44.759
<v Speaker 2>Yeah, and then skill gaps and kind of ironically, this

56
00:02:44.840 --> 00:02:46.080
<v Speaker 2>thing called tool sprawl.

57
00:02:46.159 --> 00:02:49.400
<v Speaker 1>Okay, tool sprawl, let's dig into that. So if you've

58
00:02:49.719 --> 00:02:53.240
<v Speaker 1>adopted DevOps but you still feel stuck, this sounds like

59
00:02:53.280 --> 00:02:54.080
<v Speaker 1>a big part of the.

60
00:02:54.039 --> 00:02:57.879
<v Speaker 2>Why it often is. It's this sort of ironic outcome

61
00:02:57.919 --> 00:03:00.879
<v Speaker 2>of DevOps. You want the best tool for each makes sense,

62
00:03:01.319 --> 00:03:04.319
<v Speaker 2>So you get get for version control, Jenkins for CI,

63
00:03:04.759 --> 00:03:08.560
<v Speaker 2>maybe Terraform for your infrastructure, Splunk for monitoring, all good

64
00:03:08.599 --> 00:03:11.240
<v Speaker 2>tools on their own, all great tools. But suddenly you've

65
00:03:11.280 --> 00:03:14.039
<v Speaker 2>got twenty thirty maybe even more, different tools you're trying

66
00:03:14.039 --> 00:03:14.479
<v Speaker 2>to juggle.

67
00:03:14.520 --> 00:03:16.400
<v Speaker 1>Okay, I can see how that gets messy.

68
00:03:16.120 --> 00:03:19.479
<v Speaker 2>Fast, And the book cites this figure. Over fifty percent

69
00:03:19.479 --> 00:03:23.520
<v Speaker 2>of enterprises using more than twenty DevOps tools. That creates

70
00:03:23.560 --> 00:03:24.840
<v Speaker 2>what VORL calls.

71
00:03:24.759 --> 00:03:26.919
<v Speaker 1>A tool tax cool tax, meaning.

72
00:03:27.159 --> 00:03:32.439
<v Speaker 2>Meaning significant license costs. Yeah, but also constant integration headaches

73
00:03:32.520 --> 00:03:36.120
<v Speaker 2>and developers just burning time context switching between all these

74
00:03:36.120 --> 00:03:37.639
<v Speaker 2>different interfaces.

75
00:03:37.120 --> 00:03:39.439
<v Speaker 1>Right, jumping from one UI to another, trying to remember

76
00:03:39.439 --> 00:03:39.759
<v Speaker 1>how this.

77
00:03:39.719 --> 00:03:42.639
<v Speaker 2>One works exactly. And then there are the data.

78
00:03:42.400 --> 00:03:46.479
<v Speaker 1>Silos, so each tool keeps its own data separately pretty much.

79
00:03:46.560 --> 00:03:49.759
<v Speaker 2>Build logs are over here, test results are there, deployment

80
00:03:49.800 --> 00:03:50.840
<v Speaker 2>record somewhere else.

81
00:03:50.800 --> 00:03:55.080
<v Speaker 1>Entirely, which leads to that visibility gap you mentioned precisely.

82
00:03:55.520 --> 00:03:58.360
<v Speaker 2>The book says seventy four percent of teams lack that

83
00:03:58.479 --> 00:04:01.719
<v Speaker 2>end to end visibility. So when something breaks, good luck

84
00:04:01.759 --> 00:04:03.319
<v Speaker 2>figuring out what happened quickly.

85
00:04:03.560 --> 00:04:06.719
<v Speaker 1>Ouch, So incident response times just go through the roof they.

86
00:04:06.520 --> 00:04:10.280
<v Speaker 2>Do, and it creates these DevOps ironies. Like you tried

87
00:04:10.280 --> 00:04:13.120
<v Speaker 2>to break down silos between devnops, but now you've got

88
00:04:13.120 --> 00:04:16.000
<v Speaker 2>new silos based on who knows which specific tool.

89
00:04:15.919 --> 00:04:17.879
<v Speaker 1>So more friction, duplicate effort.

90
00:04:18.240 --> 00:04:21.639
<v Speaker 2>Yeah, that whole choose your own tool culture sounds great

91
00:04:21.639 --> 00:04:25.639
<v Speaker 2>for innovation initially, but it often just spirals into fragmentation

92
00:04:25.800 --> 00:04:29.360
<v Speaker 2>and hidden costs slower time to market, more errors.

93
00:04:29.680 --> 00:04:32.240
<v Speaker 1>The book had that example, right, the financial services firm.

94
00:04:32.399 --> 00:04:34.480
<v Speaker 2>Oh yeah, that was a painful one to read about.

95
00:04:34.680 --> 00:04:34.920
<v Speaker 1>Yeah.

96
00:04:34.920 --> 00:04:37.240
<v Speaker 2>Eight different CI pipelines, three.

97
00:04:37.079 --> 00:04:39.480
<v Speaker 1>Code repositories, different logging systems.

98
00:04:39.600 --> 00:04:42.279
<v Speaker 2>Imagine being an engineer there just trying to track down

99
00:04:42.439 --> 00:04:45.199
<v Speaker 2>which version of a micro service was deployed when something

100
00:04:45.240 --> 00:04:47.680
<v Speaker 2>went wrong. Hours wasted, and.

101
00:04:47.639 --> 00:04:49.680
<v Speaker 1>It wasn't just the pipelines, right, It went down to

102
00:04:49.680 --> 00:04:50.600
<v Speaker 1>the developers machine.

103
00:04:50.680 --> 00:04:56.399
<v Speaker 2>Absolutely, multiple IDEs vs. Code intelliga eclipse. It fragments the

104
00:04:56.439 --> 00:05:00.240
<v Speaker 2>whole developer experience, harder to enforce, standards, harder to collapse.

105
00:05:00.560 --> 00:05:02.759
<v Speaker 1>And ultimately, you said, it hurts AI.

106
00:05:02.519 --> 00:05:06.199
<v Speaker 2>Readiness critically, that's the connection to the future. Why does

107
00:05:06.240 --> 00:05:09.360
<v Speaker 2>all this fragmentation matter so much for AI? Okay, why

108
00:05:09.759 --> 00:05:14.920
<v Speaker 2>because AI, especially generative AI, thrives on data consistent, complete,

109
00:05:15.040 --> 00:05:16.360
<v Speaker 2>high quality.

110
00:05:16.040 --> 00:05:18.079
<v Speaker 1>Data right, garbage in garbage.

111
00:05:17.720 --> 00:05:21.959
<v Speaker 2>App Exactly If your logs, metrics test results are scattered

112
00:05:22.079 --> 00:05:26.000
<v Speaker 2>everywhere in different formats, any AI trying to find anomalies

113
00:05:26.079 --> 00:05:28.399
<v Speaker 2>or generate code is basically working with blind.

114
00:05:28.160 --> 00:05:30.360
<v Speaker 1>Spots, so it just can't see the whole picture.

115
00:05:30.399 --> 00:05:33.839
<v Speaker 2>It can't. Fragmentation is like the number one enemy of

116
00:05:33.920 --> 00:05:35.600
<v Speaker 2>advanced AI. And DevOps.

117
00:05:35.720 --> 00:05:41.879
<v Speaker 1>Okay, so the path forward becomes well obvious. I guess standardization, standardization.

118
00:05:42.279 --> 00:05:45.720
<v Speaker 2>But it's not about stifling innovation, right, It's about creating

119
00:05:45.839 --> 00:05:51.240
<v Speaker 2>a unified, repeatable, and data friendly framework like.

120
00:05:51.240 --> 00:05:55.040
<v Speaker 1>A golden pipeline, a curated set of tools that work together.

121
00:05:54.920 --> 00:05:58.959
<v Speaker 2>Exactly that streamline collaboration, less operational overhead. The book calls

122
00:05:58.959 --> 00:06:01.959
<v Speaker 2>it the anti tool tag. Stronger security, better compliance.

123
00:06:01.519 --> 00:06:03.079
<v Speaker 1>And crucially getting ready for AI.

124
00:06:03.319 --> 00:06:07.000
<v Speaker 2>That's the big payoff. You provide that uniform structured data

125
00:06:07.079 --> 00:06:10.439
<v Speaker 2>that these autonomous AI agents need to function effectively. Vorrel

126
00:06:10.480 --> 00:06:15.199
<v Speaker 2>puts it bluntly. Without standardization, AI driven automation will never

127
00:06:15.279 --> 00:06:16.480
<v Speaker 2>reach its full potential.

128
00:06:16.839 --> 00:06:19.560
<v Speaker 1>So standardization is the blueprint. What about the foundation? The

129
00:06:19.560 --> 00:06:21.759
<v Speaker 1>book talks a lot about Cloud Native. Why is that

130
00:06:21.800 --> 00:06:22.560
<v Speaker 1>so important here?

131
00:06:22.920 --> 00:06:26.040
<v Speaker 2>Because Cloud native architecture is basically designed for this kind

132
00:06:26.079 --> 00:06:29.639
<v Speaker 2>of dynamic, automated world from the get go. Ah, Well,

133
00:06:29.680 --> 00:06:33.839
<v Speaker 2>you're using things like micro services, containers think Docker, dynamic

134
00:06:33.920 --> 00:06:38.519
<v Speaker 2>orchestration like Kubernetes, infrastructure as code with tools like Terraform.

135
00:06:38.800 --> 00:06:39.079
<v Speaker 1>Okay.

136
00:06:39.319 --> 00:06:43.120
<v Speaker 2>All that enables systems to scale automatically, to self heal

137
00:06:43.160 --> 00:06:46.319
<v Speaker 2>when things go wrong, to spin up temporary environments easily.

138
00:06:46.839 --> 00:06:49.920
<v Speaker 2>It's the technical underpinning you need for AI agents to

139
00:06:49.959 --> 00:06:51.480
<v Speaker 2>really manage things effectively.

140
00:06:51.639 --> 00:06:55.199
<v Speaker 1>Got it. So it provides the flexibility and resilience AI.

141
00:06:55.040 --> 00:06:58.800
<v Speaker 2>Needs exactly, and that connects directly to needing data centric

142
00:06:58.920 --> 00:07:00.319
<v Speaker 2>architectures and observes.

143
00:07:00.639 --> 00:07:05.519
<v Speaker 1>Meaning getting all that data in one place, logs, metrics, traces.

144
00:07:05.240 --> 00:07:08.959
<v Speaker 2>Yes, and tagging it consistently so you actually have deep visibility,

145
00:07:09.000 --> 00:07:11.319
<v Speaker 2>real time feedback loops. That's the fuel for the AI,

146
00:07:11.519 --> 00:07:12.319
<v Speaker 2>and tools.

147
00:07:12.040 --> 00:07:14.879
<v Speaker 1>Like OPS are come in here helping aggregate all that right.

148
00:07:15.160 --> 00:07:18.240
<v Speaker 2>The book mentions ops A specifically because it provides platform

149
00:07:18.319 --> 00:07:22.480
<v Speaker 2>agnostic analytics. It integrates with like over eighty different nosec

150
00:07:22.560 --> 00:07:25.839
<v Speaker 2>ops tools, wow, eighty plus Yeah, pulling all that data

151
00:07:25.879 --> 00:07:30.160
<v Speaker 2>into unified dashboards so leaders can actually see things like

152
00:07:30.279 --> 00:07:36.040
<v Speaker 2>deployment frequency, MTTR lead time, regardless of the specific tools.

153
00:07:35.839 --> 00:07:38.560
<v Speaker 1>Underneath, seeing the whole forest, not just the trees. Like

154
00:07:38.600 --> 00:07:42.000
<v Speaker 1>you said, precisely, that Retail Giant case study really showed

155
00:07:42.000 --> 00:07:46.519
<v Speaker 1>the impact, didn't it. Monthly to daily deploys outages way down.

156
00:07:46.319 --> 00:07:49.920
<v Speaker 2>And their observability shot up. That immediately paved the way

157
00:07:49.959 --> 00:07:53.720
<v Speaker 2>for them to start piloting AI for anomaly detection lay

158
00:07:53.720 --> 00:07:55.839
<v Speaker 2>the foundation see the benefits quickly.

159
00:07:56.160 --> 00:07:58.920
<v Speaker 1>So if we're aiming for this autonomous future, what does

160
00:07:59.120 --> 00:08:02.000
<v Speaker 1>GOOD have actually look like? Is there a reference architecture?

161
00:08:02.120 --> 00:08:04.879
<v Speaker 2>Yeah, the book outlines what GOOD looks like. It's a

162
00:08:04.959 --> 00:08:08.319
<v Speaker 2>unified architecture covering everything from requirements all the way to

163
00:08:08.399 --> 00:08:09.399
<v Speaker 2>monitoring and production.

164
00:08:09.560 --> 00:08:10.759
<v Speaker 1>And key features are.

165
00:08:11.079 --> 00:08:15.639
<v Speaker 2>Self service for developers, self healing capabilities, security embedded right

166
00:08:15.639 --> 00:08:18.199
<v Speaker 2>from the start, not bolted on later, and.

167
00:08:18.079 --> 00:08:21.360
<v Speaker 1>The practical way to get there. That paved road concept exactly.

168
00:08:21.439 --> 00:08:24.720
<v Speaker 2>Part I offers this practical paved road. It's about deliberately

169
00:08:24.839 --> 00:08:28.879
<v Speaker 2>choosing a lean stack, often centered around something like gethub

170
00:08:28.959 --> 00:08:33.279
<v Speaker 2>Enterprise Cloud maybe with actions for the pipelines, get Hub,

171
00:08:33.320 --> 00:08:37.919
<v Speaker 2>Advanced Security gaks for shifting security left okay, OPS area

172
00:08:38.120 --> 00:08:40.679
<v Speaker 2>for the analytics and visibility layer we just talked about,

173
00:08:40.679 --> 00:08:44.799
<v Speaker 2>and then standardizing the developer workspace, maybe on something like vs.

174
00:08:44.519 --> 00:08:50.440
<v Speaker 1>Code, so collapsing maybe dozens of tools down to a core, cohesive.

175
00:08:49.919 --> 00:08:53.480
<v Speaker 2>Set right, creating that clean telemetry foundation that you need

176
00:08:53.519 --> 00:08:58.759
<v Speaker 2>for autonomous new OPS. It's about intentional simplicity driving complex automation.

177
00:08:58.960 --> 00:09:02.000
<v Speaker 1>Okay, sounds good rate in theory, but how do you

178
00:09:02.039 --> 00:09:04.919
<v Speaker 1>actually do it? People listening might be thinking, my setup

179
00:09:04.960 --> 00:09:06.440
<v Speaker 1>is chaos. Where do I even start?

180
00:09:06.559 --> 00:09:09.840
<v Speaker 2>Yeah, it can feel overwhelming. The book provides an implementation

181
00:09:09.960 --> 00:09:11.919
<v Speaker 2>guidance playbook which is pretty helpful.

182
00:09:12.000 --> 00:09:12.720
<v Speaker 1>What are the steps.

183
00:09:12.960 --> 00:09:15.519
<v Speaker 2>It starts with forming an AI gild Tiger team, a

184
00:09:15.559 --> 00:09:19.559
<v Speaker 2>dedicated group to lead this. Then baseline your current tool sprawl.

185
00:09:19.720 --> 00:09:21.080
<v Speaker 2>You need to know how bad it.

186
00:09:21.039 --> 00:09:22.320
<v Speaker 1>Is first, Okay, measure the mess.

187
00:09:22.399 --> 00:09:25.159
<v Speaker 2>Measure the mess. Then importantly freeze new tool purchases for

188
00:09:25.200 --> 00:09:28.240
<v Speaker 2>a while. Stop adding to the problem makes sense. Publish

189
00:09:28.279 --> 00:09:32.120
<v Speaker 2>clear standards for co depositories, tagging things like that. Then

190
00:09:32.320 --> 00:09:36.200
<v Speaker 2>you systematically migrate teams and projects onto the paved road

191
00:09:36.360 --> 00:09:41.639
<v Speaker 2>and track progress absolutely, track ey KPIs, lead time, MTTR,

192
00:09:42.159 --> 00:09:46.000
<v Speaker 2>toolcount reduction, even licensed cost savings, and surface all of

193
00:09:46.039 --> 00:09:48.200
<v Speaker 2>that in a tool like opserra so everyone can see

194
00:09:48.200 --> 00:09:49.799
<v Speaker 2>the progress. It's methodical.

195
00:09:50.200 --> 00:09:53.320
<v Speaker 1>Generative AI transforms the software development life cycle.

196
00:09:53.399 --> 00:09:57.840
<v Speaker 2>Okay, so we've built this solid, standardized runaway. The foundation

197
00:09:58.000 --> 00:10:00.639
<v Speaker 2>is there. Now the book really takes off into the

198
00:10:00.679 --> 00:10:04.960
<v Speaker 2>revolutionary part generative AI, not just helping operations but actually

199
00:10:05.080 --> 00:10:07.000
<v Speaker 2>changing how we write the code itself.

200
00:10:07.159 --> 00:10:09.159
<v Speaker 1>Right, This is where it gets really exciting the rise

201
00:10:09.159 --> 00:10:12.159
<v Speaker 1>of AI coding assistance like Gethub. Copilot is just a

202
00:10:12.200 --> 00:10:13.480
<v Speaker 1>massive game changer.

203
00:10:13.279 --> 00:10:15.440
<v Speaker 2>More than just autocomplete right, oh, way more.

204
00:10:15.720 --> 00:10:19.039
<v Speaker 1>The book calls it going from autocomplete to intelligent pair programming.

205
00:10:19.360 --> 00:10:23.799
<v Speaker 1>It works directly inside VS code, deeply integrated with GitHub.

206
00:10:23.399 --> 00:10:24.799
<v Speaker 2>And the productivity james are real.

207
00:10:25.080 --> 00:10:27.559
<v Speaker 1>They seem to be. We're talking ten to thirty percent

208
00:10:27.600 --> 00:10:31.720
<v Speaker 1>boosts generally, but some studies show developers finishing tasks thirty

209
00:10:32.000 --> 00:10:35.519
<v Speaker 1>even up to forty seven percent faster. Wow, that's significant,

210
00:10:35.759 --> 00:10:38.360
<v Speaker 1>it really is. Think about the example of adding that

211
00:10:38.440 --> 00:10:39.559
<v Speaker 1>O off to middleware.

212
00:10:39.639 --> 00:10:42.559
<v Speaker 2>Yeah, thirty three percent faster with copilot. Yeah, because it

213
00:10:42.639 --> 00:10:44.960
<v Speaker 2>suggested code helped with unit.

214
00:10:44.720 --> 00:10:50.039
<v Speaker 1>Tests exactly, instant code suggestions, scaffolding for tests. It saves

215
00:10:50.120 --> 00:10:53.720
<v Speaker 1>a ton of time, especially on repetitive or boilerplate tasks.

216
00:10:53.759 --> 00:10:56.679
<v Speaker 2>But it's not perfect, right, There must be pitfalls.

217
00:10:56.200 --> 00:11:00.279
<v Speaker 1>Oh definitely. The book is clear about the challenges AI

218
00:11:00.360 --> 00:11:04.000
<v Speaker 1>hallucinations where it just makes stuff up. Uh, security risks

219
00:11:04.039 --> 00:11:07.440
<v Speaker 1>if it suggests vulnerable code, and just the danger of

220
00:11:07.480 --> 00:11:10.279
<v Speaker 1>developers becoming overreliant not thinking critically.

221
00:11:10.440 --> 00:11:12.120
<v Speaker 2>So how do you manage that? You can't just let

222
00:11:12.159 --> 00:11:13.279
<v Speaker 2>the AI run wild?

223
00:11:13.399 --> 00:11:16.559
<v Speaker 1>No way, Yeah, best practices are crucial, always human the

224
00:11:16.600 --> 00:11:19.360
<v Speaker 1>loop reviews. People need to check the AI's work. Okay,

225
00:11:19.480 --> 00:11:21.799
<v Speaker 1>you need to write clear prompts to guide the AI,

226
00:11:22.200 --> 00:11:25.200
<v Speaker 1>and you absolutely integrate the AI generated code and tests

227
00:11:25.240 --> 00:11:28.679
<v Speaker 1>into your existing CI pipelines. Security tools still need to.

228
00:11:28.639 --> 00:11:31.679
<v Speaker 2>Scan everything, so it's augmentation not replacement.

229
00:11:31.840 --> 00:11:33.759
<v Speaker 1>Augmentation not application that's the key.

230
00:11:33.879 --> 00:11:36.600
<v Speaker 2>Okay, so unit tests. But let's talk about the really

231
00:11:36.639 --> 00:11:41.120
<v Speaker 2>thorny stuff, functional and integration testing, especially with micro services,

232
00:11:41.159 --> 00:11:43.000
<v Speaker 2>that's always been a huge bottleneck.

233
00:11:43.279 --> 00:11:46.480
<v Speaker 1>Huge, and this is where AI gets really interesting again.

234
00:11:46.919 --> 00:11:48.879
<v Speaker 1>Tools like functionize are mentioned.

235
00:11:48.919 --> 00:11:51.200
<v Speaker 2>Functionize what do they do differently?

236
00:11:51.279 --> 00:11:54.840
<v Speaker 1>They use AI to automatically generate functional and integration tests

237
00:11:55.200 --> 00:11:58.200
<v Speaker 1>just by watching how users actually interact with the application.

238
00:11:58.440 --> 00:11:59.840
<v Speaker 2>Okay, observing user flows.

239
00:12:00.519 --> 00:12:03.799
<v Speaker 1>But here's the really critical part. They can also self.

240
00:12:03.480 --> 00:12:06.120
<v Speaker 2>Heal the tests self heal, meaning.

241
00:12:05.879 --> 00:12:09.519
<v Speaker 1>Meaning if a minor UI element changes or a button

242
00:12:09.679 --> 00:12:12.799
<v Speaker 1>moves slightly, things that would normally break a traditional test script,

243
00:12:13.320 --> 00:12:15.600
<v Speaker 1>the AI adapts the test script automatically.

244
00:12:15.639 --> 00:12:19.679
<v Speaker 2>WHOA Okay, that tackles the massive test maintenance burden exactly.

245
00:12:20.000 --> 00:12:22.480
<v Speaker 1>That's often where teams spend most of their testing effort

246
00:12:22.679 --> 00:12:24.639
<v Speaker 1>just fixing broken tests.

247
00:12:25.039 --> 00:12:27.840
<v Speaker 2>The e commerce case study nailed this right. Sixty percent

248
00:12:27.879 --> 00:12:29.320
<v Speaker 2>reduction in test maintenance.

249
00:12:29.399 --> 00:12:32.679
<v Speaker 1>Yeah, a sixty percent drop, and they got better coverage

250
00:12:32.679 --> 00:12:36.600
<v Speaker 1>on critical paths like checkout. That directly speeds up feature

251
00:12:36.639 --> 00:12:38.639
<v Speaker 1>delivery because testing isn't such a drag anymore.

252
00:12:38.840 --> 00:12:43.440
<v Speaker 2>And looking even further ahead, the book mentions open AI operator.

253
00:12:43.799 --> 00:12:47.320
<v Speaker 1>Yeah, that's more experimental, but fascinating. It's an AI agent

254
00:12:47.360 --> 00:12:50.720
<v Speaker 1>that interacts with an app like a human would, literally

255
00:12:50.799 --> 00:12:53.559
<v Speaker 1>using a built in browser, so it looks at the page,

256
00:12:53.679 --> 00:12:57.759
<v Speaker 1>It interprets the page, visually, understands high level concepts. It

257
00:12:57.759 --> 00:13:01.600
<v Speaker 1>doesn't rely on fragile things like HTMs locators or specific

258
00:13:01.639 --> 00:13:05.519
<v Speaker 1>API end points, so it can adapt to changes much

259
00:13:05.519 --> 00:13:06.519
<v Speaker 1>more like a person would.

260
00:13:06.639 --> 00:13:08.879
<v Speaker 2>That's kind of mind blowing. It really feels like a

261
00:13:08.879 --> 00:13:11.080
<v Speaker 2>step towards true intelligent automation.

262
00:13:11.399 --> 00:13:14.679
<v Speaker 1>It does. It's early days, but the potential is huge.

263
00:13:14.799 --> 00:13:18.240
<v Speaker 2>Okay, so AI is helping write code, helping test code.

264
00:13:18.759 --> 00:13:21.240
<v Speaker 2>What about the infrastructure it all runs on? Can AI

265
00:13:21.360 --> 00:13:22.200
<v Speaker 2>manage that too?

266
00:13:22.440 --> 00:13:26.440
<v Speaker 1>Yes? Absolutely, generative AI is moving into infrastructure as code

267
00:13:26.679 --> 00:13:28.480
<v Speaker 1>iac and also data.

268
00:13:28.279 --> 00:13:30.519
<v Speaker 2>Provisioning, so it can write my terraform for me.

269
00:13:30.639 --> 00:13:32.799
<v Speaker 1>Pretty much. You give it a high level description. I

270
00:13:32.840 --> 00:13:35.519
<v Speaker 1>need a standard web server. Setup with these specs, and

271
00:13:35.559 --> 00:13:38.639
<v Speaker 1>it can generate the terraform or claudformation scripts. The book

272
00:13:38.679 --> 00:13:42.279
<v Speaker 1>suggests this can cut INFRA provisioning time by over sixty percent.

273
00:13:42.519 --> 00:13:45.320
<v Speaker 2>Sixty percent that's huge for standing up new environments.

274
00:13:45.559 --> 00:13:48.480
<v Speaker 1>It is, but it's not just about the initial setup, right.

275
00:13:48.679 --> 00:13:52.759
<v Speaker 2>What about keeping things running smoothly preventing those annoying configured

276
00:13:52.799 --> 00:13:54.240
<v Speaker 2>drifts or scaling issues.

277
00:13:54.320 --> 00:13:58.960
<v Speaker 1>That's the next level. AI enables predictive scaling. It analyzes

278
00:13:59.080 --> 00:14:03.159
<v Speaker 1>past usage pa terns and scales resources before the spy kits,

279
00:14:03.240 --> 00:14:03.799
<v Speaker 1>not after.

280
00:14:03.960 --> 00:14:05.759
<v Speaker 2>Proactive not reactive.

281
00:14:05.559 --> 00:14:11.799
<v Speaker 1>Nice and drift remediation. The AI constantly watches the live environment,

282
00:14:12.120 --> 00:14:14.360
<v Speaker 1>compares it to the IEC definition.

283
00:14:14.039 --> 00:14:18.440
<v Speaker 2>And if something's changed someone tweaked a setting manually.

284
00:14:18.240 --> 00:14:21.240
<v Speaker 1>It can either flag it for review or even automatically

285
00:14:21.240 --> 00:14:22.799
<v Speaker 1>correct it to bring it back in line with the

286
00:14:22.799 --> 00:14:27.320
<v Speaker 1>code definition. Viral highlights how this ensures compliance without constant

287
00:14:27.320 --> 00:14:30.600
<v Speaker 1>manual checks. It's like having an automated compliance officer.

288
00:14:30.720 --> 00:14:34.399
<v Speaker 2>That fintech startup example sounded great. Faster environment spin up

289
00:14:34.440 --> 00:14:37.559
<v Speaker 2>and better PCI compliance through automated data masking.

290
00:14:37.720 --> 00:14:40.000
<v Speaker 1>Right. It freeze up the ops team from that reactive

291
00:14:40.000 --> 00:14:42.480
<v Speaker 1>firefighting to think more strategically.

292
00:14:42.000 --> 00:14:44.440
<v Speaker 2>Which brings us to this stay in the flow idea.

293
00:14:44.720 --> 00:14:45.480
<v Speaker 2>What's that about.

294
00:14:45.639 --> 00:14:48.799
<v Speaker 1>It's about bringing these capabilities directly into the developers or

295
00:14:48.840 --> 00:14:52.080
<v Speaker 1>operator's main workspace, usually their ide like vs code.

296
00:14:52.200 --> 00:14:54.919
<v Speaker 2>So instead of switching tools, you just talk to the

297
00:14:54.960 --> 00:14:55.799
<v Speaker 2>AI essentially.

298
00:14:55.840 --> 00:14:59.440
<v Speaker 1>Yeah. Using natural language processing and LP, you could type

299
00:14:59.440 --> 00:15:03.559
<v Speaker 1>something like create a masked copy of production data for

300
00:15:03.600 --> 00:15:07.000
<v Speaker 1>this staging environment, okay, or generate terraform for a new

301
00:15:07.000 --> 00:15:10.279
<v Speaker 1>micro service based on our standard template. The AI figures

302
00:15:10.279 --> 00:15:12.919
<v Speaker 1>it out, proposes the scripts or actions, and.

303
00:15:12.919 --> 00:15:15.279
<v Speaker 2>You review it right there, maybe in a pool request.

304
00:15:15.120 --> 00:15:19.039
<v Speaker 1>Exactly, all without leaving your development context. It removes that friction,

305
00:15:19.200 --> 00:15:20.559
<v Speaker 1>keeps you focused. Okay.

306
00:15:20.639 --> 00:15:25.720
<v Speaker 2>That sounds incredibly powerful. So finally, the CICD pipeline itself

307
00:15:26.000 --> 00:15:30.279
<v Speaker 2>the heart of DevOps. How does AI make the pipeline smarter?

308
00:15:30.879 --> 00:15:34.799
<v Speaker 1>Several ways? One big one is optimizing the pipeline run itself.

309
00:15:35.519 --> 00:15:37.279
<v Speaker 1>AI can do intelligent test.

310
00:15:37.240 --> 00:15:40.240
<v Speaker 2>Selection, meaning it doesn't just run all the tests every

311
00:15:40.240 --> 00:15:41.080
<v Speaker 2>single time, right.

312
00:15:41.120 --> 00:15:44.080
<v Speaker 1>It analyzes the specific code changes in a commit and

313
00:15:44.159 --> 00:15:47.200
<v Speaker 1>figures out which subset of tests are actually relevant to run.

314
00:15:47.279 --> 00:15:49.279
<v Speaker 2>That could save a lot of time, especially on big

315
00:15:49.320 --> 00:15:50.000
<v Speaker 2>test suites.

316
00:15:50.279 --> 00:15:53.279
<v Speaker 1>Huge amounts that e commerce company, example, they cut their

317
00:15:53.320 --> 00:15:55.799
<v Speaker 1>forty minute pipeline runs down to twenty minutes just with this.

318
00:15:56.200 --> 00:15:59.360
<v Speaker 2>Wow half the time. That massively speeds up the feedback

319
00:15:59.399 --> 00:16:00.399
<v Speaker 2>loop for developopers.

320
00:16:00.440 --> 00:16:04.080
<v Speaker 1>Instantly they know much faster if their change broke something.

321
00:16:04.519 --> 00:16:07.960
<v Speaker 1>And when feedback is that fast, developers feel more confident

322
00:16:08.039 --> 00:16:09.960
<v Speaker 1>making smaller, more frequent changes.

323
00:16:10.080 --> 00:16:11.399
<v Speaker 2>It changes the whole dynamic.

324
00:16:11.679 --> 00:16:14.879
<v Speaker 1>It really does. And it goes further with predictive failure

325
00:16:14.919 --> 00:16:16.159
<v Speaker 1>analysis and remediation.

326
00:16:16.440 --> 00:16:17.200
<v Speaker 2>Okay, what's that.

327
00:16:17.600 --> 00:16:20.480
<v Speaker 1>The AI is watching the pipeline run in real time

328
00:16:20.679 --> 00:16:24.480
<v Speaker 1>logs metrics. It can spot anomalies that suggest a test

329
00:16:24.559 --> 00:16:27.840
<v Speaker 1>might be flaky or a build environment is misconfigured, and

330
00:16:27.879 --> 00:16:31.120
<v Speaker 1>then it might automatically retry a step or even apply

331
00:16:31.159 --> 00:16:34.120
<v Speaker 1>a known fix. It can also get smarter about deployments.

332
00:16:34.320 --> 00:16:37.440
<v Speaker 1>How So, based on the risk profile of the code change,

333
00:16:37.559 --> 00:16:40.159
<v Speaker 1>how big it is, what areas it touches, the AI

334
00:16:40.320 --> 00:16:43.759
<v Speaker 1>could dynamically choose the best deployment strategy, maybe a slow

335
00:16:43.799 --> 00:16:46.720
<v Speaker 1>canary release for a risky change, or a faster rolling

336
00:16:46.799 --> 00:16:47.840
<v Speaker 1>update for something simple.

337
00:16:47.879 --> 00:16:49.919
<v Speaker 2>And it watches the deployment, watches.

338
00:16:49.600 --> 00:16:52.759
<v Speaker 1>The real time telemetry. If it sees aerror rate spike

339
00:16:53.000 --> 00:16:56.480
<v Speaker 1>or performance tank. It can trigger an automatic rollback.

340
00:16:56.200 --> 00:16:59.559
<v Speaker 2>So the pipeline becomes truly adaptive, not just the dumb

341
00:16:59.600 --> 00:17:00.600
<v Speaker 2>script runner.

342
00:17:00.559 --> 00:17:03.559
<v Speaker 1>Exactly intelligent, adaptive self healing.

343
00:17:03.720 --> 00:17:05.960
<v Speaker 2>And this also ties into stay in the flow.

344
00:17:06.079 --> 00:17:09.400
<v Speaker 1>Yes, a developer could be in their ID and type

345
00:17:09.559 --> 00:17:12.680
<v Speaker 1>deploy this branch to Canary with ten percent traffic, watch

346
00:17:12.720 --> 00:17:14.119
<v Speaker 1>for anomalies.

347
00:17:13.960 --> 00:17:17.720
<v Speaker 2>And AI just handles it, triggers the right pipeline monitors,

348
00:17:17.759 --> 00:17:19.000
<v Speaker 2>it gives feedback.

349
00:17:19.359 --> 00:17:23.240
<v Speaker 1>That's the vision. The AI interprets the intent, orchestrates the

350
00:17:23.279 --> 00:17:27.720
<v Speaker 1>actions and reports back, maybe even suggesting a rollback if needed.

351
00:17:28.160 --> 00:17:32.680
<v Speaker 1>It's this frictionless pipeline guided by human intent but executed

352
00:17:32.759 --> 00:17:35.400
<v Speaker 1>largely by AI. That's the core of NUOPS. According to

353
00:17:35.440 --> 00:17:36.000
<v Speaker 1>the book.

354
00:17:35.880 --> 00:17:39.480
<v Speaker 2>Wow, that final section in part two, Catalyst to Autonomy,

355
00:17:39.880 --> 00:17:41.799
<v Speaker 2>really paints a picture of it all coming together.

356
00:17:41.839 --> 00:17:45.240
<v Speaker 1>It does an AI first paved road, copilot and VS

357
00:17:45.279 --> 00:17:48.160
<v Speaker 1>code helping write the code functionize I as creating and

358
00:17:48.200 --> 00:17:51.599
<v Speaker 1>healing the tests, AI agents managing the infrastructure via.

359
00:17:51.440 --> 00:17:53.799
<v Speaker 2>IAC and all the data feeding back.

360
00:17:53.599 --> 00:17:56.559
<v Speaker 1>Every suggestion, every healed test, every drift correction, tagged and

361
00:17:56.559 --> 00:18:00.559
<v Speaker 1>streamed into that unified analytics platform like opsrac iktives get

362
00:18:00.559 --> 00:18:03.599
<v Speaker 1>real time visibility into velocity, quality.

363
00:18:03.119 --> 00:18:06.160
<v Speaker 2>Cost savings, and security gets pushed even further left.

364
00:18:06.119 --> 00:18:09.279
<v Speaker 1>Right to the keyboard. Essentially, issues blocked by copilot or

365
00:18:09.440 --> 00:18:12.480
<v Speaker 1>caught by automated security in the pipeline ideally never even

366
00:18:12.519 --> 00:18:15.839
<v Speaker 1>make it close to production. That's a massive security posture

367
00:18:15.839 --> 00:18:17.319
<v Speaker 1>improvement outro.

368
00:18:17.519 --> 00:18:22.799
<v Speaker 2>What an incredible journey really from that fragmented, often frustrating

369
00:18:22.839 --> 00:18:30.079
<v Speaker 2>world of traditional DevOps to this potential future driven by standardization, cloud,

370
00:18:30.160 --> 00:18:34.440
<v Speaker 2>native thinking, and wow, generative AI creating real autonomy.

371
00:18:34.519 --> 00:18:37.960
<v Speaker 1>It really feels like we're on the cusp of transforming

372
00:18:38.039 --> 00:18:41.640
<v Speaker 1>all that repetitive toil and software delivery into something much

373
00:18:41.640 --> 00:18:43.519
<v Speaker 1>more intelligent, almost self managing.

374
00:18:43.759 --> 00:18:46.359
<v Speaker 2>Yeah. But the key takeaway, it seems, isn't that humans

375
00:18:46.359 --> 00:18:47.119
<v Speaker 2>become obsolete?

376
00:18:47.200 --> 00:18:50.680
<v Speaker 1>Right, Not at all. The book really emphasizes this as

377
00:18:50.720 --> 00:18:54.480
<v Speaker 1>AI takes on the drudgery the human role shifts. It

378
00:18:54.599 --> 00:18:57.880
<v Speaker 1>elevates to what to higher level design, to strategy, to

379
00:18:58.039 --> 00:19:00.960
<v Speaker 1>focusing on the next innovation, not just the current lights on.

380
00:19:01.279 --> 00:19:04.039
<v Speaker 1>It's about freeing up human potential, and of course there's

381
00:19:04.039 --> 00:19:05.519
<v Speaker 1>always more to learn as this tech.

382
00:19:05.359 --> 00:19:09.759
<v Speaker 2>Of all so fast, absolutely so for everyone listening, what

383
00:19:09.839 --> 00:19:12.599
<v Speaker 2>does this all mean for your role? How can you

384
00:19:12.680 --> 00:19:16.839
<v Speaker 2>start thinking about embedding AI, making it like muscle memory

385
00:19:17.359 --> 00:19:18.519
<v Speaker 2>in your team or org.

386
00:19:18.599 --> 00:19:20.799
<v Speaker 1>How do you get from that burnout cycle to maybe

387
00:19:20.839 --> 00:19:23.720
<v Speaker 1>build chip and wonder, wonder what's next exactly.

388
00:19:24.240 --> 00:19:28.000
<v Speaker 2>We really encourage you to explore these ideas, maybe pick

389
00:19:28.079 --> 00:19:31.480
<v Speaker 2>up Vorl's book and just identify one or two places

390
00:19:31.480 --> 00:19:33.880
<v Speaker 2>where AI could start elevating your daily work.

391
00:19:34.079 --> 00:19:35.599
<v Speaker 1>Start small, build momentum.

392
00:19:35.720 --> 00:19:38.000
<v Speaker 2>Yeah, well, thank you so much for joining us on

393
00:19:38.039 --> 00:19:40.240
<v Speaker 2>this deep dive into the future of software development.

394
00:19:40.279 --> 00:19:40.799
<v Speaker 1>My pleasure.

395
00:19:40.880 --> 00:19:43.799
<v Speaker 2>We hope this exploration empowers you, gives you some ideas,

396
00:19:43.960 --> 00:19:47.119
<v Speaker 2>and helps you pave your own road towards a more autonomous, efficient,

397
00:19:47.160 --> 00:19:48.880
<v Speaker 2>and ultimately more innovative future.