1
00:00:14,279 --> 00:00:19,320
Us going on. Everyone, Welcome
to another episode of Adventures in dev Ops.

2
00:00:19,559 --> 00:00:23,239
I'm your host for today, Will
Button joining me in the studio my

3
00:00:23,399 --> 00:00:28,239
co host back for what is this
episode number three? Warren, let's call

4
00:00:28,280 --> 00:00:31,600
it three. We'll call it three. Yeah, right on. I'm excited.

5
00:00:31,640 --> 00:00:36,359
It's starting to look like a trend
here. Yeah. You know,

6
00:00:36,359 --> 00:00:40,719
I'm Warren at CTO at Authors.
Thanks for inviting me on. I know

7
00:00:40,799 --> 00:00:45,759
I said I promised just one or
two episodes, so you know, I

8
00:00:45,759 --> 00:00:49,880
think this trend is going in a
good direction, and I hopefully will be

9
00:00:49,960 --> 00:00:53,840
on future ones as well. Cool. I hope so, because I'm enjoying

10
00:00:53,960 --> 00:00:58,920
having you here on the show and
joining us. Also in the studio today

11
00:00:59,560 --> 00:01:07,599
we have the DevOps app activist from
Dina Trace, the Cloud Native Compute Foundation

12
00:01:07,840 --> 00:01:15,840
ambassador and host of the Pure Performance
podcast. And I can validate this because

13
00:01:15,879 --> 00:01:19,159
if you're not familiar with the podcasting
industry, there is actually a secret handshake

14
00:01:21,000 --> 00:01:25,159
used by all podcasts hosts around the
world. And I did validate this,

15
00:01:25,239 --> 00:01:32,040
so I can confirm that this is
actually the legit non chat GPT. Andy

16
00:01:32,079 --> 00:01:36,319
Grabner joining us on the show.
Welcome, Andy, Thank you so much

17
00:01:36,319 --> 00:01:40,319
for having me I know that AI
technology is pretty good already, but I'm

18
00:01:40,359 --> 00:01:46,680
not sure if they if they can
simulate my accent. Yeah right, And

19
00:01:46,760 --> 00:01:49,239
if you're joining us on the livestream, you can actually see Andy as well

20
00:01:49,280 --> 00:01:55,400
as Warren and myself, and we
can do the test as well to show

21
00:01:55,439 --> 00:02:00,760
that it's a real legitimate background not
behind not just an artificial background behind us.

22
00:02:00,040 --> 00:02:06,560
My my leads move here. Yeah, I can walk behind my kitchen

23
00:02:06,560 --> 00:02:08,599
counter, but I need to take
off my headset quickly and I'll show you

24
00:02:09,520 --> 00:02:20,879
right, Yeah, same thing.
There you go. Perfect successful test can

25
00:02:20,919 --> 00:02:24,479
confirm that we are not a robot. Cool. So welcome to the show.

26
00:02:24,560 --> 00:02:30,840
So you've been doing the Pure Performance
podcast for seven years? Is that

27
00:02:30,919 --> 00:02:36,560
right? Yeah? I think it's
about seven years, even maybe almost close

28
00:02:36,599 --> 00:02:40,080
to eight years. We had last
week I believe it was the two hundred

29
00:02:40,080 --> 00:02:45,800
and first episode. Oh nice you
have released. Yeah, and yeah,

30
00:02:45,840 --> 00:02:49,759
it's been. It's been exciting and
it's been if you look back, it's

31
00:02:49,759 --> 00:02:53,879
actually quite astonishing that we've been doing
this for that long. And with we,

32
00:02:53,439 --> 00:02:57,960
I also mean Brian Wilson, my
Cobles them myself, so Brian,

33
00:02:58,199 --> 00:03:02,560
it's not here today, but yeah, thanks Brian, Right, so for

34
00:03:02,599 --> 00:03:07,800
anyone who's not familiar with your podcast, give us the short summary of what

35
00:03:07,840 --> 00:03:12,680
you talk about on there. Yeah, So we initially started it because both

36
00:03:12,719 --> 00:03:19,039
Brian and I we've been in the
performance engineering space for twenty plus years now.

37
00:03:19,120 --> 00:03:22,520
It's been a long long time we've
both worked at Dana Trace. Even

38
00:03:22,560 --> 00:03:24,879
though the podcast is not related to
the product or the services we sell,

39
00:03:24,919 --> 00:03:29,199
but it's basically based on our experience
and what we see out there. So

40
00:03:29,240 --> 00:03:32,639
we started initially to talk about what
are the performance problems that we see in

41
00:03:32,759 --> 00:03:38,680
modern day applications. You know,
why are applications crashing, why are applications

42
00:03:38,680 --> 00:03:42,159
slow? What are the most common
things that we see. How can we

43
00:03:42,319 --> 00:03:46,599
educate our listeners which we initially thought
of mainly developers and our and performance testers.

44
00:03:46,919 --> 00:03:51,560
What can we teach them? But
over the seven years things have changed,

45
00:03:51,759 --> 00:03:57,800
and because our fields of topics has
changed and evolved, and we moved

46
00:03:57,840 --> 00:04:03,680
from performance engineering to develops, to
cloud native to kubernatives, to platform engineering.

47
00:04:04,240 --> 00:04:08,639
We covered a lot of range of
topics and we also had over the

48
00:04:08,719 --> 00:04:13,120
years many interesting guests, a lot
of practitioners also people that you see on

49
00:04:13,159 --> 00:04:16,560
big stage in the IT So,
yeah, it's been quite interesting and I

50
00:04:16,600 --> 00:04:21,160
think a broad range of topics and
hopefully there's something in there for everyone.

51
00:04:23,800 --> 00:04:34,040
Right on, So you mentioned that
you said your podcast audience initially was performance

52
00:04:34,079 --> 00:04:39,839
specialists and practitioners, and you've seen
that change over the years. Yeah,

53
00:04:40,000 --> 00:04:43,839
because also we changed, right and
with we I me and Brian and I

54
00:04:44,120 --> 00:04:47,120
we have changed. And the reason
why we changed is because obviously we you

55
00:04:47,160 --> 00:04:50,600
know, day in and day out, we deal and we work with our

56
00:04:50,639 --> 00:04:57,680
community that's the dial traized community,
the opstability community. And because our product

57
00:04:58,319 --> 00:05:02,600
and capabilities have evolved, so have
the people we interact with. They've changed,

58
00:05:03,439 --> 00:05:09,160
and we see nowadays more and more
you know, enterprise architects, We

59
00:05:09,199 --> 00:05:13,480
see cloud architects, We see people
that are responsible for big Kubernators clusters.

60
00:05:14,439 --> 00:05:17,439
We see people that are very heavily
engaged in the CNCF community like I am

61
00:05:17,480 --> 00:05:21,040
in the Cloud Native Computing Foundation community. So we're inviting a lot of kind

62
00:05:21,040 --> 00:05:28,000
of my counterparts to the podcast and
discuss topics that are relevant in the Cloud

63
00:05:28,079 --> 00:05:31,439
Native ecosystem. And so yeah,
that's why it has changed. But we

64
00:05:31,480 --> 00:05:35,920
always try to come back and kind
of relate it to performance because in the

65
00:05:36,040 --> 00:05:41,079
end, we all want to make
sure that we help the global community to

66
00:05:41,160 --> 00:05:46,199
build performance and resilient systems. What
was new eight years ago? Like,

67
00:05:46,240 --> 00:05:53,399
what was the topic of conversation that
what was performance important? You know,

68
00:05:53,759 --> 00:05:58,079
what were you talking about back then? I think episode number one, two

69
00:05:58,160 --> 00:06:01,279
and three, or at least the
first handful. I believe we're all focusing

70
00:06:01,319 --> 00:06:06,720
on what are the top performance problems
in Java and dot net applications because these

71
00:06:06,759 --> 00:06:13,519
were kind of like the two predominant
technologies we were still dealing with, right

72
00:06:13,519 --> 00:06:16,240
and we still are seeing a lot
of Java dot Net, And because Brian

73
00:06:16,319 --> 00:06:19,360
and I were doing a lot of
load and performance testing and a lot of

74
00:06:19,720 --> 00:06:25,839
performance analysis on these type of applications, we said, let's discuss what are

75
00:06:25,879 --> 00:06:29,680
the key top the key things we
find in applications in Java and dot net

76
00:06:29,720 --> 00:06:33,839
applications that make applications fail crash,
be slow and talk about it and educate

77
00:06:34,279 --> 00:06:40,920
our listeners. So you have a
secret love for the CLR, then yeah,

78
00:06:40,959 --> 00:06:46,199
I would. Maybe the word love
doesn't come to mind as a birthday

79
00:06:45,120 --> 00:06:51,399
sure, yeah, But I mean
the interesting thing is, right, it's

80
00:06:51,800 --> 00:06:57,240
in the end, everything we discussed
and all the patents we found, Let's

81
00:06:57,240 --> 00:07:02,199
say most of them are not limited
to a round time. Well, let's

82
00:07:02,199 --> 00:07:08,560
say you only see certain patterns in
Java or dot net, because patterns are

83
00:07:08,600 --> 00:07:14,079
patterns, and they happen whether you
are developing. We just did an episode

84
00:07:14,079 --> 00:07:17,199
recording that I think will come out
next week on mainframe, right, so

85
00:07:17,240 --> 00:07:23,319
we also cover mainframe, and we
see similar patterns that lead to problematic software

86
00:07:23,720 --> 00:07:28,519
in the mainframe versus Java, dot
Net, and now going all the way

87
00:07:28,560 --> 00:07:33,800
forward, things we see in the
highly distributed world of kubernets. So same

88
00:07:33,800 --> 00:07:39,759
patterns. I want to ask about
that real quick because one of the patterns

89
00:07:39,759 --> 00:07:49,399
I've seen throughout my career is a
tendency to blame the stack for performance issues.

90
00:07:49,560 --> 00:07:56,199
Like a really common one is,
oh, we wrote this in Java,

91
00:07:56,279 --> 00:08:00,360
but that's not performance, so we're
moving to dot net or you know,

92
00:08:00,480 --> 00:08:07,600
insert any other any other technology you
want in there. You have you

93
00:08:07,680 --> 00:08:15,480
seen that? Yeah, I mean
the easiest for humans is to blame somebody

94
00:08:15,560 --> 00:08:18,959
else, right, And the reason
why that is, I believe is because

95
00:08:20,079 --> 00:08:22,639
we as an industry, I think
we try to make it as easy as

96
00:08:22,680 --> 00:08:28,720
possible for engineers to write code.
And easy means we are abstracting things away.

97
00:08:28,839 --> 00:08:33,320
We're abstracting the complexity a way.
And therefore, when you abstract things

98
00:08:33,360 --> 00:08:37,840
away, you allow people to build
things very fast in a generic way,

99
00:08:39,240 --> 00:08:43,279
but not optimized or optimizable for the
specific use case. And so when people

100
00:08:43,320 --> 00:08:48,120
say this would be fifty times faster, or if I moved to random x

101
00:08:48,279 --> 00:08:52,960
or y, then I would argue
that this would only be This is only

102
00:08:52,960 --> 00:08:58,039
true if you actually change the implementation
underneath, right, if you are using

103
00:08:58,919 --> 00:09:01,960
you know, if you if you're
replacing the Hibernate with the A Development Entity

104
00:09:03,000 --> 00:09:07,120
framework, you will still run into
the same problem because these are all very

105
00:09:07,159 --> 00:09:09,840
generic frameworks. But if you don't
use them and optimize them for your use

106
00:09:09,879 --> 00:09:15,159
case, you will still end up
with the n plus onequibit problem capturing and

107
00:09:15,159 --> 00:09:18,279
fetching too much data that can gets
into memory that again gets filtered in Parston

