1
00:00:07,938 --> 00:00:09,979
Welcome back to Adventures in DevOps.

2
00:00:09,979 --> 00:00:12,881
Our listeners rarely can find the time to gift us feedback.

3
00:00:12,881 --> 00:00:19,864
When they do, at the top of their list is the current issues dealing with on calls arising
from the database layer.

4
00:00:19,865 --> 00:00:26,028
A few weeks ago, we brought on the Grafana X CTO and co-founder to discuss what
observability looks like in 2026.

5
00:00:26,028 --> 00:00:28,270
And now we're going to go even deeper.

6
00:00:28,270 --> 00:00:35,133
Today's focus is on challenges with observability, even when you get it right, schema
management, slow queries, and their consequences.

7
00:00:35,133 --> 00:00:36,394
To get us through this,

8
00:00:36,394 --> 00:00:43,263
Our guest today was previously fellow at Splunk, distinguished engineer at Yahoo, and is
currently the chief architect at Imply.

9
00:00:43,263 --> 00:00:44,024
Eric Cheddar.

10
00:00:44,024 --> 00:00:45,465
Welcome to the show.

11
00:00:45,590 --> 00:00:49,326
Thanks for having me, Warren, and um I'm really excited to be here.

12
00:00:49,326 --> 00:00:52,418
our main topic for today, which is of course observability.

13
00:00:52,418 --> 00:00:59,103
It seems like that no matter the size of the company, investigating incidents always seems
like it's a going to be a core component.

14
00:00:59,103 --> 00:01:00,955
Like I just don't see that going away.

15
00:01:00,955 --> 00:01:04,417
Even S AI SRE products popping up left and right.

16
00:01:04,417 --> 00:01:11,410
I think fundamentally most of the challenges that we'll continue to see are how should we
realistically store our data to make it actionable?

17
00:01:11,410 --> 00:01:12,411
Absolutely.

18
00:01:12,411 --> 00:01:13,011
Absolutely.

19
00:01:13,011 --> 00:01:22,640
Like, I mean, I believe that the introduction of AI and what it's doing, it's actually a
repetition of manufacturing automation.

20
00:01:22,640 --> 00:01:35,110
And because those robots can create so much more so fast, the supply chain and logistics
have had to scale massively in order to get the materials to the factories so that they

21
00:01:35,110 --> 00:01:36,361
can keep up with things.

22
00:01:36,361 --> 00:01:39,916
And I think that draws a parallel with the data platform.

23
00:01:39,916 --> 00:01:45,648
Like every time I use Claude, almost everything Claude tells me is wrong to some degree.

24
00:01:45,648 --> 00:01:53,351
And I there's some amount of r adjustment, poking, pushing, prodding that I have to do in
order to get stuff.

25
00:01:53,351 --> 00:02:02,778
And so that job, even with an SRE or whatever coming in as an agent, there's still a human
who needs to be able to validate what's going on and and double check things.

26
00:02:02,778 --> 00:02:10,961
I feel like for the last 30 years or so, engineering leaders have been trying to figure
out how to take the ideas of lean manufacturing and apply it to software engineering.

27
00:02:10,961 --> 00:02:17,431
And the ideas of lean are like there's different waste from a theoretical standpoint that
exist in your organization.

28
00:02:17,431 --> 00:02:23,477
And removing those wastes means that more of your time, resources are spent to delivering
value to the customer.

29
00:02:23,477 --> 00:02:26,548
And there's a whole bunch of different ways, but I'm not obviously gonna go into them.

30
00:02:26,548 --> 00:02:31,714
I'm sure having spent some time there, you are somewhat familiar with with that concept.

31
00:02:31,714 --> 00:02:43,865
The thing is I think I want to pull out is this idea that the work that software engineers
are doing or engineering in general is doing is similar to the factory floor.

32
00:02:43,865 --> 00:02:55,106
Do you think that a lot of the software engineering that we're doing today is repetitive
activities that we're can can just simply automate, or is that creative, dynamic work

33
00:02:55,106 --> 00:02:57,118
where everything is a unique one off?

34
00:02:57,118 --> 00:02:57,678
The the

35
00:02:57,678 --> 00:03:00,923
Creation of the run book is creation of repetition.

36
00:03:00,944 --> 00:03:04,110
And so everything that has a run book is absolutely repetitive.

37
00:03:04,110 --> 00:03:09,221
I think now some people are trying to use LLMs to answer that question for them.

38
00:03:09,221 --> 00:03:11,616
We'll s we'll see if that turns out to be successful.

39
00:03:11,616 --> 00:03:11,768
no

40
00:03:11,768 --> 00:03:16,446
From what I've seen, LLMs like coming up with what should be done, horrible.

41
00:03:16,446 --> 00:03:17,087
Bad odd.

42
00:03:17,087 --> 00:03:19,290
It is it it does it does not work.

43
00:03:19,290 --> 00:03:21,592
They're horrible at coming up with ideas.

44
00:03:21,592 --> 00:03:30,913
There is this theory, if random chance makes you successful more often than intentional
activity, then might as well let the LM do it because there's a chance you'll be

45
00:03:30,913 --> 00:03:34,604
successful anyway, or more successful than letting a human decide.

46
00:03:34,604 --> 00:03:37,728
Still waiting on the monkey to type up Shakespeare's works.

47
00:03:37,802 --> 00:03:41,275
I I the yeah, I I know what you're talking about.

48
00:03:41,275 --> 00:03:48,522
And I think, you know, that's that's a pretty good um, you know, counterpoint there where
the original study was like a hundred monkeys typing on a hundred keyboards.

49
00:03:48,522 --> 00:03:57,019
Uh so obviously it's like we'll eventually produce the works of Shakespeare and everything
else ever produced, and the result was just a lot of like A's and E's on the keyboard

50
00:03:57,019 --> 00:04:01,682
being hit over and over again and then, you know, punctuation and that was it.

51
00:04:02,003 --> 00:04:03,945
I think there was some like throwing feces involved.

52
00:04:03,945 --> 00:04:05,386
Uh at

53
00:04:05,386 --> 00:04:09,038
And I think that is a very apt analogy for what L LMs are doing.

54
00:04:09,038 --> 00:04:16,744
There's a there's a lot of people out there who try to sell the agentic SRE or agentic uh
SOC analyst.

55
00:04:16,744 --> 00:04:24,990
And so the agent can actually look across your silos and figure out what's going on, and
you don't have to worry about the silos anymore because the agent figures it out.

56
00:04:24,990 --> 00:04:27,711
Um, which is kind of true.

57
00:04:27,712 --> 00:04:34,597
The thing that they're missing is that if the agent is the only thing that can look across
the silos, how does the human supervise it?

58
00:04:34,597 --> 00:04:37,016
How does the human ever know?

59
00:04:37,016 --> 00:04:40,261
That like, yes, what you're doing actually makes sense.

60
00:04:40,261 --> 00:04:45,259
It instead what it turns into is, Agent, are you sure that what you said is right?

