1
00:00:05,120 --> 00:00:10,240
What's going on? Everybody? Welcome
back to another episode of Adventures in DevOps.

2
00:00:10,560 --> 00:00:14,919
I'm your host Will Button, but
I'm flying solo today. Warren is

3
00:00:15,039 --> 00:00:20,679
at the DevOps conference in Zurich,
so he'll be back with this next week.

4
00:00:21,000 --> 00:00:25,719
But meanwhile, joining me in the
studio, I have the founder and

5
00:00:25,960 --> 00:00:32,039
CEO of net Data, Costa Sausis
Costa. Welcome and I did Butcher your

6
00:00:32,079 --> 00:00:43,280
name didn't I? Yes, it's
man. Well, welcome to the show.

7
00:00:43,320 --> 00:00:47,240
Thank you for joining me here.
Thank you very much for inviting me.

8
00:00:47,719 --> 00:00:51,679
It's very nice to be here.
Yeah. So you're the founder and

9
00:00:51,840 --> 00:01:00,000
CEO of net Data, a monitoring
solution for simplifying and modernizing infrastructure observability,

10
00:01:00,280 --> 00:01:04,439
which is that's a that's a huge
task. I was you know, as

11
00:01:04,439 --> 00:01:07,159
we were talking before the show,
we've been doing this for a while and

12
00:01:07,239 --> 00:01:12,840
so you know, we've learned a
lot of lessons in the last few decades

13
00:01:12,920 --> 00:01:19,000
about doing this. So can you
give our listeners a little bit about your

14
00:01:19,000 --> 00:01:23,200
background and how you found yourself at
this point in life. Yes, So

15
00:01:23,280 --> 00:01:27,319
that's a funny story because you know, the data is a monitoring solution that

16
00:01:27,640 --> 00:01:34,560
was let's say it happened by accident. I never wanted to build a monitoring

17
00:01:34,599 --> 00:01:40,079
solution, even actually when I was
starting, when I had started building it,

18
00:01:40,319 --> 00:01:46,120
my intention was not to built a
monitoring solution. So the idea,

19
00:01:46,159 --> 00:01:52,079
guys, is the following I was
migrating some infrastructure from prem to cloud.

20
00:01:53,079 --> 00:01:57,359
We had several several problems. It
was very early in the cloud industry,

21
00:01:57,439 --> 00:02:05,680
let's say, after spending a few
big budget actually and building a large team

22
00:02:06,359 --> 00:02:12,280
of skills and consultants and advisors and
the likes, and with the help of

23
00:02:12,360 --> 00:02:19,520
the cloud provider six months past,
no outcome. Problems were still there.

24
00:02:20,360 --> 00:02:22,960
In the early days. I don't
know if you remember this, we were

25
00:02:23,000 --> 00:02:27,240
talking about that cloud is a little
bit alive and it behaves a little bit

26
00:02:27,280 --> 00:02:32,319
differently, and all this kind of
all these kind of discussions, which my

27
00:02:32,520 --> 00:02:38,400
understanding, it's a little bit of
garbage. It's it's at the end of

28
00:02:38,439 --> 00:02:43,560
the day. But anyway, after
spending quite some time there, I found

29
00:02:43,639 --> 00:02:46,319
myself, you know, it was
very painful. We had it was a

30
00:02:46,360 --> 00:02:53,280
fintech company. We were doing transactions, payments on the poss et cetera,

31
00:02:53,400 --> 00:03:00,319
you know, cards, and we
had many retail chains that we we were

32
00:03:00,360 --> 00:03:05,599
serving and the CUE the people that
were waiting in line to actually finish the

33
00:03:05,639 --> 00:03:08,800
transactions, pay for the goods and
go home. It was going around the

34
00:03:08,879 --> 00:03:19,360
blocks. It was stressful times.
So by that time I started thinking,

35
00:03:19,400 --> 00:03:23,080
come on, what is wrong?
Why we cannot find what's happening? Why

36
00:03:23,759 --> 00:03:29,800
monitoring systems are so I had the
impression that everything that they had built,

37
00:03:29,840 --> 00:03:32,479
you know, all the dashboards,
all the tools, everything there was just

38
00:03:32,680 --> 00:03:43,039
something to make me feel happy.
It didn't provide any value. But so

39
00:03:44,840 --> 00:03:47,879
initially this is how I started.
I was so picked off that I started

40
00:03:47,960 --> 00:03:53,680
building a tool to consolidate all the
consoles. So what I wanted is not

41
00:03:53,759 --> 00:03:59,120
to build a monitoring solution. I
said, okay, we have Metrix and

42
00:03:59,240 --> 00:04:04,000
data all over the let's build a
tool to aggregate everything. That was the

43
00:04:04,039 --> 00:04:08,800
goal. The goal. So instead
of having people being on the console of

44
00:04:08,840 --> 00:04:12,000
the database and the console of the
systems, and the console of this or

45
00:04:12,080 --> 00:04:19,240
that, aggregate everything into one environment
that we replaces the consoles. So the

46
00:04:19,319 --> 00:04:25,079
monitoring tool replaces the consoles. Then
in order to do that, I said

47
00:04:25,120 --> 00:04:27,319
a few goals. The first is, come on, I need the same

48
00:04:27,360 --> 00:04:30,879
fidelity if the consoles are per second, I want this thing to be per

49
00:04:30,959 --> 00:04:34,360
second if the if the consoles have
I don't know ten thousand metrics, I

50
00:04:34,560 --> 00:04:39,000
want ten thousand metrics. So whatever
the consoles do, no, no,

51
00:04:39,600 --> 00:04:46,439
no discounts at all. Once I
started building these, and you know,

52
00:04:46,519 --> 00:04:49,519
the first generation of data was born, and actually I did the same thing

53
00:04:49,639 --> 00:04:56,079
that the console tools do in many
cases. So if you have a freeze

54
00:04:56,399 --> 00:05:00,000
or a point is missing, a
sample is missing, and something cannot because

55
00:05:00,000 --> 00:05:04,040
elected, then I have a gap. It's not something that smooths out today's

56
00:05:04,160 --> 00:05:11,160
monitoring systems, most of them smooth
it out. Yeah, but in the

57
00:05:11,319 --> 00:05:15,560
data from the first day, this
was a gap. I failed to collect

58
00:05:15,639 --> 00:05:23,240
that thing at that time. So
the idea is that I worked alone weekends

59
00:05:23,319 --> 00:05:29,319
and nights, and you know,
I was a COO in the day and

60
00:05:30,199 --> 00:05:38,319
an open source maintainer at night.
So after building this for a couple of

61
00:05:38,439 --> 00:05:44,040
years and enlisted so and the people
loved it, of course, mainly because

62
00:05:44,120 --> 00:05:48,759
it gave them all the fidelity that
they were missing from monitoring tools, all

63
00:05:48,800 --> 00:05:54,480
the information. It's also fully automated, so does boards come up by themselves.

64
00:05:54,680 --> 00:06:00,120
Everything happens by itself. So with
the discovery of metrics, everything so

65
00:06:00,360 --> 00:06:02,920
database or no moving parts, plugins, that the base everything isn't there.

66
00:06:03,920 --> 00:06:09,360
So once I saw the low it's
kirokeatet. I released it and it's kirokeated

67
00:06:09,399 --> 00:06:13,680
immediately, probably one of the fastest
growing products on githubs. So it got

68
00:06:13,800 --> 00:06:16,240
ten thousand git caub starts in two
weeks or something like that. Oh wow.

69
00:06:16,519 --> 00:06:21,519
So once I saw this, I
said, okay, you know,

70
00:06:21,800 --> 00:06:27,639
initially you feel the you feel proud, but at the same time you feel

71
00:06:27,680 --> 00:06:30,959
the responsibility. You say, well, now I have built something that is

72
00:06:30,040 --> 00:06:35,360
in total thousands systems around the globe. I hope I didn't mess it up

73
00:06:35,759 --> 00:06:43,079
somehow. So you feel the responsibility. So I started getting you know,

74
00:06:43,480 --> 00:06:47,279
ideas, and new people came in
and they were contributing and all this kind

75
00:06:47,319 --> 00:06:56,000
of you know work that happens in
communities. That was amazing. So a

76
00:06:56,040 --> 00:06:59,120
couple of years later I decided to
start a company. I said, okay,

77
00:06:59,399 --> 00:07:01,600
with we have something here. This
is not this is not a toy

78
00:07:01,680 --> 00:07:08,600
anymore. This is something important that
people use every day to actually monitor their

79
00:07:08,639 --> 00:07:13,600
systems. So the I this is
how Neata was born. Of course I

80
00:07:13,720 --> 00:07:16,439
needed to find a plan for you
know, because this is funded the funded

81
00:07:16,519 --> 00:07:21,680
companies, so you need somehow to
make money and be in the market,

82
00:07:21,800 --> 00:07:26,040
have to go to market strategy,
et cetera. So what I did then

83
00:07:26,199 --> 00:07:30,480
is that I decided that the most
important thing to do is to keep this

84
00:07:30,040 --> 00:07:35,959
high fidelity nature of data, real
time, high fidelity across the board everywhere.

85
00:07:36,439 --> 00:07:40,800
How do you scale that thing?
That's that's a tricky part. How

86
00:07:40,839 --> 00:07:45,519
do you scale it? Most of
the monitoring solutions centralize everything, even the

87
00:07:45,560 --> 00:07:48,839
commercials and the data dogs and Dina
trace and you really can all the all

88
00:07:48,879 --> 00:07:54,279
the all providers today, even the
open source from et cetera. All of

89
00:07:54,360 --> 00:08:00,480
them centralize everything to one database and
then query the database or this day basis