108
00:09:18,360 --> 00:09:24,080
memory, which leads to too much
memory usage, high garbage collection, high

109
00:09:24,080 --> 00:09:28,480
CPU bad performance. So my answer
to this is, if you want to

110
00:09:28,519 --> 00:09:33,759
build really high performance applications, you
need to understand what's actually happening in your

111
00:09:33,799 --> 00:09:37,480
stack. Right, How you know
what type of data do you need,

112
00:09:37,519 --> 00:09:39,000
where you get the data from,
how do you get inefficientcy what type of

113
00:09:39,039 --> 00:09:43,679
data do you even need because the
otherwise you will end up with the same

114
00:09:45,159 --> 00:09:48,559
problem in any run time. It
doesn't matter. Yeah, the best case,

115
00:09:48,720 --> 00:09:52,159
even if it does fix whatever hypothetical
problem you have at that moment,

116
00:09:52,200 --> 00:09:56,720
you're probably just creating a whole bunch
of other ones that are not seen because

117
00:09:56,759 --> 00:09:58,480
of the swage, right, Yeah, yeah, I agree with you.

118
00:09:58,559 --> 00:10:03,720
And you know, I think we
are living in an interesting situation with now.

119
00:10:03,799 --> 00:10:07,279
When I kind of grew up,
sounds like strange. When I went

120
00:10:09,080 --> 00:10:13,600
and I got educated on software engineering. I started in high school. I

121
00:10:13,639 --> 00:10:16,679
was lucky enough to have an education
system here where one of our local high

122
00:10:16,679 --> 00:10:22,919
school was specialized in software engineering.
And we learned assembler, we learned see,

123
00:10:22,080 --> 00:10:26,320
we learned the core, and then
we we learned like how to move

124
00:10:26,440 --> 00:10:31,519
bits around and and you know,
and how to how to manage memory yourself

125
00:10:33,159 --> 00:10:39,559
and and these are traits now that
that I think are probably I'm not sure

126
00:10:39,600 --> 00:10:43,120
if they're still taught, but I
think the necessity of if somebody comes in

127
00:10:43,279 --> 00:10:46,360
new and wants to become a software
engineer, especially because of such a high

128
00:10:46,360 --> 00:10:50,320
demand, I will probably not start
with the assembler. I probably won't start

129
00:10:50,399 --> 00:10:56,200
with with managing my memory myself.
But I will start with a higher abstraction

130
00:10:56,960 --> 00:11:01,440
because I want to be productive.
I want to contrue you, and with

131
00:11:01,559 --> 00:11:07,799
that it means that you know,
I may miss things and I do things

132
00:11:07,840 --> 00:11:11,120
that later on will lead into a
problem because I don't know the underlying stake

133
00:11:11,159 --> 00:11:16,679
and what's really happening. I've seen
the problem go the other way though,

134
00:11:16,720 --> 00:11:22,600
right, like starting to play directly
with threads or whatever the underlying is because

135
00:11:22,639 --> 00:11:24,399
you think you can do it better. And maybe today it is true,

136
00:11:24,519 --> 00:11:30,240
especially in some larger organizations, But
then the industry or open source or whatever

137
00:11:30,279 --> 00:11:33,120
the language you're using framework of choice
evolves over time and comes up with a

138
00:11:33,200 --> 00:11:37,440
much better agreed upon strategy than whatever
you're using. You must have seen that

139
00:11:37,480 --> 00:11:43,919
as well. Yeah, I agree
with you, And I mean trading is

140
00:11:43,960 --> 00:11:48,360
another perfect example, right, I
mean that's in many horror horror stories or

141
00:11:48,480 --> 00:11:52,360
problematic source. And by the way, I don't want to make the impressional

142
00:11:52,399 --> 00:11:56,600
gift impression that I know how to
really in the highly efficient code. I've

143
00:11:56,639 --> 00:12:01,519
just seen many examples from other people
that have built it, and I could

144
00:12:01,559 --> 00:12:05,559
help them identify those issues. So
if you listen to this, don't hire

145
00:12:05,600 --> 00:12:11,039
me to build that system. When
you say when you just you know,

146
00:12:11,080 --> 00:12:15,240
everyone's on the same page, when
you say you know performance or high performance,

147
00:12:15,759 --> 00:12:18,639
are there sort of numbers that go
along with that that give us a

148
00:12:18,720 --> 00:12:20,879
good viewpoint into what that actually looks
like. You know, this can be

149
00:12:20,960 --> 00:12:28,759
anything from systems that can handle i
don't know, thousands or millions requests per

150
00:12:28,519 --> 00:12:33,360
per minute, per hour, highly
highly transaction volume. But this can also

151
00:12:33,440 --> 00:12:39,399
mean systems that have lower transaction volume, but that need to process terabytes of

152
00:12:39,440 --> 00:12:43,200
data. You know, patch processes
if you think about it, and patch

153
00:12:43,279 --> 00:12:48,279
processes have to finish in a certain
time because otherwise you may run out of

154
00:12:46,879 --> 00:12:52,120
a window of opportunity. Or there's
even regulations where like especially in the finance

155
00:12:52,159 --> 00:12:54,799
and the energy sector. Right now, I've just worked with the cloud client

156
00:12:54,840 --> 00:13:00,320
there. They have to finish processing
all of their transactions, do it in

157
00:13:00,320 --> 00:13:03,679
the patch at a certain time because
otherwise they're not allowed to trade the next

158
00:13:03,720 --> 00:13:07,200
day. And so this is this
also this this may mean they don't have

159
00:13:07,639 --> 00:13:13,360
let's say millions of transactions, but
they have transactions that are bigger in data

160
00:13:13,399 --> 00:13:18,519
that needs to be processed and validated, and you know, external systems need

161
00:13:18,559 --> 00:13:26,799
to be contacted and updated so highly
performance systems really means whether you can deliver

162
00:13:26,360 --> 00:13:31,960
what your end users are expecting from
your system. And end users can be

163
00:13:31,000 --> 00:13:35,240
real users that try to book an
online ticket at a show that is highly

164
00:13:35,240 --> 00:13:39,720
on demand, or it can be
you know, other systems that call an

165
00:13:39,759 --> 00:13:43,879
API and expect when they call you
API that it will deliver the result in

166
00:13:43,919 --> 00:13:48,039
a certain amount of time, and
that time could be seconds, but it

167
00:13:48,080 --> 00:13:50,679
could also be you know, maybe
an hour. But this is certain expectation

168
00:13:50,759 --> 00:13:56,240
to a system. You triggered my
curiosity there with the regulation, like there

169
00:13:56,320 --> 00:14:01,120
must be different observability importance that happen
in as something like that, where it's

170
00:14:01,120 --> 00:14:05,360
not about necessarily the reliability of individual
pieces or requests that come in, but

171
00:14:05,480 --> 00:14:09,559
over the whole data set. Like, that's not a world that's really familiar

172
00:14:09,559 --> 00:14:13,000
with me. So any insight you
got there it would be super interesting.

173
00:14:13,679 --> 00:14:16,440
Yeah. I mean, the one
thing that comes to mind here, it's

174
00:14:16,480 --> 00:14:22,559
really we talk about data integrity obviously, right, I mean from an obstability

175
00:14:22,600 --> 00:14:26,159
perspective, if it's not just that
the indust as you said, individual pieces

176
00:14:26,159 --> 00:14:31,279
of code that get executed to do
certain things work, you know, I

177
00:14:31,279 --> 00:14:33,480
mean, obviously they should work reliably
but in the end, the ends to

178
00:14:33,559 --> 00:14:37,799
end business process needs to produce a
result. So, for instance, a

179
00:14:37,039 --> 00:14:41,639
very simple example, if I would
wire you money, then I want to

180
00:14:41,639 --> 00:14:45,799
make sure that if I wire you
money and it goes through, it ends

181
00:14:45,840 --> 00:14:54,279
upon your bank account. If something
great, If for whatever reason you know,

182
00:14:54,799 --> 00:14:58,440
something happens in the middle and something
crashes, that the money doesn't just

183
00:14:58,559 --> 00:15:03,399
end up some where in a random
account. So I think this is also

184
00:15:03,480 --> 00:15:09,639
very important that we think about end
data pipeline observability. This is another big

185
00:15:09,679 --> 00:15:16,120
topic business process monitoring. There's different
terms I think for these things, but

186
00:15:16,159 --> 00:15:20,080
in the end, you want to
make sure that whatever you do, you

187
00:15:20,279 --> 00:15:24,080
end up with the results that you
expect, and that proper resiliency and proper

188
00:15:24,159 --> 00:15:26,240
error handling is taken care of,
and at the end the data on both

189
00:15:26,240 --> 00:15:33,120
sides of the system is valid and
accurate. Makes sense. So you mentioned

190
00:15:33,120 --> 00:15:41,840
that some of your listeners are architects, and it sounds like some of the

191
00:15:41,879 --> 00:15:52,600
performance conversation has been shifted from reactionary
to to further up in the design process.

192
00:15:54,879 --> 00:16:00,360
How do you define or what are
your thumb rules for design finding a

193
00:16:00,399 --> 00:16:07,600
performance application without getting into premature optimization. It's a good one, and then

194
00:16:07,639 --> 00:16:18,279
Wren is smiling. So I think
what I learned, and I remember what

195
00:16:18,320 --> 00:16:21,000
I said earlier. When I went
to high school, I was educated as

196
00:16:21,000 --> 00:16:26,279
a software engineer, and we were
never educated unfortunately back then, to think

197
00:16:26,320 --> 00:16:32,440
about how to measure and observe if
my software is actually doing what it's supposed

198
00:16:32,440 --> 00:16:36,759
to do, because it was in
the mid nineties and sure be road log

199
00:16:36,799 --> 00:16:41,679
files, but we didn't never think
about metrics and traces nowadays and things like

200
00:16:41,720 --> 00:16:47,000
that. So what I can advertise
now or advocate for, and what I

201
00:16:47,080 --> 00:16:55,159
see is observability as a requirement,
obserability driven development, which means if I'm

202
00:16:55,159 --> 00:16:57,000
building a new service, if I'm
building a new app, if I'm building

203
00:16:57,000 --> 00:17:02,279
a new function, whatever it is, I should not only care about what

204
00:17:02,360 --> 00:17:07,039
this function does, but also how
I can validate and measure where the function,

205
00:17:07,400 --> 00:17:15,160
you know, execute in the expected
time with the expected resiliency. So

206
00:17:15,240 --> 00:17:18,559
that means what happens if something,
if if my dependencies fail, how do

207
00:17:18,559 --> 00:17:23,839
I react. So it's really about
thinking with observability as a non functional requirement

208
00:17:25,880 --> 00:17:30,519
and because first of all, it
helps me as an as an engineer too

209
00:17:30,559 --> 00:17:33,079
later on validate that my stuff actually
works. Is expect that it helps me

210
00:17:33,119 --> 00:17:37,400
if something doesn't work as expected,
that I can troubleshoot if I have the

211
00:17:37,480 --> 00:17:41,440
logs that traces the metrics that the
need. But it also helps me to

212
00:17:41,640 --> 00:17:45,240
justify my work because if somebody comes
to me and say, Andy, we

213
00:17:45,400 --> 00:17:49,160
need a new social media platform.
Right, we have already too many of

214
00:17:49,200 --> 00:17:53,640
them. But let's say social media
platform, and what's the measure of success.

215
00:17:53,680 --> 00:17:56,960
How do we, you know,
differentiate ourselves with the others that are

216
00:17:56,960 --> 00:18:00,920
out there. So we want to
have some metrics, and one could be

217
00:18:02,200 --> 00:18:07,200
better user experience, faster posting,
easier API, so that others can integrate