61
00:04:45,259 --> 00:04:49,954
And the agent's like, Yes, I'm sure and you're like, Okay, I guess that's right then.

62
00:04:49,954 --> 00:04:55,188
There's this great paper that I believe I was actually my pick in a previous episode
called The Ironies of Automation.

63
00:04:55,188 --> 00:04:59,361
When you automate something, there still needs to be a human supervisor of that thing.

64
00:04:59,361 --> 00:05:03,664
And the question that the human supervisor will have is exactly the one that you
identified.

65
00:05:03,664 --> 00:05:05,745
How do they know that the system is working?

66
00:05:05,745 --> 00:05:12,710
And so you need to expose some data from that system enough so that a human can go in and
investigate what the problem is.

67
00:05:12,710 --> 00:05:17,846
The issue is that the human learns the job of doing the investigation of that system.

68
00:05:17,846 --> 00:05:19,767
Not of how to do the system, but of the job.

69
00:05:19,767 --> 00:05:23,629
And often those people historically had a job of hands-on doing the work.

70
00:05:23,629 --> 00:05:29,391
So they did the work historically, then they learn how to evaluate and monitor the system
and fix it if the problem is broken.

71
00:05:29,391 --> 00:05:39,275
So when we shift to an automated system, we take the hands-on work that someone was doing
and translate it to having to do the investigative work and the debugging work.

72
00:05:39,275 --> 00:05:42,677
And then if something goes wrong, also doing the original work that they did.

73
00:05:42,717 --> 00:05:45,484
Over time, systems become more reliable.

74
00:05:45,484 --> 00:05:47,955
So fewer and fewer people have hands on work.

75
00:05:47,955 --> 00:05:54,479
Now all the humans left only have the investigative work and the debugging work and never
the hands on work.

76
00:05:54,479 --> 00:06:00,992
So even if they're able to identify the problems that've been created, they are unable to
fix it because we just don't have those people anymore.

77
00:06:00,992 --> 00:06:07,096
So by automating stuff, we make the humans' jobs incredibly more challenging to actually
solve.

78
00:06:07,096 --> 00:06:10,428
The the complexity of doing that job becomes greater.

79
00:06:10,428 --> 00:06:14,816
So unless you have a real problem that requires increased scale.

80
00:06:14,816 --> 00:06:17,448
Automating it only costs you money.

81
00:06:17,448 --> 00:06:23,674
So you should think about before introducing agents to any system, you should always ask
the question, could we still do this with humans?

82
00:06:23,674 --> 00:06:28,398
Because if the answer is yes, then you shouldn't automate it because that's going to end
up in a worse state.

83
00:06:28,398 --> 00:06:36,485
And I think this is gonna bring me back to asking about, you know, what do we actually
mean by the data platform part and whether or not humans could still be building and

84
00:06:36,485 --> 00:06:37,186
maintaining that?

85
00:06:37,186 --> 00:06:37,624
I don't

86
00:06:37,624 --> 00:06:41,120
think that that um completely goes away.

87
00:06:41,682 --> 00:06:47,938
Well if if it goes away there's hopefully some new uh some some new future.

88
00:06:47,938 --> 00:06:49,451
What's the sort of frame of reference here?

89
00:06:49,451 --> 00:06:54,200
So if we have a log solution, we're throwing logs in it, obviously those are production
logs.

90
00:06:54,200 --> 00:06:58,552
but maybe you're also talking about infrastructure logs or business relevant metrics, uh
et cetera.

91
00:06:58,552 --> 00:07:02,695
I love the question and I love the personas that you've uh introduced.

92
00:07:02,695 --> 00:07:06,128
It turns out some logs are business relevant.

93
00:07:06,128 --> 00:07:08,240
Some logs are inf only infrastructure.

94
00:07:08,240 --> 00:07:09,361
Some logs are both.

95
00:07:09,361 --> 00:07:14,814
And sometimes you need to do some things to the logs in order to make them business
relevant or make them other things.

96
00:07:14,814 --> 00:07:26,795
And the the traditional set of data tools that have been available have created a bit of a
spaghetti of um, okay, let's put all of our logs, for example, uh going concrete, let's

97
00:07:26,795 --> 00:07:28,120
put all of our logs into Splunk.

98
00:07:28,120 --> 00:07:33,585
But then the PM wants something, and so they're told, okay, use Splunk for that.

99
00:07:33,585 --> 00:07:36,427
They use Splunk for it, and then they need to share it with someone else.

100
00:07:36,427 --> 00:07:41,662
There ends up being this notion of, okay, let's teach the business analyst to use Splunk.

101
00:07:41,662 --> 00:07:49,228
They're like, I don't the thing that's most interesting about logs is the structure of the
log and not necessarily how it's used.

102
00:07:49,228 --> 00:07:56,046
Where traditionally we've believed that you have to take the data and move it to different
systems because of how it's used.

103
00:07:56,046 --> 00:07:57,236
But that's not actually true.

104
00:07:57,236 --> 00:08:00,277
The actual thing is that a log is interesting in and of itself.

105
00:08:00,277 --> 00:08:04,358
You can compress it with kind of domain specific technologies.

106
00:08:04,358 --> 00:08:07,589
There's specific ways that people want to extract things out of logs.

107
00:08:07,589 --> 00:08:09,750
There's specific ways people want to look at logs.

108
00:08:09,750 --> 00:08:12,751
But you can take that log and make it SQL queryable.

109
00:08:12,751 --> 00:08:15,612
You can take that log and make it exposed in other systems.

110
00:08:15,612 --> 00:08:18,763
You should be able to have your log, use it from whatever system you want.

111
00:08:18,763 --> 00:08:20,743
And it's the same for the agent as well.

112
00:08:20,743 --> 00:08:23,820
Like the agent should also be able to access that same data.

113
00:08:23,820 --> 00:08:25,213
You're definitely an optimist.

114
00:08:25,213 --> 00:08:28,088
The fact that you think that the logs in these systems are valuable.

115
00:08:28,088 --> 00:08:28,389
Right.

116
00:08:28,389 --> 00:08:32,065
Because the number one thing that always comes to me is like, our logs are useless.

117
00:08:32,065 --> 00:08:36,823
Like w this log doesn't tell us anything that we actually want it to know at this point.

118
00:08:36,823 --> 00:08:49,446
we've seen as we've talked with different people and worked with stuff is especially in
the observability world, the useful lifespan of a log is much shorter than in the security

119
00:08:49,446 --> 00:08:49,966
world.

120
00:08:49,966 --> 00:08:51,477
I mean, I think that's definitely accurate.

121
00:08:51,477 --> 00:08:59,055
You for sure often don't know what will be necessary later, but at the same time people
often risk averse.

122
00:08:59,055 --> 00:09:01,557
I think that's just a true a true fact.

123
00:09:01,607 --> 00:09:08,604
and that includes uh hoarding logs that are useless uh because they don't they don't know
what they're going to need in the future.