90
00:08:00,519 --> 00:08:03,240
one for medicine, for logs,
et cetera. How do you scale it?

91
00:08:05,600 --> 00:08:09,439
The first thing is that I said, okay, we have something that

92
00:08:09,600 --> 00:08:13,160
works at the edge and it's high
fidelity. It collects everything, has a

93
00:08:13,240 --> 00:08:18,480
lot more information, amazing coverage of
technologies, it is real time. Even

94
00:08:18,639 --> 00:08:22,439
the latency is amazing. So on
the data has one second data collection visualization

95
00:08:22,600 --> 00:08:26,560
latency. So your presenter on the
console to do a change and the next

96
00:08:26,600 --> 00:08:31,919
second that does work goes choosing the
result. Oh wow, So I said,

97
00:08:31,960 --> 00:08:37,200
okay, how do we change that, how do we scale it?

98
00:08:37,279 --> 00:08:43,279
And then I said, okay,
let's go distribute it. So instead of

99
00:08:43,360 --> 00:08:48,960
centralizing everything to one place that becomes
a hooge. After a while, it

100
00:08:48,120 --> 00:08:56,840
becomes overwhelmed that I said, okay, let's let's try a completely different approach.

101
00:08:56,080 --> 00:09:03,080
Let's have the data spread out across
the infrastructure in little islands here and

102
00:09:03,200 --> 00:09:09,200
there, and let's figure out a
way if we can do it to actually

103
00:09:09,759 --> 00:09:16,240
merge everything at quiritie can we have
the data all over the infrastructure and at

104
00:09:16,559 --> 00:09:22,000
the dashboard you have the feeling that
this is one thing you can see everything.

105
00:09:22,360 --> 00:09:26,679
So that was the idea, and
this is what we implemented. We

106
00:09:26,759 --> 00:09:31,759
spent a few years, we implemented
the thing. So today in the data

107
00:09:31,879 --> 00:09:35,919
is a modern solution that you installed
to discovered. Still all the same stuff

108
00:09:35,960 --> 00:09:39,600
exists today. So it's a modern
solution that you don't need to configure anything,

109
00:09:39,080 --> 00:09:45,879
mainly because we don't cherry pick information. So on the centralized infrastructure monitoring

110
00:09:45,919 --> 00:09:50,720
systems you have to cherry pick.
You have to know beforehand what metrids,

111
00:09:50,720 --> 00:09:54,320
which methods you need, how frequently
you need them. Since we eliminated this

112
00:09:54,519 --> 00:10:00,480
factor, so let's have everything in
high resolution. Again. The next goal

113
00:10:00,639 --> 00:10:05,240
was, okay, why to configure
anything? Since we can ingest everything,

114
00:10:05,919 --> 00:10:11,159
let's to discover everything. Let's just
ingest everything by default. The next goal

115
00:10:11,399 --> 00:10:16,159
was, okay, since we now
we ingest everything, why to go through

116
00:10:16,240 --> 00:10:22,000
the process of configuring dashboards metric by
metaic insult by charge. Let's find a

117
00:10:22,120 --> 00:10:28,519
way to create the meaningful doashboards out
of the box by itself. So we

118
00:10:28,639 --> 00:10:35,000
attached metadata that allows the data to
correlate the metrics run time and present them

119
00:10:35,039 --> 00:10:39,759
in beautiful dashboards meaningful doshboards. The
same happened with alerts. Since we collect

120
00:10:39,840 --> 00:10:45,000
everything, we have everything instead of
having alerts, you know the default threshold

121
00:10:45,039 --> 00:10:48,960
alerts that you have If the aggregated
bumps goes above this trigger an alert.

122
00:10:50,480 --> 00:10:52,600
Instead of doing this, what we
did is that, okay, can I

123
00:10:52,840 --> 00:11:00,799
monitor component by components bottom up the
entire infrastructure? So can we alarms for

124
00:11:00,919 --> 00:11:05,000
a disc, alarms for a netwical
interface, alarms for a container, alarms

125
00:11:05,039 --> 00:11:09,080
for a posters database for an instance
of posters, for an instance of an

126
00:11:09,120 --> 00:11:15,480
ENGINEX. So today we see about
three hundred and fifty alerts that monitor components

127
00:11:15,799 --> 00:11:18,759
of your infrastructure. Right, So, The idea is that you install a

128
00:11:18,879 --> 00:11:24,759
data and suddenly and out of the
box in minutes, in seconds, you

129
00:11:24,879 --> 00:11:30,120
have a fully functional politory system that
you didn't do anything to get it,

130
00:11:30,279 --> 00:11:33,480
apart from installing in the data.
That is the beauty. Wow. Okay,

131
00:11:33,840 --> 00:11:37,919
we got to pause there because I'm
just trying to wrap my head around

132
00:11:37,960 --> 00:11:43,120
this. Like hearing you say it, it just makes perfect sense. The

133
00:11:43,240 --> 00:11:48,120
part that I'm struggling with is like, this makes so much sense. Why

134
00:11:50,000 --> 00:11:54,639
am I three decades into my career
and just now having this revelation Because you

135
00:11:54,720 --> 00:12:00,480
know, like you said, like
when you install a monitoring system, it's

136
00:12:00,600 --> 00:12:05,759
like it's like getting grilled by an
interrogator. What day do you want?

137
00:12:05,919 --> 00:12:09,000
What stresholds are? What frequency?
And you're like, man, I don't

138
00:12:09,120 --> 00:12:16,200
know. I just got here when
you had these answers. Yes, and

139
00:12:16,360 --> 00:12:20,600
you know, we went a lot
further. So, for example, let's

140
00:12:20,600 --> 00:12:24,240
assume that you use that. So
you installed it, you have one hundred

141
00:12:24,279 --> 00:12:28,120
several, two hundreds of thousand servers, you installed the data. Everything works

142
00:12:28,159 --> 00:12:31,200
by itself, you have alert you
have doshboards. Everything works. Okay,

143
00:12:31,679 --> 00:12:35,519
now you go and see the dashboard. Wait a moment, you see the

144
00:12:35,679 --> 00:12:41,720
matrix for the first time. These
are metals you are not familiar, right,

145
00:12:41,559 --> 00:12:48,840
right? Can we make the charts
easy to grasp, to digest at

146
00:12:50,039 --> 00:12:54,559
first sight? And what information do
we need on a chart? So we

147
00:12:54,000 --> 00:12:58,240
invented the needle framework, the middle
frame. Google is a little tool but

148
00:12:58,320 --> 00:13:03,879
above every chart that are allows you
to understand where data are coming from,

149
00:13:03,080 --> 00:13:07,240
which notes, which instances, which
them, and what labels they have and

150
00:13:07,519 --> 00:13:15,120
give you statistics about the sources that
contribute to the chart. M hmm.

151
00:13:15,919 --> 00:13:20,480
Once you have this, then we
can we started discussing about Okay, now

152
00:13:20,559 --> 00:13:24,519
that we have really a lot of
metrics and everything is automated and everything is

153
00:13:24,639 --> 00:13:28,879
visualized by default, can we come
up you know, it's it's the trouble

154
00:13:28,919 --> 00:13:35,440
shooting that we say that there is
a troubleshooting to why because we try to

155
00:13:35,639 --> 00:13:41,919
solve the problem of being efficient a
troubleshooting time. So how how it works

156
00:13:41,919 --> 00:13:46,360
for more for most monitoring systems.
So you have an infrastructure and you face

157
00:13:46,399 --> 00:13:50,600
a problem there is a dive in
your shales or your users or whatever you

158
00:13:50,639 --> 00:13:54,440
say, a dive or a chart. Okay, what do you do next?

159
00:13:54,759 --> 00:14:01,559
You start speculating, Oh, probably
it's it's database. It's going the

160
00:14:01,639 --> 00:14:05,559
database if you don't have charge,
let's figure out how to build charge for

161
00:14:05,679 --> 00:14:11,320
that. Let's validate the assumption.
Oh, it's not the database, it

162
00:14:11,360 --> 00:14:13,159
should be the network. I think
we have a problem in a network.

163
00:14:13,240 --> 00:14:16,480
Right. This is how it works. You're speculating all the time and you

164
00:14:16,679 --> 00:14:24,240
hope that your experience will help you
pinpoint the right cause because the monitoring itself

165
00:14:24,279 --> 00:14:28,919
cannot tell you. So what we
did is that we added to the data

166
00:14:28,120 --> 00:14:37,320
supervised machine learning. So we train
multiple machine learning models for every metric,

167
00:14:37,960 --> 00:14:43,960
multiple for every metric. And then
what we do is that data is able

168
00:14:43,039 --> 00:14:48,279
to detect a normal list in real
time based on the past of its metric,

169
00:14:48,919 --> 00:14:52,759
so it is the path of its
metric trends models. And then during

170
00:14:54,000 --> 00:14:58,960
a collection, it decides if they
just collected value is an anomal orner it's

171
00:14:58,960 --> 00:15:03,000
an aler okay, And we store
this in the database. So together with

172
00:15:03,120 --> 00:15:05,519
example, we say oh, this
was a normalogy or no, no,

173
00:15:05,679 --> 00:15:11,399
this was long a noomas. Now
the beauty of this is that we create

174
00:15:11,480 --> 00:15:15,600
a tool we call it a dobe
advisor that you highlight a spike or a

175
00:15:15,679 --> 00:15:20,519
diver, whatever is interesting, and
we have we build a scoring engine inside

176
00:15:20,600 --> 00:15:24,879
inside the data, so it goes
for that timeframe that you highlighted across all

177
00:15:26,080 --> 00:15:30,679
the metrics. It doesn't matter how
many how many metrics are there, and