218
00:18:07,240 --> 00:18:10,680
better with my social media platform.
And then I need to say, if

219
00:18:10,720 --> 00:18:15,000
I'm developing it, I also want
to make sure we can measure that the

220
00:18:15,000 --> 00:18:19,319
system is really used. And the
hypothesis that we have that our system will

221
00:18:19,359 --> 00:18:25,279
be adopted better because we are faster
and more resilient, it's actually, you

222
00:18:25,319 --> 00:18:30,519
know, the hypothesis works. And
so what I see now more and more

223
00:18:30,640 --> 00:18:34,960
is this, you know, pushing
observability into the minds of architects, of

224
00:18:36,039 --> 00:18:41,440
developers early on, of people that
build frameworks, of people that build new

225
00:18:41,480 --> 00:18:45,440
libraries. That observability is baked in
and not an afterthought. I think that's

226
00:18:45,519 --> 00:18:52,039
very important. Yeah, for sure. I've spent many decades at this point

227
00:18:52,279 --> 00:18:57,559
working in early stage startups, and
I think that's been one of the most

228
00:18:57,720 --> 00:19:02,880
critical mistakes in a lot of the
startups I've been involved with, is failing

229
00:19:02,920 --> 00:19:07,440
to define what I call it the
success criteria. So you build this product

230
00:19:07,440 --> 00:19:11,880
and you launch it, but then
you don't have this definition of success to

231
00:19:12,000 --> 00:19:21,000
tell you that your product is being
being consumed, utilized, and implemented the

232
00:19:21,000 --> 00:19:23,720
way that you thought it was going
to. And so now you're off building

233
00:19:23,720 --> 00:19:27,839
your company in this direction, and
your potential customers are off going in this

234
00:19:27,960 --> 00:19:33,359
direction and you never identify that gap, which ultimately is bad for your startup.

235
00:19:33,920 --> 00:19:37,799
Yeah, exactly, because and especially
at the startup, you have obviously

236
00:19:37,839 --> 00:19:41,720
limited resources, and you need to
make sure that you are putting your resources

237
00:19:41,759 --> 00:19:45,400
where you have the most impact.
But if you cannot measure the impact,

238
00:19:45,880 --> 00:19:48,880
and if you don't know where what's
your north star, like where you need

239
00:19:48,920 --> 00:19:52,000
to go, then yeah, and
you're just running potentially in circles. Yeah.

240
00:19:52,200 --> 00:19:56,319
So you run out of cash,
yeah exactly, and then if you're

241
00:19:56,359 --> 00:20:00,119
lucky enough, you sell whatever you
have left and start something new and a

242
00:20:02,160 --> 00:20:07,119
serial entrepreneur. It's also great.
I mean you run into the problem sometimes

243
00:20:07,160 --> 00:20:11,359
there though that you're successful in spite
of your mistakes, and then you get

244
00:20:11,359 --> 00:20:14,839
to tell a great story about all
the things you did right and then people

245
00:20:14,880 --> 00:20:18,480
go and copy you. True.
Yeah, yeah, yeah cool. So

246
00:20:18,680 --> 00:20:26,559
in your work over at the the
C and CF, what does a what

247
00:20:26,599 --> 00:20:30,920
does a typical day as an ambassador
look like there? And how does that

248
00:20:30,000 --> 00:20:37,079
relate to your podcast, because I
think there's probably a correlation there of your

249
00:20:37,160 --> 00:20:45,319
public presence versus or your public presence
aligned with an open project like C and

250
00:20:45,440 --> 00:20:48,480
CF. Mm hmm. Yeah.
So the first of all, I'm really

251
00:20:49,119 --> 00:20:53,000
grateful that the CNCF gave me the
opportunity to be an ambassador. And just

252
00:20:53,039 --> 00:20:56,599
for those people that don't know how
this works, you have to apply to

253
00:20:56,680 --> 00:21:00,039
become an embassador, and investador really
means to work the community, to help

254
00:21:00,079 --> 00:21:06,240
the community to grow, to help
new members that come in, to find

255
00:21:06,240 --> 00:21:10,079
the way around, to help them
contribute, become just part of the community,

256
00:21:10,160 --> 00:21:14,599
right. And you also have to
reapply for the investadorship because it's always

257
00:21:14,640 --> 00:21:15,920
a year. So we just had
to reapply and now we need to keep

258
00:21:15,960 --> 00:21:22,119
fingers crossed that we did everything right. Now, how does this relate to

259
00:21:22,319 --> 00:21:26,799
my podcast? Since I've been an
ambassador, I've obviously been more connected or

260
00:21:26,839 --> 00:21:33,119
better connected with project leaders in the
c and CF. And for instance,

261
00:21:33,200 --> 00:21:38,400
we just had an episode of pe
performance around the open source project kepla a

262
00:21:38,480 --> 00:21:44,920
C and CF project. We also
just recorded an episode on our Goal,

263
00:21:45,119 --> 00:21:48,880
which is a very prominent player in
the C and CF. And so me

264
00:21:49,039 --> 00:21:56,640
being an embassador gives me the chance
to easier connect with these different project teams,

265
00:21:56,680 --> 00:22:00,000
with the project leads, with the
maintainers, and then I offer them

266
00:22:00,160 --> 00:22:07,359
platform to promote their work. Then
also hopefully help with this grow the CNCF

267
00:22:07,400 --> 00:22:12,960
ecosystem and the CNCF community and educate
them. It's a win win situation because

268
00:22:14,559 --> 00:22:18,039
in the end, you know,
if you look at the CNCF, it's

269
00:22:18,079 --> 00:22:22,920
a big, big landscape. If
you look at the CNCF landscape, our

270
00:22:22,920 --> 00:22:26,079
industry will try to figure out how
we build platforms on top of Kubernator is

271
00:22:26,119 --> 00:22:30,119
the base platform, and then picking
the right tools and so my goal is

272
00:22:30,160 --> 00:22:36,039
to educate on how to build platforms
in the end that make people successful.

273
00:22:36,079 --> 00:22:41,400
So platforms that allow developers to push
out code faster. The big topic for

274
00:22:41,440 --> 00:22:45,920
us is always observability. How can
we make sure that everything we build on

275
00:22:45,000 --> 00:22:51,319
top of kubernatores is observable by default? What does this them mean for rgo,

276
00:22:51,640 --> 00:22:56,680
for flax, for open feature,
for keplar, some of these tools

277
00:22:56,759 --> 00:23:02,279
you know that I had represented on
my podcast, and so we educate people

278
00:23:02,279 --> 00:23:07,759
on how to choose these tools,
but also get observability by default when they

279
00:23:07,079 --> 00:23:14,519
when they decided to choose these tools
in there in the landscape, right,

280
00:23:14,720 --> 00:23:19,920
Because to apply to be a C
and C of project, there's there's criteria

281
00:23:21,000 --> 00:23:22,799
you have to meet, right,
and there's like an incubation process, and

282
00:23:22,839 --> 00:23:26,799
you have these certain goals that you
have to meet in order to get to

283
00:23:26,960 --> 00:23:30,000
that graduated status. Is that correctly
exactly? You start with the sandbox,

284
00:23:30,160 --> 00:23:33,880
so that's kind of like the first
phase of it, and then you need

285
00:23:33,920 --> 00:23:38,480
to prove that you have real adopters, meaning that people that are really using

286
00:23:38,559 --> 00:23:44,799
your project in a production environment.
You need to have people that are maintaining

287
00:23:44,799 --> 00:23:48,119
the project, that are contributing to
the project. So you need to provide

288
00:23:48,160 --> 00:23:52,680
you need to kind of prove that
this is a viable project that doesn't only

289
00:23:52,720 --> 00:23:56,400
depend on a single person, because
that could obviously be if somebody is very

290
00:23:56,480 --> 00:24:00,640
enthusiastic and build a great framework or
a library of obcheck. But it's it's

291
00:24:00,799 --> 00:24:04,480
one person. What happens if this
person is hit by the legendary bus,

292
00:24:04,519 --> 00:24:10,279
right, So that's that's uh,
that's why you want to. You want

293
00:24:10,279 --> 00:24:14,559
to build an ecosystem and a community, and you want to you need to

294
00:24:14,559 --> 00:24:17,119
prove it. And once you prove
this, then you get into the uh

295
00:24:17,839 --> 00:24:21,440
uh, the incubation status, and
then into the graduated status exactly. So

296
00:24:21,480 --> 00:24:25,599
that's how the scene CF defines the
different maturity levels. The details of the

297
00:24:25,599 --> 00:24:30,759
criteria I don't know them. I
cannot recite them by heart. I'm pretty

298
00:24:30,799 --> 00:24:36,000
sure there's a website we can link
to get a tattooed on your forearm.

299
00:24:36,039 --> 00:24:41,400
Oh yeah, I think there's actually
a sci fi movie waiting to happen there,

300
00:24:41,440 --> 00:24:44,519
you know, because we talk about
the bus factor. I bet we

301
00:24:44,559 --> 00:24:49,440
could make like a Stephen King style
sci fi book or movie about this haunted

302
00:24:49,519 --> 00:24:57,880
bus that just travels around the world
taken out solo founders. Huh interesting,

303
00:24:59,400 --> 00:25:10,359
Yeah, side quest, it was
just a tangent. There's the XKCD with

304
00:25:10,799 --> 00:25:15,480
you know, a small little self
contained component that everyone's depending on that's holding

305
00:25:15,519 --> 00:25:18,279
up a mess of architecture. So
I think I think you would steel like

306
00:25:18,839 --> 00:25:26,440
society, civilization Crumball very quickly in
that regard post apocalyptic film for sure.

307
00:25:32,079 --> 00:25:34,799
So how did you get How many
years have you been a cn CF ambassador?

308
00:25:36,720 --> 00:25:38,680
Uh, well, I am now
applying for my second year, so

309
00:25:38,720 --> 00:25:45,359
it's still in my first year right
on, and uh I'm still a baby,

310
00:25:45,400 --> 00:25:48,000
I guess in that, yeah,
in that respect, but yeah,

311
00:25:48,119 --> 00:25:52,119
no, it's been, it's been. It's been good. And as I

312
00:25:52,160 --> 00:25:56,279
say that, just reapplied and so
we'll see if they will leave me in

313
00:25:56,319 --> 00:26:00,279
the game. They also so with
data scenes you have, they invested the

314
00:26:00,279 --> 00:26:07,200
program. They also have we have
regular check ins where we basically show what

315
00:26:07,240 --> 00:26:11,359
we've done in order to contribute back
to the scenes safe in order to qualify

316
00:26:11,839 --> 00:26:15,480
to be a good investor and not
just use the title for nothing, you

317
00:26:15,519 --> 00:26:21,480
know, besides doing the podcast that
do speak at different meetups and conferences,

318
00:26:21,559 --> 00:26:26,559
especially KCDS, gubernators communities these days. The topic that I'm currently kind of

319
00:26:26,599 --> 00:26:30,920
promoting and advocating for is the whole
topic of platform engineering. So I was

320
00:26:30,920 --> 00:26:36,079
really lucky so then I think also
the Investador title helped a little bit to

321
00:26:36,119 --> 00:26:38,960
be picked as a speaker at some
of these local events that we have here

322
00:26:40,000 --> 00:26:45,880
in Europe. And yeah, so
yeah, so hopefully hopefully you will have

323
00:26:45,960 --> 00:26:48,119
me back at some point and I
can then you can ask me the question

324
00:26:48,160 --> 00:26:52,240
and say how long have you been
an embassador and I can say seventeen years

325
00:26:52,279 --> 00:26:56,400
now, and then I will ask
you why did it take seventeen years for

326
00:26:56,599 --> 00:27:02,759
me for you to call me back
on that podcast? Well? Currently I