124
00:09:08,604 --> 00:09:14,230
With conscious thought you or deliberate action you would know you know, which logs would
actually be relevant.

125
00:09:14,230 --> 00:09:14,552
The

126
00:09:14,552 --> 00:09:25,835
The logs of people interacting with the site, the logs of people interacting with the
online banking, or the logs of people interacting with the e commerce site are useful for

127
00:09:25,835 --> 00:09:37,208
the observability team because they use it to figure out, you know, what what caused
outages, what was going on, how many people were impacted, what uh what things happened.

128
00:09:37,208 --> 00:09:43,074
You can you look for the logs in order to discover anomalous behavior that you can respond
to.

129
00:09:43,074 --> 00:09:48,255
The exact same data set that's coming in that ends up powering each of them.

130
00:09:48,396 --> 00:09:52,027
It's the access logs from how people are interacting with the website.

131
00:09:52,027 --> 00:10:00,069
It's event telemetry from the single page JavaScript application that's being fired back
about how the users are working on stuff.

132
00:10:00,069 --> 00:10:09,512
That often turns into, well, we have to get this data in, but then we also have to make
sure that this subset of this data gets ETL'd over to this other system so that these

133
00:10:09,512 --> 00:10:11,330
people can look at this thing.

134
00:10:11,330 --> 00:10:15,130
And we have to get this other thing over here so that these people can look at that thing.

135
00:10:15,130 --> 00:10:15,776
Oh

136
00:10:15,776 --> 00:10:21,778
Historically, at least in my teams and my organizations, it we always go with the the
DevOps mindset.

137
00:10:21,778 --> 00:10:28,771
If you build it, you run it, which also means you capture logs and you have to review
what's there in case of an incident, you're responsible there.

138
00:10:28,771 --> 00:10:32,071
So of course the logs that you're generating have to be meaningful to you.

139
00:10:32,071 --> 00:10:37,734
Um and engineers obviously have a notorious track record of being hard users to please.

140
00:10:37,734 --> 00:10:38,274
So

141
00:10:38,274 --> 00:10:43,434
The platform that we utilize in any of those moments has always been the thing everyone
complains about.

142
00:10:43,434 --> 00:10:50,301
Uh they hate historically, they hate sumo logic, they hate Elasticsearch, they hate
Grafana, they hate CloudWatch insights.

143
00:10:50,301 --> 00:10:55,504
You know, you stick in something here, uh logs log z dot io or whatever, however you
pronounce it.

144
00:10:55,504 --> 00:11:00,636
I mean, the list is goes on and on of all these platforms that I've seen w some team try
try.

145
00:11:00,636 --> 00:11:04,091
Because every single time I come in, I I see they're using something like we hate it.

146
00:11:04,091 --> 00:11:05,829
I'm like, great, do some research.

147
00:11:05,829 --> 00:11:07,370
Find a platform you love.

148
00:11:07,724 --> 00:11:08,855
And then we'll try that one.

149
00:11:08,855 --> 00:11:10,936
They do that and they hate that one too.

150
00:11:10,936 --> 00:11:19,434
And the re the reason I I say this is because even if we were able to find something that
they liked, there's still this problem of are they collecting the right information?

151
00:11:19,434 --> 00:11:28,686
And even if they are, how do other teams get access to that in a way which they're not
held accountable for the data that shows up in those logs?

152
00:11:28,887 --> 00:11:32,729
And the reason I I bring that up is because historically there's this challenge, right?

153
00:11:32,909 --> 00:11:34,370
There is some production data.

154
00:11:34,370 --> 00:11:44,043
which another team uh or someone else in a different role, as you pointed out, like
product managers or business analysts, say, you know, hey, we wanna be able to perform

155
00:11:44,043 --> 00:11:45,173
this query on our data.

156
00:11:45,173 --> 00:11:52,375
And historically they'll they'll use one of their giant data lake uh SQL back query
solutions to do this.

157
00:11:52,495 --> 00:11:58,776
And the question is how does the data get from the production system into that other, I'll
say third party system?

158
00:11:58,797 --> 00:12:02,498
Is there an act an ETL extract transformer load job that runs?

159
00:12:02,498 --> 00:12:04,182
If it does, who owns that?

160
00:12:04,182 --> 00:12:07,785
Which fields are extracted or whole databases extracted?

161
00:12:07,785 --> 00:12:17,101
And it doesn't seem like there's a right answer here because if you extract everything and
and another team owns that responsibility, that's just always constantly broken.

162
00:12:17,101 --> 00:12:22,124
Like if an engineering team doesn't do it, then the the data changes all the time.

163
00:12:22,124 --> 00:12:24,896
Uh someone complains, hey, my query broke.

164
00:12:24,896 --> 00:12:33,548
The ETL job breaks down because it all of a sudden security says, Hey, we can't be
exposing full access on the production databases to third party tools.

165
00:12:33,548 --> 00:12:35,338
So that that stops working.

166
00:12:35,539 --> 00:12:42,421
And even after all of that, someone says, Hey, we're not actually getting the data that we
only want in the first place.

167
00:12:42,421 --> 00:12:44,001
It doesn't even exist.

168
00:12:44,141 --> 00:12:45,109
You know, we're not recording it.

169
00:12:45,109 --> 00:12:45,950
We're writing it down, right?

170
00:12:45,950 --> 00:12:46,752
We wrote other things.

171
00:12:46,752 --> 00:12:50,943
Just like in a lot of production systems, we may forgot to write audit trails, right?

172
00:12:50,943 --> 00:12:53,864
You know, you don't always have everything up front.

173
00:12:53,984 --> 00:13:01,186
And on the other side of the spectrum, you have engineering teams being forced to der pull
hand picked fields.

174
00:13:01,186 --> 00:13:09,091
from their production databases and sending them over to your tableaus, your Splunk's,
whatever have you.

175
00:13:09,191 --> 00:13:11,213
And then the data isn't there anyway.

176
00:13:11,213 --> 00:13:13,415
But at least they're responsible for doing it.

177
00:13:13,415 --> 00:13:15,977
And you can go to a team and say, Hey, we're not getting this field.

178
00:13:15,977 --> 00:13:17,438
Can we add it in some way?

179
00:13:17,438 --> 00:13:17,862
That

180
00:13:17,862 --> 00:13:20,483
is a great question.

181
00:13:20,483 --> 00:13:24,466
It's a question that business intelligence has fought with for a very long time.

182
00:13:24,466 --> 00:13:25,506
It's data governance.

183
00:13:25,506 --> 00:13:37,552
Uh you you in in the business intelligence world you end up with these with people who
have these UML diagrams of table structure and they're like, thou shalt generate things

184
00:13:37,552 --> 00:13:40,738
that follow this structure and put things in and

185
00:13:40,738 --> 00:13:45,241
But developers never j like developers are horrible at at like aligning with that.

186
00:13:45,241 --> 00:13:46,302
They're like, I need this thing.