178
00:15:30,919 --> 00:15:37,440
scores them based on their anomaly rate. So your your your ham moment,

179
00:15:37,759 --> 00:15:41,159
Oh the disc did that is within
the list, so you don't need to

180
00:15:41,240 --> 00:15:46,519
speculate. We just go there,
press a button and the data comes up

181
00:15:46,600 --> 00:15:48,360
with a list. You show the
list. You say, okay, if

182
00:15:48,399 --> 00:15:50,879
this happened, this happened, I
know, I know, I know what

183
00:15:52,080 --> 00:15:56,440
is this? What happened here?
How the database did that, or why

184
00:15:56,480 --> 00:16:00,440
did this or why the network did
that. So the idea is to simplify

185
00:16:00,960 --> 00:16:08,679
tremendously trouble to allow yousers be a
lot more efficient in the resolution of problems.

186
00:16:10,720 --> 00:16:15,120
So not only do you have access
to the data points from the metrics,

187
00:16:15,200 --> 00:16:18,919
but you're also putting them in context. So when you look at the

188
00:16:19,559 --> 00:16:23,080
when you look at the graph or
the dashboard, you see the numbers,

189
00:16:23,120 --> 00:16:26,720
which you're providing context to say is
this a good number or is this a

190
00:16:26,759 --> 00:16:33,360
bad number? M HM. And
we in our visualization we have added an

191
00:16:33,360 --> 00:16:40,960
anormally ribbon where you can see in
real time what the anrmally the anomalists do

192
00:16:41,679 --> 00:16:47,720
the machine learning does how the machine
learning detects anomalists in real time. What

193
00:16:47,919 --> 00:16:53,000
we found also is so when we
had all this infrastructure that was training all

194
00:16:53,080 --> 00:16:59,519
this kind of stuff and detecting anomalists
in real time, we realize that anormalist

195
00:16:59,600 --> 00:17:04,960
happening clusters. So you go there
and you see that they are normal lists

196
00:17:06,559 --> 00:17:11,079
on across nodes happening in clusters within
a node. So a lot of methods

197
00:17:11,119 --> 00:17:15,519
get anomalous wearing something or when there
is an anomally within a node, but

198
00:17:15,640 --> 00:17:19,880
also a lot of notes together in
very short time, one after the other,

199
00:17:21,000 --> 00:17:26,720
they get anomalous high in a great
percentage. So we didn't know that.

200
00:17:26,000 --> 00:17:33,559
We realize this by we're reviewing the
data and then we build a tune

201
00:17:33,960 --> 00:17:41,440
to actually to allow people to review
a normal list across the infrastructure. So

202
00:17:41,599 --> 00:17:45,160
now we have a chart, for
example, that gives you for a line

203
00:17:45,240 --> 00:17:49,519
for every node that you have,
and it's a percent that the percentage of

204
00:17:49,680 --> 00:17:56,759
metrics being anomalous concurrently, so you
can see the strength of the anomally and

205
00:17:56,880 --> 00:18:00,440
the spread of the anomally that at
the same time. So this is the

206
00:18:02,039 --> 00:18:04,839
story. This is a short the
story of data. Let's say we are

207
00:18:04,960 --> 00:18:14,799
trying to make observability a lot more, a lot easier for people to tell

208
00:18:14,839 --> 00:18:21,559
you that there was when develops started, there was this little diagram that the

209
00:18:21,880 --> 00:18:26,720
consultants or the consultants films. They
were saying that, you know, devlops

210
00:18:27,319 --> 00:18:36,920
is a joint between data science,
software engineering, and IT infrastructure, and

211
00:18:37,079 --> 00:18:41,400
were saying, at the at the
the three bubbles, at the point they

212
00:18:41,599 --> 00:18:47,359
join, all three of them,
you have DeVos. My understanding, this

213
00:18:47,519 --> 00:18:52,119
is in theory it is okay,
but in practice to have an extremely good

214
00:18:52,240 --> 00:18:59,519
data scientist that is also software engineer
and it knows about IT architecture and the

215
00:18:59,680 --> 00:19:03,200
depth of the IT technology that exists. Come on, guys, this guy

216
00:19:03,279 --> 00:19:08,559
does not exist. I don't know
if the world may have a couple of

217
00:19:08,640 --> 00:19:11,440
them, three of them, I
don't know for sure. You cannot have

218
00:19:11,599 --> 00:19:18,599
one next to you. The idea
is that monitoring needs to be simpler,

219
00:19:18,920 --> 00:19:23,039
and it can be simpler. No
need to learn query within the data.

220
00:19:23,160 --> 00:19:26,319
We don't. You don't need to
learn query language so you can filter,

221
00:19:26,519 --> 00:19:32,480
slice dies the data. You know, it's like a tube. You can

222
00:19:33,000 --> 00:19:36,559
change the tube the way you see
I fits by point and click to create

223
00:19:36,640 --> 00:19:40,720
those words by drag and drop.
So the idea is that we are trying,

224
00:19:41,000 --> 00:19:45,319
let's say, let's say that we
we try to bring the technology in

225
00:19:45,440 --> 00:19:52,319
the monitoring technology that the best organization
of this world have so real time per

226
00:19:52,400 --> 00:20:00,880
second high resolution machine learning everywhere and
bring it to everyone in a very simply

227
00:20:03,000 --> 00:20:07,359
affordable package. Because the data also
is mainly because of its distributed design,

228
00:20:08,039 --> 00:20:12,839
is the most cost efficient solution.
Oh right, yeah, because you're not

229
00:20:12,960 --> 00:20:18,279
stuck with a couple of years from
now having to run these monster servers just

230
00:20:18,400 --> 00:20:22,920
to maintain the amount of data you
got. Actually, we use resources,

231
00:20:23,319 --> 00:20:29,160
computer resources that are available and spare. It's your servers. They have two

232
00:20:29,240 --> 00:20:33,039
PERCENTPE to spare and I don't know, two hundred megabytes of RAM, that's

233
00:20:33,079 --> 00:20:37,440
easy. And this is what we
use. Two percent cype of a single

234
00:20:37,480 --> 00:20:41,559
core, three percent cype of a
single core. This is what data needs.

235
00:20:41,119 --> 00:20:48,279
Resources and two hundred megabytes of RUM
and I don't know one gigabyte or

236
00:20:48,440 --> 00:20:53,759
two gigabytes of this that's it.
Well, So not to mention that if

237
00:20:53,799 --> 00:21:00,720
you compare with commercial offerings, all
of them require tremendous mount of egress bandwidth.

238
00:21:03,799 --> 00:21:08,880
The data does not stream anywhere.
It's it's inside there, so it

239
00:21:10,359 --> 00:21:14,440
out egress. Banquet will be used
only when you view the dashboard. If

240
00:21:14,480 --> 00:21:19,839
you don't view, there's nothing there, there's no egress. So that's the

241
00:21:19,880 --> 00:21:26,160
whole point. Simplify. Take something
that is the best out there. We

242
00:21:26,319 --> 00:21:33,119
integrated in the data technoledge for example
that we use a variation of Gorilla compression.

243
00:21:33,440 --> 00:21:41,039
But Facebook developed so Facebook has developed
a real time high resolution monitoring system

244
00:21:41,640 --> 00:21:45,119
data base, time data base,
and it's called Gorilla. We took the

245
00:21:45,200 --> 00:21:48,960
concept, we adapted to the data
and now Gorilla compressions in the data.

246
00:21:49,200 --> 00:21:53,160
So that's across the board. That's
what we do. Across the board.

247
00:21:53,319 --> 00:21:56,240
We're trying to bring the best and
give it to a This is why we

248
00:21:56,359 --> 00:22:07,759
say that we democratized monitor So when
you get to this level where you're bringing

249
00:22:07,799 --> 00:22:15,759
in this granular data from all across
your infrastructure, how do you how do

250
00:22:15,799 --> 00:22:18,880
you determine what's a surface for the
user? Because that seems like an avenue

251
00:22:18,920 --> 00:22:25,480
where you can get to information overload
really really quickly. So the idea is

252
00:22:25,519 --> 00:22:30,240
that, Yeah, so the idea
is that we group everything into meaningful stuff,

253
00:22:30,640 --> 00:22:34,720
so you have you go and it
says, here are medical interfaces,

254
00:22:34,880 --> 00:22:40,480
the top information about network, the
faces, this package and bandwidth for example

255
00:22:40,480 --> 00:22:42,799
in terrors. But then that are
all that is that you may need in

256
00:22:44,000 --> 00:22:48,640
order to explore what's happening. The
same happens everywhere, so your database,

257
00:22:48,680 --> 00:22:52,319
ever, your even your tables.
Do we go down to the intex level?

258
00:22:53,000 --> 00:23:00,200
Now all this information mainly because we
have this scoring. Eagine when when

259
00:23:00,279 --> 00:23:03,559
you don't know what to do,
so you are in a dashboard it has

260
00:23:03,599 --> 00:23:07,000
five hundred charge on it. Okay, what do I do now here?

261
00:23:07,839 --> 00:23:11,480
The first thing is that we there
is a button that says, okay,

262
00:23:14,599 --> 00:23:22,160
identify for me the ones that are
currently in the visible time frame, the

263
00:23:22,279 --> 00:23:26,200
most unormalous for example, so to
give you something to look at. You

264
00:23:26,279 --> 00:23:30,119
know, when you are looking for
something, you don't know where to start,

265
00:23:30,880 --> 00:23:36,400
but it will identify the doshboard sections. Okay, here I have twenty

266
00:23:36,440 --> 00:23:41,799
percent. Normally this is bad,
go look here. So the idea is

267
00:23:42,279 --> 00:23:49,880
one we've developed tools to help people
with the information overloads, let's say.