327
00:27:02,759 --> 00:27:07,559
can use the excuse that my emails
down, but if it's down for seventeen

328
00:27:07,680 --> 00:27:12,160
years, I think we'll go fully
off. Is it really a problem though,

329
00:27:12,160 --> 00:27:18,480
if my email doesn't get fixed,
as long as slack and everything else

330
00:27:18,519 --> 00:27:23,480
works. How did you get from
I don't know if your podcast is related

331
00:27:23,519 --> 00:27:26,799
to this, but you know you
started the podcast almost eight years ago and

332
00:27:26,920 --> 00:27:33,920
now you're CCP ambassador, Like,
what was the path here? The path

333
00:27:33,039 --> 00:27:36,920
here? It's a good question.
So when we started the podcast, funny

334
00:27:36,960 --> 00:27:41,160
story is that we had a very
close friend, one of mine, Brian's

335
00:27:41,160 --> 00:27:48,319
close friends, Mark Mark Tomlinson.
He actually encouraged us back then to start

336
00:27:48,319 --> 00:27:52,720
the podcast. He had his own
podcast was called pup of proof Fites.

337
00:27:52,039 --> 00:27:55,599
He also talked about performance and then
he said, hey, why don't you

338
00:27:55,680 --> 00:27:57,960
just start a podcast? And then
Brian asked me, He said, hey,

339
00:27:57,960 --> 00:28:00,960
do you want to do it?
And what does it take and how

340
00:28:00,000 --> 00:28:03,480
do we who do we need?
Who do we need to ask for permission?

341
00:28:03,519 --> 00:28:04,559
And I said, you know what, let's just do it and ask

342
00:28:04,599 --> 00:28:08,400
for forgiveness later in case somebody is
not happy with this, and that actually

343
00:28:08,400 --> 00:28:15,319
worked out pretty well. So we
we just started with pure performance and what

344
00:28:15,400 --> 00:28:18,720
we what Brian Again, thank you
Brian for all that he's doing, because

345
00:28:18,799 --> 00:28:25,480
I just need to talk and he's
doing all the the post production and everything,

346
00:28:25,720 --> 00:28:27,720
so I mean it's not just talking. Also, try I bring the

347
00:28:27,720 --> 00:28:33,720
guests because of my network with our
community that DNA Trace the Scenes. You

348
00:28:33,799 --> 00:28:37,680
have community, so I have good
connections to always find guests. But we

349
00:28:38,160 --> 00:28:41,799
what we tried to do is and
what we kept is since we've been doing

350
00:28:41,799 --> 00:28:45,839
it, we do a podcast episode
every second week. This is also what

351
00:28:45,920 --> 00:28:48,240
you need for consistency. I'm sure
you guys notice as well. You need

352
00:28:48,279 --> 00:28:55,119
to have consistency. This will help
you in recognition and this will help you

353
00:28:55,160 --> 00:29:00,000
I guess also with all the different
algorithms that then eventually bubble up your pots

354
00:29:00,119 --> 00:29:04,119
guests amongst the millions of artists that
are out there, and uh, yeah,

355
00:29:04,160 --> 00:29:10,440
and we've been, we've been.
I've always found the most the most

356
00:29:10,440 --> 00:29:15,440
interesting thing for me was that I
always try to pick guests where I definitely

357
00:29:15,480 --> 00:29:19,359
can learn something, right, because
I want to pick guests that are experts

358
00:29:19,359 --> 00:29:25,640
in the field where I don't have
expertise in because this allows me to learn

359
00:29:25,680 --> 00:29:29,759
something. So at least the hour
that I spent in recording the podcast,

360
00:29:29,839 --> 00:29:33,519
it's an hour well spent because I
learned something. Whether we have listeners or

361
00:29:33,559 --> 00:29:37,799
know. I know we have listeners, but that's that's always good. And

362
00:29:38,000 --> 00:29:44,079
yeah, we just pre COVID,
I was traveling a lot with different different

363
00:29:44,119 --> 00:29:48,160
conferences, meeting different people, and
so when I thought, hey, this

364
00:29:48,240 --> 00:29:52,240
is an interesting speaker at this conference, talk about an interesting topic that is

365
00:29:52,279 --> 00:29:55,759
adjacent to the performance kind of main
thing that we have, then I asked

366
00:29:55,759 --> 00:29:59,319
them, do you want to become
a guest on my podcast? And that

367
00:29:59,480 --> 00:30:03,759
always help and so yes, eight
years later, we had, as I

368
00:30:03,880 --> 00:30:07,000
just said earlier, the two hundred
and first episode, and we were lucky

369
00:30:07,319 --> 00:30:12,039
in the early days to have people
like Guaranca. She was the head of

370
00:30:12,160 --> 00:30:18,160
performance inside with ability engineer at Facebook. We had Kelsey high Tower, We

371
00:30:18,240 --> 00:30:25,400
had Jean Kim talking about develops right. We had many amazing guests that I

372
00:30:25,640 --> 00:30:30,079
would have probably not had on the
podcast if we wouldn't be persistent with,

373
00:30:30,279 --> 00:30:33,440
you know, kind of building up
a reputation. Some luck. Obviously,

374
00:30:33,440 --> 00:30:37,480
there's always some luck that you happen
to be at a conference and you happen

375
00:30:37,519 --> 00:30:41,400
to meet this person, and then
all of them are really helpful and they

376
00:30:41,400 --> 00:30:47,160
are willing to get on the podcast, and so yeah, so this is

377
00:30:47,160 --> 00:30:52,240
how It's how the path kind of
went, and here we are and now

378
00:30:52,319 --> 00:30:53,640
I'm with Will and Warren. I
mean, what else can I ask for?

379
00:30:56,319 --> 00:30:57,599
I don't know. I kind of
think that's the top that I know,

380
00:30:59,759 --> 00:31:02,839
Like, where do you go from
here? And I think, I

381
00:31:02,880 --> 00:31:06,640
think I just follow your lead and
I shut down my email and retire,

382
00:31:06,759 --> 00:31:15,599
right, go off the grid by
a typewriter and a cabin in Montana.

383
00:31:17,400 --> 00:31:21,400
Yeah, he sud He was super
motivated to talk about platform engineering. And

384
00:31:21,440 --> 00:31:23,839
I feel like I've heard this term
throughout my entire career, and to this

385
00:31:23,960 --> 00:31:30,559
day, I still couldn't tell you
what that is, so, you know,

386
00:31:30,599 --> 00:31:33,480
funny enough, I'll give you my
my explanation a second, but funny

387
00:31:33,519 --> 00:31:37,480
enough. I was on a was
it It was another podcast. It was

388
00:31:37,519 --> 00:31:42,279
similar to this, but it was
like a discussion where it was we were

389
00:31:42,920 --> 00:31:48,359
two and two on each side and
one we're saying DevOps is dead, and

390
00:31:48,440 --> 00:31:51,279
the other ones were saying, no, depthops is not dead. So kind

391
00:31:51,279 --> 00:31:53,279
of like defops is dead, that
platform engineering is the new thing, and

392
00:31:53,319 --> 00:31:56,960
then the others. This is where
I was, depops is not dead because

393
00:31:57,000 --> 00:32:00,960
I have you know, been talking
about develops for many many years, and

394
00:32:01,039 --> 00:32:05,680
so they put me on that area, on that side. But coming back

395
00:32:05,680 --> 00:32:12,359
to platform engineering, I think platform
engineering is trying to solve one big problem,

396
00:32:12,400 --> 00:32:20,559
which is that currently when you try
to build software, tested, deployed,

397
00:32:20,720 --> 00:32:24,160
operated, you need to know a
lot of a lot of things,

398
00:32:24,279 --> 00:32:29,680
right, a lot of different technology. The technology we work on is very

399
00:32:29,720 --> 00:32:32,079
complex, and especially if you then
try to scale this if you have if

400
00:32:32,079 --> 00:32:36,319
you're not like a small startup like
the three of us, but if we

401
00:32:36,400 --> 00:32:40,640
are one hundred five hundred, one
thousand engineers in an organization and you ask

402
00:32:40,720 --> 00:32:45,119
from every engineering team to do everything
end to end, then you probably end

403
00:32:45,200 --> 00:32:49,400
up with a lot of duplicated work, with a lot of wasted time because

404
00:32:49,400 --> 00:32:52,920
everybody tries to figure out how to
build, how to deploy, how to

405
00:32:52,960 --> 00:32:55,880
patch, how to do security,
how to do network and so platform engineering,

406
00:32:58,119 --> 00:33:05,079
from my perspective, tries to provide
what's called golden paths. So as

407
00:33:05,319 --> 00:33:08,880
in an organization, right if you
are I don't know if your job.

408
00:33:09,200 --> 00:33:13,319
If you are an organization that is
heavy, Let's say I'm building Java based

409
00:33:13,359 --> 00:33:17,960
applications because that's your skill set,
then you provide golden paths where developers can

410
00:33:19,000 --> 00:33:22,640
go to a portal and say I
need to build a new travel based micro

411
00:33:22,720 --> 00:33:28,920
service or a new travel based app. And then the platform engineering team provides

412
00:33:28,960 --> 00:33:32,680
a self service portal whereas a developer
can go in, I don't need to

413
00:33:32,720 --> 00:33:37,319
care about how it gets built,
how it gets deployed, and don't need

414
00:33:37,359 --> 00:33:40,039
to care about security because all of
this is bake them by the platform engineering

415
00:33:40,039 --> 00:33:46,759
team. So the platform engineering team
is essentially building an internal product that solves

416
00:33:47,200 --> 00:33:52,680
problems of internal customers, which are
developers, so that they can focus on

417
00:33:52,759 --> 00:33:57,319
writing code instead of having to figure
out how to package the code, how

418
00:33:57,319 --> 00:34:00,759
do they push it out into the
different environments, how to do automated performance

419
00:34:00,799 --> 00:34:06,480
and low testing, how to do
security checks. So platform engineering, in

420
00:34:06,519 --> 00:34:10,599
a simple sense, is fulfilling the
promise of DETHOBS and enterprise scale by providing

421
00:34:10,679 --> 00:34:16,320
it as a sealf service. I
think it's a longer nnger than I anticipated,

422
00:34:16,400 --> 00:34:20,960
but I would like to add that
a little bit too, because the

423
00:34:21,360 --> 00:34:27,639
way that I treat platform engineering is
it's about putting guardrails in place. You

424
00:34:27,639 --> 00:34:34,800
know, because every company has financial, operational, security, and legal constraints

425
00:34:35,039 --> 00:34:38,639
about how they operate their business,
and so I treat platform engineering as a

426
00:34:38,679 --> 00:34:45,639
way of putting guardrails in place so
that someone from the engineering team can get

427
00:34:45,679 --> 00:34:54,039
from their application idea to production while
meeting all of those constraints, even when

428
00:34:54,079 --> 00:34:58,800
they don't know what those constraints are. It's sort of like, you know,

429
00:34:58,800 --> 00:35:00,320
when you go to the bowling alley
and you put the bumpers and the

430
00:35:00,360 --> 00:35:05,119
gutters along the side so that no
matter what you do, your ball is

431
00:35:05,159 --> 00:35:07,679
going to make it down and at
least hit the pins. I kind of

432
00:35:07,679 --> 00:35:13,119
treat platform engineering as the same way
we're putting in the bumpers to keep your

433
00:35:13,159 --> 00:35:16,599
bowling ball from falling off into the
gutter. I like that. Yeah,

434
00:35:17,000 --> 00:35:21,599
yeah, it's a great analogy.
I may borrow it at some point.

435
00:35:22,400 --> 00:35:24,159
I'm pretty sure I borrowed it from
someone else. I just don't murder you.