187
00:13:46,302 --> 00:13:47,283
I'm gonna add this field.

188
00:13:47,283 --> 00:13:51,616
I'm not gonna look up what it's supposed to be named based on these people in this other
team.

189
00:13:51,616 --> 00:13:53,328
And so the there's that.

190
00:13:53,328 --> 00:13:59,032
So I don't um I don't know exactly how to solve the data governance problem.

191
00:13:59,032 --> 00:14:07,028
I don't believe that trying to organize everybody and create structure out of it is
actually ever gonna work.

192
00:14:07,298 --> 00:14:12,230
Because especially as you expand in an organization, you're just never gonna get everybody
to agree.

193
00:14:12,344 --> 00:14:23,203
I I think I I have seen that the most successful mechanism for the data transfer between
uh production or uh engineering organization and their databases to other people to be

194
00:14:23,203 --> 00:14:33,111
able to use it is when the engineering team is uh responsible and accountable for deciding
what their interfaces are going to be and what data they're going to expose in the schema

195
00:14:33,111 --> 00:14:41,578
is as if they're maintaining their API format in an open API specification, except the
format and the schema that they're maintaining is in

196
00:14:41,934 --> 00:14:51,622
uh some third party or other service running, such as you know, uh an object store in the
cloud somewhere or Snowflake or, you know, what have you.

197
00:14:51,622 --> 00:14:55,636
And then the team says, yes, you know, we are we we are accountable.

198
00:14:55,636 --> 00:15:01,331
We decide as part of the responsibility of our team that we're going to publish data to
this specific repository.

199
00:15:01,331 --> 00:15:02,512
And here is the schema for that.

200
00:15:02,512 --> 00:15:05,313
And anyone who wants to use it can use it.

201
00:15:05,334 --> 00:15:05,864
And that's it.

202
00:15:05,864 --> 00:15:06,755
End of story.

203
00:15:06,755 --> 00:15:10,220
Because then you don't have a separation between

204
00:15:10,220 --> 00:15:17,077
Someone who's trying to define or has expectations on that schema and the team that is
basically going to be held accountable for it.

205
00:15:17,077 --> 00:15:24,614
I think putting the ability and responsibility uh to the team that will end up doing this
is the right thing.

206
00:15:24,614 --> 00:15:30,370
You know, you push down the decision and ownership down to the team that has it, uh and
not expose the whole database.

207
00:15:30,370 --> 00:15:30,570
If

208
00:15:30,570 --> 00:15:40,296
you talk to anyone at a company, even at Yahoo size, and ask them what technologies are
your company using, the answer will be everything.

209
00:15:40,296 --> 00:15:41,857
Like, are are you using this?

210
00:15:41,857 --> 00:15:42,487
Yes, we are.

211
00:15:42,487 --> 00:15:43,137
Somewhere.

212
00:15:43,137 --> 00:15:44,058
I don't know where.

213
00:15:44,058 --> 00:15:46,309
Somewhere we're we're probably using it.

214
00:15:46,309 --> 00:15:50,362
That that's just such a common mode of operation in a large enterprise.

215
00:15:50,362 --> 00:15:58,098
As much as you might want to force consolidation of technology, a new company is going to
be acquired.

216
00:15:58,098 --> 00:16:05,301
And that company that you acquired had no idea about any of the things that you tried to
enforce until after you acquired them.

217
00:16:05,301 --> 00:16:10,203
And now the question is like, is it actually worth it to carry all of that over?

218
00:16:10,203 --> 00:16:16,486
And I think all of this is just pointing to this notion of silos and independent decision
making.

219
00:16:16,566 --> 00:16:19,307
I just saw every technology used in all the places.

220
00:16:19,307 --> 00:16:25,010
Uh there were there was one team that um was

221
00:16:25,422 --> 00:16:29,554
for telemetry and metrics, they were using one system for it.

222
00:16:29,554 --> 00:16:32,468
my background is uh kind of with Apache Druid and stuff.

223
00:16:32,468 --> 00:16:42,956
I started the that project and and built stuff and so we used the teams that I worked with
we used Apache Druid to do uh some advertising analytics and and things like that.

224
00:16:42,956 --> 00:16:48,401
And there there were conversations sometimes with the telemetry folks around, you know, we
could use this for that.

225
00:16:48,401 --> 00:16:50,232
I don't think they were wrong

226
00:16:50,232 --> 00:16:55,005
They never really were like, Yes, we're we're gonna adopt this and run with it.

227
00:16:55,005 --> 00:16:57,547
And I don't think they're wrong for that choice.

228
00:16:57,547 --> 00:16:59,318
They're the ones operating the system.

229
00:16:59,318 --> 00:17:00,989
They kind of know what's going on.

230
00:17:00,989 --> 00:17:02,170
They're they're getting at it.

231
00:17:02,170 --> 00:17:06,353
They have their own service boundaries, so they they get to make their choice.

232
00:17:06,353 --> 00:17:15,840
We had other teams, you know, that were though for analytics it was heavy on Hive and on
um Tez and Hive running on Tez and and all of that stuff.

233
00:17:15,840 --> 00:17:19,166
This was back when uh Hadoop was still a challenger.

234
00:17:19,166 --> 00:17:25,870
At large organizations, that you will always have independent teams making independent
decisions.

235
00:17:25,891 --> 00:17:29,272
And I don't think it's ever possible to fully align them.

236
00:17:29,353 --> 00:17:42,422
And so instead of doing that, you have to lean into what is something that gives us the
ability to just store the data as is and then connect the dots later.

237
00:17:42,422 --> 00:17:48,952
When a a local team makes a decision and they're like, this is how we're going to expose
it almost from an open API.

238
00:17:48,952 --> 00:17:50,024
perspective, right?

239
00:17:50,024 --> 00:17:56,332
If it's a rest endpoint that they're using to expose it from, how does business analyst
use rest?

240
00:17:56,333 --> 00:18:02,314
They they don't unless they they can tell SQL to go and issue uh REST requests, right?

241
00:18:02,314 --> 00:18:11,511
See, I was gonna say correctly, but I I mean I guess I guess incorrectly is also the uh
viable answer that's in the multiple choice drop down there.

242
00:18:11,511 --> 00:18:14,498
Yeah, like they they but they're they're just not going to.

243
00:18:14,498 --> 00:18:19,048
They're gonna be like, I don't know how to I don't know how to how to interact with that.

244
00:18:19,054 --> 00:18:21,114
So here here's a counter argument there.

245
00:18:21,114 --> 00:18:32,946
Uh organizations that followed the rant that Bezos had set off, and now it's been I think
over a decade, is that data analysts would be required to use the rest interfaces to

246
00:18:32,946 --> 00:18:36,439
expose or get the data that they want from other teams.

247
00:18:36,439 --> 00:18:47,502
So I I totally agree though, in most organizations, you don't have such a strong and
specific and maybe mature mindset about how teams will operate on top of