268
00:23:51,440 --> 00:23:56,880
But the most important thing is that
there are people that are afraid this information

269
00:23:56,000 --> 00:24:03,119
overload. There are other people that
enjoy the depth and the detail. What

270
00:24:03,400 --> 00:24:10,480
we hear from users is that when
you use the data for some time to

271
00:24:10,599 --> 00:24:14,359
explore your infrast actions. Let's assume
that you're not troubleshooting anything. You just

272
00:24:14,519 --> 00:24:21,599
want to understand. It's like feeling
the pulse and the breath of the infrastruction.

273
00:24:21,759 --> 00:24:25,079
You feel it because you see it
on every second. It's extremely high

274
00:24:25,119 --> 00:24:32,480
resolution, so you can understand what
is really happening there. And I think

275
00:24:32,559 --> 00:24:34,960
that this is the most important.
Of course, it's a tool for people

276
00:24:36,000 --> 00:24:40,000
that want to learn. If someone
wants to just traffic lights, oh it's

277
00:24:40,119 --> 00:24:45,359
healthy, it's not healthy. If
someone wants just this, it's very whelming

278
00:24:45,519 --> 00:24:49,640
for them. But if someone wants
to learn to dive, to understand to

279
00:24:49,839 --> 00:24:56,839
fix the problem, this is where
in the data steps in. Wow,

280
00:25:00,440 --> 00:25:04,640
that's wild, that's wild. I
mean, you know, because I feel

281
00:25:04,720 --> 00:25:10,640
like from my own personal perspective,
like you know, we've been approaching monitoring

282
00:25:10,720 --> 00:25:18,839
and observability the same way for so
long and then this just completely flips all

283
00:25:18,920 --> 00:25:23,160
of that upside down. But that's
the whole point, and I think this

284
00:25:23,319 --> 00:25:27,880
is the monitoring system that is missing
today. So PROMI, for example,

285
00:25:27,920 --> 00:25:34,279
are amazing for customizability. You can
build whatever imaginable you imagine it, you

286
00:25:34,359 --> 00:25:41,480
build it great. The big guys
data dog Dinah, Trace and they likes.

287
00:25:41,559 --> 00:25:45,519
They try to give you a silicopter
view of the most important things.

288
00:25:45,759 --> 00:25:55,039
Although they value high resolution, they
charge high resolutions, they are not by

289
00:25:55,119 --> 00:26:03,160
default. So I think that there
was no tool to cover this, this

290
00:26:03,559 --> 00:26:08,279
this area of real time deep dive
monitoring that you can go and take some

291
00:26:08,480 --> 00:26:15,400
in everything in high resolution and very
detailed. To tell you the truth I

292
00:26:15,599 --> 00:26:22,160
have. The simplicity that we added
to the tool is one thing that our

293
00:26:22,279 --> 00:26:26,440
users love. So when I go
and speak about data, I see in

294
00:26:27,079 --> 00:26:32,960
many I was enforced them, for
example a month ago, and it was

295
00:26:33,039 --> 00:26:41,119
amazing because you see people that are
skeptical about observability. There are some that

296
00:26:41,279 --> 00:26:48,039
are the point of observability denial.
The idea is that what they have an

297
00:26:48,119 --> 00:26:52,480
argument. What they say is that
come on, this is too complex,

298
00:26:52,759 --> 00:26:59,319
too expensive for what I get for
sure. So with what we tried,

299
00:26:59,880 --> 00:27:04,599
the the fact that we solve the
cardinalti granularity problem and we can scale infinitely

300
00:27:04,720 --> 00:27:11,240
without actually becoming a problem, this
allowed us to become a lot simpler.

301
00:27:12,000 --> 00:27:17,240
So it does a lot more.
But the thing is simple. You don't

302
00:27:17,359 --> 00:27:22,319
have to do anything, you just
have to use it. So this is

303
00:27:22,559 --> 00:27:26,039
I think that this is the booming
factor, is that it is higher resolution

304
00:27:26,400 --> 00:27:30,480
and at the same time extremely easy. You don't have to do anything.

305
00:27:30,559 --> 00:27:34,519
It doesn't require from you, not
even resources. Just give it the resources

306
00:27:34,559 --> 00:27:40,680
that you already have and that's pair. So I think this is the This

307
00:27:40,880 --> 00:27:45,960
is the combination of things that make
the data so appealing to you. Yeah,

308
00:27:47,039 --> 00:27:49,119
for sure, especially the ease of
use thing, because a lot of

309
00:27:49,559 --> 00:27:57,359
the other observability tools and just my
own personal experience with them is they they

310
00:27:57,480 --> 00:28:03,720
rely on me too much, and
and they rely on me to know what

311
00:28:03,960 --> 00:28:07,240
questions to ask. And I'm like, man, if I knew a question

312
00:28:07,440 --> 00:28:12,279
to ask, I probably wouldn't be
asking. You wouldn't be Yeah, yeah,

313
00:28:12,920 --> 00:28:18,759
you know. The interesting part is
that some people when it is when

314
00:28:18,519 --> 00:28:22,920
they hear, for example, a
distributed monitoring solution that everything is at the

315
00:28:22,039 --> 00:28:26,279
edge, the first thing that they
say is way the moment, man,

316
00:28:26,759 --> 00:28:33,240
this is going to be more heavy
than the other agents, right. Yeah.

317
00:28:33,640 --> 00:28:36,359
We did a comparison on our side. There is a blog post where

318
00:28:36,359 --> 00:28:41,440
I could compare the agents of all
monitoring solutions that we could find. The

319
00:28:41,640 --> 00:28:45,839
data is one of the lightest.
So the core of the data is written

320
00:28:45,880 --> 00:28:52,440
insane. It's severely optimized to be
performance m of course we have plug ins

321
00:28:52,480 --> 00:28:56,359
and the likes that are high leveled
and written in goal or whatever, but

322
00:28:56,599 --> 00:29:04,480
the core is x extremely optimized to
be very efficient. For example, we

323
00:29:04,599 --> 00:29:10,640
have we did a stress test against
against Prometheos, mainly because Promethels is the

324
00:29:10,799 --> 00:29:15,319
industry studdard. So one third,
let's SPU same lod. So we gave

325
00:29:15,400 --> 00:29:21,759
them three terabytes to almost three million
metrics and we said per second, everything

326
00:29:21,799 --> 00:29:25,119
per second, and we said again, let's let's see the resources that both

327
00:29:25,200 --> 00:29:30,319
systems need. The data and Promethels
the data used one third LESSIPU, half

328
00:29:30,400 --> 00:29:37,839
the memory, it used ten percent
less bandwidth, ninety eight percent less diskyo,

329
00:29:37,160 --> 00:29:44,400
almost the disc was idle all the
time with the data, and seventy

330
00:29:44,920 --> 00:29:51,519
it managed to fit seventy five percent
more data into the same store. So

331
00:29:51,759 --> 00:29:57,880
we have for example promythees has either
uncompressed data on disc at two points something

332
00:29:57,960 --> 00:30:04,200
two point ten and if I remember
correctly bites per example on disc or compressed

333
00:30:04,279 --> 00:30:10,920
with Gorilla that goes to one point
three one point three bytes per sample.

334
00:30:11,799 --> 00:30:18,160
The data has zero point five zero
point half a byte per sample on disc.

335
00:30:21,079 --> 00:30:22,960
It's extremely efficient. This is this
is why we did it in c

336
00:30:23,720 --> 00:30:27,559
to make it extremely efficient. Yeah, for sure, for sure. And

337
00:30:29,440 --> 00:30:33,039
you know the data traditionally was only
metrics. But last year I said,

338
00:30:33,519 --> 00:30:41,119
we had built our own logs management
thing, so it logs database that we're

339
00:30:41,119 --> 00:30:45,039
integrated into in the data. But
then last year I said, wait,

340
00:30:45,119 --> 00:30:49,279
the moment I think we're doing it
wrong, I realized that all of us

341
00:30:49,680 --> 00:30:53,200
have a new system, the journey. System the Journal is part of system

342
00:30:53,279 --> 00:31:00,519
G fort the logs, et cetera. This thing is amazing. Probably we

343
00:31:00,640 --> 00:31:06,759
don't know it, but it is
amazing. All the logs management systems they

344
00:31:07,039 --> 00:31:12,480
sufferre from cardinality. So how many
streams of data are right right? System

345
00:31:12,559 --> 00:31:18,200
the Journal does not care. So
every log line can have its own fields

346
00:31:18,799 --> 00:31:25,079
and its own values on these fields, and all of them will be indexed,

347
00:31:25,279 --> 00:31:32,880
all of them. So cardinality not
the problem. Full indexing on everything

348
00:31:33,000 --> 00:31:34,960
the only problem that has. So
even if you centralize, you put a

349
00:31:36,039 --> 00:31:41,680
lot of logs, web server logs
for jump to it. The ingestion process,

350
00:31:41,759 --> 00:31:48,319
et cetera. Are extremely optimized for
system the journal. The only problem

351
00:31:48,400 --> 00:31:52,480
that it has is that they need
disk space, so it requires more disk

352
00:31:52,559 --> 00:31:56,359
space than the rest, but it
does more with the disk space, and

353
00:31:56,400 --> 00:31:59,759
at the same time it is secure. It's the only logs management solution that

354
00:31:59,880 --> 00:32:08,160
has us fall tolerance and high availability
and even secure ceiling for securescess for ceiling,

355
00:32:08,599 --> 00:32:15,559
so it ensures that the logs cannot
be tempered. So the idea,

356
00:32:15,839 --> 00:32:22,000
the way we managed to use system
the journal is exactly the same way with