436
00:35:28,199 --> 00:35:31,920
And I think maybe one other thing
the platform engineering is a platform engineering

437
00:35:31,920 --> 00:35:36,400
doesn't solve one hundred percent of the
problems that you have in your organization.

438
00:35:36,440 --> 00:35:42,000
I think as platform engineering teams,
you should, like with any product that

439
00:35:42,039 --> 00:35:45,079
you build, right, you want
to figure out what are they the pain

440
00:35:45,119 --> 00:35:47,719
points of eighty percent of your engineers, whether eighty percent of your engineers waste

441
00:35:47,760 --> 00:35:52,559
their time and things that they shouldn't
waste the time on, and then come

442
00:35:52,679 --> 00:35:55,320
up with an easier way for them
to do it. And this could be

443
00:35:55,840 --> 00:36:00,280
something simple, as you know,
create a wiki page to explain how to

444
00:36:00,440 --> 00:36:05,599
create a new project with at least
the basic security scans, but it can

445
00:36:05,639 --> 00:36:10,840
be something as sophisticated as building an
IDP and internal development platform using tools like

446
00:36:10,880 --> 00:36:15,559
backstage, port Io or others where
developer just clicks on the button and then

447
00:36:15,599 --> 00:36:21,679
fills out a couple of fields and
then outcomes a fully configured Git repository with

448
00:36:21,719 --> 00:36:27,440
pipelines, with security scans, with
observability building and so I think the point

449
00:36:27,519 --> 00:36:30,880
is, you know you need to, like when building any type of product,

450
00:36:30,000 --> 00:36:34,280
you first need to understand who is
your end user and why would you

451
00:36:34,440 --> 00:36:37,079
end user use your product? What
pain do they have that you can solve?

452
00:36:38,280 --> 00:36:43,920
And if you figured that out in
an organization, then you're also set

453
00:36:43,960 --> 00:36:47,639
up for success because the other way
around will be somebody here as platform engineering

454
00:36:47,719 --> 00:36:52,440
is the cool thing, so let's
build a platform. And then you build

455
00:36:52,440 --> 00:36:55,960
a platform, and then the platform
doesn't help anybody in the organization because it

456
00:36:57,000 --> 00:37:00,800
doesn't do doesn't solve problems that their
people have right now. No, I

457
00:37:00,800 --> 00:37:02,800
think that's a really important point that
often gets messed. Like if we're talking

458
00:37:02,840 --> 00:37:08,119
about platform teams as a team topology
concept, then what's often missing I can't

459
00:37:08,119 --> 00:37:15,519
believe still today is what you're essentially
saying is product management from that platform team

460
00:37:15,519 --> 00:37:17,239
so that they know what they're working
on, working on the right things.

461
00:37:19,280 --> 00:37:22,000
And this is also why what I
try to stress coming back to savability,

462
00:37:22,239 --> 00:37:27,400
because that's what I do on a
day to day basis with any product,

463
00:37:28,239 --> 00:37:31,360
whether it's your let's say, your
your e commerce website that you're building,

464
00:37:31,400 --> 00:37:35,159
you want to monitor how many people
are using it and how much money.

465
00:37:35,199 --> 00:37:37,880
Do you make the same issrue for
your platform? If you're building a platform,

466
00:37:37,920 --> 00:37:43,360
you want to know do you have
one development team that uses it because

467
00:37:43,480 --> 00:37:45,440
you feel sad for you if they
don't use it because they're your friends,

468
00:37:45,800 --> 00:37:50,360
what do you have eighty percent of
the development teams use it because you actually

469
00:37:50,360 --> 00:37:52,519
scover a problem and are they becoming
more efficient in the work. So that's

470
00:37:52,559 --> 00:38:00,119
why you also need to observe success
the adoption platform, and therefore you need

471
00:38:00,159 --> 00:38:05,840
to solve a problem. And very
importantly, your platform, it'sself ulto needs

472
00:38:05,880 --> 00:38:08,079
to be available at the time when
your developers need it. It needs to

473
00:38:08,079 --> 00:38:13,239
be resilient, and it needs to
be performing. Because if at eight o'clock

474
00:38:13,239 --> 00:38:17,159
on Monday morning and all of your
developers come back on the weekends and they

475
00:38:17,199 --> 00:38:21,559
all of the great idea, they
all start writing new stuff and they use

476
00:38:21,599 --> 00:38:24,039
your platform and say avenue adear,
and all of a sudden, your platform

477
00:38:24,039 --> 00:38:30,480
crashes, and you also miss the
point. So you need treat it as

478
00:38:30,519 --> 00:38:36,880
a product, and therefore you need
to buy all the principles of software engineering

479
00:38:36,880 --> 00:38:40,960
through that product. Yeah, for
sure. It's one of the big misconceptions

480
00:38:40,960 --> 00:38:46,519
there that most of you have addressed
is that your engineering teams are your customer,

481
00:38:47,440 --> 00:38:52,960
and the misconception is that they don't
have to choose your platform as a

482
00:38:52,000 --> 00:38:55,519
customer. They are free to go
elsewhere. And so unless you have that

483
00:38:57,320 --> 00:39:01,400
frequent communication with them and really understand
what they'res are, they will go somewhere

484
00:39:01,400 --> 00:39:07,480
else exactly. And you know,
I've seen the problem actually even go further

485
00:39:07,519 --> 00:39:09,079
than that, whereas like if you
just count the number of teams that are

486
00:39:09,159 --> 00:39:14,159
using your thing, you don't know
if they're actually getting the value out right.

487
00:39:14,440 --> 00:39:15,320
If your platform is going to fall
over one day, you know,

488
00:39:15,360 --> 00:39:21,320
that could certainly be a problem.
I've seen organizations mandate the use of internal

489
00:39:21,400 --> 00:39:24,719
tools that have been built which can
slow the teams down and whatnot. I

490
00:39:24,719 --> 00:39:29,159
mean, I assume the list of
problems here goes on and on. I'm

491
00:39:29,199 --> 00:39:34,840
sure Andy has quite a few number
of horror stories. Yeah, And I

492
00:39:34,880 --> 00:39:38,039
mean that's I think this is what
I said earlier. It's the if,

493
00:39:38,440 --> 00:39:43,159
I mean, certain things in certain
industry have to be mandated because there's no

494
00:39:43,239 --> 00:39:47,039
way around. You cannot just allow
I don't know, somebody in the financial

495
00:39:47,440 --> 00:39:52,039
and highly regulated areas so in governments
to just pick any cloud vendor in any

496
00:39:52,079 --> 00:39:57,719
GEO, that's just not possible.
So certain rules of engagement, certain cardhels

497
00:39:57,760 --> 00:40:02,440
have to be there. But if
you come back to understanding the pain point

498
00:40:04,159 --> 00:40:09,559
of your internal customers and then making
their life easier, it will be success.

499
00:40:10,599 --> 00:40:15,760
If you think you know what your
customers, your internal customers need without

500
00:40:15,800 --> 00:40:21,480
even talking to them and building something, chances of success slower. So it's

501
00:40:21,719 --> 00:40:25,639
as simple ast that. Yeah,
and that's a hard conversation to have,

502
00:40:25,800 --> 00:40:30,079
right, because you're going to go
up to someone and it's the same for

503
00:40:30,199 --> 00:40:32,519
all areas of your life. You
know, you have to walk up to

504
00:40:32,519 --> 00:40:37,119
someone and say, hey, what
am I doing that's actually not helping you?

505
00:40:37,320 --> 00:40:39,679
Or what can I do to help
you better? And so you're going

506
00:40:39,760 --> 00:40:45,679
to get that feedback that's just going
to like ship away. You know,

507
00:40:45,719 --> 00:40:49,880
you walk into the conversation thinking,
damn, I nailed this, and then

508
00:40:49,960 --> 00:40:54,679
you have this conversation and they start
chipping it away at it and it's feedback

509
00:40:54,679 --> 00:40:58,719
that some people don't want to hear, but it's absolutely critical if you're going

510
00:40:58,800 --> 00:41:05,880
to have a successful platform initiative when
people really like negative feedback. Right,

511
00:41:07,119 --> 00:41:13,400
So I just had the pleasure We
just had our annual user conference from from

512
00:41:13,440 --> 00:41:19,039
Dina Trace two weeks ago and I
had the pleasure to have Marcellina from Dell

513
00:41:19,199 --> 00:41:22,639
on stage and he was also you
know, he was talking about how they

514
00:41:22,679 --> 00:41:29,960
brought observability as a self service into
their internal platform and I asked him,

515
00:41:30,239 --> 00:41:37,880
what are the measures the KPIs that
you were reporting back to your leadership that

516
00:41:37,000 --> 00:41:40,440
actually shows that your team, your
platform team that is bringing up stability in

517
00:41:40,599 --> 00:41:45,599
is actually successful manage any impact.
And and I think I need to look

518
00:41:45,599 --> 00:41:50,719
at the actual numbers, but it's
all the recording is available. But one

519
00:41:50,719 --> 00:41:55,280
of the things that they measured is
they were serving their engineers and say how

520
00:41:55,360 --> 00:42:00,679
much time do you currently you know, spending coding so doing things that is

521
00:42:00,719 --> 00:42:07,159
considered toil. And they went from
something like thirty six percent productive to eighty

522
00:42:07,199 --> 00:42:13,679
percent productive. Wow. Right,
because they received a platform or they were

523
00:42:13,719 --> 00:42:17,599
given a platform that really solves problems. That was you know, taking away

524
00:42:17,800 --> 00:42:24,280
work from them that could be automated
by making it easier to get their logs,

525
00:42:24,400 --> 00:42:29,519
metrics and trastic without having without them
having to figure out how to whether

526
00:42:29,559 --> 00:42:32,440
write the log how to create metrics. They just Marchia on his team.

527
00:42:32,480 --> 00:42:37,360
They just invested a lot of time
they were investing in in invester pipelines,

528
00:42:37,400 --> 00:42:42,800
in more resilient pipelines. So he
showed some numbers on how many million of

529
00:42:42,800 --> 00:42:45,920
pipeline runs they have, you know, increased in a matter of a year

530
00:42:46,039 --> 00:42:52,280
or two, which means faster turnaround, faster faster software engine, faster software

531
00:42:52,280 --> 00:42:55,039
development and experimentation. So it's really
fantastic. And so this is like the

532
00:42:55,079 --> 00:43:00,639
reason why I asked them, what
metrics did you use to show us success?

533
00:43:00,800 --> 00:43:05,960
I was really blown away by you
know, the toil how much that

534
00:43:06,119 --> 00:43:09,719
went down, the number of pipelines
they ran. That means how many more

535
00:43:09,760 --> 00:43:15,840
releases they pushed out. Also,
the I think he had one interesting metric

536
00:43:16,440 --> 00:43:22,079
game we are coming from an opstability
perspective or background, the meantime to instrumentation,

537
00:43:22,320 --> 00:43:27,840
how long does it take you to
actually get the instrumentation? And uh,

538
00:43:28,119 --> 00:43:32,719
they it was fantastic, right,
good twist on the original Dora metric.

539
00:43:34,360 --> 00:43:38,400
Yeah, yeah, yeah, we
get the metrics right after our first

540
00:43:38,400 --> 00:43:45,119
production outage. Do you measure do
you measure by the number of negative tweets

541
00:43:45,199 --> 00:43:50,599
or what do you do? I
mean, you know, I've heard a

542
00:43:50,639 --> 00:43:54,800
number of companies though they talk about
gray failures that are ones that it's not

543
00:43:54,880 --> 00:44:01,920
so obvious that there's a problem and
that requires external feedback that a set of

544
00:44:02,239 --> 00:44:07,000
serial requests or something like that achieve
too high a latency, for instance,