248
00:18:47,502 --> 00:18:47,932
technology.

249
00:18:47,932 --> 00:18:55,777
And I I feel like if some teams aren't as technologically savvy, then they are limited in
their capacity to solve particular business problems.

250
00:18:55,777 --> 00:19:06,172
Or if the tools they're using because someone made a bad business decision and bought a 10
year contract with a company to use a particular product that refuses to add in a OAuth to

251
00:19:06,172 --> 00:19:10,285
integrated supported interface to or even REST API.

252
00:19:10,285 --> 00:19:16,450
You know, maybe it's using WCF or SOAP or something horrific that reads and writes, you
know, is it flat

253
00:19:16,450 --> 00:19:23,854
Text files on a on a physical machine somewhere, then you are limited by the real world
situation there.

254
00:19:23,854 --> 00:19:34,340
One one thing that does come up, and I think you sort of hit on this, is that it doesn't
matter what the situation is, even if you prescribe the perfect tool for the job, someone

255
00:19:34,340 --> 00:19:37,682
someone on the other end can always still mess it up.

256
00:19:37,772 --> 00:19:38,142
Right.

257
00:19:38,142 --> 00:19:39,323
Well they'll mess it up.

258
00:19:39,323 --> 00:19:42,165
My team has defined this API.

259
00:19:42,165 --> 00:19:47,409
So if you want to use it, you need to change what you're doing in order to align with my
decision.

260
00:19:47,409 --> 00:19:54,304
Getting humans to change their behavior is, I believe, the most difficult thing to do in
the world.

261
00:19:54,304 --> 00:20:00,818
You're more likely to get people to be like, okay, I don't need it than you are to get
them to actually change their behavior.

262
00:20:00,999 --> 00:20:03,980
And so this leads me to the what if.

263
00:20:04,141 --> 00:20:05,902
So what if

264
00:20:05,984 --> 00:20:19,443
You could have your data in a place, and that data could be accessible via the tool of
your local team's choice, and also accessible via the tool of that the other team's

265
00:20:19,443 --> 00:20:26,008
choice, and also accessible via the tool of some other team you've never heard of's
choice.

266
00:20:26,368 --> 00:20:35,010
But you have the data in that one place, you can own the definition of it, and it can be
accessible from all of the different places that people have.

267
00:20:35,010 --> 00:20:36,750
That is, I believe, the Holy Grail.

268
00:20:36,750 --> 00:20:38,032
Yeah, I know what you're talking about.

269
00:20:38,032 --> 00:20:48,245
You're about to say it it's going to be give them direct access to the production database
so they can read the files on the server directly and use whatever data they want there.

270
00:20:49,634 --> 00:20:53,178
You you have the files up on cloud storage.

271
00:20:53,178 --> 00:20:53,798
Yeah.

272
00:20:53,798 --> 00:21:05,250
So if you use that as a way to disintermediate your production systems from the actual
kind of analytics and and access of it, have this three layer cake where things have

273
00:21:05,250 --> 00:21:07,091
decoupled to allow for it.

274
00:21:07,091 --> 00:21:14,028
And the the primary thing that allowed for that decoupling is the SQL query language.

275
00:21:14,328 --> 00:21:20,662
Where that's fundamentally the API that the visualization layers use and that the business
analysts use.

276
00:21:20,683 --> 00:21:30,690
And so when you talk about um the team should define the API that they're gonna support,
the the thing is there's not just one API that you're gonna support.

277
00:21:30,690 --> 00:21:34,893
And in the logs world, people want to access logs from SQL.

278
00:21:34,893 --> 00:21:42,598
And the language is more belonging to the persona, where the data format itself, the log,

279
00:21:42,670 --> 00:21:51,666
can be queried from a number of different languages and different personas prefer
different languages because the the language is aligned to the job that they're trying to

280
00:21:51,666 --> 00:21:52,002
do.

281
00:21:52,002 --> 00:22:00,669
We have had a similar challenge in in our space when we're defining the, and I hate to
call them policies, we call them access records for one of our products.

282
00:22:00,750 --> 00:22:03,992
And I mean, we provide like login and access control as a as a SaaS.

283
00:22:03,992 --> 00:22:08,176
And customers come in and say, Hey, you know, can you support this?

284
00:22:08,176 --> 00:22:09,918
Like, we love this particular format.

285
00:22:09,918 --> 00:22:12,219
I'm like, or this format, or this format.

286
00:22:12,219 --> 00:22:15,522
And uh realistically, it's all stored as JSON for us.

287
00:22:15,522 --> 00:22:19,820
It uh I mean you can store it as some other DSLs, like they're

288
00:22:19,820 --> 00:22:23,322
The every every domain specific language, DSL, is is the worst.

289
00:22:23,322 --> 00:22:24,851
They're they're all literally the worst.

290
00:22:24,851 --> 00:22:34,290
Uh they're almost like a programming language, but they promise that they're parsable
until people find vulnerabilities with the the language itself and find ways to in inject

291
00:22:34,290 --> 00:22:35,301
attacks in.

292
00:22:35,301 --> 00:22:44,287
And they're all unique that you have to understand the domain in a lot of ways to actually
be able to write one or write the the form to even do the query in the first place.

293
00:22:44,287 --> 00:22:49,408
And those that are amateurs and have come from one world make it very difficult to

294
00:22:49,408 --> 00:22:50,469
expose in different way.

295
00:22:50,469 --> 00:22:59,084
But it's very easy for us to add in different content types to our API and expose the
exact same data via different formats because all of them are constructible.

296
00:22:59,084 --> 00:23:09,510
And the one thing I learned, I say, my last 20 years of engineering, and it wasn't that
early on, maybe this is a bit of a regret, is that I always tried to avoid SQL uh when

297
00:23:09,510 --> 00:23:14,092
making an API for querying particular data on a production database.

298
00:23:14,092 --> 00:23:17,548
It it's the worst, you know, let's use something constructible, something nice.

299
00:23:17,548 --> 00:23:22,280
that is can be defined in in JSON and passed over the API and can be validated.

300
00:23:22,280 --> 00:23:27,653
But over time, what you find out is you just made another bad uh domain-specific language.

301
00:23:27,653 --> 00:23:29,843
You just made a worse DSL somewhere.

302
00:23:30,084 --> 00:23:39,178
And at this point, I'm just like, everything should be able to speak SQL because it has is
essentially the thing that humanity has centered upon working correctly.

303
00:23:39,178 --> 00:23:41,949
And it's portable from one system to another one.

304
00:23:41,949 --> 00:23:44,030
And as long as you can provide that

305
00:23:44,030 --> 00:23:48,954
specifically as your query language, then often it's easy to add these other things on
top.

306
00:23:48,954 --> 00:23:57,940
And it sounds like for your product, you know, for your data pipeline, uh being able to
port from the underlying data store to the to the bad terrible DSL that every single

307
00:23:57,940 --> 00:24:08,838
different persona has said, you know, I want it in CQL in and SQL and whatever, whatever
have you, and also understand the semantics of that particular language, like the the