357
00:32:22,279 --> 00:32:27,519
the data, so we use them
in a distributed way. You don't need

358
00:32:27,559 --> 00:32:32,519
to centralize your logs. Why the
whole world tries to build a logs processing

359
00:32:32,599 --> 00:32:37,880
pipeline and they try to install real
time tools to do analysis and the likes

360
00:32:37,920 --> 00:32:40,839
and all this kind of stuff,
you know, in order to get insights

361
00:32:40,839 --> 00:32:46,160
from the logs. And what we
said is why do we need the pipeline

362
00:32:46,200 --> 00:32:52,480
in the first place. We have
an agent next to the logs that can

363
00:32:52,759 --> 00:32:58,640
quate the logs in real time,
extract all the information needed and report it.

364
00:33:00,119 --> 00:33:02,720
So why why to move the logs
from there? Let them be there.

365
00:33:05,079 --> 00:33:07,359
Yes, that's the same same approach
as you were talking about with the

366
00:33:07,720 --> 00:33:12,200
metrics collection you've got. You can
just take a little bit of the CPU

367
00:33:12,319 --> 00:33:15,279
and the memory that's not being used
on as system and just do the work

368
00:33:15,400 --> 00:33:22,839
there rather than the transport method of
shipping it off someplace and dealing with this

369
00:33:22,920 --> 00:33:27,039
stuff in volume. Of course,
we have centralization points, so if you

370
00:33:27,079 --> 00:33:30,799
have a femeral, you have a
coubernetus cluster, you can have any data

371
00:33:30,920 --> 00:33:32,960
partent. This is how we call
it. It's the same software thet but

372
00:33:34,079 --> 00:33:37,559
you have a parent now, so
all the ephemeral notes push metrics to it

373
00:33:37,640 --> 00:33:40,279
in real time. But these are
small and only do the degree need it,

374
00:33:40,759 --> 00:33:45,519
so you don't need to centralize your
entire infrastructure to this. And you

375
00:33:45,640 --> 00:33:49,920
can have multiple centralization points, one
here, one there on if you are

376
00:33:49,960 --> 00:33:52,759
a high if you have if you
use a hybrid cloud, you can have

377
00:33:52,920 --> 00:33:55,519
one on a WUS, one on
a P one on Azure, one on

378
00:33:55,720 --> 00:34:00,440
prem whatever. So the flexibility that
you have. You can have the same

379
00:34:00,559 --> 00:34:06,559
system the journal, you can have
centralization points which system Digenal methodology is not

380
00:34:06,559 --> 00:34:10,000
in the data system, the journal
remote and system the general upload, but

381
00:34:10,280 --> 00:34:16,079
it's exactly the same philosophy centralized to
the degree required for your operational needs.

382
00:34:16,760 --> 00:34:22,320
Yeah, and not because the system, the monitoring system requires it. So

383
00:34:22,400 --> 00:34:28,920
it's your operational needs that require some
centralization of some kind, gotcha. Yeah,

384
00:34:29,000 --> 00:34:31,960
So that puts the that puts the
decision back on you to meet the

385
00:34:32,039 --> 00:34:37,920
needs of your business rather than putting
the burden on you because of the tool

386
00:34:37,960 --> 00:34:42,639
that you chose. So and also
you can centralize for high high availability.

387
00:34:42,760 --> 00:34:45,800
Do you need high availability? Of
course, push the metrics somewhere, the

388
00:34:45,840 --> 00:34:49,320
logs pustem somewhere, to have two
copies of them, of course. But

389
00:34:49,559 --> 00:34:54,119
this is the idea. You centralize
for operasonal needs, not because the monitoring

390
00:34:54,159 --> 00:35:01,119
system mandates it, right, Yeah, yeah, I got you. That's

391
00:35:01,239 --> 00:35:06,480
wild. This is just this is
just I feel bad saying this, but

392
00:35:06,559 --> 00:35:10,199
it really is mind blowing to me
because it just makes so much sense.

393
00:35:12,159 --> 00:35:19,280
And I'm just I'm just shocked that
it's so obvious. But here we are.

394
00:35:20,880 --> 00:35:23,199
That's the beauty of it. You
know that most of the monitoring systems,

395
00:35:23,239 --> 00:35:29,639
you know, the monitoring systems evolved. There is a Initially we had

396
00:35:29,800 --> 00:35:34,840
nagios and the likes vise were check
basis. So they run a check,

397
00:35:35,519 --> 00:35:37,840
they take a result. Together with
the result, probably they have one or

398
00:35:37,880 --> 00:35:44,599
two metrics or some logline or something, a string to say what's wrong,

399
00:35:45,119 --> 00:35:50,800
and the check has status one or
more status actions there it may be healthy

400
00:35:50,840 --> 00:35:54,760
and healthy or warning or whatever.
All the systems, not the zubis,

401
00:35:55,000 --> 00:36:00,960
Essensiu, Insigna, solar, Aguain, spirited, the all of them are

402
00:36:00,079 --> 00:36:06,920
in this the first generation of check
based systems. Right then the world went

403
00:36:07,000 --> 00:36:15,480
to from technology that is metrics logs, so metrics databases, logs databases.

404
00:36:15,559 --> 00:36:20,039
It's not checks anymore. We gather
the information, we put them in the

405
00:36:20,119 --> 00:36:23,719
database, and the go analyze the
database. The problem with this is that

406
00:36:24,079 --> 00:36:29,400
it struggles at scales. It is
expensive generally to run, so you need

407
00:36:29,480 --> 00:36:37,000
to filter, you need to slower
the resolution. Cherry pic metrics lose some

408
00:36:37,199 --> 00:36:43,000
metrics some information in order to have
a performance system and a performance centralized system.

409
00:36:43,679 --> 00:36:47,360
Of course, this philosophy the guys, the data dog and Dinatries and

410
00:36:47,360 --> 00:36:52,519
the likes, they took it and
they built integrated environments, very nice,

411
00:36:52,920 --> 00:36:58,239
very nice, inte great environments.
So what we do is, I think

412
00:36:58,400 --> 00:37:02,519
it is the next generation. It's
the next evolution. So we take this

413
00:37:02,679 --> 00:37:07,400
philosophy of metrics, logs, et
cetera, et cetera, where you don't

414
00:37:07,440 --> 00:37:13,079
do checks right, but the checks
are on the logs and the metrics and

415
00:37:13,199 --> 00:37:19,280
the data, and we did it
distribute it. So we did it in

416
00:37:19,360 --> 00:37:24,480
a way that it's still integrated,
it's still one infrastructure, but we eliminated

417
00:37:24,880 --> 00:37:31,840
all the problems there that forced people
so far to provide low resolution insights or

418
00:37:32,199 --> 00:37:37,840
eliminate several insights from it, et
cetera. And I think that we did

419
00:37:37,880 --> 00:37:42,519
it in a very efficient way.
So the way I think of it is

420
00:37:42,559 --> 00:37:46,719
that the data is the next evolution
of monitoring systems, and it's nice to

421
00:37:46,800 --> 00:37:52,320
see. You know, one aspect
that we didn't speak so far is the

422
00:37:52,400 --> 00:37:57,639
following the data has. You know, monitoring systems are metrics, logs,

423
00:37:57,679 --> 00:38:00,440
traces. We don't do traces yet. I think we're when I started soon

424
00:38:00,639 --> 00:38:05,119
and it's going to be also distributed. But metrics locks, let's say,

425
00:38:05,119 --> 00:38:08,599
for the number and traces when you
have micro services. Developing micro services,

426
00:38:10,000 --> 00:38:15,519
what we found out is that there
are a lot of information that is neither.

427
00:38:16,000 --> 00:38:20,920
It's not metrics, it's not logs, it's not traces. It's all

428
00:38:20,960 --> 00:38:23,519
the show cats, for example,
all the network connections that the system has,

429
00:38:24,000 --> 00:38:30,440
it's all the the processes that run. It's so it's all the files

430
00:38:30,480 --> 00:38:37,239
that are open. So the idea
is that we created a mechanism where are

431
00:38:37,239 --> 00:38:43,159
our collectors the click ins that collect
data. So they collect to a postgress

432
00:38:43,320 --> 00:38:46,719
for the connect to posts to collect
for some some metrics. But they expose

433
00:38:46,800 --> 00:38:52,719
a function that allows the dashboard to
say, okay, show me the slow

434
00:38:52,800 --> 00:38:58,440
queries of postives. So query posts
the slow queries and give me a list

435
00:38:59,360 --> 00:39:02,239
of the slow which is that are
currently running. Similarly, give me all

436
00:39:02,280 --> 00:39:07,400
the network connections or the outbound connection
or the inbound connections, or the listening

437
00:39:07,519 --> 00:39:12,000
circuits. Show me all the processes
that are running. So the idea is

438
00:39:12,079 --> 00:39:20,000
that at the end we created a
monitoring tool. It's the original idea when

439
00:39:20,039 --> 00:39:24,360
you're trying to kill all the consoles, who still do right the consoles?

440
00:39:27,079 --> 00:39:30,920
Yeah, because that's like that's again
that's additional context. You know, you

441
00:39:30,039 --> 00:39:37,400
get your list of slow queries from
postgrass and eventually, if you don't quickly

442
00:39:37,480 --> 00:39:40,280
see oh well this is this is
a query problem because we're missing an index

443
00:39:40,480 --> 00:39:45,519
or whatever, you do end up
you know, sshing into that system and

444
00:39:45,679 --> 00:39:51,199
running top and checking the open files
handles and all of that stuff. Because

445
00:39:52,000 --> 00:39:59,239
no one can afford to run full
time monitoring of that level of detail using

446
00:39:59,480 --> 00:40:02,639
some of the other monitoring tools like
you you you would bankrupt your company trying