545
00:44:07,239 --> 00:44:13,920
and so having that stream seems super
valuable to be able to know immediately by

546
00:44:14,000 --> 00:44:20,360
watching the API from some third party
social platform as an observability tool. Yeah.

547
00:44:21,280 --> 00:44:22,679
No, I mean yeah, I
mean I was half choking earlier.

548
00:44:22,719 --> 00:44:30,880
I know that what I was saying
is I hope that you have more observability

549
00:44:30,920 --> 00:44:34,719
than just monitoring the social feedback on
the feedback on the social media. But

550
00:44:35,840 --> 00:44:38,920
yeah, I mean we I know, we have users, customers of managers

551
00:44:38,920 --> 00:44:45,760
and they are pulling in data from
the Twitter API and winteresting there were other

552
00:44:45,880 --> 00:44:50,119
API social media to get a kind
of like a sentiment of what's going on

553
00:44:50,199 --> 00:44:57,039
out there. Wow, that's going
to be Elon's new monetized product is using

554
00:44:57,440 --> 00:45:01,360
x as an observe observability platform.
That would require people to still be using

555
00:45:01,400 --> 00:45:10,840
it. It's true. And I
stopped the commenting here because run over.

556
00:45:12,519 --> 00:45:19,559
We all have careers on the line
here, So next topic please, Yeah,

557
00:45:20,599 --> 00:45:23,880
and awkward silence. No, uh, you know, it's really interesting.

558
00:45:23,920 --> 00:45:28,280
I was actually listening to some of
your more recent podcasts to see how

559
00:45:28,320 --> 00:45:31,840
the how it's changed over time,
and one of them really intrigued me was

560
00:45:31,880 --> 00:45:36,159
the one on AI coming up,
and I figured it'd be a topic,

561
00:45:36,320 --> 00:45:39,280
and uh, you know, whatever
interest you have or insight you got,

562
00:45:39,280 --> 00:45:45,119
there is certainly appointment for whatever is
happening in Double today. Yeah, I

563
00:45:45,119 --> 00:45:49,400
mean AI is a topic. I
think we all need to figure out what

564
00:45:49,440 --> 00:45:52,079
that means going forward, right,
because we were all I think, at

565
00:45:52,119 --> 00:46:00,039
least from my side, I'm both
excited yet it's not scared, but I

566
00:46:00,039 --> 00:46:01,360
think we need to be very careful
we probably do with it, and I

567
00:46:01,360 --> 00:46:08,599
think that's that's something we as an
industry, even as a uh you know,

568
00:46:08,599 --> 00:46:10,840
as humans, we need to figure
we need to figure this out as

569
00:46:10,840 --> 00:46:17,280
a society. Now from what I
believe where AI is obviously great help as

570
00:46:17,280 --> 00:46:22,599
you can tell from my accent and
for my not private English. That helps

571
00:46:22,639 --> 00:46:27,519
me a lot when I write things
so that I don't make grammar mistakes,

572
00:46:27,519 --> 00:46:30,760
because you know, that's what this
is great for. It also helps a

573
00:46:30,760 --> 00:46:35,960
lot of people to write code,
not coming up maybe with new cool algorithms,

574
00:46:35,960 --> 00:46:39,679
but at least writing boilerpled code.
And otherwise it's just a time consumer.

575
00:46:39,920 --> 00:46:47,119
Right, And how the question is
right if we are letting if we

576
00:46:47,159 --> 00:46:52,079
are ending up creating and letting AI
generate a lot of code, and then

577
00:46:52,119 --> 00:46:58,320
nobody understands that code anymore, and
how can we tell if that code is

578
00:46:58,679 --> 00:47:02,880
not doing something that we didn't expect
or even in the future something malicious.

579
00:47:02,920 --> 00:47:09,239
Right, Because if we had a
one of our keynote speakers at our conference,

580
00:47:09,400 --> 00:47:13,760
she was heavily involved in the I
and EI research, and then the

581
00:47:13,880 --> 00:47:21,199
security aspect that she was saying,
if hackers infiltrate the training material of AIS

582
00:47:21,280 --> 00:47:27,159
that generate code, then who knows, maybe THEI generates some backdoor into your

583
00:47:27,199 --> 00:47:31,920
code that can then be taken over
by somebody. So this brings me back

584
00:47:31,920 --> 00:47:37,440
actually where I started my conversation in
the beginning. If we are trusting the

585
00:47:37,519 --> 00:47:42,639
stuff that is given to us without
understanding what's happening, then we may end

586
00:47:42,719 --> 00:47:50,360
up with the next big performance problem, resiliency problem, or security problem.

587
00:47:50,679 --> 00:47:55,000
I mean, for sure, we
know that it's possible to poison the mL

588
00:47:55,159 --> 00:48:00,159
models so that the result is problematic. It's obviously short jump there to get

589
00:48:00,159 --> 00:48:04,519
to the next step where you could
do it in a way which causes a

590
00:48:04,559 --> 00:48:07,159
real problem or opens the back door. Like you said, it's a really

591
00:48:07,159 --> 00:48:10,719
good point. Do you see it
happening in like the observability space, Like

592
00:48:12,400 --> 00:48:15,960
is there just anominally detection or are
there things on top of that that you

593
00:48:15,000 --> 00:48:21,039
see coming down the pipeline that really
are a real step forward that you're looking

594
00:48:21,039 --> 00:48:23,840
forward to. Yeah, I see
so. I think this is not only

595
00:48:23,840 --> 00:48:30,320
true for obserability, but with many
areas and products where you have a lot

596
00:48:30,320 --> 00:48:35,239
of people that need to use these
tools but not on a data day basis,

597
00:48:35,280 --> 00:48:38,000
which means they're not experts. So
right, if I look at at

598
00:48:38,039 --> 00:48:43,679
our product and our competitors product,
they're extremely powerful products, but most people

599
00:48:44,280 --> 00:48:49,119
only interact with let's say the data
that comes out in case there's a problem.

600
00:48:49,519 --> 00:48:52,480
So maybe this happens once a week, maybe this happens once a month.

601
00:48:52,559 --> 00:48:54,800
If you only interact with it two
once per month, it's going to

602
00:48:54,840 --> 00:48:58,679
be very challenging. You're not going
to be efficient. So one way how

603
00:48:58,719 --> 00:49:00,960
AI can help you. That's also
what we've built into the product, and

604
00:49:00,960 --> 00:49:04,960
I believe our competition is stand that
as well, or other players in the

605
00:49:05,039 --> 00:49:10,800
space, is using a generative AI
to say, you know, explain that

606
00:49:10,960 --> 00:49:15,840
data to me, or create a
dashboard for this particular incident so that I

607
00:49:15,960 --> 00:49:21,480
understand what's going on for the ara
of the code that I'm responsible for.

608
00:49:22,880 --> 00:49:30,440
So using generative AI to really become
more efficient with a complex tool with complex

609
00:49:30,519 --> 00:49:35,480
data when you don't work with it
on a data day basis, when you're

610
00:49:36,039 --> 00:49:38,000
basically not an expert. And I
think that's where it's huge help. And

611
00:49:38,039 --> 00:49:43,760
that's the same with with code generation
just on any type of business code,

612
00:49:43,800 --> 00:49:50,719
right because you don't write that maybe
certain basic algorithms you know every day and

613
00:49:50,960 --> 00:49:52,920
I can either then look it up
if I need a special sort algorithm on

614
00:49:52,960 --> 00:49:55,519
stake go go flow and then copy
it in or just say, hey,

615
00:49:55,840 --> 00:50:00,840
cope a lot, I need this. Help please set this array in the

616
00:50:00,840 --> 00:50:05,599
most efficient way. And that's a
cool thing, and and I see that

617
00:50:05,679 --> 00:50:10,159
this is there Another thing that I
in the kind of my opinion in one

618
00:50:10,320 --> 00:50:16,840
area in the opstability space is standardization. So we have open telemetry as a

619
00:50:16,840 --> 00:50:22,239
standard to collect data, and the
industry is kind of trying to figure out

620
00:50:22,239 --> 00:50:23,840
a way how can we not only
standardize the way we collect data, but

621
00:50:23,920 --> 00:50:28,119
how can we also standardize the way
we analyze the data that is collected,

622
00:50:28,559 --> 00:50:30,599
So like, shall we shall we, you know, come up with a

623
00:50:31,280 --> 00:50:35,400
with a standard query language, Shall
we come up with something? And I

624
00:50:35,480 --> 00:50:42,079
believe that these generated VIIs actually have
the power to maybe not solve it,

625
00:50:42,119 --> 00:50:45,840
but to mitigate this problem because I
can say today, I'm using two X

626
00:50:46,000 --> 00:50:51,679
and please Copilot give me that data
in two legs tomorrow and to move into

627
00:50:51,719 --> 00:50:55,440
two Y, and I can still
in natural language say give me that data.

628
00:50:55,519 --> 00:50:59,440
And I don't know what the language
is that they're using to query this

629
00:50:59,559 --> 00:51:00,760
data, but just give it to
me, because you are the expert,

630
00:51:00,840 --> 00:51:07,880
right cool the expert. So I
think it could also solve this problem.

631
00:51:08,159 --> 00:51:12,400
It's interesting you brought up data.
I feel like I've been hearing forever,

632
00:51:12,519 --> 00:51:15,159
like we have to save all of
our data. It used to be for

633
00:51:15,360 --> 00:51:20,639
testing, and so companies piled on
you know, magnetic tape backups of whatever

634
00:51:20,960 --> 00:51:24,920
worthless thing they had, and then
it's moved to user analytics and maybe business

635
00:51:24,960 --> 00:51:29,800
analytics, and I still feel like
every company I worked for didn't know what

636
00:51:29,840 --> 00:51:34,159
they were doing with it. And
now it's maybe we can write some mL

637
00:51:34,239 --> 00:51:38,480
on top of it. Best LLM
model to I don't know generate stuff.

638
00:51:39,199 --> 00:51:42,320
Do you think that's changing, Like, are there still like a majority of

639
00:51:42,360 --> 00:51:45,199
the data that companies are saving just
isn't worth anything and now it's changing,

640
00:51:45,360 --> 00:51:52,559
or they're still finding the important aspect
in whatever you're saving. There is a

641
00:51:52,639 --> 00:51:57,440
very tough question to answer. I
think we are still probably saving on the

642
00:51:57,480 --> 00:52:00,440
one set, too much data and
it is also not the welst fructured,

643
00:52:00,280 --> 00:52:05,880
which means the only way to make
sense with this is actually to come up

644
00:52:05,880 --> 00:52:10,960
with algorithms and using I guess email
systems to to kind of make sense of

645
00:52:12,000 --> 00:52:15,400
this data. But on the other
side, I believe we have the opportunity

646
00:52:15,440 --> 00:52:21,760
now to educate people, first of
all, to come up to use standards,

647
00:52:22,079 --> 00:52:25,639
to come up with with with with
good practices on unstructured logging, on

648
00:52:27,000 --> 00:52:30,000
when they use traces, what should
be on a trace, when when you're

649
00:52:30,079 --> 00:52:34,480
using when you're creating metrics, you
know what metrics makes sense and how should

650
00:52:34,480 --> 00:52:37,480
they what dimension should they have,
and also come up with with some best

651
00:52:37,519 --> 00:52:40,960
practices. On the other side,
what we do, at least from the

652
00:52:42,000 --> 00:52:46,000
company I work for, right we
we we try to connect the data because

653
00:52:46,000 --> 00:52:52,639
what we've seen historically many organizations in
the divisibility space started somewhere, right,

654
00:52:52,719 --> 00:52:55,840
we ad Din a trace. We
started with tracing, so we've been doing

655
00:52:55,840 --> 00:53:00,199
tracing for the last twenty years,
and then we added you know, metrics