308
00:24:08,838 --> 00:24:11,470
MySQL of the world versus the

309
00:24:11,476 --> 00:24:12,928
MS SQL, the Microsoft SQL.

310
00:24:12,928 --> 00:24:14,690
Like it's not exactly the same, right?

311
00:24:14,690 --> 00:24:18,082
It it there are some fundamental differences there based on the data.

312
00:24:18,082 --> 00:24:23,166
Getting the semantics right is definitely a key element of things.

313
00:24:23,166 --> 00:24:28,269
So there's some people out there who are like observability, SQL for observability.

314
00:24:28,269 --> 00:24:31,191
Everything should be SQL, all observability should be SQL.

315
00:24:31,191 --> 00:24:45,841
And while I think that everything should support SQL, I actually think that the the
diaspora of different query languages for logs is indicative of a different usage pattern

316
00:24:45,842 --> 00:24:46,526
that

317
00:24:46,526 --> 00:24:59,315
is actually extremely meaningful for working with logs that is not as interesting for
working with business data and like rigid column or structure data.

318
00:24:59,315 --> 00:25:10,863
And so I I think that I I do actually think while right now there's tons of different
query languages for logs, I do expect that to converge down on a subset of query languages

319
00:25:10,923 --> 00:25:15,000
that uh will remain and that that will exist.

320
00:25:15,000 --> 00:25:16,631
Changing human behavior is hard.

321
00:25:16,631 --> 00:25:24,938
It instead of telling them that they they need to change what they're doing, if you can
just meet them where they are, um, you can see that's in metrics too for observability.

322
00:25:24,938 --> 00:25:29,561
Like people use PromQL so much more than they use SQL for for metrics and telemetry.

323
00:25:29,561 --> 00:25:37,848
Um really PromQL kind of has, I believe, has won as a de facto standard for metrics and
time series style things.

324
00:25:37,848 --> 00:25:41,484
I'm I'm less aware of different languages in that space.

325
00:25:41,484 --> 00:25:42,374
And you're totally right.

326
00:25:42,374 --> 00:25:51,438
The smart thing to do is to convert whatever interface someone has into the best, most
generic solution that can be run on any single platform.

327
00:25:51,438 --> 00:25:56,206
So it doesn't matter what DSL someone is using, if you can convert that to an abstract

328
00:25:56,206 --> 00:26:01,451
syntax tree and AST, then you can directly execute that AST on whatever run engine you've
got.

329
00:26:01,451 --> 00:26:07,796
We actually had uh an episode on how uh a company is doing that specifically and I will
plug that in the description.

330
00:26:07,796 --> 00:26:10,288
But I I think this this may this solves a lot of problems, right?

331
00:26:10,288 --> 00:26:18,786
You don't have as long as you can come up with a can a transform from that to an AST that
you can run and you just run the AST, you've solved the problem.

332
00:26:18,786 --> 00:26:23,820
And if you can't convert it to the AST, then you know that there's a feature in the dead
DSL that

333
00:26:23,820 --> 00:26:25,881
you aren't able to fully utilize.

334
00:26:25,881 --> 00:26:27,352
And then the question is why.

335
00:26:27,352 --> 00:26:36,465
I do think there's an interesting uh corollary here, realistically, whereas if you are in
a different space, if you can't convert it to the same kind of ASTs that you're used to

336
00:26:36,465 --> 00:26:39,546
running, are people thinking about that problem differently?

337
00:26:39,546 --> 00:26:41,297
And I'll just use an example.

338
00:26:41,297 --> 00:26:45,179
I think very early on I was full in on traces.

339
00:26:45,179 --> 00:26:53,182
This is the idea of storing log information that is grouped together during the whole
request and maybe across requests.

340
00:26:53,268 --> 00:26:54,299
At a single moment.

341
00:26:54,299 --> 00:26:59,184
So when you want to query something, you're looking at a single object with lots of
additional data in it.

342
00:26:59,224 --> 00:27:03,769
An example is like, let's say there's an error in production and you see a log message
with that error.

343
00:27:03,769 --> 00:27:05,501
Now maybe you have some sort of correlation ID.

344
00:27:05,501 --> 00:27:11,437
And so you make your SQL statement, select all the rows where the correlation ID equals
the value you know.

345
00:27:11,437 --> 00:27:14,220
You're pulling multiple different logs and you're getting that data.

346
00:27:14,220 --> 00:27:16,116
For us, that was always really annoying.

347
00:27:16,116 --> 00:27:20,329
Especially when you have a whole list of correlation IDs that you want to pull stuff for
and you want to join it up with.

348
00:27:20,329 --> 00:27:29,576
So very early on, what we did was whenever there was a log message, well, during the whole
program execution, we would store a property bag of all the context of all the variables

349
00:27:29,576 --> 00:27:32,297
of everything that was happening, and we shove it into the error message.

350
00:27:32,297 --> 00:27:37,302
So when it gets logged, we have everything there in one place that we can actually
validate and use.

351
00:27:37,302 --> 00:27:38,733
And I think this has caught on recently.

352
00:27:38,733 --> 00:27:43,533
I think uh in the last few years, Honeycomb was a huge proponent of what they were calling
observability two point zero.

353
00:27:43,533 --> 00:27:48,567
And I think since then a lot of other companies have jumped on the bandwagon here of being
like, hey, you know what?

354
00:27:48,567 --> 00:27:51,348
Storing line by line stuff isn't necessarily the right answer.

355
00:27:51,348 --> 00:27:58,591
The reason I bring this up is because that query sort of depends on the fact that we have
data stored in a particularly different way.

356
00:27:58,591 --> 00:28:04,773
And so it wouldn't be straightforward to necessarily convert from the query language to an
AST that could run on these different kinds of data.

357
00:28:04,773 --> 00:28:07,084
So it's not just necessarily about the

358
00:28:07,084 --> 00:28:17,631
transforming of the data language that we're using the the DSL to something that we can
execute, we also need to understand fundamentally how the data may be relevantly stored

359
00:28:17,631 --> 00:28:27,487
for accessing, you know, things like indexes, the what's in a a wide table format or a
columnar format, like these things are potentially relevant, whether it's stored as a blob

360
00:28:27,487 --> 00:28:27,977
and whatnot.

361
00:28:27,977 --> 00:28:33,118
So there's there there are a lot of complexities here that any company would potentially
have to deal with.

362
00:28:33,118 --> 00:28:36,231
And obviously, you know, some areas that you you've seen particularly.

363
00:28:36,231 --> 00:28:40,954
I mean, obviously if it's just giving the consumer a DSL that matches their expectations.

364
00:28:40,954 --> 00:28:44,347
You know, you could do a lot of hacks under the hood there.

365
00:28:44,427 --> 00:28:52,622
but outside of that, you know, you really start to come into areas where there are
challenges because fundamentally the data has to be exposed in different ways.