447
00:40:02,639 --> 00:40:07,719
to collect and store all of that
data exactly, and this is exactly what

448
00:40:07,000 --> 00:40:13,199
the data changes. So it's more
it's more cost deficient to run the data

449
00:40:13,519 --> 00:40:20,039
than running any other Commercially, it's
more cost deficient because we don't need resources,

450
00:40:20,079 --> 00:40:25,079
you don't need skills. It just
works. Yeah, and and the

451
00:40:25,159 --> 00:40:30,599
information is just there when you need
it. But it's not hurting when you

452
00:40:30,679 --> 00:40:34,159
don't need it. It's not costing
you when you don't need it. Exactly.

453
00:40:34,719 --> 00:40:42,880
Wow, So what's the what's the
onboarding process look like to start using

454
00:40:43,039 --> 00:40:47,800
that data? So today we have
so there is the open source agent that

455
00:40:47,960 --> 00:40:53,960
you We have two paths how people
can join the community. Two paths.

456
00:40:54,119 --> 00:41:00,519
One is you are a did have
fun open source fun or whatever and enthusiasts.

457
00:41:01,039 --> 00:41:06,320
You go and install the data the
agent. The agent is monitoring in

458
00:41:06,360 --> 00:41:08,519
a box, so by itself on
a single node, you will have it

459
00:41:08,639 --> 00:41:12,800
will do everything, does watch,
alert everything, it will do that do

460
00:41:12,920 --> 00:41:15,360
them for you. That's one path, and then you will you do the

461
00:41:15,400 --> 00:41:21,119
second installation the third and then you
realize that you can build parents or you

462
00:41:21,199 --> 00:41:25,320
can use nedata Cloud to unify an
infrastructure. The other part is that people

463
00:41:25,440 --> 00:41:30,519
that are looking companies that are looking
to replace their monitoring system, they go

464
00:41:30,639 --> 00:41:35,679
to the first five through Google or
whatever, they find our site. So

465
00:41:35,840 --> 00:41:39,599
they went to our site. There
is a trial where they sign up to

466
00:41:39,880 --> 00:41:46,320
nedata Cloud this time and nedata Cloud
instructs them to install agents with certain keys

467
00:41:46,320 --> 00:41:52,159
et cetera. In short, in
order to link them with their own space,

468
00:41:52,199 --> 00:41:58,440
their own account. So in both
cases you start for free. Nedata

469
00:41:58,480 --> 00:42:02,960
Cloud is a thing do centralize data. So the data are still distributed,

470
00:42:04,039 --> 00:42:07,199
but nedda Cloud is a layer that
builds a map of your topology, so

471
00:42:07,320 --> 00:42:12,119
it knows where are the nodes and
what retention they have and what metrics they

472
00:42:12,199 --> 00:42:16,760
have without centralizing the metrics themselves the
values. And then when you go to

473
00:42:16,920 --> 00:42:21,679
queer data, ne Data Cloud says, okay, I'm gonna quer this this

474
00:42:21,880 --> 00:42:24,519
and that notes to get the data, merges the data present them to you.

475
00:42:25,880 --> 00:42:30,639
Okay, all these are in real
time. All these yea, there's

476
00:42:30,679 --> 00:42:37,039
no latencies there. All these are
like these very very quick. So the

477
00:42:37,159 --> 00:42:40,480
idea is that people can start either
by the open source world, go to

478
00:42:40,519 --> 00:42:46,119
GitHub, download the software, install
it, or they can from a commercial

479
00:42:46,199 --> 00:42:52,800
world go to nedata cloud, sign
up a trial. Again, you're gonna

480
00:42:52,800 --> 00:42:55,880
download the agents, et cetera.
So Neddada Cloud, our commercial offering,

481
00:42:55,960 --> 00:43:00,239
let's say, uses the agents as
a distributed base, so we don't have

482
00:43:00,880 --> 00:43:06,159
different enterprise agents. It's the same
thing in the open source software. But

483
00:43:06,360 --> 00:43:10,679
what it provides is the following.
The first it allows it allows you to

484
00:43:10,719 --> 00:43:15,519
skill your infrastructure horizontally. So if
you don't use an data cloud, the

485
00:43:15,639 --> 00:43:20,679
only thing you can do is bigger, build a bigger parent, bigger and

486
00:43:20,760 --> 00:43:24,239
bigger and bigger to aggregate all the
infrastructure there. Like the old traditional centralized

487
00:43:24,239 --> 00:43:29,920
systems, it skills better than them, but still it's one system. This

488
00:43:30,800 --> 00:43:35,480
is one way with n data cloud. You can have as many independent centralization

489
00:43:35,639 --> 00:43:39,159
points or individual standard loone servers and
all of them will become one at query

490
00:43:39,239 --> 00:43:44,639
type. The second is success from
anywhere, so the agents. You need

491
00:43:44,679 --> 00:43:47,519
to hit the IP of the server
to access the dark ware for the data

492
00:43:47,559 --> 00:43:51,239
cloud. It doesn't matter. You
look into up in the data cloud and

493
00:43:51,519 --> 00:43:55,599
then you access severity. The data
cloud gives you a mobile lab for push

494
00:43:55,639 --> 00:44:00,480
notifications, so all the alerts across
the infrastruction will be pushed to your mobile

495
00:44:00,519 --> 00:44:08,280
lab adroid and dios. And also
it dispatches alert centrally. So instead of

496
00:44:08,320 --> 00:44:14,079
dispatching all the ages to dispatch alerts
to slug or pay your duty or whatever

497
00:44:14,199 --> 00:44:20,400
email whatever you use, the data
clouds receives all the transitions that dapplicates them

498
00:44:20,840 --> 00:44:25,119
and then dispatches the alert central.
There is a free ti air two for

499
00:44:25,679 --> 00:44:30,679
home users, et cetera. There
is a small free air on data cloud

500
00:44:31,119 --> 00:44:37,480
But overall, you know, mainly
because we decop it the cost of observability

501
00:44:38,760 --> 00:44:45,920
from the monitoring itself, it is
a lot significantly more cost efficient. So

502
00:44:46,119 --> 00:44:51,559
if you go for the commercial offering, if you go to data with the

503
00:44:51,639 --> 00:44:58,000
legs, you start at twenty and
thirty dollars a month per not right three

504
00:44:59,159 --> 00:45:02,960
oh wow. And even with data
Dog, like when you start with that

505
00:45:04,159 --> 00:45:13,400
level like that, quickly you quickly
learn that that's only the monitoring costs.

506
00:45:13,480 --> 00:45:15,639
Like once you start bringing in the
data, there's data charges as well,

507
00:45:15,760 --> 00:45:25,719
and those others I have actually here
because we did this comparison about the resources

508
00:45:27,360 --> 00:45:32,599
that data Dog for example needs versus
Data Sepe. Usage of the Data Dog

509
00:45:32,679 --> 00:45:39,639
agent fourteen percent the data through three
point six memory usage data DOG almost a

510
00:45:39,679 --> 00:45:45,239
gigabyte nine hundred and seventy two megabytes
are from the data one hundred and eighty

511
00:45:45,280 --> 00:45:54,679
one egress pernude eleven gabytes per month
perndes. The data nothing doesn't need an

512
00:45:54,800 --> 00:46:05,159
egress barnment. So it's you.
It's more expensive and you put more resources

513
00:46:05,199 --> 00:46:13,960
to it compared to Yeah, wow, So are there are there you?

514
00:46:14,079 --> 00:46:16,280
You know, we mentioned early on
in the podcast that your background started with

515
00:46:17,400 --> 00:46:27,159
retail transactions point of sale systems,
which are very high throughput and if you've

516
00:46:27,159 --> 00:46:35,639
ever worked in retail with a customer, they're they're not the most they're the

517
00:46:35,800 --> 00:46:37,719
easiest things to deal with. So
you come from a high stress environment.

518
00:46:38,079 --> 00:46:45,239
Are there is that? Is that
indicative of the type of customers who really

519
00:46:45,599 --> 00:46:50,119
embrace net data or is there a
specific industry that you work really really well

520
00:46:50,159 --> 00:46:52,840
with. I think we have people, we have businesses from all over the

521
00:46:53,599 --> 00:46:59,280
old industries. So we have people
from health care, we have people from

522
00:46:59,400 --> 00:47:04,880
manufacturing, we have people from technology, a lot of technology of course,

523
00:47:04,960 --> 00:47:10,719
right, So I think that the
key point here is, Look, if

524
00:47:10,760 --> 00:47:15,639
you go to a DevOps guy that
wake ups at three A at three am.

525
00:47:15,800 --> 00:47:22,840
We have another like this that says, I love three am. If

526
00:47:22,880 --> 00:47:27,079
you have a guy that wake ups
at three am, you have to understand

527
00:47:27,159 --> 00:47:34,280
that at three am has he's pissed
off? So you have you have to

528
00:47:34,440 --> 00:47:39,920
be real time. We have many
big companies, really among the Fortune five

529
00:47:40,039 --> 00:47:49,760
hundred say companies that they don't accept
the latency that others provide. Yeah,

530
00:47:50,159 --> 00:47:55,280
a minute latency is what. No, at three am, I will not

531
00:47:55,440 --> 00:48:00,880
wait one or two or three minutes
to see if fixed it or not.

532
00:48:00,400 --> 00:48:05,599
I wish say it now. Yeah, okay, So that's the that's the

533
00:48:05,719 --> 00:48:14,119
idea you have. People have to
value the fidelity the insights, so they

534
00:48:14,239 --> 00:48:17,960
need to. It's like people that
want to learn more, to understand more,