656
00:53:00,199 --> 00:53:05,320
and logs and relyuse the monitoring others, you know, I'm sure like Splunk

657
00:53:05,360 --> 00:53:08,360
for instance, right, they started
from logs and then they expanded into other

658
00:53:08,400 --> 00:53:14,199
areas. And I think many vendors
out there right now, and especially if

659
00:53:14,199 --> 00:53:16,639
you, let's say do it yourself
and you put in you create your own

660
00:53:16,639 --> 00:53:22,039
opstability platform, you have data silos
where you have your logs, your metrics,

661
00:53:22,039 --> 00:53:24,199
your traces, your events and so
on. And this actually makes it

662
00:53:24,320 --> 00:53:30,119
very hard to then analyze the data
and put the context. And so one

663
00:53:30,159 --> 00:53:32,480
of the things that we at least
try to solve is as we interest the

664
00:53:32,559 --> 00:53:37,119
data we connected, we enrich it
with topology information, so we know that

665
00:53:37,199 --> 00:53:42,159
this log comes from this trace,
from this service, from this Kubernators cluster,

666
00:53:42,519 --> 00:53:46,559
from this end user. And with
that we are also more efficient when

667
00:53:46,599 --> 00:53:52,559
we run our AI over the data, when we do analytics. And as

668
00:53:52,599 --> 00:53:55,239
I said, I can only speak
what we are doing. Maybe others are

669
00:53:55,280 --> 00:54:00,199
doing it as well, but I
think the problem that we should we need

670
00:54:00,239 --> 00:54:06,639
to solve as an industry is don't
just collect data because you can, but

671
00:54:06,840 --> 00:54:09,280
think about when you collect the data, what type of data is it,

672
00:54:10,199 --> 00:54:14,199
what's the meaning of it, how
does it connect to other data? What

673
00:54:14,239 --> 00:54:17,199
are you expectations, what do we
expect this data to be Because you're talking

674
00:54:17,199 --> 00:54:22,559
about data observability. If you have
a let's say, a percentage number that

675
00:54:22,639 --> 00:54:25,920
should be between zero and one hundred, and if all of a sudden five

676
00:54:25,960 --> 00:54:29,920
hundred comes in, there's something wrong. And I'm sure this is the same

677
00:54:30,000 --> 00:54:31,840
with with with with other things too. So you want to you want to

678
00:54:31,840 --> 00:54:36,199
make sure that the data is clean, that the data is accurate, and

679
00:54:36,239 --> 00:54:38,199
that you only collect data that actually
really makes sense in the end, because

680
00:54:38,239 --> 00:54:43,079
then we can we can also make
it easier to analyze the data in the

681
00:54:43,159 --> 00:54:46,519
end. Having a plan before you
starts a good idea, it's always a

682
00:54:46,519 --> 00:54:50,719
good idea, exactly. Yeah.
And to me that highlights like one of

683
00:54:50,760 --> 00:54:57,719
the big advantages of using a you
know, not only a performance tool like

684
00:54:58,039 --> 00:55:04,079
kind of traise, but having organizations
like to see INCF that can because there's

685
00:55:04,119 --> 00:55:07,599
a lot of work in making all
those decisions right and you have to have

686
00:55:07,119 --> 00:55:14,559
a ton of expertise in that area
to even know what the right questions are

687
00:55:15,159 --> 00:55:21,280
to be asking, much less even
get to an answer. And so that's

688
00:55:21,320 --> 00:55:28,960
where I think having those resources available
to someone like myself who's just trying to

689
00:55:28,960 --> 00:55:35,559
write application code to run my business
actually helps because then I can use your

690
00:55:35,599 --> 00:55:38,960
expertise to solve problems that I didn't
even know I was going to have.

691
00:55:39,320 --> 00:55:44,199
And I think that's a hard mental
shift for some people, especially younger people,

692
00:55:44,719 --> 00:55:46,119
like oh, I can just write
this myself and then I don't have

693
00:55:46,239 --> 00:55:51,880
to use this product or I don't
have to sign up for the subscription service.

694
00:55:51,920 --> 00:55:55,280
But there are some long term benefits
to, you know, using the

695
00:55:55,320 --> 00:56:00,599
product created by a team of a
thousand engineers who are solving problems and I'm

696
00:56:00,599 --> 00:56:04,079
not even aware of. I just
want to add one comment. It's not

697
00:56:04,119 --> 00:56:07,079
only the young people that think they
know everything better. It's also some old

698
00:56:07,119 --> 00:56:13,880
people. That's their point, and
I include myself sometimes, right, sometimes

699
00:56:13,920 --> 00:56:16,079
you just think you have seen this
before and you know it much better.

700
00:56:16,159 --> 00:56:20,679
But yeah, but yeah, right, yeah, you know the scene CF

701
00:56:20,679 --> 00:56:22,920
and especially if you think that this
happened. I mean, I'm very happy

702
00:56:22,920 --> 00:56:27,760
about open Telemetry already obviously, right, it's in the divisibility space and how

703
00:56:27,760 --> 00:56:31,320
everybody's collaborating here. All the big
vendors are collaborating, bringing in their expertise,

704
00:56:31,400 --> 00:56:38,280
contributing the different types of agents for
instrumenting application code automatically and then en

705
00:56:38,280 --> 00:56:43,840
reaching a bit open telemetry or we
have launched two years ago on our almost

706
00:56:43,920 --> 00:56:47,360
open feature to standardize feature flagging,
and a lot of companies you know,

707
00:56:47,559 --> 00:56:52,679
are contributing to it. It's really
great to see how what the scene CF

708
00:56:52,800 --> 00:56:58,400
does because it breaks down a lot
of these barriers and walls that you normally

709
00:56:58,519 --> 00:57:04,159
have between competing usations for sure.
Yeah, because that's a definite change.

710
00:57:04,440 --> 00:57:06,920
You know, we've been all three
of us have been in this industry long

711
00:57:07,000 --> 00:57:10,639
enough to know that that was not
how this industry started, you know,

712
00:57:10,760 --> 00:57:15,840
like back in the late nineties early
two thousands, to think that Microsoft was

713
00:57:15,920 --> 00:57:23,559
going to do something collaborative with another
company was just completely unheard of. Yeah,

714
00:57:24,039 --> 00:57:27,679
yeah, here we are. Yeah. We always make the comment,

715
00:57:27,760 --> 00:57:31,079
I think, Brian, he always
makes the comment, this is no longer

716
00:57:31,119 --> 00:57:37,320
the Microsoft that I that I knew
for sure. Yeah, it's amazing.

717
00:57:37,800 --> 00:57:45,760
Yeah, I mean it's interesting you
bring up the collaboration. I see.

718
00:57:45,920 --> 00:57:47,760
I see. One of the things
that comes up is that a lot of

719
00:57:47,800 --> 00:57:52,639
these tools are still incredibly expensive for
our small scale and I see that being

720
00:57:52,880 --> 00:57:57,480
a reason that especially individual contributors if
they're just trying something out or building,

721
00:57:58,079 --> 00:58:01,360
want to even or motive to do
it themselves. Actually, it's interesting,

722
00:58:02,440 --> 00:58:07,199
we actually have a similar problem at
Offerers that we're trying to solve just on

723
00:58:07,280 --> 00:58:09,719
the metrics side, and it's just
such a small amount of metrics that we

724
00:58:09,840 --> 00:58:15,159
want to collect from a volume standpoint, but high number of dimensions, and

725
00:58:15,239 --> 00:58:22,360
it's difficult to find something that purpose
fits what we're looking for without jumping into

726
00:58:22,920 --> 00:58:25,079
a giant product that has a lot
of different bells and whistles that go in

727
00:58:25,119 --> 00:58:30,719
a lot of different directions. And
the cloud provider we're utilizing right now just

728
00:58:31,039 --> 00:58:35,760
fails in that regard, which makes
it a real struggle. Well, I

729
00:58:35,840 --> 00:58:38,400
mean this is the reason why you
know as well as you say, whether

730
00:58:38,639 --> 00:58:43,280
there are our organizations that have thousands
of engineers and that we resolve into tough

731
00:58:43,360 --> 00:58:47,119
problems like high codinality, lots of
data, lots of metrics, lots of

732
00:58:47,159 --> 00:58:52,800
dimensions, but as you said,
not one hundred percent of organizations have this

733
00:58:52,920 --> 00:58:58,199
problem right away, and therefore for
a long time it's completely perfectly fine and

734
00:58:58,760 --> 00:59:01,800
to to to use solutions that are
free in that open source. But at

735
00:59:01,880 --> 00:59:08,280
some point there's a reason why commercial
companies exists, and that invests like we

736
00:59:08,440 --> 00:59:14,880
we have more than a thousand engineers
worldwide. You know, it's not we're

737
00:59:14,920 --> 00:59:17,559
not just sitting there and doing nothing
and just collecting the checks. We're actually

738
00:59:19,400 --> 00:59:23,039
we solved some of these challenging problems
that some we many of our customers have.

739
00:59:24,320 --> 00:59:27,760
Yeah, I mean, for sure
a lot trying to make sure that

740
00:59:27,840 --> 00:59:31,039
I can even a container you run
of an open source project inside your cluster

741
00:59:31,320 --> 00:59:36,519
on a machine is incredibly difficult to
get a high reliability out of it and

742
00:59:36,719 --> 00:59:40,480
configured in an optimal way for your
environment. It's not a trivial challenge.

743
00:59:42,960 --> 00:59:45,480
And maybe that's one one comment to
this, and I know we are probably

744
00:59:45,559 --> 00:59:50,119
already way over time, but I
wanted to add one more thing, coming

745
00:59:50,199 --> 00:59:53,519
back to the EI question that you
had earlier, because what you just said

746
00:59:53,679 --> 01:00:00,719
is it's very hard to configure and
find know how to correctly configure your kubernat

747
01:00:00,800 --> 01:00:06,199
Is nodes, your pots, your
resource limits, your request limits, and

748
01:00:06,280 --> 01:00:09,920
again, this is also something where
I believe where EI can help us or

749
01:00:10,039 --> 01:00:16,920
whatever whatever you want to call it, right is basically using the best practices

750
01:00:16,960 --> 01:00:22,920
and things we've learned from other systems
and then applied to workloads we now see.

751
01:00:22,159 --> 01:00:27,880
So we were working with a partner
company in Italy. Let's just give

752
01:00:27,920 --> 01:00:30,559
them a quick shout out because maybe
somebody's interested in Kamas and they are doing

753
01:00:32,519 --> 01:00:39,280
they're running experiments AI rhythmic experiments where
they are finding the optimal setting for your

754
01:00:39,360 --> 01:00:44,440
JVMs, your CLRs, for your
containers, for your kubernatores clusters, and

755
01:00:44,519 --> 01:00:47,239
they look at obserability data and then
you give them a goal. You said,

756
01:00:47,280 --> 01:00:52,039
hey, I want to optimize memory
and CPU, but I also don't

757
01:00:52,119 --> 01:00:55,239
want to jeopardize my performance. So
you can set them goals and then they

758
01:00:55,320 --> 01:01:00,599
find the right configuration based on some
machine left in that they know that some

759
01:01:00,719 --> 01:01:06,119
models that they build, and they
have some really interesting numbers. And I'm

760
01:01:06,159 --> 01:01:10,840
not an expert in Kubernetes down to
every single configuration line, but this is

761
01:01:10,840 --> 01:01:15,880
where again I would go to at
least AI to support me and say this

762
01:01:15,000 --> 01:01:22,039
is what I would recommend because I've
seen, I've analyzed thousands of systems and

763
01:01:22,119 --> 01:01:25,679
therefore give you this recommendation if I
CEO system and then I can decide whether