366
00:28:52,622 --> 00:28:53,162
Absolutely.

367
00:28:53,162 --> 00:28:55,904
And and traces is the a great example.

368
00:28:55,904 --> 00:28:57,705
Like I've been talking about logs a lot.

369
00:28:57,705 --> 00:29:06,650
Interacting with traces and a language for interacting with traces will fundamentally
understand the notion of a trace versus a span.

370
00:29:06,650 --> 00:29:17,296
But the actual like fundamentals of how is the data stored, how is it persisted, how do
you index it, and which query languages are supported is actually a function of the data

371
00:29:17,296 --> 00:29:18,377
format itself.

372
00:29:18,377 --> 00:29:20,138
And so a trace

373
00:29:20,202 --> 00:29:21,804
requires different languages.

374
00:29:21,804 --> 00:29:24,266
And same with metrics like PromQL.

375
00:29:24,266 --> 00:29:28,509
You could convert PromQL into something that runs against logs.

376
00:29:29,111 --> 00:29:32,394
the language believes it's working with time series objects.

377
00:29:32,394 --> 00:29:37,110
And if you're reconstructing time series objects at query time, you're wasting a lot of
CPU.

378
00:29:37,110 --> 00:29:43,793
Well, I Postgres, I think, would disagree with you because they've managed to just say,
yes, we're always going to take all the data and store it in rows and columns, uh,

379
00:29:43,793 --> 00:29:50,826
including your you know key value storage and and graph graph databases and vectors and
whatever and somehow make it make it work.

380
00:29:50,826 --> 00:29:58,069
But and then there's i of course the alternative argument, which is that uh the relational
database is always the fastest, no matter what.

381
00:29:58,069 --> 00:30:00,550
Uh which which I've also seen is true.

382
00:30:00,550 --> 00:30:05,216
Uh we we've sort of validated that graph databases are so slow that performing

383
00:30:05,216 --> 00:30:15,359
Stupid not great queries in in SQL tend to be faster uh by making lots of extra queries,
ten queries at the same time and stitching together the results, rather than using a graph

384
00:30:15,359 --> 00:30:18,130
database, which is sort of uh unfortunate in a lot of ways.

385
00:30:18,130 --> 00:30:26,783
But I I mean, you sort of echoed my point, which is that of it's not necessarily the
languages which are the problem, but some of the semantics of them, but realistically how

386
00:30:26,783 --> 00:30:27,613
the data is being stored.

387
00:30:27,613 --> 00:30:31,670
So how do you deal with the fact that the data format is important?

388
00:30:31,670 --> 00:30:34,491
relational database can store everything, yes.

389
00:30:34,491 --> 00:30:37,973
And everything that's in a relational database can also be a log.

390
00:30:37,973 --> 00:30:41,835
Um everything that's in a relational database you can also model as traces.

391
00:30:41,835 --> 00:30:45,337
I don't know that there's actually a one size fits all.

392
00:30:45,337 --> 00:30:48,768
This is the way that all data shall be modeled.

393
00:30:50,723 --> 00:30:58,412
Back to the uh if you don't have the business problem then there's then there's no there's
no issue technological problem you have to solve.

394
00:30:58,412 --> 00:30:59,722
It's always a great one.

395
00:30:59,722 --> 00:31:02,375
Uh which is why pushing back is important, right?

396
00:31:02,456 --> 00:31:08,896
if you tell someone that, it's gonna be really difficult to do that, they may go back and
find out that they don't need to do it after all.

397
00:31:08,896 --> 00:31:10,783
Y yes, yes.

398
00:31:10,978 --> 00:31:15,963
You know, uh, Eric, I think this may be a good moment to switch over to picks for the
episode.

399
00:31:15,963 --> 00:31:19,240
So maybe you could share with the audience what you've brought.

400
00:31:19,240 --> 00:31:23,231
Uh yeah, I spent a a bunch of time in Japan.

401
00:31:23,231 --> 00:31:25,312
really enjoyed learning the language and stuff.

402
00:31:25,312 --> 00:31:31,803
And and learning the language to me is I think computer science and all that, it's also
language learning in in my mind.

403
00:31:31,803 --> 00:31:33,194
I think of it as as similar.

404
00:31:33,194 --> 00:31:39,355
But the the big thing is there's a a saying that I love uh from Japanese.

405
00:31:39,516 --> 00:31:48,618
It's keizokwa chikaronari, which literally means persistence leads to strength or

406
00:31:48,802 --> 00:31:52,145
Continuous improvement kind of leads to strength.

407
00:31:52,145 --> 00:32:02,234
And it's this notion that if you do something five minutes a day, ten minutes a day, after
a year, you will have done 3,650 minutes.

408
00:32:02,234 --> 00:32:10,101
After two years, after three years, you will have done it so repetitively that you will
find that you are now capable of doing it.

409
00:32:10,101 --> 00:32:15,996
And and I think looking back on my life on everything, like there's a bunch of things that
I did and then stopped doing.

410
00:32:16,070 --> 00:32:20,613
And maybe I was okay at it for a little time, but now and I can't do it at all.

411
00:32:20,613 --> 00:32:29,738
But it's that notion of like, it's not so much about getting to this end state and being
like, okay, it's done, declare victory and we've won.

412
00:32:29,738 --> 00:32:39,303
It's about making sure that you're continuously investing and kind of driving towards
something, whether that be large time commitments or small time commitments.

413
00:32:39,303 --> 00:32:44,106
Uh I I think this notion and this philosophy, I just I I love it is that

414
00:32:44,354 --> 00:32:53,213
The things that are really important, if you just continuously work on them, even if it's
not a lot, out outcomes will will come along with it.

415
00:32:53,442 --> 00:33:01,009
The non research, the sort of feeling result was that it's about a thousand hours of
anything before you become a master.

416
00:33:01,009 --> 00:33:04,642
And a five minutes a day would take you about 20 years to master anything.

417
00:33:04,642 --> 00:33:06,374
Uh, but then you can look at it that way.

418
00:33:06,374 --> 00:33:09,187
After 20 years, you can have mastered whatever it is that you want.

419
00:33:09,187 --> 00:33:16,803
Uh, I think the research actually comes from a book called The Formula, The Science of
Success by Barabasi.

420
00:33:16,824 --> 00:33:19,706
And it was where they evaluated which

421
00:33:19,846 --> 00:33:27,708
in there, there was a lot of good research, but one of them was which Ol Olympic athletes
become Olymp like successful, like actually get gold medals.

422
00:33:27,728 --> 00:33:37,771
And the ones that get to that level are usually not the ones with raw talent or ability,
but the ones who go through significant practice and basically perseverance through

423
00:33:37,771 --> 00:33:39,471
through training to get there.

424
00:33:39,471 --> 00:33:42,532
So not that you're born with it, but that you actually went and did it.

425
00:33:42,532 --> 00:33:49,804
They weren't the best y younger on or when they started, but by the end that that is when
uh they were still able to achieve