535
00:48:19,079 --> 00:48:24,239
to feel the infrastructure more. This
is our best clients, best customers,

536
00:48:24,400 --> 00:48:30,480
best users. On the other hand, people that they are afraid of

537
00:48:30,559 --> 00:48:32,519
this thing. If it works,
don't touch it, let's rebut it.

538
00:48:32,760 --> 00:48:37,400
That's the funny thing because many people
do that, Oh it doesn't work,

539
00:48:37,480 --> 00:48:44,079
let's put it. It's okay.
Then the data is not that useful for

540
00:48:44,199 --> 00:48:47,599
you to you you need Actually the
first kind of monitoring, the check based

541
00:48:47,719 --> 00:48:57,440
the check based systems for sure you
have just the light or not. So

542
00:48:57,559 --> 00:49:04,960
another thing that's that strikes me as
being really cool about this is that you've

543
00:49:05,000 --> 00:49:09,079
got all of the observe observability data
in one spot, because that's been one

544
00:49:09,079 --> 00:49:14,039
of the other challenges I've had over
the years is you get the alert,

545
00:49:15,000 --> 00:49:16,880
but now it's just an alert.
You don't really have the context, so

546
00:49:16,920 --> 00:49:22,079
you have to go somewhere else to
get the context of what what, why

547
00:49:22,159 --> 00:49:27,119
did this thing alert? What does
this mean? And there's another spot for

548
00:49:27,320 --> 00:49:31,719
every alert that we see. We
have a community site that people can go

549
00:49:31,960 --> 00:49:37,400
and see what others did about this. So you we have a CTA on

550
00:49:37,679 --> 00:49:45,480
the alert that goes to the forum
about this alert where people have this alert.

551
00:49:46,800 --> 00:49:51,000
We have an introduction with that that
we wrote ourselves. This is what

552
00:49:51,079 --> 00:49:53,519
the alert means. This is how
you what you should do if you have

553
00:49:53,639 --> 00:49:57,320
the system do like this, if
you have the other system to like that.

554
00:49:57,440 --> 00:50:05,960
But then people discuss forum that's wild
because like even even you know,

555
00:50:06,039 --> 00:50:08,079
there's just you get alerts for all
kinds of things, and then you add

556
00:50:08,159 --> 00:50:13,639
to that that you're getting paged at
three am. You know you you might

557
00:50:13,840 --> 00:50:19,880
need a little a little help there
to understand the context. So thin within

558
00:50:19,920 --> 00:50:22,920
the data is that the community is
vast. So so far we count more

559
00:50:22,960 --> 00:50:30,559
than ten million users. The community
grows with about five to ten thousand new

560
00:50:30,719 --> 00:50:36,039
users a day. Even Docker have
downloads. For example, we have about

561
00:50:36,119 --> 00:50:43,639
one hundred and fifty two hundred thousand
DOCKERHB downloads every day. Even on our

562
00:50:43,800 --> 00:50:47,079
Sash offering, we have about one
hundred and fifty two hundred sign ups every

563
00:50:47,159 --> 00:50:54,480
day. Business that's that's that's a
lot in a lot of project. And

564
00:50:55,000 --> 00:51:00,159
not only that, for example,
the love that we see from users is

565
00:51:00,199 --> 00:51:05,320
extreme. The data in terms of
user love starts. For example, we

566
00:51:05,599 --> 00:51:10,559
lead the c and safe observability category. We sur passed Elastic in October.

567
00:51:12,079 --> 00:51:16,519
Now we are leading the observability category
although we are not incubated where it seems

568
00:51:16,559 --> 00:51:23,039
if does not endorse the data.
But it's the most loved project. Let's

569
00:51:23,039 --> 00:51:28,760
say that. Yeah, that's just
crazy. I mean, and just af

570
00:51:28,800 --> 00:51:32,679
you're talking with you, I can
see why you're getting those kinds of numbers.

571
00:51:34,000 --> 00:51:38,119
It's just I'm still just trying to
wrap my head around it. It

572
00:51:38,239 --> 00:51:42,199
almost seems too good to be true. I'll just be honest with you.

573
00:51:42,320 --> 00:51:45,599
It's like what's the catch? Yes, what's the catch here? I will

574
00:51:45,639 --> 00:51:50,280
tell you all the data is not
not mature yet, so we're building that

575
00:51:51,400 --> 00:51:54,880
does boards are pretty new, it's
less than a year old. Even our

576
00:51:55,039 --> 00:52:00,920
database, it's the third version of
the database. We feel is the last

577
00:52:00,000 --> 00:52:06,239
year. So it's not that we
have not built that many tools on top

578
00:52:06,440 --> 00:52:10,320
of the infrastructure of the monitoring infrastructure
yet. So the baseline is there.

579
00:52:10,840 --> 00:52:15,239
You have high fidelity, you know, unlimited methings. You have all the

580
00:52:15,840 --> 00:52:20,840
building blocks to actually do the work. We are lacking in a lot of

581
00:52:21,000 --> 00:52:25,559
high level tools right that we're building. Now that's okay, yeah, yeah,

582
00:52:25,639 --> 00:52:29,840
for sure. The good thing is
that the foundation is very good.

583
00:52:30,400 --> 00:52:35,679
Yeah, and it's it's open source. Do you what's your what's the open

584
00:52:35,719 --> 00:52:38,519
source community look like? Do you
find a lot of do you get a

585
00:52:38,559 --> 00:52:45,360
lot of poor requests and input?
I will tell you we have a lot.

586
00:52:45,480 --> 00:52:51,480
We have about four hundred fifty five
hundred contributors. Some of them very

587
00:52:51,559 --> 00:52:54,320
few, are very skillful. Because
we write in sea. If you remember

588
00:52:54,480 --> 00:52:59,599
the course in c this is pretty, this is pretty. It's not easy.

589
00:53:00,679 --> 00:53:06,559
In the early days, a lot
of community used because come on,

590
00:53:07,039 --> 00:53:14,679
I used to be an engineer in
the nineties. Then suddenly in twenty fourteen

591
00:53:14,800 --> 00:53:19,480
fifteen, I became an engineer again, so I was rusking. You can

592
00:53:19,639 --> 00:53:22,880
understand that. So sub in technology
all these years, I was a coo

593
00:53:23,360 --> 00:53:28,440
all of all my time, it
was city o stuff like this. But

594
00:53:28,639 --> 00:53:34,000
suddenly I had to write quode myself
and people helped me. So a lot

595
00:53:34,119 --> 00:53:38,000
of people stepped in and showed me
how this is done, and you know,

596
00:53:38,760 --> 00:53:45,400
pushed me a little bit beyond my
limits. All this happened. But

597
00:53:45,519 --> 00:53:50,519
I think that today in that I
is a mature open source project. It's

598
00:53:50,639 --> 00:53:54,880
very robust. We also wanted to
crassies and the likes of that. It's

599
00:53:55,519 --> 00:54:04,000
very nice, it's very reliable software. So I think as time passes it

600
00:54:04,119 --> 00:54:09,920
becomes incrementally more difficult for people to
contribute code. Yeah, and actually what

601
00:54:10,440 --> 00:54:15,519
happens now, we're going system the
Journal D. We submit it to system

602
00:54:15,679 --> 00:54:24,360
D repositories patsies to make System the
Journal fourteen times faster. So we are

603
00:54:24,360 --> 00:54:30,159
also a community contributor to that thing. So the System the Journal that you

604
00:54:30,280 --> 00:54:32,920
have in your in the next version
that you're gonna have there, it's going

605
00:54:34,000 --> 00:54:39,159
to have parties of a data inside
to be fourteen times faster than it work.

606
00:54:39,840 --> 00:54:44,920
See, and that's cool that part, that part of open source really

607
00:54:45,159 --> 00:54:49,559
gets me excited. You know,
where you you're consuming an open source thing

608
00:54:49,840 --> 00:54:53,800
and you're like, ohw this can
be better, and rather than forking it

609
00:54:54,039 --> 00:54:58,199
or creating your own, like,
contributing back to that, I think is

610
00:54:58,440 --> 00:55:04,960
a more idea. You want them
to. You want the software that tend

611
00:55:05,039 --> 00:55:09,679
to be maintained and high quality.
So and actually, the work of applying

612
00:55:09,840 --> 00:55:15,639
patsies to your version, come on, that's not good. Yeah, It's

613
00:55:15,760 --> 00:55:19,440
better to have it there and they
maintain it from now on for sure.

614
00:55:19,559 --> 00:55:23,119
Yeah, because yeah, I've seen
that trend over the last few years of

615
00:55:23,199 --> 00:55:29,880
people patching or forking or creating a
competing product, and I just I think

616
00:55:29,960 --> 00:55:31,920
we would all be so much better
if you just contribute back to upstream,

617
00:55:31,960 --> 00:55:39,039
because you get all of the benefits
of your work, plus the benefits that

618
00:55:39,079 --> 00:55:43,679
everyone else in the community is contributing
as well. If you think of it

619
00:55:43,800 --> 00:55:45,239
in the data of the day,
because it's monitoring out of the box,

620
00:55:45,280 --> 00:55:51,239
it's an opinionated monitoring. So what
happens is that when you're install the data

621
00:55:51,400 --> 00:55:58,280
in your infrastructure, you're monitoring team
is the data. We are your monitoring

622
00:55:58,360 --> 00:56:02,320
things. You're just a consumer,
right, using it the same way we

623
00:56:02,599 --> 00:56:10,800
want system D to be there for
us exactly. It's utilizing the whole community

624
00:56:12,440 --> 00:56:19,159
in order to provide high quality to
end users. Yeah. Because and that's

625
00:56:19,320 --> 00:56:23,960
that's really key because very few of
us, none well none of us really