764
01:01:25,760 --> 01:01:31,400
I want to go with this recommendation
or not. Makes sense. Yeah,

765
01:01:31,440 --> 01:01:34,480
And on the other side of that, I find one of the common things

766
01:01:34,519 --> 01:01:38,679
I do with AI is whenever I
come across a configuration or some code that

767
01:01:38,800 --> 01:01:45,079
someone else has written, I'll just
paste it over into AI and say,

768
01:01:45,280 --> 01:01:49,400
can you explain what this does?
And obviously what is in the end means

769
01:01:49,440 --> 01:01:53,880
there will definitely be certain jobs that
will be less in demand because they will

770
01:01:53,920 --> 01:02:00,599
definitely be replaced by AI. But
I think this also gives us much better

771
01:02:00,639 --> 01:02:07,840
opportunity to think about instead of doing
the same mundane thing all over, I

772
01:02:07,920 --> 01:02:13,480
hopefully have now more time to think
about how I can contribute my brain power

773
01:02:13,599 --> 01:02:16,559
to something that an AI cannot solve. Right. Yeah, if your career

774
01:02:16,719 --> 01:02:23,960
passion is creating security groups inside an
AWS VPC, AI might be a career

775
01:02:24,079 --> 01:02:28,840
limterter for you. But if you
would just prefer to move on with something

776
01:02:28,880 --> 01:02:31,880
a little more fun, I don't
think AI is at risk of taking your

777
01:02:31,960 --> 01:02:37,880
job away. Yeah. I think
continual learning as always a requirement as technology

778
01:02:37,920 --> 01:02:43,480
evolves. I've seen AI disrupt more
companies though than individual jobs in a lot

779
01:02:43,519 --> 01:02:46,639
of areas. So you know,
like giant companies that, like say stack

780
01:02:46,719 --> 01:02:52,199
overflow disrupt it. But as far
as individuals and their abilities like that's still

781
01:02:52,239 --> 01:02:58,199
an open question as far as what
that will happen. All right, should

782
01:02:58,199 --> 01:03:01,199
we move on and do some picks. Let's do it, Warren, I'm

783
01:03:01,199 --> 01:03:04,000
going to put you on the spot. Have you got a pick for us

784
01:03:04,000 --> 01:03:06,679
this week? Yeah? You know, I have to have to spend all

785
01:03:06,760 --> 01:03:15,440
week thinking about that part time job. Yeah, that's that's actually more challenging

786
01:03:15,559 --> 01:03:20,719
than doing the preparation for the episode. Honestly. Uh, this one I

787
01:03:20,840 --> 01:03:22,559
think I figured out though. In
a couple of weeks, I'll actually be

788
01:03:22,679 --> 01:03:28,239
in Dressden for the Decompiled conference in
Germany. I'm actually getting a talk there

789
01:03:28,280 --> 01:03:34,440
on how AT offers we iteratively added
security as as we grew both our technology

790
01:03:34,480 --> 01:03:37,559
product and our organization, and I'm
sharing that with who's ever else there.

791
01:03:37,599 --> 01:03:42,119
But there's a lot of interesting talks
for the one day conference that's there,

792
01:03:42,239 --> 01:03:45,159
So shout out to Decompile and I'm
sure I'll bring it up again before I

793
01:03:45,239 --> 01:03:52,519
actually have to hop over for that. Right on, Andy you were pretty

794
01:03:52,559 --> 01:03:54,199
excited about doing picks. What have
you got for us? I actually got

795
01:03:54,239 --> 01:03:59,960
two for you. Oh absolutely,
So first first, the fun thing.

796
01:04:00,719 --> 01:04:01,840
So I think it's very important in
life. You know, we spend a

797
01:04:01,920 --> 01:04:05,599
lot of time in our job,
even though we love it and we're passionates,

798
01:04:05,599 --> 01:04:09,320
a lot of time. I think
you still need to have something outside

799
01:04:09,320 --> 01:04:12,719
of your regular work that kind of
keeps you, you know, gets your

800
01:04:12,920 --> 01:04:16,280
mind of mind. Is salsa dancing. And I know there's a lot of

801
01:04:16,800 --> 01:04:21,920
salsa dancers, so at least you
know dancers in our industry. So if

802
01:04:21,960 --> 01:04:25,800
you have not yet tried salsa,
you should. And the good news is

803
01:04:25,880 --> 01:04:29,840
in any city where I've traveled,
and I've traveled quite a bit, there's

804
01:04:29,840 --> 01:04:33,719
typically always a salsa community. And
salsa communities have been around for a little

805
01:04:33,760 --> 01:04:38,079
while, so most of them still
organize themselves on Facebook. So if you

806
01:04:38,159 --> 01:04:42,360
are kind of post Facebook generation,
because you're much younger than we are,

807
01:04:42,920 --> 01:04:45,239
then this might still be a good
thing to go on. And then you

808
01:04:45,400 --> 01:04:47,920
just say, salsa in Boston,
Salsa in Los Angeles. You've found it.

809
01:04:48,000 --> 01:04:51,559
So that's a just I love it. When I travel, I go

810
01:04:51,719 --> 01:04:56,920
dancing and it keeps my mind off. It also is and it's an exercise,

811
01:04:57,039 --> 01:05:00,679
so it keeps me fit and healthy
as well. Right, and then

812
01:05:00,719 --> 01:05:04,719
the second thing is just a it's
just a little tip, not if people

813
01:05:04,760 --> 01:05:10,760
are watching. Still, but on
the weekend I went ski hiking, so

814
01:05:10,960 --> 01:05:15,079
like not not downhill skiing, but
you know, I think it's not cost

815
01:05:15,159 --> 01:05:17,960
quanty, but you actually go up
on the high hills on the peaks ski

816
01:05:18,039 --> 01:05:23,880
touring. Yeah, and unfortunately we
have a lot of it's like too warm

817
01:05:23,960 --> 01:05:27,480
right now, so that means we
had to get very high up to actually

818
01:05:27,519 --> 01:05:29,679
get some snow. And then it
was so warm and I thought I can

819
01:05:29,800 --> 01:05:32,199
just be cool and I just you
know, go with my short sleeves and

820
01:05:32,320 --> 01:05:38,800
my shorts and nothing will ever happen. Well, my wife disapproves, she

821
01:05:38,840 --> 01:05:44,199
would like seeing me. When I
was I was like I made a wrong

822
01:05:44,280 --> 01:05:46,079
step and I was sliding down a
couple only a couple of meters, but

823
01:05:46,360 --> 01:05:49,800
the on the ice and the snow, I have a couple of bruises.

824
01:05:50,039 --> 01:05:53,920
And so folks, if you think
even if it's a warm day and you

825
01:05:54,039 --> 01:05:59,840
think you have no problem on skis
because you can you will never drip or

826
01:06:00,280 --> 01:06:04,239
or sleep, don't do it.
Just wear something long slip. It's just

827
01:06:04,320 --> 01:06:12,280
better. It's painful out of us. It's been painful for days right on.

828
01:06:13,760 --> 01:06:16,119
So I have two picks this week
as well. If you've been listening

829
01:06:16,159 --> 01:06:19,519
to the last few episodes, you
won't be surprised at my first pick,

830
01:06:19,599 --> 01:06:28,039
and that is for platform Con coming
up here this spring. Platform Con is

831
01:06:28,119 --> 01:06:35,199
great. It's a five day,
free virtual event on platform engineering and there's

832
01:06:35,320 --> 01:06:40,199
just tons and tons of great speakers
lined up. So if you if you

833
01:06:40,280 --> 01:06:44,440
heard what we were talking about on
platform engineering today and you're interested and want

834
01:06:44,440 --> 01:06:48,079
to figure out how that can actually
make your life easier, make your time,

835
01:06:48,280 --> 01:06:53,000
your team's life easier, make your
company more successful. They'll at least

836
01:06:53,079 --> 01:06:56,760
be a few talks to check out
on platform Con. And then at the

837
01:06:56,920 --> 01:07:01,239
end I'm doing a live Q and
A with some of the conference speakers,

838
01:07:01,880 --> 01:07:10,320
so that's going to be fun.
And then my second pick is for Obie

839
01:07:10,440 --> 01:07:15,599
Vincent. Obi is a he's a
personal trainer from the UK, but he

840
01:07:15,719 --> 01:07:24,079
has a great website and focuses on
a lot of kettlebell type workouts and I'm

841
01:07:24,119 --> 01:07:28,039
a huge fan of kettlebells. As
of this last year, I've been working

842
01:07:28,079 --> 01:07:33,360
with kettlebells exclusively for about the last
year, and he's got some workouts and

843
01:07:33,440 --> 01:07:38,960
some guides and some tips and stuff
on his website Obie Vincent dot com on

844
01:07:39,119 --> 01:07:43,679
how to effectively use the kettlebell and
get a great workout in with those.

845
01:07:43,800 --> 01:07:46,920
So, if you've never done kettlebells
or you're looking to try to get into

846
01:07:47,039 --> 01:07:51,119
working out, kettlebells are just super
cool because it's a low barrier to entry

847
01:07:53,000 --> 01:07:59,840
and it's dynamic. And actually I've
noticed in the last year of using kettlebells.

848
01:08:00,679 --> 01:08:04,360
You know, I'm fifty three now, but I've actually gotten stronger by

849
01:08:04,480 --> 01:08:12,320
stopping using barbells for working out and
using kettlebells just because it tends to line

850
01:08:12,440 --> 01:08:16,039
up with how our bodies want to
move anyway, which translates to greater strength

851
01:08:16,079 --> 01:08:19,880
improvements. So, yeah, go
check out Obi Vincent dot com. Do

852
01:08:19,960 --> 01:08:25,439
you have some in that room there
that you want to show off? No,

853
01:08:25,640 --> 01:08:28,279
they're actually out in the shop,
but I can bring some in for

854
01:08:28,479 --> 01:08:34,880
the for next week's episode, for
sure. Yeah. Absolutely, Yeah,

855
01:08:34,880 --> 01:08:42,960
I've got I've got about five hundred
pounds of kettlebells and different sizes. Yeah,

856
01:08:44,199 --> 01:08:49,279
which that's definitely not needed. That's
yeah, yeah, yeah, don't

857
01:08:49,399 --> 01:08:53,880
don't do that. And god,
I've got to finance this. Now you

858
01:08:53,960 --> 01:08:59,399
can. You can just grab one
kettlebell and start with their So that's like

859
01:08:59,399 --> 01:09:01,680
the upper If you're you're hitting that
number, you know, maybe you need

860
01:09:01,760 --> 01:09:08,359
to see over right, or maybe
like talk to your therapist about what you're

861
01:09:08,399 --> 01:09:18,279
really not focusing on. But that's
a subject for a different podcast. Awesome,

862
01:09:18,720 --> 01:09:21,359
Andy, thank you so much man. This has been a great conversation.

863
01:09:21,640 --> 01:09:26,279
I really enjoyed having you on the
show. Thanks for having me.

864
01:09:26,479 --> 01:09:29,239
And yeah, yeah, as I
said, you know, seventeen more years,

865
01:09:29,720 --> 01:09:31,640
seventeen more years, so now we'll
be back. I'll put it on

866
01:09:31,720 --> 01:09:35,760
the calendar. Yeah for sure,
Warren, thanks for joining me. Love

867
01:09:35,840 --> 01:09:39,880
having you as my co host.
It's been a blast and look forward to

868
01:09:39,960 --> 01:09:45,199
many many future episodes with you and
to all of our listeners, thank you

869
01:09:45,319 --> 01:09:49,560
for listening, and be sure and
check out the Pure Performance podcast as well

870
01:09:49,600 --> 01:09:53,479
if you aren't already. And we
will see you all next week.