426
00:33:49,804 --> 00:34:00,689
I mean obviously there are some, you know, naturals that still take it, but by by and
large, the most victorious ones are are the ones that just continued at it consistently.

427
00:34:00,748 --> 00:34:06,520
couple it with the notion um every time I look in the past, time always went really fast.

428
00:34:06,520 --> 00:34:10,701
Where when you look in the future, time like it if things seem much further out.

429
00:34:10,701 --> 00:34:16,473
Even that five minutes a day, after three years, looking in the past, you will be able to
do something.

430
00:34:16,473 --> 00:34:24,296
Maybe you're not a master, you'll be able to do something and it will have taken like no
time at all because it will have all gone extremely quickly.

431
00:34:24,482 --> 00:34:34,277
I think especially in the Western world now, there's w it does feel like things are
speeding up rather than what has historically been recommended, which is slow down and do

432
00:34:34,277 --> 00:34:35,648
things deliberately.

433
00:34:35,808 --> 00:34:39,450
And uh I think maybe maybe AI is to blame for that.

434
00:34:39,450 --> 00:34:41,051
Maybe cultural is to blame for that.

435
00:34:41,051 --> 00:34:42,892
Uh we'll see.

436
00:34:42,892 --> 00:34:44,293
That's not related to my pick.

437
00:34:44,293 --> 00:34:53,562
Um my my pick uh is and only 'cause I just completely binged it was a television show
called The Agency with Michael Fassbender.

438
00:34:53,562 --> 00:34:54,540
Um

439
00:34:54,814 --> 00:34:57,526
It has to do with the CIA operating out of London.

440
00:34:57,526 --> 00:35:00,639
I mean, obviously, complete fiction.

441
00:35:01,540 --> 00:35:02,517
and I don't know what it is.

442
00:35:02,517 --> 00:35:06,104
I I I don't I don't have love for stuff that is centered in the in the US.

443
00:35:06,104 --> 00:35:11,659
I I always I don't know what it is, but the CIA operating of London, you it's it honestly
is really, really good.

444
00:35:11,659 --> 00:35:13,320
And I think it's produced by Showtime.

445
00:35:13,742 --> 00:35:15,303
Okay.

446
00:35:15,303 --> 00:35:16,195
Nice.

447
00:35:16,206 --> 00:35:19,584
So I don't know if you're into uh spy dramas.

448
00:35:19,584 --> 00:35:21,930
Yeah, I'm I'm trying I'm trying to remember that name.

449
00:35:21,930 --> 00:35:29,557
There was uh there was a a show a while back about uh an ex spy based out of Yeah, Burn
Notice, yes.

450
00:35:29,557 --> 00:35:30,338
Uh

451
00:35:30,364 --> 00:35:32,803
Burn Notice, uh absolutely fantastic.

452
00:35:32,803 --> 00:35:34,166
Uh as well.

453
00:35:35,427 --> 00:35:38,588
Yeah, it's it's definitely something you can also binge.

454
00:35:38,588 --> 00:35:39,619
It's it's great.

455
00:35:39,619 --> 00:35:47,193
I mean the nice thing about Burn Notice is that it was produced in a time before w shows
got canceled before they were over.

456
00:35:48,294 --> 00:35:51,836
Michael Weston, uh not the actor, the the character.

457
00:35:51,836 --> 00:35:52,966
I don't remember the actor's name.

458
00:35:52,966 --> 00:35:55,978
Uh he's in a bunch of things, but uh also very good.

459
00:35:55,978 --> 00:35:56,768
So

460
00:35:56,972 --> 00:35:57,862
Yeah.

461
00:35:58,304 --> 00:35:59,293
I d I don't know what it is.

462
00:35:59,293 --> 00:36:08,086
Uh and you know what, there's sort of like it's not like such negative dark comedy or or
drama.

463
00:36:08,086 --> 00:36:10,539
Like the dark the it's not as bad as dark drama.

464
00:36:10,539 --> 00:36:16,674
I mean there's still stuff going on, but it doesn't feel like uh they just do it for the
the kick, so

465
00:36:16,674 --> 00:36:23,859
Like one of the nice things about Burn Notice was that it it was very episodic, but there
was a little bit of a background thread running between them.

466
00:36:23,859 --> 00:36:36,566
And so you could enjoy one episode and and get completion, get some sort of closure, but
still there was like the the allure or like what's going on behind the scenes, who's

467
00:36:36,566 --> 00:36:37,257
actually doing it.

468
00:36:37,257 --> 00:36:42,162
Is is the agency like you gotta watch the whole season to get the gear closure or is it
one

469
00:36:42,162 --> 00:36:44,243
Yeah, I think that unfortunately that's still where we're at.

470
00:36:44,243 --> 00:36:44,853
Don't worry.

471
00:36:44,853 --> 00:36:55,728
Uh the second screen experience is is coming soon and every show that shows up on a
streaming service will all be episodic so that people don't have to pay attention anymore.

472
00:36:55,728 --> 00:37:06,692
But the agency is still I think it's it's not totally epis um not episodic like a single
thread, but it uh you pretty you do need to sort of know what's going on from the previous

473
00:37:06,692 --> 00:37:07,093
episode.

474
00:37:07,093 --> 00:37:08,333
There still is a major thing there.

475
00:37:08,333 --> 00:37:10,668
There's two seasons right now and they are

476
00:37:10,668 --> 00:37:11,509
Sort of separated.

477
00:37:11,509 --> 00:37:14,801
So you could watch only one and feel like it's complete.

478
00:37:14,801 --> 00:37:19,961
Still, yeah, unfortunately, if you're just looking for single stuff, that's not it.

479
00:37:19,961 --> 00:37:28,251
I will say that the nice part about Burn Notice was that they also sort of educated you on
what is reasonable in Spycraft.

480
00:37:28,251 --> 00:37:29,842
I don't know if that was accurate.

481
00:37:29,842 --> 00:37:35,827
I mean, I think there are lots of videos on YouTube basically saying, you know, these
things they show in shows, you know, aren't real.

482
00:37:35,827 --> 00:37:37,708
I think Burn Notice does a better job.

483
00:37:37,708 --> 00:37:44,746
And I think some of the things they do in the agency also, like if you're paying
attention, uh really help to clue you in on like how things actually work in practice

484
00:37:44,746 --> 00:37:50,712
rather than like today, rather than uh just doing stuff for the for the heck of it.

485
00:37:51,573 --> 00:37:52,354
Okay.

486
00:37:52,354 --> 00:38:00,032
So um thank you, Eric, for coming on and discussing observability with us and the
challenges of managing the database.

487
00:38:00,123 --> 00:38:01,305
Yeah, thank you.

488
00:38:01,305 --> 00:38:02,147
Thank you for having me.

489
00:38:02,147 --> 00:38:03,489
It was great discussion.

490
00:38:03,604 --> 00:38:09,285
And thanks to the audience for tuning in for this week and hopefully we'll see everyone
back again next week.