WEBVTT

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.