626
00:56:24,239 --> 00:56:30,360
except for the people who work system
D A are are getting paid to create

627
00:56:31,239 --> 00:56:37,159
you know, the journal Like our
customers aren't interested in our journaling, they're

628
00:56:37,199 --> 00:56:40,000
interested in the product. That I
think for projects like system D, this

629
00:56:40,159 --> 00:56:45,280
is easy because most of the engineers
that work there are paid by other companies

630
00:56:45,320 --> 00:56:49,920
by their company and work on that
thing. So other commands red hat or

631
00:56:50,239 --> 00:56:55,800
mund this or that, they contribute
resources that are working dedicated on this stuff.

632
00:56:57,360 --> 00:57:00,360
Yep, that's okay. So their
job is to work on system D,

633
00:57:01,360 --> 00:57:07,000
but they work for some other company
that uses system right for a startup

634
00:57:07,079 --> 00:57:10,719
like us, because we are startup
still, so we just started we started

635
00:57:10,760 --> 00:57:16,480
monetizing five months ago. Oh wow, okay, this is pretty new.

636
00:57:16,960 --> 00:57:23,159
Yeah, very so for us,
we cannot dedicate so much resources. But

637
00:57:23,480 --> 00:57:28,719
for sure, the whole point is
the community. The whole point is to

638
00:57:29,039 --> 00:57:34,360
aggrediate a lot of to unify the
community, gather together a lot of value

639
00:57:34,800 --> 00:57:43,679
the users. Yeah, so early
stage start up. What's the future?

640
00:57:43,719 --> 00:57:49,559
What are your what's on your roadmap
for data? Oh? You know,

641
00:57:51,079 --> 00:57:57,000
monitoring is endless, endless, and
there is no way for this to finish.

642
00:57:58,000 --> 00:58:02,280
What we are trying to do currently
cover us much because we want to

643
00:58:02,480 --> 00:58:08,000
grow our sales. We are not
sustained, so we need we still need

644
00:58:08,079 --> 00:58:15,480
to prove that the data is sustainable
and it deserves more. So when this

645
00:58:15,639 --> 00:58:22,119
process. The idea is that currently
we are looking to help the users that

646
00:58:22,239 --> 00:58:28,440
have a budget. This is our
main thing because this will allow us to

647
00:58:28,480 --> 00:58:34,159
survive. Once we pass through this, I think the next steps will be

648
00:58:36,400 --> 00:58:40,199
to address tracing, provide the high
level tools that people need, become more

649
00:58:40,320 --> 00:58:45,079
contextual in the US interface, and
the likes. I think that the data

650
00:58:45,400 --> 00:58:52,920
has the winning mix, the winning
combination in product design, easy, higher

651
00:58:52,920 --> 00:58:58,760
resuls hire insights, higher fidelity,
the overwhelming part of you said, or

652
00:58:58,840 --> 00:59:01,079
we already know how to fix it, so people not to feel overy well

653
00:59:01,239 --> 00:59:07,000
by the amount of information if we
switch to a more contextual approach at the

654
00:59:07,079 --> 00:59:14,920
presentation level. So we're going to
switch from overwhelming to very deep. Right,

655
00:59:15,679 --> 00:59:21,480
So these are these are changes that
we need to do as we progress.

656
00:59:21,719 --> 00:59:23,960
But I think the first thing is
people to to try in the data,

657
00:59:24,239 --> 00:59:30,199
seeing the data, if they use
the data in production environments for commercial

658
00:59:30,239 --> 00:59:34,639
purposes, to buy a license because
this will allow us to continue guys who

659
00:59:34,639 --> 00:59:38,199
are here to actually we are here
to provide value. And for sure,

660
00:59:38,800 --> 00:59:43,719
if people don't buy the value,
then what are we doing here? Yeah?

661
00:59:44,159 --> 00:59:46,320
No, And and it's a it's
a proven business model, you know,

662
00:59:46,480 --> 00:59:52,079
data Dog and and Dine Tracing those
other companies have proven that you that

663
00:59:52,159 --> 00:59:57,559
there is a market for this,
and so if you're able to tap into

664
00:59:57,639 --> 01:00:04,679
that market and provide better service at
cheaper price. Yes, it's not only

665
01:00:05,079 --> 01:00:09,559
cheap, it's the overall cost that
is better, all of it across the

666
01:00:09,599 --> 01:00:15,599
board, so even cost optimization.
We see a trend for the unification of

667
01:00:15,639 --> 01:00:22,400
the monitoring tools. So mostly because
tools. Monitoring tools are not that comprehensive.

668
01:00:22,559 --> 01:00:28,000
Let's say they have certain aspects that
are very good, but they're very

669
01:00:28,039 --> 01:00:31,679
bad at others. Mostly for these
people use a lot of tools, right,

670
01:00:32,679 --> 01:00:37,119
so people are trying to consolidate tools. They are trying to save money,

671
01:00:38,119 --> 01:00:42,800
become more efficient in troubleshooting. This
is what we do. This is

672
01:00:42,920 --> 01:00:45,960
exactly what we're trying to do with
the data. Simplify monitoring, make it

673
01:00:46,000 --> 01:00:52,000
accessible to everyone, let them focus
on their job, not a monitoring tool,

674
01:00:52,360 --> 01:00:54,440
nothing to learn, just some familiarity
with the tool and you're done.

675
01:00:55,440 --> 01:01:00,559
Stuff like this for sure. Yeah, Like simplification of the tool is huge

676
01:01:00,639 --> 01:01:08,280
because we're all getting increased responsibilities and
increased scope of work. So and that

677
01:01:08,360 --> 01:01:15,800
technology becomes more complex. Really,
absolutely, our time passes the complexity skyrokids.

678
01:01:17,079 --> 01:01:21,960
You cannot you cannot fit it in
your head anymore. So you need

679
01:01:22,079 --> 01:01:27,800
the tool to be smarter. Instant
looks, get smarter tools, tools that

680
01:01:27,960 --> 01:01:31,280
do stuff by themselves. Yeah,
and that to me, that's a huge,

681
01:01:32,280 --> 01:01:37,119
huge win here. Just providing the
information in context, what do I

682
01:01:37,199 --> 01:01:40,079
need to know at this given time, rather than me having to go find

683
01:01:40,159 --> 01:01:47,239
it something that presents it is huge. Well, this has been an eye

684
01:01:47,320 --> 01:01:53,920
opening conversation. I'm I'm excited.
I mean, I monitoring gets let's be

685
01:01:54,000 --> 01:01:57,800
honest, it's one of those hard
things to get excited about, but this

686
01:01:58,119 --> 01:02:04,519
is kind of exciting. It changes
the dynamics, it changes everything, Yeah,

687
01:02:04,679 --> 01:02:07,320
it does. I mean I think
back to like a few decades ago

688
01:02:07,519 --> 01:02:16,159
configuring nagios and zabs and thinking about
how that just led to this here.

689
01:02:16,679 --> 01:02:22,440
It's pretty cool. It's definitely definitely
something worth checking out. So thank you

690
01:02:22,519 --> 01:02:27,400
for joining me today, Thank you
for being here, for inviting me.

691
01:02:28,440 --> 01:02:34,800
It was great. I hope you
enjoyed it. I did. I thoroughly

692
01:02:34,960 --> 01:02:39,800
enjoyed it because this is a perspective
on monitoring and observability that I never had.

693
01:02:40,440 --> 01:02:45,119
I feel like I'm walking away from
this conversation with a completely different set

694
01:02:45,159 --> 01:02:51,199
of goals for how I'm going to
approach this problem in the future. Like

695
01:02:51,360 --> 01:02:53,559
you know, you hear, especially
in a start space, you hear the

696
01:02:53,719 --> 01:02:59,719
term disruptive throne around a lot,
But I mean this one, it kind

697
01:02:59,760 --> 01:03:05,239
of like it fits that category and
it's just such an odd place, like

698
01:03:05,639 --> 01:03:08,440
who thought, you know, you
could disrupt observability, But here we are.

699
01:03:09,239 --> 01:03:14,480
YEA, Let's hope it works.
It remains because you know, the

700
01:03:14,599 --> 01:03:19,960
devil is in the details for sure. Work hard to smooth everything out to

701
01:03:20,159 --> 01:03:24,239
to make it as perfect as possible. Yeah, but it's a big only

702
01:03:24,239 --> 01:03:28,199
the integration that we have, you
know, it's eight hundred integrations. Come

703
01:03:28,239 --> 01:03:32,119
on, it's it's and we're a
small team. We're thirty people. Wow,

704
01:03:32,440 --> 01:03:37,559
that's impressive. That's impressive. So
for all of our listeners, if

705
01:03:37,599 --> 01:03:43,760
they want to find out more about
data, where can they go data dot

706
01:03:43,800 --> 01:03:49,840
cloud or no data monitoring on Google, your shirts on GitHub. The data

707
01:03:49,880 --> 01:03:54,760
and data is that Apple didubs last
data, slast data. I think it's

708
01:03:54,800 --> 01:03:58,239
quite popular, so it's easy to
find. There's a big community, they

709
01:03:58,280 --> 01:04:01,840
speak about it and we have read
it. Also there is an army data

710
01:04:02,440 --> 01:04:08,960
so yeah, right on it sounds
good. Costa, thank you so much

711
01:04:09,000 --> 01:04:12,320
for joining me today. This has
been opening and I really appreciate it.

712
01:04:12,559 --> 01:04:15,840
And to all the listeners, I
hope y'all found this useful. I hope

713
01:04:15,840 --> 01:04:17,840
you go check out net data.
I know I'm going to and I will

714
01:04:17,920 --> 01:04:20,519
see y'all next week. By it