1
00:00:14,599 --> 00:00:18,839
All right, what's going on,
y'all? Welcome to another episode of Adventures

2
00:00:18,839 --> 00:00:23,480
in dev Ops. I'm your host
for today, Will Button and joining me

3
00:00:23,719 --> 00:00:28,679
for his second attempt, which is
always exciting because you know, I wasn't

4
00:00:28,679 --> 00:00:31,480
sure he was going to come back. I actually had a job one time

5
00:00:31,559 --> 00:00:36,039
where at the end of my first
day, my boss said, hey,

6
00:00:36,079 --> 00:00:39,679
thanks for showing up. It was
great working with you. Hope to see

7
00:00:39,679 --> 00:00:45,200
you tomorrow, but if not,
enjoy your new laptop. But welcoming back

8
00:00:45,280 --> 00:00:49,200
to the studio my new co host, Warren. Hey, Warren, what's

9
00:00:49,240 --> 00:00:52,880
going on? Oh? Thanks?
Well, you know, I definitely plan

10
00:00:52,960 --> 00:00:58,479
on being here for at least one
more session after this. I think i'll

11
00:00:58,479 --> 00:01:03,079
have I think i'll have, you
know, beat by maybe a couple of

12
00:01:03,159 --> 00:01:06,480
days. But you know, thanks
for welcoming me. Yeah, for sure.

13
00:01:06,599 --> 00:01:11,239
I like that you put a commitment
out there, but not a huge

14
00:01:11,239 --> 00:01:14,799
commitment. You're like, I'll be
here for at least one more episode and

15
00:01:14,840 --> 00:01:18,920
then we'll reevaluate. You know.
I have a whole talk on this,

16
00:01:19,000 --> 00:01:26,760
but I think achievable goals are really
important. Also joining us in the studio

17
00:01:26,879 --> 00:01:33,159
today, I'm looking forward to this. I have Mike Bauer's chief architect at

18
00:01:33,400 --> 00:01:40,040
Faircom Corporation, and he he's got
quite the background here. We were talking

19
00:01:40,079 --> 00:01:45,680
before I hit the record button.
He's actually got a little bit more experienced

20
00:01:45,680 --> 00:01:49,799
in this industry than I do,
which is rare when you get to my

21
00:01:49,959 --> 00:01:55,400
age. So I'm excited about that. He works on high performance no SQL,

22
00:01:55,439 --> 00:02:00,359
SQL databases, IoT platforms. He's
the author of pro cs s and

23
00:02:00,640 --> 00:02:05,400
HTML design patterns and this is super
cool. A member of the i n

24
00:02:05,560 --> 00:02:12,360
C I t S Technical Technical Committee
that develops the standards for SEQL and GQUL

25
00:02:12,719 --> 00:02:16,639
the graph Querry language, and that's
super cool. And then if we have

26
00:02:16,759 --> 00:02:21,879
time, one thing I do want
to get into here, just from looking

27
00:02:21,919 --> 00:02:24,919
at your background. You are the
principal architect at the LDS Church, and

28
00:02:24,960 --> 00:02:30,759
I just think that's got to be
a super cool, fascinating job where you

29
00:02:30,800 --> 00:02:36,759
get like those two industries melding together. But anyway, rambling aside, welcome

30
00:02:36,800 --> 00:02:40,280
Mike, glad to be here.
Yeah, it's it's fun. You guys

31
00:02:40,280 --> 00:02:46,639
are blast already cool. Well,
like I tell my wife, if nothing

32
00:02:46,680 --> 00:02:53,879
else, I'm entertaining, No thanks
for thanks for being on the show.

33
00:02:53,000 --> 00:02:58,280
So let's talk a little bit about
your background. You know, like I

34
00:02:58,280 --> 00:03:02,479
mentioned, you've been doing this for
a a minute or two, and you

35
00:03:02,840 --> 00:03:10,439
you appear to have built a lot
of your expertise in the domain of databases.

36
00:03:10,719 --> 00:03:14,800
So tell me a little bit about
how you got to that point.

37
00:03:15,039 --> 00:03:16,599
Hey, folks, this is Charles
Maxwell. I've been talking to whole bunch

38
00:03:16,599 --> 00:03:22,360
of people that want to update their
resume and find a better job, and

39
00:03:22,479 --> 00:03:24,159
I figure, well, why not
just share my resume. So you if

40
00:03:24,199 --> 00:03:29,919
you go to top endevs dot com
slash resume, enter your name and email

41
00:03:29,960 --> 00:03:32,719
address, then you'll get a copy
of the resume that I use that I've

42
00:03:32,800 --> 00:03:38,439
used through freelancing through most of my
career, as I've kind of refined it

43
00:03:38,479 --> 00:03:42,159
and tweaked it to get me the
jobs that I want. Like I said,

44
00:03:42,199 --> 00:03:46,080
topendevs dot com slash resume, we'll
get you that and you can just

45
00:03:46,120 --> 00:03:50,000
kind of use the formatting. It
comes in word and pages formats and you

46
00:03:50,000 --> 00:03:53,479
can just fill it in from there. Yeah. I started out as a

47
00:03:53,520 --> 00:04:00,280
software developer and did that over twenty
years and had a variety of experience is

48
00:04:00,639 --> 00:04:05,960
writing software for consulting firms, and
then moved into manufacturing and built software solutions

49
00:04:06,080 --> 00:04:11,759
and integrated factories like in the silicon
industry. I wore the buddy suit going

50
00:04:11,759 --> 00:04:15,160
into the fabs, you know,
like the Intel commercial they're dancing that was.

51
00:04:15,480 --> 00:04:17,800
I'm not in the commercial, but
I was in the I was definitely

52
00:04:17,839 --> 00:04:25,040
in the fabs, integrating these expensive
million dollars pieces of equipment and learning all

53
00:04:25,079 --> 00:04:32,319
their protocols. And then from there
I moved into working like at Freightliner and

54
00:04:32,480 --> 00:04:38,040
helping them automate their systems. You
know the sprinter van that everybody gets and

55
00:04:38,360 --> 00:04:42,800
either rebuilds it so they can do
campers out of it, and they're like,

56
00:04:42,800 --> 00:04:46,680
this's the Mercedes van and the Mercedes
Freightliner van. That van has a

57
00:04:46,720 --> 00:04:50,879
computer in it. And I wrote
the program that the compiler and the system

58
00:04:50,920 --> 00:04:58,160
that programs that whole thing. So
that was that was really fun. That's

59
00:04:58,160 --> 00:05:01,959
cool, And that's got to be
some interesting constraints there, just knowing that

60
00:05:03,399 --> 00:05:10,399
once that thing leaves the factory,
you've got limited options for getting updates or

61
00:05:10,399 --> 00:05:13,839
communication to in front it. Right. Oh yeah, you got to take

62
00:05:13,839 --> 00:05:16,279
it back into the service system and
they'll plug it in and then then you

63
00:05:16,319 --> 00:05:21,920
can update it with the new electronic
parameters. But that's actually a real computer

64
00:05:23,120 --> 00:05:28,800
with it's completely The engineer that designed
it wanted it to be one hundred percent

65
00:05:28,839 --> 00:05:31,319
programmable, which is unusual. Usually
you just have these little parameters, turn

66
00:05:31,399 --> 00:05:34,399
on, the heated mirrors, turn
on, you know this other feature.

67
00:05:34,879 --> 00:05:40,199
But he wanted it completely programmable,
and so I had to write a compiler,

68
00:05:40,360 --> 00:05:45,480
a true compiler that compiles down to
buy machine code to program that thing.

69
00:05:46,519 --> 00:05:48,160
That's one of those things that I
feel like you'd be able to look

70
00:05:48,199 --> 00:05:51,480
back later and be like that was
either a really great idea or that was

71
00:05:51,600 --> 00:05:58,319
a really bad idea. Right,
Well, I think the spinner bands still

72
00:05:58,399 --> 00:06:01,399
doing well, so I guess it
was a good idea. But my fear

73
00:06:01,600 --> 00:06:05,480
was, you know, I would
have a bug in there, and people's

74
00:06:05,519 --> 00:06:09,360
lives would be at risk because you
know, if there's a bug, bands

75
00:06:09,399 --> 00:06:14,480
can crash, So that was kind
of scary. But no, it's been

76
00:06:14,560 --> 00:06:18,439
really good. There's the vehicle's great. And it was hard the electrical engineers

77
00:06:18,439 --> 00:06:23,000
who were his peers. I was
in the meetings with them and they were

78
00:06:23,079 --> 00:06:28,519
criticizing him like crazy because they couldn't
understand what he was doing. Because he

79
00:06:28,560 --> 00:06:32,040
made the thing programmable. No one
does that. But he wanted flexibility.

80
00:06:32,040 --> 00:06:34,439
He wanted a system that would last
forever. That you, of course,

81
00:06:34,480 --> 00:06:39,079
if you're programmable, you can then
make it do anything in the future.

82
00:06:39,800 --> 00:06:43,959
And so in the meetings they were
killing the project because no one could understand

83
00:06:43,959 --> 00:06:46,360
it. But I was getting what
he was saying, and I thought,

84
00:06:46,439 --> 00:06:48,040
I can do this. I can
write the competitor to program this thing.

85
00:06:48,680 --> 00:06:53,319
And so he talked to him and
I switched my role from building the system

86
00:06:53,360 --> 00:06:59,000
that the web system that would actually
send down the electronic parameters. I built

87
00:06:59,000 --> 00:07:00,959
most of that already, and then
we switched gears to writing the compiler,

88
00:07:01,000 --> 00:07:03,439
and I spent a year on that
and got that going. So yeah,

89
00:07:03,439 --> 00:07:09,160
I think it was good. Beach
did talk to Freightliner see if they thought

90
00:07:09,199 --> 00:07:13,920
it it's still good. That's a
good question, you know, because they

91
00:07:13,920 --> 00:07:15,319
had to pay another firm to take
over when I left, I was a

92
00:07:15,360 --> 00:07:19,720
consultant, and so that firm has
to maintain it, so we'll see.

93
00:07:20,399 --> 00:07:28,399
I don't know. But then from
there I went to I was watching all

94
00:07:28,519 --> 00:07:32,639
these people that were DBAs making a
lot of money at the time, right

95
00:07:32,680 --> 00:07:36,279
back in the two thousand era,
the DBAs made more money than developers,

96
00:07:36,759 --> 00:07:42,800
and I was also frustrated that Microsoft
had shifted their whole tool set and I

97
00:07:42,800 --> 00:07:46,040
had become an expert in certain tools
and they completely pulled us out from under

98
00:07:46,079 --> 00:07:49,399
me, and I was frustrated,
and I thought, Okay, more money.

99
00:07:49,680 --> 00:07:54,199
I love databases. I love data. So I kind of decided I

100
00:07:54,240 --> 00:07:57,759
wanted to become an Oracle DBA because
they made the most money for sure,

101
00:07:57,800 --> 00:08:03,399
And so then I decided to switch
careers and move into that area. And

102
00:08:03,439 --> 00:08:07,920
then is from there that I got
employed at the Eldis Church. And I

103
00:08:07,959 --> 00:08:13,800
started out as an Oracle DBA and
the person who hired me wanted me to

104
00:08:13,839 --> 00:08:16,360
do that for a little bit and
then become a manager of the team,

105
00:08:16,839 --> 00:08:20,439
and I went from and I did
that, and then I I was a

106
00:08:20,519 --> 00:08:24,439
dB Oracle DBA for about a year
and I managed the Oracle DBA team that

107
00:08:24,519 --> 00:08:30,360
the core team that supported cour teams
with twelve engineers, and we supported over

108
00:08:30,480 --> 00:08:35,519
sixty database engineers, so DBAs south
through organization, we had on thousands of

109
00:08:35,639 --> 00:08:41,440
databases. And then from there I
became the data architect for the entire organization,

110
00:08:41,879 --> 00:08:48,759
which is a multi billion dollar international
organization, so it's very large with

111
00:08:50,440 --> 00:08:58,879
thousands of developers. You think the
church, but it's it's an international organization

112
00:08:58,000 --> 00:09:03,440
that builds lots of software for its
members to do membership like things. Like

113
00:09:03,480 --> 00:09:09,519
one of these systems was an international
banking system because the church brings in tithing

114
00:09:09,639 --> 00:09:16,039
from all over the world and they
need they it's very important to keep this

115
00:09:16,200 --> 00:09:20,960
money safeguarded. Right there is no
international banking system that you can just buy.

116
00:09:22,799 --> 00:09:24,519
You just can't. You know,
that doesn't exist, So we had

117
00:09:24,519 --> 00:09:28,000
to build it. So I was
the lead on the data side for that

118
00:09:28,080 --> 00:09:33,799
whole project to build a brand new
international banking system from the ground up.

119
00:09:33,879 --> 00:09:37,200
So that's the kind of stuff I
did there. And while I was there,

120
00:09:37,240 --> 00:09:41,639
I looked into these no SQL databases, so we brought in everyone you

121
00:09:41,679 --> 00:09:46,759
could think of. This was right
during the whole revolution between the sequel and

122
00:09:46,799 --> 00:09:48,039
the no sequel, and so I
was right in the middle of all that,

123
00:09:48,519 --> 00:09:56,000
and I became an expert in mark
Logic, Mango dB Cassandra, and

124
00:09:56,600 --> 00:10:01,759
then we had a bunch of and
of course the Oracle sequel server and then

125
00:10:01,799 --> 00:10:05,679
mark Logic, which is an XML
database, and so those databases were on

126
00:10:05,679 --> 00:10:11,679
my team, and I was the
architect for helping people decide which databases to

127
00:10:11,799 --> 00:10:16,159
choose. So I became really good
at each of those technologies and supporting them

128
00:10:16,440 --> 00:10:20,279
as a developer. Right as a
developer, why would you choose one of

129
00:10:20,320 --> 00:10:22,559
these databases that I invised the whole
you know, Like I said, we

130
00:10:22,600 --> 00:10:26,840
had a several thousand developers, so
I was advising them on which database do

131
00:10:26,840 --> 00:10:31,559
you want to choose for your next
project? So that was that's where I

132
00:10:31,600 --> 00:10:33,919
became. I went to conferences,
I started presenting a conferences, and that's

133
00:10:33,919 --> 00:10:39,039
where Faircom saw me and they go, well, we want you to become

134
00:10:39,080 --> 00:10:45,559
our chief architect because Faircom builds as
for forty years has built a database product

135
00:10:46,639 --> 00:10:50,200
and they are the Fundamentally, Faircom
is a no SQL database, but it

136
00:10:50,240 --> 00:10:56,879
has SQL capabilities, and they wanted
to make their no SQL features more modern.

137
00:10:56,960 --> 00:11:01,440
They had a forty year old ISAM
technology which is actually amazingly fast and

138
00:11:01,600 --> 00:11:05,759
efficient but very hard to program,
and they wanted to modernize that. So

139
00:11:05,840 --> 00:11:11,240
I was brought on board to turn
Faircom dB into a JSON database and a

140
00:11:11,240 --> 00:11:16,559
SQL database and an M database at
the same time on the same data.

141
00:11:18,639 --> 00:11:22,240
So you could have three APIs that
are completely different on the same data and

142
00:11:22,320 --> 00:11:28,120
give you three advantages like the sequel
as universal standardized works with everything, and

143
00:11:28,879 --> 00:11:31,320
the M is super fast, bare
metal. A record on disc is a

144
00:11:31,399 --> 00:11:35,720
record in memory in your process,
no layers in between. Nothing can beat

145
00:11:35,720 --> 00:11:39,960
the performance of that layer. It's
just you have to program it. You

146
00:11:39,000 --> 00:11:43,480
have a lot of programming to do. And then I added a JSON layer,

147
00:11:43,759 --> 00:11:48,679
so you can create with JSON and
get data back as JSON and it's

148
00:11:48,679 --> 00:11:50,120
the same data we get in SQL, the same data we get in the

149
00:11:50,320 --> 00:11:54,639
ICM. So that's what for the
last five years, that's what I've been

150
00:11:54,639 --> 00:11:58,840
working on, and we're delivering here
in March a brand new version that has

151
00:12:00,039 --> 00:12:05,000
full Jason capabilities like Mango or couch
Base plus these other two layers, which

152
00:12:05,039 --> 00:12:07,120
the other with couch Base has a
SQL plus plus, so they have a

153
00:12:07,120 --> 00:12:13,519
sequel like solution we treat. We
have true ant CI squel solution Faircom does

154
00:12:13,600 --> 00:12:18,080
with the Jason with this low level
API, so when your queries can't get

155
00:12:18,120 --> 00:12:22,159
fast enough, you can go inside
the machine, inside the engine with that

156
00:12:22,240 --> 00:12:28,799
ISM layer and get incredible performance.
And I'm not exaggerating when I say faster

157
00:12:28,000 --> 00:12:31,960
than anything else on the market.
I got a machine doing a million inserts

158
00:12:33,000 --> 00:12:37,840
per second, and Oracle would and
I twoed Oracle database. I built Oracle

159
00:12:37,879 --> 00:12:43,679
exit data replacements at the Ilias Church. I design those and built them faster

160
00:12:43,759 --> 00:12:48,200
than Oracle exit data runs using an
Oracle database. So I know what speed

161
00:12:48,240 --> 00:12:50,320
is and how fast the Oracle can
go. And this blows Oracle away.

162
00:12:52,440 --> 00:12:54,559
It's just the level of programming you
have to do is about four or four

163
00:12:54,799 --> 00:13:01,559
times harder at that ISM layer than
sequel is. So the underlying data is

164
00:13:01,600 --> 00:13:07,240
the same in any case, it's
just you choose which of those three options

165
00:13:07,279 --> 00:13:11,039
you want to use to get the
data exactly. Wow, that's pretty good.

166
00:13:11,080 --> 00:13:16,120
Yeah, so fun. The Jason
is. I love the document database

167
00:13:16,200 --> 00:13:20,639
world. You know, I as
a developer. I was. I was

168
00:13:20,679 --> 00:13:24,480
a developer first before I became a
DBA and before I became a data architect.

169
00:13:24,279 --> 00:13:30,440
So I love building software. I
love doing it quickly, and I

170
00:13:30,519 --> 00:13:33,879
know I don't hate. I hate
to spend days on the low level stuff

171
00:13:33,919 --> 00:13:37,120
twiddling, you know, finding reading
this spec and figuring out okay, well

172
00:13:37,120 --> 00:13:39,960
that bit, oh yeah, that
bit's the one that makes it work.

173
00:13:39,000 --> 00:13:43,840
You know. The Jason changes everything. You get up and running in no

174
00:13:43,000 --> 00:13:48,159
time. You're building solutions so fast. It's so simple, and and it

175
00:13:48,200 --> 00:13:52,799
still has the core engine speed of
our core ISAM. It's just it has

176
00:13:52,840 --> 00:13:58,039
the translation layer tuned from Jason.
So it's fast and it's easy and it's

177
00:13:58,200 --> 00:14:01,919
fun. So yeah, Jason is
one of my favorites, so of course,

178
00:14:01,960 --> 00:14:05,679
but I love SQL. Like I'm
on the Insights Committee, like you

179
00:14:05,720 --> 00:14:09,120
said, I part of the Equal
Standards Group. The sequel is a great

180
00:14:09,200 --> 00:14:13,159
language, and we're enhancing it,
like to do more things. And GQUL

181
00:14:13,279 --> 00:14:18,120
is a graph queer language, right, so we're enhancing that and so those

182
00:14:18,159 --> 00:14:24,000
are so I really am a fan
of those technologies. But it's not It

183
00:14:24,039 --> 00:14:28,639
shouldn't be one game in town.
Your database shouldn't lock you into just I'm

184
00:14:28,639 --> 00:14:31,759
a SQL database, that's all I
do. Or I'm a even stranger,

185
00:14:31,799 --> 00:14:35,080
I'm an ISAM database, which is
what fair Come has been for until the

186
00:14:35,159 --> 00:14:39,480
last until now. And then of
course the Jason is like, well we're

187
00:14:41,120 --> 00:14:43,080
Manga, says well, I'm a
Jason database. That's all I really do.

188
00:14:46,159 --> 00:14:48,960
So yeah, you have the best
of all worlds for sure. Yeah,

189
00:14:48,000 --> 00:14:54,360
because each one has its own strengths
and weaknesses that our gun to one

190
00:14:54,360 --> 00:14:58,919
of those is going to line up
with what you're trying to achieve better and

191
00:14:58,559 --> 00:15:05,440
and that just help shore. It
has the potential to help you build more

192
00:15:05,519 --> 00:15:11,759
quickly and actually focus on what you're
delivering to your customers rather than focusing on

193
00:15:11,879 --> 00:15:18,000
the technology limitations. Yes, you
get that scenario where Okay, I want

194
00:15:18,039 --> 00:15:20,039
SQL for most of my stuff because
I can write those queries fast, I

195
00:15:20,039 --> 00:15:26,440
can join my data, have flexibility. I know I could achieve any kind

196
00:15:26,480 --> 00:15:30,000
of functionality in sequel, it just
may not be super fast. And then

197
00:15:30,039 --> 00:15:33,279
you go, but what about that
one query. There are times when I'm

198
00:15:33,279 --> 00:15:37,000
been in an oracle in that big
banking system I was talking about. We

199
00:15:37,039 --> 00:15:41,919
had a query that ran for two
weeks because they had so many billions and

200
00:15:41,960 --> 00:15:46,679
billions of records turning through them and
making reports. The thing ran for two

201
00:15:46,679 --> 00:15:50,840
weeks, and so I had to
go in there and I write low level

202
00:15:50,919 --> 00:15:54,519
functions to really tune this and that. We spent weeks tuning that query.

203
00:15:54,639 --> 00:15:58,639
Finally we got it to run in
four hours, but it was a massive

204
00:15:58,679 --> 00:16:03,879
effort. And I was thinking about
this. If I would have had the

205
00:16:03,960 --> 00:16:07,480
ISAM engine, that would have been
that would have been a day of work,

206
00:16:07,840 --> 00:16:11,279
and I would had total control and
I would have gotten ten times faster.

207
00:16:11,320 --> 00:16:15,840
It'd have been forty minutes there instead
of forty four hours, you know,

208
00:16:15,279 --> 00:16:18,720
from two weeks. So that's that's
the kind of when you need to

209
00:16:18,759 --> 00:16:22,879
get under into the engine and say, I know how to make this fast.

210
00:16:22,039 --> 00:16:25,919
I know what I need to do. Just get out of my waist.

211
00:16:25,919 --> 00:16:29,840
Sequel, let me do it.
And it's really hard in these SQL

212
00:16:29,919 --> 00:16:33,840
databases to go down there and do
that. So yeah, you use the

213
00:16:33,879 --> 00:16:37,440
right tool for the right job on
the same data makes a big difference.

214
00:16:38,080 --> 00:16:41,039
What I'm hearing is you left the
Oracle world and went to the no sequel

215
00:16:41,080 --> 00:16:48,440
world and it's better. Yes,
well but yeah, that's true. But

216
00:16:48,480 --> 00:16:52,080
I the sequel that does things that
the no squel can't do, and that's

217
00:16:52,120 --> 00:16:57,840
really important. The nosequel world threw
the baby out with the bathwater when they

218
00:16:57,879 --> 00:17:03,879
said we don't need we don't need
acid consistency. Well, actually, I

219
00:17:03,919 --> 00:17:07,839
know the president of Mango dB,
not the current one but the one previous

220
00:17:07,839 --> 00:17:11,079
one, and you know, we've
be met a lot and talked and and

221
00:17:11,079 --> 00:17:14,720
he says, you know, by
the way, don't tell anyone. I

222
00:17:14,759 --> 00:17:18,240
guess. I guess I'm telling everyone
now because he's gone. But they go,

223
00:17:18,799 --> 00:17:21,720
you know, we know we need
to be acid compliant, we know

224
00:17:21,799 --> 00:17:25,160
we need to build. It's just
hard, it's really hard, and it

225
00:17:25,279 --> 00:17:30,359
slows us down, and so we're
just telling everybody you don't need that stuff.

226
00:17:30,920 --> 00:17:34,799
It's eventually consistent. It's awesome,
and it's you know, eventually good

227
00:17:36,920 --> 00:17:41,440
in terms of consistency. But eventual
consistency is a euphemism for never consistent.

228
00:17:41,720 --> 00:17:45,519
And if your data is not consistent, that's not a good thing. It

229
00:17:45,519 --> 00:17:48,079
means you write a lot of code
to compensate. There are some use cases

230
00:17:48,119 --> 00:17:51,160
where it is good, So don't
get me wrong, there are some use

231
00:17:51,200 --> 00:17:55,240
cases eventually consistence perfect. Those are
the exceptions. Most of the time you

232
00:17:55,319 --> 00:17:59,759
need consistent data your customers expect when
they put something into query it and it

233
00:17:59,799 --> 00:18:03,880
comes back. And Mango wrote all
kinds of workarounds to make a lot of

234
00:18:03,920 --> 00:18:07,319
illusions happen. I'm not saying it's
a bad product. I'm just saying that

235
00:18:08,119 --> 00:18:11,960
when you need consistency, it's really
hard to get it in a no SQL

236
00:18:12,039 --> 00:18:17,119
database. Now fair comes different.
We have our engine is at its core

237
00:18:17,240 --> 00:18:21,960
consistent, and then if you want
to relax that and go inconsistent, I'm

238
00:18:21,960 --> 00:18:26,319
going to use the less fun term
inconsistency of less. Is it eventually consistent,

239
00:18:26,960 --> 00:18:30,119
then you can and then you know
your trade offs. So I think

240
00:18:30,119 --> 00:18:32,880
it's good to have an engine that
you really can tune to go where you

241
00:18:32,920 --> 00:18:37,279
needed to go. But the other
thing about seql that they threw out was

242
00:18:37,839 --> 00:18:41,720
the ad hoc query ability, and
the Mango kept a lot of it,

243
00:18:41,759 --> 00:18:45,079
but a lot of other databases threw
that one out, and then they said,

244
00:18:45,119 --> 00:18:48,680
well, we don't need joints.
Well, that's the dumbest thing I've

245
00:18:48,720 --> 00:18:55,279
ever heard. You can't denormalize your
data to put everything that you ever possibly

246
00:18:55,279 --> 00:18:59,720
could to query and put it into
one thing. If you did, you'd

247
00:18:59,720 --> 00:19:03,480
have the tired database in one Jason
document. You know, let's just make

248
00:19:03,519 --> 00:19:04,920
a whole database on one joy and
we could carry the heck out of it

249
00:19:04,960 --> 00:19:07,839
anybody want. Yeah, but that
won't perform you to have a whole database

250
00:19:07,920 --> 00:19:14,680
level locks like Mongo used to have, you know it just you need to

251
00:19:14,720 --> 00:19:18,400
break your data into pieces. You
need customers to be separate from orders because

252
00:19:18,400 --> 00:19:21,920
customers are not orders, and orders
are separate from products because they're not the

253
00:19:22,039 --> 00:19:25,079
same thing, and you need so
you need to break them apart as soon

254
00:19:25,119 --> 00:19:27,720
as you break them apart, then
you have to join them. And so

255
00:19:27,880 --> 00:19:33,880
SEQL is fantastic. It joins,
It has all these great join technologies to

256
00:19:33,960 --> 00:19:37,920
bring the data back together at high
speed, and developers have forgotten that.

257
00:19:37,000 --> 00:19:41,759
They forgot because it's under the hood, it's invisible in the sequel engines.

258
00:19:41,200 --> 00:19:44,480
They just think, oh, yeah, you just go loop through and join

259
00:19:44,519 --> 00:19:47,279
it by hand. You really how
much code you have to write to do

260
00:19:47,319 --> 00:19:49,680
that? And then it's slow because
you don't get the cool algorithms like the

261
00:19:49,759 --> 00:19:53,480
merge join the index, the hash
joins the index, joints, all these

262
00:19:53,519 --> 00:19:59,359
really cool technologies that speed things up
that sequel engines have built in over forty

263
00:19:59,440 --> 00:20:02,359
years of two those things. Developers
don't even know what they are for the

264
00:20:02,400 --> 00:20:07,319
most part, so they don't even
realize what they're missing. And so what

265
00:20:07,440 --> 00:20:11,200
you need it You need SQL for
those kind of things because it's good at

266
00:20:11,240 --> 00:20:15,359
those, but you need no SQL
for other kinds of things like JSON for

267
00:20:15,400 --> 00:20:18,480
the simplicity and development and for the
flexibility. You know, Jason is not

268
00:20:18,599 --> 00:20:23,720
so rigid. You can add new
things as you go, but there's always

269
00:20:23,759 --> 00:20:27,000
a caveat with you add new things
as you go. Let's say you put

270
00:20:27,000 --> 00:20:30,559
them in some documents, some properties
in some documents and leave them out of

271
00:20:30,599 --> 00:20:33,920
others, and you run a query. If the property is not there,

272
00:20:34,039 --> 00:20:38,440
the document doesn't show up. And
now your queries aren't useful because you're not

273
00:20:38,519 --> 00:20:42,920
getting everything. So you need some
schema level protection to Jason and say,

274
00:20:42,960 --> 00:20:45,960
you know, I'm queering on this
property. You better have it there and

275
00:20:47,000 --> 00:20:49,359
you better index it, you know, And so you need It's more than

276
00:20:49,559 --> 00:20:55,240
just let's just throw everything in a
bit bucket and hope it works, which

277
00:20:55,279 --> 00:21:00,400
is how no SQL markets itself.
I can't just do that and expect your

278
00:21:00,440 --> 00:21:03,480
app to work. So that's why
I'm a big passionate person. And it's

279
00:21:03,519 --> 00:21:07,519
not because I work at Faircom.
I came to work at fair Com because

280
00:21:07,559 --> 00:21:11,720
I'm passionate about you need multiple models. You need when you need consistency,

281
00:21:11,759 --> 00:21:15,319
you need it. When you need
less consistency or eventual consistency, you need

282
00:21:15,359 --> 00:21:19,880
it. When you need SQL and
joins, you know you can't get with

283
00:21:19,960 --> 00:21:22,880
that. You need that technology,
and when you need Jason, you need

284
00:21:22,960 --> 00:21:26,480
flexibility, you need it. So
why not have an engine in a model

285
00:21:26,720 --> 00:21:30,759
that can do all of those things? And that's my dream because I wasn't

286
00:21:30,799 --> 00:21:36,160
finding it really anywhere, and when
Faircom recruited me five years ago, this

287
00:21:36,240 --> 00:21:37,240
is what I wanted to build.
I've been wanting to build my own nose

288
00:21:37,240 --> 00:21:41,160
SQL database for the last fifteen years, and so I went, oh,

289
00:21:41,279 --> 00:21:45,400
this is my dream job. I
get to design and build my dream database.

290
00:21:45,920 --> 00:21:51,079
So and releasing the first version of
that database, like I said in

291
00:21:51,160 --> 00:21:56,400
March, so I'm super excited about
that. I'm thinking to like the cloud

292
00:21:56,440 --> 00:22:02,839
providers and what they're offering as far
as no SQL and cloud providers databases and

293
00:22:03,200 --> 00:22:06,519
SQL ones, and I get the
sense that the no sqle ones are always

294
00:22:06,680 --> 00:22:08,920
cheaper and easier to get up and
running and start integreeting with. And I'm

295
00:22:08,960 --> 00:22:15,200
wondering how much that encourages developers around
the board engineering departments, even startup companies

296
00:22:15,240 --> 00:22:22,400
that grow to eventually make them the
primary use case for whatever sort of data

297
00:22:22,440 --> 00:22:26,359
they need to store. And I
keep thinking, well, maybe if we

298
00:22:26,400 --> 00:22:30,599
want SQL to still have a world
like where is the cheap to run,

299
00:22:30,720 --> 00:22:34,119
very very easy to spin up straight
away? Like where is that? Yeah?

300
00:22:34,640 --> 00:22:38,519
Yeah, and Oracle is the most
complicated, hard to learn technology ever

301
00:22:38,599 --> 00:22:44,359
invented in the universe. I'm not
exaggerating that. You know, single servers

302
00:22:44,400 --> 00:22:47,440
easy, you know, Microsoft SQL
servers a beautiful easy piece of cake.

303
00:22:47,480 --> 00:22:51,160
And Postcress is kind of in between
Oracle and siql server because it's some source

304
00:22:51,200 --> 00:22:55,079
and they have all these PhD students
at Berkeley just adding new features and it's

305
00:22:55,119 --> 00:22:57,960
ad hoc and it's not reorganized as
well. So Postcress has is harder than

306
00:22:59,000 --> 00:23:03,200
SQL server. Oracle though, is
just a nightmare. I've never seen things

307
00:23:03,240 --> 00:23:07,279
so complicated. So, yeah,
where is the easy SQL database that you

308
00:23:07,279 --> 00:23:08,559
could just stand up in the cloud? I mean, you could argue SQL

309
00:23:08,599 --> 00:23:14,599
server might be that database, but
then what about the no sequel? Right

310
00:23:14,599 --> 00:23:19,240
that the no SQL databases are so
specialized with a few exceptions, Like you

311
00:23:19,279 --> 00:23:26,839
take Amazon they have there, they
have Dynamo dB, and Dynamo dB is

312
00:23:26,920 --> 00:23:30,920
really a key value store that it's
all about the key. You can have

313
00:23:30,279 --> 00:23:37,160
a hierarchical key, and you can
if you can segment your key properly,

314
00:23:37,240 --> 00:23:41,799
you can query down inside your key
and get subsets of data. You can

315
00:23:41,880 --> 00:23:45,799
have secondary indexes, but that's really
just another database under the hood with with

316
00:23:45,880 --> 00:23:49,640
doubling your cost for every secondary index, and you know, by the time

317
00:23:49,680 --> 00:23:52,160
you look at really doing that for
real, Like, you know, how

318
00:23:52,160 --> 00:23:56,079
many indexes do I have a real
database like a Oracle or single server.

319
00:23:56,359 --> 00:24:00,599
I have thousands of indexes in a
real application. Well let's see to imagine

320
00:24:00,599 --> 00:24:03,920
the cost of at a thousand copies
of my data in Dynamo dB just to

321
00:24:03,960 --> 00:24:07,599
try to do the same kind of
thing. It's just ridiculous. So Dynamo

322
00:24:07,680 --> 00:24:12,680
dB is a good example in my
mind, of a specialized database that's good

323
00:24:12,799 --> 00:24:17,640
for certain use cases like use your
profiles. If you want to get use

324
00:24:17,640 --> 00:24:21,680
your profile data fast and you want
guaranteed response times. I want to look

325
00:24:21,759 --> 00:24:23,759
up Warren, I want to get
your data app Boom, it's there.

326
00:24:23,799 --> 00:24:27,680
You know it will boom it's there. So that's Dynamo dB. That's why

327
00:24:27,680 --> 00:24:32,400
they admitted it for their own Amazon
dot Com. You know, it's good

328
00:24:32,400 --> 00:24:34,640
for those use cases. But that's
not what you build an app on.

329
00:24:36,039 --> 00:24:38,799
I need an app that needs to
grow with the company. I have yet

330
00:24:38,880 --> 00:24:41,319
to see an app that said,
oh yeah, here's the specs. They're

331
00:24:41,319 --> 00:24:45,319
perfect. You build it in six
months, will never change, it will

332
00:24:45,400 --> 00:24:48,680
never evolve it, We'll never have
another use case. You know, it's

333
00:24:48,759 --> 00:24:52,000
you know, the exact opposite right, you're tweaking that thing forever and you

334
00:24:52,039 --> 00:24:53,519
go. Then the customer comes back, Oh, I didn't think about this.

335
00:24:55,400 --> 00:24:57,039
How do you get customer? I
want to go around a career that

336
00:24:57,079 --> 00:25:00,799
gives me all the customers that made
these orders, where the customers were over

337
00:25:00,880 --> 00:25:04,640
forty years old, and the products
were oreos, and the orders are made

338
00:25:04,720 --> 00:25:07,119
last month, and you got to
join that data together and you got to

339
00:25:07,160 --> 00:25:11,039
filter those three take those three pieces
of data and bring it all together in

340
00:25:11,079 --> 00:25:15,599
a filtered way. And you're like, uh, I can't do that in

341
00:25:15,680 --> 00:25:19,519
Dynamo dB. I didn't. I
didn't denormalize my data properly to answer that

342
00:25:19,640 --> 00:25:23,799
question. Sorry, let me go
copy all my data and then put it

343
00:25:23,839 --> 00:25:29,920
over here and that other specialized database. And now the customers do this.

344
00:25:29,960 --> 00:25:33,200
I teams do this. Like there's
a one of our customers built a cloud

345
00:25:33,200 --> 00:25:37,839
solution. They had five database technologies
in Amazon that they thought this would be

346
00:25:37,839 --> 00:25:42,160
great. We'll use these specialized databases
and we'll build each one. We'll spread

347
00:25:42,200 --> 00:25:47,319
the data across them. The cost
of that application is so high no one

348
00:25:47,359 --> 00:25:52,400
will buy it. So their product
uses fair Com and it's super fast.

349
00:25:52,799 --> 00:25:56,599
The cloud version with all these databases
is way slower, so expensive, no

350
00:25:56,640 --> 00:26:00,039
one will buy it. They're they're
looking at putting Faircom in the cloud cloud

351
00:26:00,160 --> 00:26:04,079
just to run their product in the
cloud because you don't have the complexity or

352
00:26:04,519 --> 00:26:10,400
they and the costs is so simple
and inexpensive. So yeah, I think

353
00:26:10,440 --> 00:26:14,039
it's important to keep all those things
in mind when you build a product.

354
00:26:14,119 --> 00:26:17,880
Complexity is your enemy, and that's
what the cloud makes you do. It's

355
00:26:18,160 --> 00:26:22,160
complex solutions. I'm not anti cloud. I'm just saying the cloud, the

356
00:26:22,200 --> 00:26:26,079
salesman and the cloud wants you to
buy five databases. They want you to

357
00:26:26,119 --> 00:26:30,759
spend up all this because they make
a fortune off of you and they don't

358
00:26:30,799 --> 00:26:34,240
and they think that's the way to
go because it it's their financial you know,

359
00:26:34,279 --> 00:26:38,279
it makes them rich, so it's
great for them. But yeah,

360
00:26:38,319 --> 00:26:44,599
and not only do you have like
the cost of maintaining those five instances,

361
00:26:45,079 --> 00:26:51,160
but like the the ETL and the
data transformation for replicating that data is not

362
00:26:51,440 --> 00:26:55,039
a trivial task. You know,
you have to hold the data, make

363
00:26:55,039 --> 00:26:59,599
sure you're getting the last the correct
data and making the right transformations to it,

364
00:26:59,640 --> 00:27:03,599
and then writing it to that new
data source and verifying that it's there.

365
00:27:03,720 --> 00:27:10,559
And like the the maintenance and overhead
of just keeping that process alive is

366
00:27:10,640 --> 00:27:15,359
a dedicated team. It is just
to write it. But then I love

367
00:27:15,400 --> 00:27:18,920
the DevOps angle. The dedicated team
to keeping that alive is people are so

368
00:27:19,039 --> 00:27:22,160
expensive. You know, you don't
want to hire me to go build your

369
00:27:22,200 --> 00:27:26,000
systems, and as you're gonna put
me on a very productive environment because I'm

370
00:27:26,559 --> 00:27:30,640
super expensive. And now you're going
to say, now, Mike, you're

371
00:27:30,200 --> 00:27:36,359
you are in DevOps. You need
to keep this complex five database system alive.

372
00:27:36,680 --> 00:27:40,160
I think of all the break points. You've got network connections between five

373
00:27:40,200 --> 00:27:44,559
different systems. Each of those systems, typically in the cloud, is sharded,

374
00:27:44,839 --> 00:27:48,920
so it scales horizontally. That means
multiple servers in each database that have

375
00:27:48,000 --> 00:27:51,400
to be kept running. And you
say, well, Amazona will do all

376
00:27:51,440 --> 00:27:53,240
that for me, Well they do, and they don't. They keep it

377
00:27:53,319 --> 00:27:57,079
up, they patch it for you. But making it work, troubleshooting the

378
00:27:57,079 --> 00:28:02,640
problems in your application across all the
systems, oh, DevOps the developer can

379
00:28:02,680 --> 00:28:04,359
do all that. Well. The
last thing I want to do is a

380
00:28:04,400 --> 00:28:08,640
developer, is maintain infrastructure. Is
I don't want to support that stuff.

381
00:28:10,279 --> 00:28:11,680
I want to throw it over the
wall and let those guys do it.

382
00:28:12,039 --> 00:28:17,200
But now nope, DevOps developer,
you are on call. You're gonna go

383
00:28:17,279 --> 00:28:18,759
fix it. You're going to go
maintain it. And that's we're going to

384
00:28:18,799 --> 00:28:22,759
do that to you because we want
you to build a simple, maintainable solution.

385
00:28:22,400 --> 00:28:26,799
That's not possible in the cloud unless
you switch your paradigm to something like

386
00:28:26,839 --> 00:28:30,559
a Aircom database where you say I'm
going to do I'm going to get a

387
00:28:30,559 --> 00:28:34,480
tool that gives me the it's not
just a Swiss Army knie because it gives

388
00:28:34,480 --> 00:28:37,039
you the wrong idea. It's like
a bunch of tools. It's like,

389
00:28:38,160 --> 00:28:42,440
we don't even have the right analogy. It's three APIs over the same engine.

390
00:28:44,279 --> 00:28:48,720
It's not like three hammers like cosmocbs
is five hammers. There are if

391
00:28:48,839 --> 00:28:53,640
you think you're buying five one one
database engine with five APIs. No,

392
00:28:53,839 --> 00:28:56,839
every time you put data in one
of those engines, like there're no SEQL

393
00:28:56,880 --> 00:29:02,480
engine or their SEQL engine, it's
completely separate engine with the data separate.

394
00:29:02,920 --> 00:29:06,079
It's a marketing gimmick to say it's
one database. No, it's a bunch

395
00:29:06,119 --> 00:29:11,000
of different databases or your data spread
out all over the place. So having

396
00:29:11,039 --> 00:29:15,559
a real database with multiple APIs on
it is. It's sort of like a

397
00:29:15,559 --> 00:29:17,880
Swiss Armony knife. You get the
best of all the above, but it's

398
00:29:17,920 --> 00:29:22,519
one engine, which Swiss Armon Knife's
not that way, you know. So

399
00:29:22,799 --> 00:29:33,599
it's a bad analogy. But so
you know you mentioned earlier that earlier in

400
00:29:33,640 --> 00:29:38,599
your career, like the DBA was
the the highest paid member in engineering,

401
00:29:38,599 --> 00:29:42,200
and I remember those days. Everyone
wanted to be a DBA and the DBAs

402
00:29:42,759 --> 00:29:49,400
had this almost limitless power. They
could stop a production release and its tracks

403
00:29:51,000 --> 00:29:53,200
and not tell you when they're going
to release it, and the entire company

404
00:29:53,319 --> 00:29:56,839
was like, oh, well,
okay, you know, but they did

405
00:29:56,880 --> 00:30:00,119
a lot of work. You know, they did add value because they they

406
00:30:00,119 --> 00:30:04,119
were answering and designing for a lot
of these problems we've been talking about so

407
00:30:04,319 --> 00:30:10,279
far. But when I look around
today, I don't see DBAs anymore.

408
00:30:10,319 --> 00:30:11,920
And I know that there are still
some out there and some companies still have

409
00:30:12,039 --> 00:30:17,920
them, but for the most part, there are no DBAs, but those

410
00:30:18,000 --> 00:30:23,279
problems still exist. So what are
the what are the things that as DevOps

411
00:30:23,279 --> 00:30:29,440
and as software developers, what are
the things that we should be thinking about,

412
00:30:29,680 --> 00:30:33,960
or what are like the high level
thumb rules we should be using to

413
00:30:33,240 --> 00:30:40,480
avoid making us really wish we had
hired DBAs. Yeah, I think that

414
00:30:40,599 --> 00:30:45,960
no sequel moment was really the no
DBA movement at this right, I totally

415
00:30:47,000 --> 00:30:51,680
get it because when I was at
Freightliner, we had a DBA. This

416
00:30:51,759 --> 00:30:56,960
person she was the how I would
say, she's the Nazi DBA. I

417
00:30:56,960 --> 00:30:59,839
mean, it was just a nightmare. You try to go and you give

418
00:30:59,880 --> 00:31:03,240
her your schema and she goes,
nope, nope, nope, go fix

419
00:31:03,279 --> 00:31:07,279
it. What do you want when
you make it right, I'll approve it.

420
00:31:07,599 --> 00:31:10,440
Well, why do you when you
make it right? Like see,

421
00:31:10,519 --> 00:31:11,839
then you go, well, what
is right to you? Because right that

422
00:31:11,920 --> 00:31:15,720
because it was right to me,
you know, So I go tweak it

423
00:31:15,720 --> 00:31:18,839
again. Finally, at one point
I said, you know what, she's

424
00:31:18,880 --> 00:31:22,599
disapproving every single thing I'm doing.
And I know I'm not doing a bad

425
00:31:22,680 --> 00:31:25,839
job here. I know the rules
of normalization, I know all this stuff,

426
00:31:25,880 --> 00:31:27,720
and I had normalized it beautifully and
I also tuned it for performance.

427
00:31:29,079 --> 00:31:33,000
And then she got Then I realized, you know what she is wanting simple.

428
00:31:33,359 --> 00:31:36,799
She wants one bulletproof schema that will
work for any kind of data,

429
00:31:36,839 --> 00:31:38,000
anywhere, at any time, and
I'm like, I know how to do

430
00:31:38,039 --> 00:31:42,160
this. I'm going to build a
database within a database. So I designed

431
00:31:42,240 --> 00:31:47,039
five tables that if you use it
just right, you can put any data

432
00:31:47,160 --> 00:31:51,319
without ever calling her again. I
showed this model to her and she goes

433
00:31:51,680 --> 00:31:56,200
perfect approved because I would never have
to go back to her again, and

434
00:31:56,240 --> 00:31:59,359
she didn't have to talk to me
again. And it was like, this

435
00:31:59,480 --> 00:32:02,640
is the but this most horrible thing
ever created. This is the anti pattern

436
00:32:02,680 --> 00:32:06,720
of all data designs. So yeah, so this is an example of why

437
00:32:06,759 --> 00:32:12,119
developers like, Okay, this is
a dumb DBA creating really bad designs,

438
00:32:12,799 --> 00:32:15,759
fall breaking all the rules because she
doesn't know any better, and and it

439
00:32:15,799 --> 00:32:20,279
was really sad. But that's the
kind of stuff like I'm free now,

440
00:32:20,519 --> 00:32:22,480
I don't have I'm a developer.
I can just build my app. No

441
00:32:22,599 --> 00:32:27,359
DBA to get in my way.
But to your point, we lost a

442
00:32:27,400 --> 00:32:30,759
lot of things. For one,
the developer lost a DBA to take the

443
00:32:30,799 --> 00:32:37,079
heat because the DBA sits between infrastructure
and the developer, and the first thing

444
00:32:37,119 --> 00:32:39,880
an app has a problem, the
developer just points to the DBA as your

445
00:32:39,880 --> 00:32:44,079
fault. They always do that,
and then DBA points to infrastructure. It's

446
00:32:44,119 --> 00:32:46,960
your fault, right, and so
it's usually it is infrastructure's fault because they

447
00:32:47,000 --> 00:32:51,519
have storage goes out or some network
thing went wrong. But sometimes it's the

448
00:32:51,599 --> 00:32:53,759
database, and a lot of times
it's the app itself, you know.

449
00:32:53,839 --> 00:32:58,400
So it's it could be anywhere,
but the DBA is right in the middle.

450
00:32:58,559 --> 00:33:01,160
You take the DBA away to what
happens to developers on the hook for

451
00:33:01,200 --> 00:33:06,720
everything except for the infrastructure, and
the infrastructure guys are worse than DBAs to

452
00:33:06,759 --> 00:33:08,920
do it. It's not my storage
system. I don't have any problems.

453
00:33:09,759 --> 00:33:15,119
I had a one time it was
I had. I had so many storage

454
00:33:15,119 --> 00:33:19,319
problems at one place I was working
that we had to hire ten thousand dollars

455
00:33:19,359 --> 00:33:22,279
per consultant to come in and run
in scripts on the system to prove it

456
00:33:22,359 --> 00:33:25,599
was the storage rate because the storage
r egg. I kept saying, no,

457
00:33:25,680 --> 00:33:29,559
it's not my problem. I knew
it was the storage. So we

458
00:33:29,680 --> 00:33:32,160
paid ten thousand dollars to prove it
was a storage to get the problem fixed,

459
00:33:32,599 --> 00:33:37,200
to get to get our solution built. So yeah, now the developer

460
00:33:37,200 --> 00:33:39,599
has to do that. The developer
doesn't even know what I ops are.

461
00:33:40,039 --> 00:33:44,240
The developer doesn't even know what latency
is. I mean, how in the

462
00:33:44,279 --> 00:33:47,319
heck are you supposed to get a
developer even talk the lingo of the infrastructure

463
00:33:47,359 --> 00:33:51,759
folks to figure out a problem.
So you take the DBA away, You're

464
00:33:52,079 --> 00:33:55,640
you're asking for all kinds of headaches
and problems. And then there's data.

465
00:33:57,240 --> 00:34:04,240
Data requires some structure, it requires
some forethought, and a developer lives in

466
00:34:04,240 --> 00:34:07,079
the now. It says, how
can I get this feature out the door

467
00:34:07,200 --> 00:34:09,480
today? How can I crank this
code out as fast as possible? Let

468
00:34:09,559 --> 00:34:15,000
QA get the bugs out? You
know, Well, that last thing they

469
00:34:15,039 --> 00:34:19,679
want to think about is how do
I structure my data to survive the test

470
00:34:19,719 --> 00:34:22,480
of time? Is my application ages
I'm going to I'm going to really have

471
00:34:22,519 --> 00:34:27,920
to rewrite everything if I don't design
this data well a good DBA. A

472
00:34:27,960 --> 00:34:31,400
good DBA not the one that a
head of Fredeliner would come back and say,

473
00:34:31,519 --> 00:34:37,039
how do how do we make it
bulletproof? But not overdesigned? You

474
00:34:37,079 --> 00:34:40,400
know, it's that sweet spot.
And then most developers don't understand that,

475
00:34:40,599 --> 00:34:44,639
and so they just crank it out, and then they're rewriting and rewriting and

476
00:34:44,639 --> 00:34:49,440
rewriting. Their companies pay a fortune
for these developers to rewrite it. Because

477
00:34:49,440 --> 00:34:53,400
they didn't have forethought and so,
and Agile just makes that worse because Agile

478
00:34:53,480 --> 00:34:57,039
is like crank the teacher out this
week, our sprint's done, get it

479
00:34:57,039 --> 00:35:00,280
out the door, show the demo, show the UI. Absolutely, the

480
00:35:00,400 --> 00:35:04,360
uh I doesn't have the data structure
and it so no one sees that or

481
00:35:04,400 --> 00:35:07,760
cares about it. Now, before
the Agile people get angry at me,

482
00:35:07,760 --> 00:35:10,039
they would say, well, that's
not true agile, and I agree with

483
00:35:10,079 --> 00:35:14,480
them, except for every company I've
worked for that does agile, doesn't do

484
00:35:14,559 --> 00:35:15,920
true agile. They do what I
just said, crank it out, get

485
00:35:15,920 --> 00:35:22,599
it out the door, show the
UI. So there's reality here. Yeah.

486
00:35:22,679 --> 00:35:30,320
I think if the excuse is is
always well that's not the pure implementation

487
00:35:30,400 --> 00:35:35,239
we designed, then maybe maybe that's
a problem with the purity of your design.

488
00:35:36,239 --> 00:35:42,039
Yeah exactly, Yeah, yeah right, I'm just you know, I

489
00:35:42,159 --> 00:35:45,679
keep going on with my head like
I wonder if something regarding how we treat

490
00:35:45,719 --> 00:35:51,800
databases today and the separation of ownership
maybe in this regard, has devofs failed

491
00:35:51,880 --> 00:35:55,960
us. Yeah. I think we
need balance again. I think Agile and

492
00:35:57,000 --> 00:36:00,920
DevOps and some of these new and
then no Squl trends which threw the DBA

493
00:36:01,039 --> 00:36:06,880
out with the bathwater. You know, I think that is went too far.

494
00:36:07,079 --> 00:36:09,199
I think I'm not And in fact, some companies are bringing back debas

495
00:36:09,239 --> 00:36:14,719
for some database like Mango, DBA
and Cassandra are so hard to maintain they

496
00:36:14,800 --> 00:36:17,360
hire full time people. They don't
call them DBAs as much, but they're

497
00:36:17,480 --> 00:36:22,559
administrators to keep the system running because
Mango is pretty hard to keep running,

498
00:36:22,559 --> 00:36:25,360
and so is Cassandra. In fact, my last job, we hired a

499
00:36:25,400 --> 00:36:31,239
full time person just to reboot the
Cassandra database every week because and it's not

500
00:36:31,320 --> 00:36:35,719
just the database is a whole bunch
of servers. By the way, Cassandra

501
00:36:35,800 --> 00:36:38,079
is super expensive. If you're going
to go down to the cass you better

502
00:36:38,119 --> 00:36:42,519
really know what you're doing. Because
that's my least favorite database of all time

503
00:36:42,840 --> 00:36:45,599
for because it dev ops as a
nightmare in it and it's so complicated to

504
00:36:45,639 --> 00:36:49,519
design. It takes you ten times
longer to build anything because you have to

505
00:36:49,559 --> 00:36:53,760
denormalize everything because you can only query
data in one table, so or you

506
00:36:53,840 --> 00:36:59,320
have multiple tables. They're white column
tables. But if you can't join so

507
00:36:59,480 --> 00:37:02,719
you're basically saying all my possible careers
I could ever do have to match one

508
00:37:02,800 --> 00:37:07,800
table and you and you you know, we just talked about that earlier.

509
00:37:07,880 --> 00:37:09,880
You have to join, but because
you can't at Cassandra, you do you

510
00:37:10,360 --> 00:37:15,519
just it drives you crazy. It
took us five years to build an application

511
00:37:15,559 --> 00:37:17,239
that you could have built in six
months in some of the night fair com

512
00:37:17,320 --> 00:37:22,079
dB because Cassandra's limitations and in that
database, we had a hard just to

513
00:37:22,119 --> 00:37:25,599
reboot all these servers in the cluster
once a week. He just his job

514
00:37:25,719 --> 00:37:28,679
was to write, you know,
run these scripts to reboot them, make

515
00:37:28,679 --> 00:37:31,559
sure they came back up. And
nothing went down on that overall cluster database,

516
00:37:31,599 --> 00:37:36,360
but the servers themselves were going down
and back up because Java has garbage

517
00:37:36,360 --> 00:37:40,719
collection and casoder's written in Java,
and so when that hits your database performance

518
00:37:42,159 --> 00:37:45,039
just takes so you have to you
have to reboot the server to clear out

519
00:37:45,039 --> 00:37:49,719
the Java Java, the garbage collection
engineer Java, just to make the thing

520
00:37:49,800 --> 00:37:52,000
run. So I was like,
oh my gosh. You know, that's

521
00:37:52,039 --> 00:37:57,519
why there's so much marketing high ground
no sequel, which is the promise of

522
00:37:57,559 --> 00:38:01,679
a developer owns their world. Well, when you own the world, like

523
00:38:01,760 --> 00:38:05,400
you're saying, Warren, you know, it's kind of the death of DevOps

524
00:38:05,400 --> 00:38:08,880
because developers don't want to be that
involved in the ops side, in the

525
00:38:08,880 --> 00:38:15,400
administration side of anything, and so
they don't and it's pulling teeth to get

526
00:38:15,440 --> 00:38:21,480
them involved. So yeah, I
think it's a real problem for DevOps to

527
00:38:21,480 --> 00:38:24,880
not have database specialists. So like
we have front end in the developer where

528
00:38:24,880 --> 00:38:29,840
we have frontend specialists and back in
specialists, your back in specialists are now

529
00:38:29,920 --> 00:38:34,519
the DBAs they need or really know
your data. So I think I think

530
00:38:34,519 --> 00:38:37,840
that's good too, but you got
to realize your back in specialists really need

531
00:38:37,880 --> 00:38:42,480
to know your data engine and think
about data and if you do that,

532
00:38:42,639 --> 00:38:45,280
I think you're going to be fine
as a company. And then the front

533
00:38:45,360 --> 00:38:47,639
end guys will never do DevOps because
they're just the front end app. So

534
00:38:47,679 --> 00:38:53,159
the back end you're backing engineers are
your DBAs, they're your DevOps people.

535
00:38:53,800 --> 00:39:00,360
So hire data savvy back in engineers
and you'll be fine as a companycause they'll

536
00:39:00,360 --> 00:39:02,880
make good decisions. I feel like
this is a hot tag, but maybe

537
00:39:02,920 --> 00:39:07,960
it's if we're always using a database
where we need to hire an additional person

538
00:39:08,039 --> 00:39:12,920
in order to figure out and run
it effectively. Has that database technology failed

539
00:39:13,000 --> 00:39:15,400
us? Like no one to be
using Cassandra, if it really is true

540
00:39:15,400 --> 00:39:19,599
that we have to hire people to
manage that. And I feel like the

541
00:39:19,639 --> 00:39:22,920
promise of the no squel, as
you pointed out, is that you can

542
00:39:22,039 --> 00:39:28,159
have the usage of those databases by
engineers and run them without hiring an additional

543
00:39:28,199 --> 00:39:30,719
person. I mean, how do
we rectify that in the world where we

544
00:39:30,800 --> 00:39:37,039
stop using these technologies where you have
to hire a DBA or whatever the new

545
00:39:37,119 --> 00:39:42,239
term is system administrator for our database
type, Because as long as we have

546
00:39:42,320 --> 00:39:44,840
them, people are going to keep
falling to the trap of maybe we can

547
00:39:44,960 --> 00:39:47,719
use that database of what it promises
on the marketing website, but then find

548
00:39:47,719 --> 00:39:52,519
out later that we need to hire
a really high paid specialist in order to

549
00:39:52,559 --> 00:39:55,760
come in in order to actually utilize
the technology effectively. Yeah, I think

550
00:39:57,199 --> 00:40:00,000
I think that's what the whole no
sequel moment was about. Was more high

551
00:40:00,639 --> 00:40:06,079
you know, they were it's a
good thing to compete with SQLQ SQL databases

552
00:40:06,079 --> 00:40:10,719
were kind of sitting on their laurels, not innovating enough in real ways that

553
00:40:10,719 --> 00:40:15,119
that developers need. So no SQL
was great and is great for that,

554
00:40:15,840 --> 00:40:21,679
but it doesn't you can't hide the
reality that work needs to be done.

555
00:40:21,760 --> 00:40:23,800
In fact, I had a really
wise engineer once told me, you know,

556
00:40:23,920 --> 00:40:27,760
it doesn't matter where you put the
work in a software project. The

557
00:40:27,840 --> 00:40:30,920
work needs to be done. So
if you move all the work to the

558
00:40:30,960 --> 00:40:34,159
developer, great, but make sure
that you're going to have to have specialized

559
00:40:34,199 --> 00:40:37,719
developers who know how to do the
work. The work doesn't The data is

560
00:40:37,760 --> 00:40:40,519
hard. You have to think about
co locating data. You have to think

561
00:40:40,559 --> 00:40:44,840
about do I run the code on
a separate server or on the database server,

562
00:40:44,920 --> 00:40:47,079
because if it's a batch job or
bulk processing job, the code has

563
00:40:47,119 --> 00:40:52,320
to run near the data because network
latency and network throughput is going to kill

564
00:40:52,320 --> 00:40:54,039
you. By moving the need to
off the server somewhere else and bringing it

565
00:40:54,079 --> 00:41:00,199
back. You need to run the
code on the server. So there's these

566
00:41:00,239 --> 00:41:06,159
specialists who know how data works,
and you can pretend, oh, yeah,

567
00:41:06,239 --> 00:41:07,719
we got rid of that. And
that's what the no sequel movement did

568
00:41:08,239 --> 00:41:13,360
in the and the and the in
Mango is the most successful of all of

569
00:41:13,360 --> 00:41:16,840
them, fifth most popular database in
the world. Now, by pretending that

570
00:41:17,079 --> 00:41:22,400
these problems don't exist and the developers
is fully in charge, it's a brilliant

571
00:41:22,599 --> 00:41:28,719
marketing play. Totally brilliant but the
reality is now the developer is the DBA,

572
00:41:29,400 --> 00:41:31,679
so and that that work didn't go
away, And as a developer,

573
00:41:31,719 --> 00:41:37,679
did you really want to be the
DBA. That's that's the question you have

574
00:41:37,679 --> 00:41:40,039
to ask yourself. If you're back
in engine, if you're back in developer,

575
00:41:40,440 --> 00:41:45,000
now you're the hated DBA because you're
gonna build a web service and the

576
00:41:45,039 --> 00:41:45,880
friend of the guys is going to
give you this year and go, no,

577
00:41:46,239 --> 00:41:49,480
I've got to refracture my data.
That's not going to work for me,

578
00:41:50,320 --> 00:41:52,760
and then then they're gonna hate you. So then there'll be a revolution

579
00:41:52,840 --> 00:41:55,800
against the back end engineer. It's
all fronting the engineers. I don't know,

580
00:41:55,800 --> 00:42:00,840
I'm joking on that, but it
could happen. I don't mean it's

581
00:42:00,880 --> 00:42:04,320
a bit ridiculous, but actually there
are plenty of products out there that claim

582
00:42:04,400 --> 00:42:07,280
that they are back ends as a
service and from some company that is offering

583
00:42:07,320 --> 00:42:12,199
this and you don't have to worry
about how your data even looks like or

584
00:42:12,239 --> 00:42:15,119
anything like. You just throw data
at us and we'll store it and do

585
00:42:15,199 --> 00:42:17,320
the right thing. And I think
the same probably can be said of all

586
00:42:17,360 --> 00:42:22,079
of those products as well. Right, totally, totally their work has to

587
00:42:22,119 --> 00:42:25,199
be done. Somebody has to think
about data and the structure and where you're

588
00:42:25,199 --> 00:42:31,480
going to process it. And it's
a specialty. So figure out where as

589
00:42:31,519 --> 00:42:35,559
an organization, figure out where you
want to be. I don't think no,

590
00:42:35,679 --> 00:42:37,559
I don't think SEQL databases are dead
by any means, and I don't

591
00:42:37,559 --> 00:42:42,599
think the DBA for those are dead. I think we just need this.

592
00:42:42,760 --> 00:42:46,760
Seql is innovating and they're embracing Jason
a little more. The secret databases.

593
00:42:46,800 --> 00:42:52,119
Do you have Jason support? Postgress
is the best at Jason support, and

594
00:42:52,159 --> 00:42:57,280
that's why it's becoming really popular.
But you could choose a kitchen sink database

595
00:42:57,360 --> 00:43:00,920
like Postgress or Oracle, which has
everything you can imagine in it, but

596
00:43:00,960 --> 00:43:05,639
none of them are really awesome except
for the sqel engine. Or you could

597
00:43:05,679 --> 00:43:10,079
choose especially database like Mango that's really
good at JSON technically Bison, you know,

598
00:43:10,159 --> 00:43:15,320
but then it and then but that's
not really good at the joining of

599
00:43:15,400 --> 00:43:19,880
data. So there's not there's really
no perfect solution out there yet. That's

600
00:43:19,920 --> 00:43:22,880
why I'm working at Faircom because my
goal is to build the right solution.

601
00:43:23,239 --> 00:43:27,400
And to your point, that's point
warrant about. People just want a service.

602
00:43:27,760 --> 00:43:30,960
Right, that the data layer moved
from a seqel layer, which traps

603
00:43:31,000 --> 00:43:37,000
the data behind SQL, the SQL
career language, to a web service layer,

604
00:43:37,000 --> 00:43:39,840
which frees the data in JSON.
Right. So well, with fair

605
00:43:39,840 --> 00:43:43,679
coom dB, we have the seql
air, we have the ISAM layer,

606
00:43:43,679 --> 00:43:45,519
which we need super speed, but
now we have the Jason layer, and

607
00:43:45,639 --> 00:43:51,960
it is the Jason layer is the
service. It's it's over HTTP. So

608
00:43:52,039 --> 00:43:57,039
you just send JSON requests over HTTP
and then you get answers back and the

609
00:43:57,119 --> 00:44:00,440
JSON and the answer comes back to
JSON. So your data is Jason,

610
00:44:00,599 --> 00:44:05,199
your query's or Jason. Everything's Jason. And it is a web service over

611
00:44:05,480 --> 00:44:09,800
Https. So we provide that now
and we and and like you said,

612
00:44:09,800 --> 00:44:13,639
everybody says, well now we need
to transform the data. We need to

613
00:44:13,639 --> 00:44:16,800
reshape the Jason. So that's the
next phase we're building here at Faircom is

614
00:44:16,840 --> 00:44:23,199
that is the VA JavaScript engine into
our product to do all those fancy transforms

615
00:44:23,239 --> 00:44:27,000
on the server side, so you
get the data shape to the way you

616
00:44:27,079 --> 00:44:30,360
need it. But that doesn't even
though that's to me, that's a game

617
00:44:30,440 --> 00:44:35,920
changer and and and potentially it could
even replace a lot of back end development

618
00:44:37,480 --> 00:44:40,119
because we are a web service as
well, But that doesn't mean it replaces

619
00:44:40,159 --> 00:44:46,320
all of the back end development just
really simplifies their efforts. But you you

620
00:44:46,400 --> 00:44:51,159
still need to think about data.
That doesn't change the fact you've got to

621
00:44:51,199 --> 00:44:54,719
think like a DBA, a developer
DBA. Where you're where you are thinking

622
00:44:54,719 --> 00:44:58,960
about our architecture DBA, How should
the data be data? How should we

623
00:44:59,039 --> 00:45:01,519
organize the data? How shoul to
be model the data? So we could

624
00:45:01,519 --> 00:45:07,159
build an application that can survive the
test of time. Maybe eighty percent of

625
00:45:07,199 --> 00:45:10,400
the time. You'll never get one
hundred percent, but eighty percent is pretty

626
00:45:10,400 --> 00:45:13,960
awesome. But if you use something
like if you don't do any of it,

627
00:45:14,000 --> 00:45:15,639
you're gonna be surviving twenty percent of
the time on your current design and

628
00:45:15,719 --> 00:45:21,440
rewriting eighty percent of the time,
and your company is as a developer,

629
00:45:21,440 --> 00:45:25,360
it's great job security, and developers
actually think about those things. Oh yeah,

630
00:45:25,360 --> 00:45:30,159
this is great, I'll be employed
here forever, you know, but

631
00:45:30,960 --> 00:45:32,760
it's not good for the company.
So any manager listening to this to really

632
00:45:32,800 --> 00:45:38,800
pay attention that developers are protecting themselves
by cranking out stuff fast and they know

633
00:45:38,840 --> 00:45:42,599
they have to rewrite it and they're
going to job security is there, and

634
00:45:42,599 --> 00:45:45,599
you're paying them the biggest bucks now
to do all of that, you should

635
00:45:45,840 --> 00:45:52,920
think really carefully about data design and
cutting, you know, really reducing costs.

636
00:45:53,480 --> 00:45:57,480
Hey, there, this is Charles
Maxwood. I'm excited because I wanted

637
00:45:57,480 --> 00:46:00,039
to let you know about this thing
that I pulled together that I had just

638
00:46:00,360 --> 00:46:05,440
I've been dying to have this for
years and I never felt like I could,

639
00:46:05,719 --> 00:46:07,119
and then I just realized that there's
no reason why I can't. So

640
00:46:07,480 --> 00:46:12,039
I'm putting together a book club and
we're going to read development focused books,

641
00:46:12,199 --> 00:46:15,760
career books, you know, technical
books, whatever. The first book that

642
00:46:15,760 --> 00:46:20,159
we're going to do is going to
be Clean Architecture by Uncle Bob Martin.

643
00:46:20,320 --> 00:46:22,719
If you're not familiar with clean code
or some of the other stuff that Bob

644
00:46:22,760 --> 00:46:25,239
has done, check that out.
I've also talked to him on the Clean

645
00:46:25,280 --> 00:46:30,000
Coders podcast, which is on top
end Devs. But yeah, we're going

646
00:46:30,079 --> 00:46:31,119
to get on. He's going to
show up to some of our meetings,

647
00:46:31,320 --> 00:46:36,119
and what I'm thinking is we'll probably
have like five or six people part of

648
00:46:36,159 --> 00:46:39,239
the conversation along with Bob and I
at the same time, and we'll just

649
00:46:39,679 --> 00:46:44,280
so somebody can come on, they
can ask their question and then we'll just

650
00:46:44,679 --> 00:46:47,679
rotate people through, so we'll mute
one person, unmute another person when it's

651
00:46:47,719 --> 00:46:52,480
their turn to come on and be
part of the discussion. So we'll do

652
00:46:52,559 --> 00:46:53,760
that for like an hour, hour
and a half. And then the other

653
00:46:53,800 --> 00:46:58,159
part of it that I'm putting together
is just kind of a meet and greet

654
00:46:58,239 --> 00:47:04,679
gather area on Gathered and so after
the meetup and the call, we we'll

655
00:47:04,679 --> 00:47:07,800
do as we'll all go over to
gather town and you can just log in,

656
00:47:07,880 --> 00:47:10,119
walk up to a group and have
a conversation, and that way we

657
00:47:10,119 --> 00:47:15,039
can all kind of get to know
each other and make friends and get to

658
00:47:15,039 --> 00:47:17,079
know people across the world. One
thing that I'm finding is that, yeah,

659
00:47:17,119 --> 00:47:20,719
the meetups are starting to come back, but a lot of people don't

660
00:47:20,719 --> 00:47:22,480
have the opportunity to go to a
meetup. And I really want to meet

661
00:47:22,480 --> 00:47:24,920
you guys and talk to you.
So we're gonna put all that together.

662
00:47:25,000 --> 00:47:28,559
We'll all be part of that book
club. You can go to topendevs dot

663
00:47:28,599 --> 00:47:30,719
com slash book Club to be part
of it, and I'm looking forward to

664
00:47:30,760 --> 00:47:36,159
seeing you there. The first book
club meeting will be in December, the

665
00:47:36,239 --> 00:47:39,800
beginning of December, we're starting the
first week of December, and you'll also

666
00:47:39,840 --> 00:47:44,440
be part of the conversation about which
book we do next. I have one

667
00:47:44,440 --> 00:47:46,480
in mind, but I want to
see where everybody's at. So there you

668
00:47:46,519 --> 00:47:52,360
go for sure they're doing Yeah,
they're doing exactly what you've asked them to

669
00:47:52,400 --> 00:47:58,280
do. Yeah, yeah, exactly. So I want to get your opinion

670
00:47:58,320 --> 00:48:02,719
on this because to me, whenever
a lot of the companies I've worked with,

671
00:48:04,159 --> 00:48:08,119
you know, they're spending fifty sixty
one hundred thousand dollars a month on

672
00:48:08,719 --> 00:48:16,599
Looker and Snowflake, and not for
the visualization part of those tools, but

673
00:48:16,679 --> 00:48:22,840
for the ETL transformation. That's where
all the money gets spent. And to

674
00:48:22,960 --> 00:48:28,440
me, that's not a product.
That's a symptom of not having your database

675
00:48:28,760 --> 00:48:32,000
design well thought out to serve your
business. What are your thoughts on that?

676
00:48:32,719 --> 00:48:37,239
Yeah, well, it may be
a symptom of not thinking it through

677
00:48:37,360 --> 00:48:42,280
for sure, right, and it
also may be a symptom of specialization.

678
00:48:42,559 --> 00:48:45,679
So and when you write an online
transaction application and you're trying to service transactions

679
00:48:45,679 --> 00:48:51,360
with low latency, right, you're
going to design your data model and optimize

680
00:48:51,400 --> 00:48:55,519
it for that use case. That's
the exact opposite of the opposite optimization you

681
00:48:55,599 --> 00:49:00,000
have to do for a data warehouse. A data warehouse, you're going to

682
00:49:00,639 --> 00:49:02,840
completely design it a different way.
You're going to go into I like the

683
00:49:02,920 --> 00:49:08,400
Kimball model. There's two major warehousing
philosophies Inman and Kimball, and Kimball is

684
00:49:08,599 --> 00:49:15,440
more practical. Kimball says, denormalize
your data into a fact table and dimensions.

685
00:49:15,119 --> 00:49:20,159
And basically what you're doing is you're
saying, you asked the question what

686
00:49:20,519 --> 00:49:23,719
questions will our users ask? What
answers do they need from our data?

687
00:49:23,880 --> 00:49:29,480
And so you build those answers into
the dimensions that we build the filters for

688
00:49:29,559 --> 00:49:31,119
the answers and the dimensions, and
then you put the facts in the fact

689
00:49:31,119 --> 00:49:34,639
table. So the facts could be
like the order costs. You know,

690
00:49:34,840 --> 00:49:37,920
if you're ordering a product, what
was the order cost? The dimensions are

691
00:49:37,119 --> 00:49:39,840
when did you order it, who
ordered it, where do they live?

692
00:49:40,000 --> 00:49:44,000
What time? All these all these
you know, who win, what where,

693
00:49:44,079 --> 00:49:49,599
why how dimensions surrounding the fact table. You would never build a transaction

694
00:49:49,679 --> 00:49:53,159
system of doing that because you're you'd
be super duper slow. So what happens

695
00:49:53,239 --> 00:49:58,519
is you have to take the data
out of your transaction system and then etil

696
00:49:58,559 --> 00:50:01,679
it over or e lt O over
to your your data warehouse, which could

697
00:50:01,679 --> 00:50:06,639
be Snowflake or red Shift, or
it could be Oracle Exit Data. Now

698
00:50:06,679 --> 00:50:08,960
there's all kinds of warehouse products out
there, and and that's the one one

699
00:50:09,280 --> 00:50:13,280
my roles at the LDS Church was
the data architect. We had one hundred

700
00:50:13,320 --> 00:50:17,280
person b I t that I was
the architect for so I have hands on

701
00:50:17,360 --> 00:50:22,280
experience with all this and these We
had one hundred engineers pulling data out of

702
00:50:22,360 --> 00:50:30,840
these transactional databases, restructuring them to
answer queries that the end the business users

703
00:50:30,880 --> 00:50:35,119
have so to make to write a
database that can answer queries in a timey

704
00:50:35,239 --> 00:50:38,760
fashion for a business user, you
have to restructure the data. So it's

705
00:50:38,800 --> 00:50:44,760
actually it's a problem of optimization.
It's but it's it's not it's not a

706
00:50:44,760 --> 00:50:50,840
bad optimization. It's that you're optimizing
transactions for their things. Gardener, optimizing

707
00:50:50,920 --> 00:50:55,039
for two different use cases. Yeah, and that's and that's okay. Gardner.

708
00:50:55,039 --> 00:50:59,280
For a while, there was promoting
this hybrid model where you'd have your

709
00:50:59,280 --> 00:51:05,519
operational and you're analytical in the same
database. And the dream was you'd put

710
00:51:06,000 --> 00:51:08,920
you you'd optimize your data for transactional
in the SEQUL side of the database,

711
00:51:08,920 --> 00:51:15,880
but then you'd have in memory column
stores. So use your your Calumn technology

712
00:51:15,880 --> 00:51:20,280
instead of road based transactional, you'd
switch it to column based in memory,

713
00:51:20,559 --> 00:51:23,840
and then you have a Calumner view
of your road data, but the columns

714
00:51:23,840 --> 00:51:30,400
in memory. So then you can
create the Calumner data sort of like Kimball's

715
00:51:30,440 --> 00:51:35,480
model of facts and dimensions, but
you really have But that doesn't. The

716
00:51:35,559 --> 00:51:38,079
Kimball model works only when you ask, ay, what are the questions our

717
00:51:38,159 --> 00:51:43,360
customers you're asking, and then you
organize the data to answer those questions.

718
00:51:43,519 --> 00:51:45,840
Think of it this way, Kimball
says, I'm going to pre define my

719
00:51:45,920 --> 00:51:49,039
reports as data, so all you
have to do is just I want this

720
00:51:49,079 --> 00:51:51,599
on my report, this report.
You're just selecting I want this, this,

721
00:51:51,639 --> 00:51:54,440
and this this on my report done
well. You're not going to take

722
00:51:54,440 --> 00:51:59,480
a transactional system and put it in
a Columner store in memory and expect that

723
00:51:59,559 --> 00:52:04,559
to perform well because you're not tuning
it to answer the exact questions your users

724
00:52:04,599 --> 00:52:07,719
have. So it's more fantasy than
reality to say I can have a database

725
00:52:07,800 --> 00:52:15,360
do everything without data modeling. Gotcha, But could you simplify the process of

726
00:52:15,360 --> 00:52:21,320
getting data to those data warehouses because
ETL is about is about getting the data

727
00:52:21,440 --> 00:52:25,559
extracting it, and that actually is
harder than you think. The E part

728
00:52:25,880 --> 00:52:30,320
is one of the hardest parts.
The transforming part is pretty straightforward once you

729
00:52:30,360 --> 00:52:32,559
know what you want, and then
the loading it is super easy. So

730
00:52:34,079 --> 00:52:37,119
the E part is where the problem
is. So if you can get the

731
00:52:37,239 --> 00:52:40,840
data, if you can get a
database to automatically extract this data for you

732
00:52:40,880 --> 00:52:45,880
and push it where it needs to
go, then the solution becomes way better.

733
00:52:46,440 --> 00:52:51,800
So I build a system at Faircom
to do that because I know this

734
00:52:51,880 --> 00:52:54,840
problem and I wanted to solve it, and so we build a what we

735
00:52:54,880 --> 00:52:59,000
call it dB Notify, and what
it does is every time there's a change

736
00:52:59,039 --> 00:53:04,920
in the source system, we automatically
send a JSON message over and our We

737
00:53:04,960 --> 00:53:07,960
have an MPTT broker product as well, so it's a high it's a mission

738
00:53:07,960 --> 00:53:13,119
critical MPTTT broker, so it's a
message que broker. So we what we

739
00:53:13,199 --> 00:53:16,159
do is every time a data change
occurs in the database, we send a

740
00:53:16,239 --> 00:53:22,119
Jason message over our message broker,
which guarantees delivery and and I guarantees delivery

741
00:53:22,199 --> 00:53:25,480
wants, because you you've got to
have that guaranteed in order to get your

742
00:53:25,519 --> 00:53:30,760
data somewhere reliably. Of course.
Yeah. So then and then any system,

743
00:53:30,920 --> 00:53:34,519
whether it's a Java program putting it
into a cash, whether it's a

744
00:53:34,519 --> 00:53:39,800
SQL database retrieving you know, for
warehousing, can can subscribe to these messages

745
00:53:40,199 --> 00:53:45,320
and get the data automatically. So
the e part, the hard e part

746
00:53:45,360 --> 00:53:47,679
of extracting the data goes away,
and you just simply say give me Jason

747
00:53:49,280 --> 00:53:52,440
and and the data just flows and
you have Jason and now with a JSON

748
00:53:53,119 --> 00:54:00,280
you can you can now manage the
the T and the L trivially. Yeah,

749
00:54:00,320 --> 00:54:02,239
because there is a huge trouble that
actually a lot of companies, I

750
00:54:02,239 --> 00:54:06,559
feel like, run into where they
have a lot of individual teams with each

751
00:54:06,599 --> 00:54:10,199
of their own databases, and then
they overinvest in setting up a complex technology

752
00:54:10,559 --> 00:54:16,400
like Kofka to varying messages from those
individual databases to align it and push it

753
00:54:16,440 --> 00:54:22,280
into whatever their data warehouse is.
Coff is a great example what Kafka's advantage

754
00:54:22,280 --> 00:54:27,840
is, It's like it's like a
combination of a message que plus a log,

755
00:54:28,360 --> 00:54:31,280
right, so you can so you
can query the message log and see

756
00:54:31,320 --> 00:54:35,119
everything that's happened, and it's distributed
to at scales and all that. But

757
00:54:35,159 --> 00:54:37,159
it's complicated, hard to use and
all that. Well, what I did

758
00:54:37,199 --> 00:54:40,440
is I looked at that and I
said, no way, can't it be

759
00:54:40,639 --> 00:54:45,000
simple? So I said, what
is the simplest message queue technology on the

760
00:54:45,000 --> 00:54:50,280
market as a protocol. And the
answer is MQTT. It's it's because taking

761
00:54:50,320 --> 00:54:54,679
over a MQP, because a MQP
is complicated as the Advanced Message q protocol

762
00:54:54,920 --> 00:54:59,880
and that's used in Rabbit, mqqubit
and other products and active mq it's a

763
00:55:00,239 --> 00:55:05,079
technology, it's just complicated. M
qtt's taken over the IoT world by storm

764
00:55:05,159 --> 00:55:08,159
because it's simple. You can embed
it in a little device, a little

765
00:55:08,199 --> 00:55:12,079
sensor, you can, you can
put it in big machines and it's it

766
00:55:12,519 --> 00:55:15,480
truly pushes data sou as an event
happens, it pushes it to all the

767
00:55:15,519 --> 00:55:19,679
subscribers. All the subscribers get it. It's super easy to use. So

768
00:55:20,639 --> 00:55:24,480
we took m QTT and then we
said, Hakka Kafka has a log,

769
00:55:24,559 --> 00:55:30,119
but it's not really a queriable log, but the logs that secret sauce because

770
00:55:30,119 --> 00:55:35,119
it's it's like a streaming serve event
server with a with a log on disc.

771
00:55:35,559 --> 00:55:38,159
So we took the fair Comm database, edit it to our own message,

772
00:55:38,199 --> 00:55:43,199
que MPTT broker, merge the two
together. They're one thing. Added

773
00:55:43,239 --> 00:55:45,760
a transform feature to it so we
could transform the data on the way in

774
00:55:45,880 --> 00:55:49,920
and on the way out of that
thing. And now you have a full

775
00:55:50,280 --> 00:55:55,239
data integration platform that does et L
super easily, and I like Cofka,

776
00:55:55,440 --> 00:56:00,719
you can go back and query all
the changes. But now it's Seql database.

777
00:56:00,760 --> 00:56:04,400
Number of Faircom has the sequel,
the JSON and the ICE and layers,

778
00:56:04,599 --> 00:56:07,480
so you can get the data out
through Seql queries. You can get

779
00:56:07,480 --> 00:56:09,679
the data out. You see,
can queer your transaction log or your log

780
00:56:09,719 --> 00:56:15,880
of events, your event log with
Seql or with JSON, and it's queriable

781
00:56:15,960 --> 00:56:19,199
and filterable on the flight and you
can index parts of it. And so

782
00:56:19,320 --> 00:56:22,599
you have a real time not real
time is but a very near time dynamic

783
00:56:22,840 --> 00:56:28,000
dynamic query system on top of Kafka. Imagine if you could have Kafka with

784
00:56:28,039 --> 00:56:30,760
a real database instead of was just
a static log that you could query and

785
00:56:30,800 --> 00:56:36,280
filter and you have real time push
events through PGT. That's what we built

786
00:56:37,000 --> 00:56:45,159
a broker. So many words there
that I just get triggered on. I

787
00:56:45,199 --> 00:56:50,239
can't. Sorry, I'm just geeking
out here because I just love this stuff.

788
00:56:51,679 --> 00:56:55,199
You said something really interesting a little
while ago about basically needing to hire

789
00:56:55,199 --> 00:56:59,159
a DBA specialist, and I'm trying
to figure out, like you know,

790
00:56:59,320 --> 00:57:02,760
I'm if you have a company or
were under twenty people like that still feels

791
00:57:02,800 --> 00:57:07,199
too early. But if you don't
hire them early enough, then you end

792
00:57:07,239 --> 00:57:08,719
up with a lot of the problems
you talked about. So like when when

793
00:57:08,760 --> 00:57:12,639
in your view do you actually mean
it's not at three people? Right?

794
00:57:13,280 --> 00:57:15,000
Maybe that's yours, that's what you
were suggesting. It's like, oh,

795
00:57:15,079 --> 00:57:19,159
yeah, you know one of your
first few engineers, like after your founding

796
00:57:19,199 --> 00:57:22,000
engineer, you need to have some
sort of database specialist. What do you

797
00:57:22,000 --> 00:57:24,880
think? Yeah, I think you
need to have a data expert. Now

798
00:57:24,880 --> 00:57:30,599
if they are your back end engineer
who's a data but truly data expert understands

799
00:57:30,440 --> 00:57:36,679
how the long term implications of data
design not so obsessed that they stop production.

800
00:57:36,760 --> 00:57:38,440
That's what the other old school DBAs
did, Right, you can't do

801
00:57:38,559 --> 00:57:44,320
anything. You can't touch my database. And the hard part is you've got

802
00:57:44,320 --> 00:57:47,920
to hire a person who really knows
what they're doing, because like Freightliner hired

803
00:57:49,320 --> 00:57:53,320
this one czar that was blocking everything
and making bad decisions. Right, So

804
00:57:53,840 --> 00:57:58,760
you've got to It's hard because you
have to know enough about data to hire

805
00:57:58,800 --> 00:58:01,360
the right person. But it could
be a back end engineer, it could

806
00:58:01,400 --> 00:58:06,159
be a that's what it probably would
recommend these days. Instead of hiring a

807
00:58:06,239 --> 00:58:09,440
DBA, hire a back end engineer
who specializes in a number of data technologies.

808
00:58:09,480 --> 00:58:14,199
And on their resume they can demonstrate
or an interview, they demonstrate to

809
00:58:14,239 --> 00:58:19,320
you scenarios where they designed the data
one way using this technology and it caused

810
00:58:19,360 --> 00:58:22,280
them problems. They designed it another
way and another technology caused them problems.

811
00:58:22,679 --> 00:58:25,000
They or they didn't design at all
and it caused them problems. And they

812
00:58:25,000 --> 00:58:29,079
can tell you what those problems are. And they learned their lessons from the

813
00:58:29,079 --> 00:58:30,239
school of hard knocks, and then
they can say, you know what,

814
00:58:30,519 --> 00:58:34,239
I'm not going to do that ever
again. We're gonna up front, we're

815
00:58:34,280 --> 00:58:37,159
gonna we're gonna be practical. We're
not going to over engineer, over design

816
00:58:37,159 --> 00:58:40,280
because you'll never get out the door. But we're gonna we're going to protect

817
00:58:40,360 --> 00:58:45,000
you eighty percent of the time from
those problems that you're going to have and

818
00:58:45,480 --> 00:58:52,559
if he could demonstrate that through experience, then you've got a winner. Okay,

819
00:58:52,840 --> 00:58:57,239
that's good advice. You know,
I'm actually thinking down that path,

820
00:58:57,280 --> 00:59:00,760
like there must be aspiring uh,
you know database administrators out there, uh,

821
00:59:00,960 --> 00:59:04,760
and they want to hear like,
well, you know what, what's

822
00:59:04,760 --> 00:59:07,320
the first thing to go down this
path? Right? You know, how

823
00:59:07,360 --> 00:59:14,719
do I learn more about becoming the
database specialist back end for a burning company?

824
00:59:14,760 --> 00:59:16,880
You know what? What do I
need to know realistically? Yeah?

825
00:59:16,920 --> 00:59:21,320
And I and I think there has
been a market shift, a good one

826
00:59:21,519 --> 00:59:25,880
from there's another DBA. There's a
DBA is you know, stands for several

827
00:59:25,880 --> 00:59:32,400
things database administrator, database architect,
and then there's developer DBAs they're all lumped

828
00:59:32,400 --> 00:59:38,559
together in DBAH. The administrator person
is the one that I'm glad that we're

829
00:59:38,559 --> 00:59:43,280
shifting away from. I think it's
the cloud is removed a lot of the

830
00:59:43,320 --> 00:59:45,480
need for that low level back up
your database. I used to Actually in

831
00:59:45,480 --> 00:59:49,679
the cloud, you have to configure
your own backups, but the technology to

832
00:59:49,719 --> 00:59:53,119
do it, the cloud provides upgrades. You don't have to do the upgrades.

833
00:59:53,119 --> 00:59:57,679
The cloud do the upgrades for you. So that's good. So the

834
00:59:57,679 --> 01:00:00,159
cloud is now if you if you
get a aviation product that does this for

835
01:00:00,239 --> 01:00:02,960
you, or you go into the
cloud like the fair Com does this for

836
01:00:04,079 --> 01:00:07,519
you. We don't require DBA in
our product, but we can run on

837
01:00:07,599 --> 01:00:12,960
premise or the cloud. But not
Oracle requires a DBA just to just to

838
01:00:13,039 --> 01:00:16,360
keep it up and running. So
getting an Oracle Cloud instance of Oracle would

839
01:00:16,360 --> 01:00:19,840
be good for you because you're going
to save a ton of money and the

840
01:00:19,920 --> 01:00:22,679
trivial stuff you don't want to.
So if I, if I give recommendation

841
01:00:22,800 --> 01:00:28,559
for a newbie, don't become the
administrator that is just knows how to run

842
01:00:28,599 --> 01:00:32,679
the script that the books said to
run to back up the database. That

843
01:00:32,800 --> 01:00:37,199
kind of administrator is not the value
add and that and that's the kind they're

844
01:00:37,199 --> 01:00:40,119
having to add like Mango and Cassandra. You have to hire those kind of

845
01:00:40,159 --> 01:00:45,760
administrators because that's the systems are so
poorty designed. You got to got to

846
01:00:45,800 --> 01:00:47,119
have a local level guy just to
keep it lights wrong. But that's a

847
01:00:47,159 --> 01:00:52,559
dead end career. The value is
in the data, so the data arket,

848
01:00:53,000 --> 01:00:57,960
the dB architect, the guy who
So you're back in a minute,

849
01:00:57,960 --> 01:01:01,639
you're back in developer who really understands
how to architect the data so that your

850
01:01:01,639 --> 01:01:08,559
application will perform well and grow well
over time. That's that's gold. And

851
01:01:08,679 --> 01:01:12,639
so if you have a mind to
do that, you have to have kind

852
01:01:12,639 --> 01:01:15,719
of a mathematical mind. I don't
mean you have to like coakyas or something.

853
01:01:15,760 --> 01:01:19,000
I just mean you have to have
a very logical mind. Then you

854
01:01:19,039 --> 01:01:22,400
have to look at things logically and
systematically and understand practically. You have to

855
01:01:22,400 --> 01:01:25,920
be practical. You have to say, Okay, this technology does X,

856
01:01:27,320 --> 01:01:30,639
if I do if I do X
with this technology, I'll be successful.

857
01:01:30,639 --> 01:01:32,119
But I know I need a little
bit of why over here to make the

858
01:01:32,440 --> 01:01:37,519
to grow the system. How can
I how can I make this X system

859
01:01:37,559 --> 01:01:40,199
do why? I need a multipurpose
system so I can do X and Y,

860
01:01:42,119 --> 01:01:44,559
but it needs to do both well. You know, you have to

861
01:01:44,599 --> 01:01:50,159
make a lot of decisions. And
that's where a really experience. So if

862
01:01:50,199 --> 01:01:53,159
you hire a good back inagy with
like thirty years of experience, twenty years

863
01:01:53,159 --> 01:01:57,679
of experience with lots of data work, you're you're going to be in good

864
01:01:57,719 --> 01:02:01,079
shape. So don't skimp on that
back end engineer who does these data architecture.

865
01:02:01,079 --> 01:02:04,559
That's going to be gold for you
in the long run, as long

866
01:02:04,599 --> 01:02:06,800
as they have a good personality,
as long as they're not like the no

867
01:02:07,320 --> 01:02:12,679
guy. Don't hire those guys.
They'll block your whole company and you'll die.

868
01:02:14,119 --> 01:02:16,880
They need to be the yes guy
who says yes but think about this

869
01:02:16,960 --> 01:02:20,880
and this and this, and I
will help you achieve the goal. I

870
01:02:20,920 --> 01:02:23,440
will overcome the problems. I won't
just be no. We'll solve this together.

871
01:02:23,719 --> 01:02:27,360
No. I think that's pretty good
spot on advice, irrelevant of the

872
01:02:28,039 --> 01:02:31,599
special specialty that someone would normally go
into, Like I think, relevant of

873
01:02:31,679 --> 01:02:38,880
whether it's databases or UI's or other
back end services, graft culi databases,

874
01:02:38,920 --> 01:02:43,280
you know, whatever, whatever have
you. Actually, you know, this

875
01:02:43,400 --> 01:02:47,320
really got me thinking. And I've
dabbled in a bunch of different database technologies

876
01:02:47,320 --> 01:02:50,480
over the years, and one thing
that keeps coming up for me, and

877
01:02:50,519 --> 01:02:53,320
maybe this is specific because I always
pay attention to security, is it just

878
01:02:53,320 --> 01:03:00,000
feels like security plus databases is like
oil and water. Yeah. Well,

879
01:03:00,199 --> 01:03:06,400
first off, it's super hard.
I think that's why because because you're your

880
01:03:06,519 --> 01:03:10,599
data is the thing you're protecting the
most that you are protecting its intrusion.

881
01:03:10,719 --> 01:03:14,840
So that's where you know front hackers
can get into a system. But what

882
01:03:14,880 --> 01:03:16,239
are the hackers trying to do when
they get in, Well, they're going

883
01:03:16,280 --> 01:03:20,079
to either encrypt your data and ransom
you, or they're going to encrypt your

884
01:03:20,119 --> 01:03:22,119
data and steal it. And of
course what are all the breaches about data?

885
01:03:22,239 --> 01:03:24,840
Right, So you've got to encrypt
your data at rest, you got

886
01:03:24,920 --> 01:03:29,719
encrypted at transit. You've got to
prevent the injection attacks to give you backdoors

887
01:03:29,760 --> 01:03:35,119
into the database. So then take
it over. Security. A good database

888
01:03:35,159 --> 01:03:40,239
product, security should be number one
in the APIs and in the system.

889
01:03:40,280 --> 01:03:46,320
It should be secure by default.
Oracle has a common password that has been

890
01:03:46,679 --> 01:03:49,800
that's well known. I'm not going
to say it because I don't want to

891
01:03:49,800 --> 01:03:52,599
promote this, but you know,
and half your dba's in the world don't

892
01:03:52,719 --> 01:03:58,960
change it it is. You know. Sometimes these are more administrative DBAs and

893
01:03:59,000 --> 01:04:00,679
just run the scripts as if.
They drive me crazy because they don't know

894
01:04:00,719 --> 01:04:05,960
what they're doing and and and they
don't make it secure, so they don't

895
01:04:06,039 --> 01:04:09,960
change things. I had. I
remember one database we stalled. I stalled

896
01:04:09,960 --> 01:04:14,679
this database product over fifteen years ago
at at this organization, and they kept

897
01:04:14,679 --> 01:04:18,440
the same password I used in that
database for fifteen years. Finally, I

898
01:04:18,480 --> 01:04:21,519
think it was just a year ago
they finally changed it. I'm like,

899
01:04:23,119 --> 01:04:26,800
really, I left that company five
years ago and you're still using my password.

900
01:04:26,840 --> 01:04:29,400
My son works there now, and
so I actually happened to know.

901
01:04:29,880 --> 01:04:31,360
I got a job on my old
team and happened to know they actually never

902
01:04:31,440 --> 01:04:35,199
changed it when I left it.
I'm trustworthy of but it was a good

903
01:04:35,199 --> 01:04:40,679
password. But still, so this
is the Yeah, you're worried it will

904
01:04:40,679 --> 01:04:43,079
break something, right if you change
the password, you know, production will

905
01:04:43,079 --> 01:04:45,719
go down. So I really should
be careful. Someone could be using that,

906
01:04:45,840 --> 01:04:47,719
you know, in a way that
wasn't intended. Totally true, and

907
01:04:47,719 --> 01:04:50,519
then the DBAs are lazy. Everybody's
lazy, right, So, like I

908
01:04:50,679 --> 01:04:57,719
memorized this stupid, horrible password,
I'm never changing this one. But yeah,

909
01:04:57,960 --> 01:05:00,920
right, we rotate passwords in apike
every time the Roman Empire falls.

910
01:05:02,800 --> 01:05:09,800
Well, you know what's good that
the updated nest whatever eight hundred is now

911
01:05:10,079 --> 01:05:14,840
no longer, suggesting that rotation actually
prevents a certain category of attacks, because

912
01:05:15,320 --> 01:05:18,159
the need to rotate means people will
forget and have to write it down.

913
01:05:18,280 --> 01:05:23,599
So now, luckily now there is
written documentation that may suggest that even doing

914
01:05:23,679 --> 01:05:28,519
so doesn't have a positive long term
impact. Yeah, and password managers are

915
01:05:28,559 --> 01:05:32,079
super huge. Get one that does
crypto random passwords. You'll never remember it.

916
01:05:32,559 --> 01:05:35,360
You don't write it down because it's
in your password manager and you just

917
01:05:35,559 --> 01:05:42,000
use it. And another thing that's
a really cool trick that the older databases

918
01:05:42,079 --> 01:05:45,039
did not do. Because they didn't
they wasn't well known at the time,

919
01:05:45,719 --> 01:05:49,559
was how do you encrypt data at
risk? Well, they all can encrypt

920
01:05:49,599 --> 01:05:53,599
it, they can use as standards
and they can encrypt at risk. But

921
01:05:53,639 --> 01:05:57,920
where do you put the keys?
That's the big question. And the model

922
01:05:57,920 --> 01:06:02,800
that I love the most is you
have a master key that encrypts all the

923
01:06:02,880 --> 01:06:08,360
keys that encrypt everything else. So
that level of indirection is awesome because the

924
01:06:08,360 --> 01:06:14,239
customer can can change the master key
when they need to. The database is

925
01:06:14,320 --> 01:06:19,000
constant. A good one, a
good back of database will automatically rotate it's

926
01:06:19,280 --> 01:06:24,400
internal keys and re encrypt data in
files. When they optimize the file,

927
01:06:24,440 --> 01:06:30,519
you rotate that internal key so that
your data that the customer could change it

928
01:06:30,519 --> 01:06:32,199
and own their master pastor. But
you don't have to worry about at rest

929
01:06:32,519 --> 01:06:36,920
your keys are Your data is encrypted
in a very secure way and then that's

930
01:06:38,000 --> 01:06:43,079
very maintainable. So the best databases
do that technique. Some of the older

931
01:06:43,079 --> 01:06:46,119
ones don't. So that's keep that
in mind. If a database has been

932
01:06:46,119 --> 01:06:49,480
around a long time and never really
thought through these issues, they're going to

933
01:06:49,519 --> 01:06:54,679
have our time with security. Oracle
or what does an okay job. I'm

934
01:06:54,679 --> 01:06:57,039
not going to give away all those
secrets. I don't want to, like,

935
01:06:57,639 --> 01:07:00,559
you know, help packers out here, but I'll just say one thing.

936
01:07:00,880 --> 01:07:05,360
If there was, I can't say
it, but I'll just they don't

937
01:07:05,360 --> 01:07:09,159
give extra well, but it's okay. I think they're doing it pretty well

938
01:07:09,159 --> 01:07:13,320
all by themselves. Or yeah,
Oracle did. Oracle did a terrible thing

939
01:07:13,360 --> 01:07:16,559
and was embedding secrets in places they
never should have embedded them, and it

940
01:07:16,599 --> 01:07:21,000
was really obvious and it was like, really, are you kidding me?

941
01:07:21,880 --> 01:07:26,679
And luckily hackers weren't super aware of
this, but we were. And it's

942
01:07:26,760 --> 01:07:28,599
like, oh gosh, if they
got a hold of this, they'd get

943
01:07:28,599 --> 01:07:31,199
the whole keys of the kingdom.
I think Oracle latest releases they probably fixed

944
01:07:31,239 --> 01:07:34,280
it. I hope, but Oracle's
so backwards cant pattle. They may not

945
01:07:34,360 --> 01:07:38,400
have. I haven't looked lately,
so I'm not going to go any deeper

946
01:07:38,440 --> 01:07:41,880
into that. But like, there
are so many holes in Oracle because it's

947
01:07:41,920 --> 01:07:45,679
an old system and they never really
thought it through. I would never use

948
01:07:45,760 --> 01:07:49,760
these utel not an Oracle fan,
and it's not because it's just because it's

949
01:07:49,800 --> 01:07:55,920
so complicated and complicated means not secure. It was complicated. You can't cover

950
01:07:55,960 --> 01:07:59,559
all your bases and make it secure. So I'm much a bigger fan.

951
01:07:59,599 --> 01:08:02,719
If you're eqal database, you know, SQL server is much simpler and Microsoft

952
01:08:02,760 --> 01:08:05,880
has kept it that way and so
it's easier to secure it easier to run

953
01:08:05,920 --> 01:08:10,559
it. So from a DeVos perspective, Secret seqle server is really good.

954
01:08:11,239 --> 01:08:15,000
It's not as expensive as ourable,
so it's not cheap. Postgress is,

955
01:08:15,000 --> 01:08:19,560
like I said, created by PhD
grad students at Berkeley for the most part.

956
01:08:19,640 --> 01:08:24,319
And and the code, it's the
code inside that thing is every you

957
01:08:24,359 --> 01:08:28,239
know, every developer rized different coastyles. Imagine over the last thirty years,

958
01:08:28,960 --> 01:08:32,479
every PhD student writing their own little
module in Berkeley in the inside of Postgrass.

959
01:08:32,560 --> 01:08:36,439
It's just a it's a code nightmare. So the complexity of that code

960
01:08:36,479 --> 01:08:45,079
base makes that system hard to secure
and complicated. Do they not use route

961
01:08:45,399 --> 01:08:50,199
DPMs on the physical devices to encrypt
the master key in some way, so

962
01:08:50,239 --> 01:08:57,920
it's not actually exposed to the database
process, rather than having just some master

963
01:08:58,000 --> 01:09:01,800
key that it generates. You know, network if you're across platform database,

964
01:09:03,119 --> 01:09:06,760
that depends on your operating system and
so on. The ones the database they

965
01:09:06,800 --> 01:09:11,199
run on Windows that focus on Windows
is a core platform. They do that

966
01:09:11,560 --> 01:09:15,319
like seql server. They can do
that. Fair Coom does that. We

967
01:09:15,640 --> 01:09:19,039
use that technology running on Linux,
though it's a little different. You have

968
01:09:19,079 --> 01:09:23,119
to it's a little harder because the
OS doesn't support some of those things as

969
01:09:23,119 --> 01:09:26,560
well, and when you want to
be a cross platform database, you have

970
01:09:26,600 --> 01:09:31,119
to work extra hard to figure out
ways to to make things secure on Linux

971
01:09:31,199 --> 01:09:36,560
versus Windows versus Mac. May be
the first person that I've ever heard say

972
01:09:36,680 --> 01:09:41,479
that it's more difficult to secure things
on Linux. I feel like the HSM

973
01:09:41,520 --> 01:09:45,880
with pks, you know eleven has
no problem encrypting whatever you've got, whatever

974
01:09:45,920 --> 01:09:48,920
you need to throw at it.
So you know that that's an interesting train

975
01:09:48,960 --> 01:09:53,560
of thought. There then is a
new one that I'll have to consider.

976
01:09:54,000 --> 01:09:57,439
Well, it's not I didn't mean
to say harder as much as different.

977
01:09:58,520 --> 01:10:01,239
The harder part the harder part is
if you're a company writing database software,

978
01:10:01,279 --> 01:10:06,840
you've got to use different technologies and
test different technologies on each platform. So

979
01:10:06,880 --> 01:10:10,319
that's more of what it is.
It's not that Linux is not secure.

980
01:10:10,359 --> 01:10:12,520
I'm not. I don't even want
to begin to say that, because actually

981
01:10:12,479 --> 01:10:18,279
I like Linux a lot. But
I will say securing Linux requires some specialty

982
01:10:18,319 --> 01:10:24,880
skills. That Windows is is well
known as there for hacks and all that

983
01:10:24,880 --> 01:10:28,279
stuff. They are trying. They
try to simplify things for their customers,

984
01:10:28,680 --> 01:10:32,840
especially on Window. Server is a
pretty good platform, but it's so expensive

985
01:10:33,159 --> 01:10:36,399
you got to go Linux. Everybody
goes Linux. So I'm so yeah,

986
01:10:36,399 --> 01:10:42,199
we we it's just Linux is you're
in the open source world and you say,

987
01:10:42,239 --> 01:10:44,920
okay, I want to use this
feature. Now I'll go find open

988
01:10:44,960 --> 01:10:46,079
source. Well, how do I
know if that open source is safe?

989
01:10:46,079 --> 01:10:48,720
How do I know that open source
hasn't been hacked? How do I know

990
01:10:48,760 --> 01:10:54,119
that that does a good job.
Well, there's no company behind that open

991
01:10:54,119 --> 01:10:56,600
source. Typically, if you're talking
about this kind of low level code,

992
01:10:56,600 --> 01:11:00,039
you're just bringing in some It was
some developer who's going out there creating some

993
01:11:00,119 --> 01:11:01,840
thing. Then you bring it in, you run tons of tests on it.

994
01:11:01,920 --> 01:11:05,840
The work and cost of bringing that
in can be really high if you

995
01:11:05,880 --> 01:11:10,520
want to make sure, if you
want to guarantee it's secure, So companies

996
01:11:10,520 --> 01:11:15,039
don't do that. They just bring
it in in hope because you can't afford

997
01:11:15,079 --> 01:11:17,560
to go and let's go run.
It's spent two years testing this open source

998
01:11:17,640 --> 01:11:19,840
piece, you know, a piece
of code to make sure it really works

999
01:11:19,840 --> 01:11:27,680
well, so you hope. So
I think adding to that is there's the

1000
01:11:27,760 --> 01:11:32,720
different Linux distributions because what might be
implemented in one Linux distribution might not be

1001
01:11:32,800 --> 01:11:39,239
implemented in another one, or it's
implemented a different way. Yeah, and

1002
01:11:39,279 --> 01:11:44,119
everybody runs on red hat because you
could count on all those features being there

1003
01:11:44,560 --> 01:11:48,399
and so or of course not everybody
does completely on red hat, but the

1004
01:11:48,439 --> 01:11:51,560
red hat is the one that every
database spender is going to run on.

1005
01:11:53,239 --> 01:11:57,880
And then do you support others?
Fair Com has a history of running everywhere,

1006
01:11:57,960 --> 01:12:00,720
so we build our software to run
on every possible platform you can imagine.

1007
01:12:00,760 --> 01:12:05,479
At one point we supported over one
hundred and twenty nine operating systems at

1008
01:12:05,479 --> 01:12:09,880
the same time. Well, the
world is luckily shrunk down, so now

1009
01:12:09,920 --> 01:12:13,880
you know we we support we still
support all the UXes that are out there,

1010
01:12:14,079 --> 01:12:16,840
hp AI, x Q and X
you name the you know, all

1011
01:12:16,880 --> 01:12:21,399
the Unix stuff. But when primarily
people want today it's Linux and Windows,

1012
01:12:21,760 --> 01:12:25,479
and on the database world, not
so much Mac. But we support Mac

1013
01:12:25,520 --> 01:12:30,680
as well because developers have Mac laptops. So we yeah, we we support

1014
01:12:30,720 --> 01:12:34,640
and we run it are extremely portable. We have fantastic All we written in

1015
01:12:34,720 --> 01:12:39,359
C and we wrote it in portable
C code so that we can run on

1016
01:12:39,399 --> 01:12:43,560
any operating system, real time orperating
systems, you name it. And not

1017
01:12:43,680 --> 01:12:48,359
every database can do that, so
there's a real cost when they when you

1018
01:12:48,359 --> 01:12:53,119
buy. For example, mark Logic
is a database that was optimized for Linux.

1019
01:12:53,159 --> 01:12:56,199
They did all their testing Linux,
They coded on Linux, but then

1020
01:12:56,199 --> 01:12:59,640
a lot of their customers started buying
it to run them Windows. They supported

1021
01:12:59,680 --> 01:13:03,079
Window, but it was the step
and so you're like, it's all kinds

1022
01:13:03,079 --> 01:13:06,960
of problems on Windows because if you
don't, if your juniors are all Linux

1023
01:13:06,960 --> 01:13:09,640
e geniors, they know how to
do it there, but they don't know

1024
01:13:09,640 --> 01:13:11,800
how to do it on Windows,
and then you create problems. So for

1025
01:13:11,840 --> 01:13:15,119
DevOps, it's really important for you
to know is this is this database primarily

1026
01:13:15,119 --> 01:13:21,039
of Windows or a Linux database or
is it really do the engineers really know

1027
01:13:21,119 --> 01:13:26,479
both really well and can support both
really well, and your your code base

1028
01:13:26,560 --> 01:13:29,640
can run on all of them because
it's designed that way. That's that's a

1029
01:13:29,760 --> 01:13:32,800
huge issue for you, because so
many times you buy the product and run

1030
01:13:32,920 --> 01:13:36,520
on the wrong operating system for whatever
reason, and and do you pay a

1031
01:13:36,600 --> 01:13:42,600
cost bug costs and a support cost. That's a good point. I mean,

1032
01:13:42,760 --> 01:13:45,000
I you know, I've been the
Linux user for a long time,

1033
01:13:45,039 --> 01:13:48,760
and I just pray that there's some
sort of Open Container Initiative compatible container out

1034
01:13:48,800 --> 01:13:51,720
there that I could just you know, pull it and run. And if

1035
01:13:51,720 --> 01:13:56,560
it's not, that I've add to
the next technology. Yeah. Yeah,

1036
01:13:56,800 --> 01:13:59,560
And you have to have containers for
most of these products, like Oracle.

1037
01:13:59,560 --> 01:14:02,239
I would never want install an Oracle
without a container because that's just a nightmare.

1038
01:14:02,680 --> 01:14:04,960
For my first first day on the
job, I was sitting next to

1039
01:14:04,960 --> 01:14:06,760
a guy and they said, what
are you doing? He goes, oh,

1040
01:14:06,800 --> 01:14:10,760
I'm installing Oracle And I go,
oh, how's that going? Well,

1041
01:14:10,800 --> 01:14:16,319
I'm on my third day, third
day, third day, and like,

1042
01:14:16,359 --> 01:14:18,800
what the what do you well?
I mean, you know, can

1043
01:14:18,920 --> 01:14:21,199
it be ten minutes? Can't you
just run a script? No? No,

1044
01:14:21,319 --> 01:14:25,359
and it was just a I mean, Oracle's better than that today a

1045
01:14:25,359 --> 01:14:29,159
little bit. But you know you
used to the minutes. But a container

1046
01:14:29,159 --> 01:14:31,479
you just pop in and rune.
One thing about fair Calm, because we

1047
01:14:31,720 --> 01:14:36,680
are real sensitive this. We unzip
and run us like that. You download,

1048
01:14:36,840 --> 01:14:41,840
unziped, run, you're going that's
all there is. So we don't

1049
01:14:41,880 --> 01:14:46,199
even need containers because containers do slow
databases down by about twenty percent. And

1050
01:14:46,199 --> 01:14:51,640
the reason they slow databases down is
because the storage. They containers don't totally

1051
01:14:51,720 --> 01:14:57,199
virtualize the storage, but they they
were out the storage through their subsystem and

1052
01:14:57,279 --> 01:15:03,119
it causes a performance loss. So
containers databases or a performance problem. So

1053
01:15:03,199 --> 01:15:06,239
if you can run a database thats
by unziped and run, and you can

1054
01:15:06,359 --> 01:15:11,479
run multiple instances of the database on
the same computer, then you don't need

1055
01:15:11,520 --> 01:15:15,079
containers. Well, fair com is
one of the only databases that can run

1056
01:15:15,159 --> 01:15:18,720
multiple instances on the same computer with
an unzip and run out of the box

1057
01:15:18,760 --> 01:15:23,560
story. So we can run hundreds
of database instances on the same computer.

1058
01:15:23,800 --> 01:15:28,119
Oracle takes over the whole machine.
It assumes one instance one machine, single

1059
01:15:28,159 --> 01:15:31,399
server takes over the whole machine.
Postcuss takes over the whole machine. That

1060
01:15:31,439 --> 01:15:36,159
means you need containers, right,
because you need that flexibility. That's why

1061
01:15:36,560 --> 01:15:40,840
a fair Com I really like this
core engine that we have because we don't

1062
01:15:40,880 --> 01:15:45,079
have those limitations of these other databases. And it makes a difference for DevOps,

1063
01:15:45,159 --> 01:15:48,840
especially like market logic took over the
whole machine. You going to run

1064
01:15:48,840 --> 01:15:53,960
one instance on machine. And this
is before container technology. This is about

1065
01:15:54,000 --> 01:15:56,800
ten years ago, right, well
more than that, about twelve years ago

1066
01:15:57,199 --> 01:16:01,800
or thirteen anyway, we were looking
at architecturally we wanted to run multiple instances

1067
01:16:01,840 --> 01:16:04,640
on the same machine. We had
to use VMS to do it, and

1068
01:16:04,680 --> 01:16:11,039
that's even more of a HITD than
containers, and it complicated our whole architecture.

1069
01:16:11,079 --> 01:16:13,640
If I could have run multiple instances
on one machine, I could have

1070
01:16:13,680 --> 01:16:16,880
simplified the entire architecture, saved us
a ton of DevOps time, development time,

1071
01:16:16,960 --> 01:16:24,039
engineering time, architecture time. But
that limitation tied my hands. So

1072
01:16:24,119 --> 01:16:29,119
something like Faircom no limits on the
architecture, which as an architecture I like

1073
01:16:29,199 --> 01:16:31,560
that I could just do what I
need to do get the job done right.

1074
01:16:32,159 --> 01:16:40,760
Well, there you go. That
was a random stream of It was

1075
01:16:40,840 --> 01:16:44,560
fun. That was that was a
lot to take in though, and I

1076
01:16:44,560 --> 01:16:53,520
think it really it really highlights how
much thought and effort and planning has to

1077
01:16:53,560 --> 01:17:00,399
go into your database solution. It's
not really it's not really and oh,

1078
01:17:00,439 --> 01:17:02,520
by the way, task or it
can be, but you're going to pay

1079
01:17:02,560 --> 01:17:09,439
for that for a really long time
if you're successful at all. That's a

1080
01:17:09,560 --> 01:17:13,840
really important point because we at the
last but I was working on this church,

1081
01:17:13,880 --> 01:17:17,319
that large organization. We had,
we we had standardized, we had

1082
01:17:17,319 --> 01:17:20,359
certain databases we supported, like we
started supporting it, you know, and

1083
01:17:21,920 --> 01:17:26,199
we had developers all the time they're
bringing this under the hood. They would

1084
01:17:26,199 --> 01:17:29,399
go sneak out and go get a
Mango or get a Cassandra, get into

1085
01:17:29,399 --> 01:17:32,039
the database that we weren't supporting it. And React was one of their favorites.

1086
01:17:32,079 --> 01:17:35,319
That bring it in is start build
their app on it, right,

1087
01:17:35,560 --> 01:17:40,079
and then they go to release the
production. The manager and the and the

1088
01:17:40,119 --> 01:17:43,279
infrastrut team goes, what is this, Oh, it's just a database,

1089
01:17:43,319 --> 01:17:45,279
don't worry about it, just all
it. No, we can't who's supporting

1090
01:17:45,319 --> 01:17:48,439
it? Well we are, Well, no, you have to talk to

1091
01:17:48,479 --> 01:17:51,399
the database team. We're supposed to
support these technologies. So then they call

1092
01:17:51,479 --> 01:17:54,920
me up and go, Mike,
we're using this. Can you support it?

1093
01:17:55,479 --> 01:17:59,399
What we don't? What are you
doing? And so like, no,

1094
01:17:59,479 --> 01:18:01,479
we we don't have the people because
every time you bring a database in,

1095
01:18:01,520 --> 01:18:05,119
you're going to have to train people
to read, to understand the technology,

1096
01:18:05,359 --> 01:18:09,479
to give it the proper support.
You just can't throw someone at and

1097
01:18:09,560 --> 01:18:13,000
hope that they get their job.
Then databases are kind of like a marriage,

1098
01:18:13,399 --> 01:18:15,159
you know, and you're you have
to be serious about this. You're

1099
01:18:15,159 --> 01:18:19,920
gonna have that database for a long
time for and you need to know how

1100
01:18:20,039 --> 01:18:24,399
to make that marriage work. And
it's not just you're gonna get married,

1101
01:18:24,439 --> 01:18:27,399
because if you don't, you're gonna
get a divorce. And but you can't

1102
01:18:27,399 --> 01:18:30,159
divorce the database. The problem is
is still sitting there, it's still running.

1103
01:18:30,279 --> 01:18:32,399
It's still causing you trouble because you
can't just rewrite your app overnight.

1104
01:18:32,760 --> 01:18:35,800
You can't just afford to do that. So this is a maybe it's worse

1105
01:18:35,840 --> 01:18:44,479
than you know. Marriages are great. I've just been You're stuck with it

1106
01:18:44,520 --> 01:18:50,439
forever, right, I think therapy
podcast? Yeah, so yeah, you're

1107
01:18:50,520 --> 01:18:55,479
right. You just developers are sneaking
these in and then no, it's no

1108
01:18:55,560 --> 01:18:59,039
problem. And next thing you know
you've got you've got a real problem in

1109
01:18:59,079 --> 01:19:02,840
your organization. And we had to
rewrite so many apps because the app couldn't

1110
01:19:02,880 --> 01:19:06,720
be supported. And you think about, you're gonna have a core team.

1111
01:19:06,800 --> 01:19:10,439
No matter what database you use,
you're gonna have a core team that's going

1112
01:19:10,520 --> 01:19:15,039
to give you twenty four to seven
support on that thing. And so you're

1113
01:19:15,039 --> 01:19:16,800
going to and to do that.
You can't just put one person on that

1114
01:19:16,880 --> 01:19:20,880
team or you'll kill them off twenty
four to seven, right, and even

1115
01:19:20,880 --> 01:19:25,560
if they're a ATAG guy. Like
that's the Marcologic database for example, it

1116
01:19:25,600 --> 01:19:28,239
was like a Maytag database. It
never went down, it never broke.

1117
01:19:28,680 --> 01:19:33,479
So we had two people running over
over six hundred instances of Marcologic supporting the

1118
01:19:33,520 --> 01:19:38,640
whole thing throughout the entire organization.
But they were still too because they were

1119
01:19:38,680 --> 01:19:42,079
twenty four seven support and they even
they weren't called. They had to carry

1120
01:19:42,119 --> 01:19:44,199
the pager, they had to carry
the cell phone, they had to be

1121
01:19:44,479 --> 01:19:47,520
had their laptop with them. The
stress of the support is always with you,

1122
01:19:48,159 --> 01:19:51,239
and so you have to take that
in consideration. When you bring in

1123
01:19:51,239 --> 01:19:55,359
a technology, you're gonna have to
get your support people to support it.

1124
01:19:55,720 --> 01:19:58,640
That's like the secret conversation. It's
like are you ready, like to the

1125
01:19:58,680 --> 01:20:00,720
development team, are you ready to
for the new database bringing in? And

1126
01:20:00,720 --> 01:20:03,119
they're like, yes, we know
everything about it. And there were only

1127
01:20:03,119 --> 01:20:09,279
response you can say to that as
you're wrong, it's going to be okay

1128
01:20:09,359 --> 01:20:14,359
here, but you have no idea
what you're talking about. Yeah. Well,

1129
01:20:14,359 --> 01:20:16,119
it was just to bring in mark
Logical in my last organization, because

1130
01:20:16,119 --> 01:20:17,880
I was in charge of that whole
thing that so I bring it up.

1131
01:20:19,359 --> 01:20:25,199
It took one hundred thousand dollars project
to go bring it in and get it

1132
01:20:25,239 --> 01:20:30,760
integrated into infrastructure, to get all
the support processes in place, to establish

1133
01:20:30,800 --> 01:20:33,880
a high availability version and how we're
going to support that thing. I ran

1134
01:20:33,920 --> 01:20:39,359
that whole project and it was it
was expensive and it was a real eye

1135
01:20:39,359 --> 01:20:42,439
opener to me, like why can't
you just run it? But no,

1136
01:20:42,600 --> 01:20:46,640
it was a major project and because
we did that, though we now have

1137
01:20:47,399 --> 01:20:53,439
it grew like crazy throughout the organization
and it's super successful to this day in

1138
01:20:53,479 --> 01:20:58,880
that organization. Because deployments are just
a piece of cake. The main the

1139
01:20:58,920 --> 01:21:01,880
maintenance is a piece of cake.
Whole thing because because we brought it in

1140
01:21:02,079 --> 01:21:05,479
correct, but then these other ones
like React came in and not only did

1141
01:21:05,479 --> 01:21:10,079
it come in surreptitiously and was never
supported, the company went out of business.

1142
01:21:11,479 --> 01:21:15,600
And you know, so you got
to think about you know, if

1143
01:21:15,600 --> 01:21:19,000
it's a long term relationship and your
relationship dies, you know, you got

1144
01:21:19,000 --> 01:21:23,840
to think about that. That's a
big one life support. That's a new

1145
01:21:23,880 --> 01:21:31,159
product. Right. I love that, But do you talk to developers.

1146
01:21:31,199 --> 01:21:33,359
I had so many arguments. They
would say, well, it's open source,

1147
01:21:33,640 --> 01:21:39,199
it'll live forever. It's open source
is free, Like, okay,

1148
01:21:39,439 --> 01:21:43,680
do you realize that there's a company
that built this product and their entire goal,

1149
01:21:43,760 --> 01:21:48,680
whether it's Manga or Cassandra or couch
base or faircom. If you're open

1150
01:21:48,800 --> 01:21:54,720
source, it's an illusion. It's
a marketing strategy. It's totally an illusion.

1151
01:21:54,800 --> 01:22:00,520
And and you're developing your you're completely
in fantasyland thinking open source is is

1152
01:22:00,840 --> 01:22:04,279
the answer because that company has to
support it. They have the engineers who

1153
01:22:04,319 --> 01:22:08,800
built it. If that company goes
under, it's not like the community will

1154
01:22:08,840 --> 01:22:12,840
pick it back up and run.
That code is too hard. Database code

1155
01:22:12,920 --> 01:22:15,760
is way too detailed and hard for
just anyone out of there. Oh,

1156
01:22:15,880 --> 01:22:18,680
I just get your grandmother to come
and go. Program you know, get

1157
01:22:18,680 --> 01:22:23,840
it from GitHub and go change this
forget it. This takes specialized engineers that

1158
01:22:23,840 --> 01:22:27,720
spent ten to twenty years of their
life learning this code and learning how it

1159
01:22:27,760 --> 01:22:30,520
works and learning all the internals.
So when that company goes away and those

1160
01:22:30,560 --> 01:22:34,760
developers are no longer there, they
go to other companies. They're working on

1161
01:22:34,800 --> 01:22:41,760
other things. That database product is
dead. So get another team. Like

1162
01:22:42,159 --> 01:22:45,640
when Oracle bought my sequel and then
the team that didn't want to work for

1163
01:22:45,680 --> 01:22:49,079
Oracle left it built Maria dB,
right they but the team left it built

1164
01:22:49,079 --> 01:22:51,920
another company and they forked the code. Can you do that? Yeah?

1165
01:22:53,239 --> 01:22:59,960
But will they do that? You
know that's a big question and database software,

1166
01:23:00,800 --> 01:23:04,199
but that you're basically becoming the database
company, right Like you're like,

1167
01:23:04,279 --> 01:23:06,479
oh, you know, you have
to be okay with that. You have

1168
01:23:06,560 --> 01:23:10,960
to be willing to take that code, build it, run it, become

1169
01:23:10,960 --> 01:23:13,800
the experts of it yourself. If
you're if you're going to go down that

1170
01:23:13,880 --> 01:23:17,119
route, yeah, for sure.
And that's not realistic. It's just you

1171
01:23:17,159 --> 01:23:20,319
know, that would be if you
hired me, for example, I could

1172
01:23:20,359 --> 01:23:23,560
go do something like that because that's
the kind of guy I am. But

1173
01:23:24,239 --> 01:23:26,880
I'm kind of a Unicorn they're there. I mean, I'm not unique,

1174
01:23:26,920 --> 01:23:31,199
but I'm just saying there the Unicorn
herd is not huge that that loves to

1175
01:23:31,199 --> 01:23:35,800
get to that level of code,
understands what databases really are and what they

1176
01:23:35,800 --> 01:23:39,479
should do, and knowing that kind
of code and make that happen. And

1177
01:23:39,560 --> 01:23:43,439
you can't replace people like me very
easily, so and you don't want to

1178
01:23:43,479 --> 01:23:46,359
afford me, you know, I'm
super expensive. So that's the other thing

1179
01:23:46,439 --> 01:23:51,760
that just because it's open source doesn't
mean that there's a huge pool of talent

1180
01:23:51,880 --> 01:23:58,600
willing to work on that product for
free. Yeah, oh yeah, and

1181
01:23:58,720 --> 01:24:01,199
are even capable of working on it
right, you know, if they're at

1182
01:24:01,199 --> 01:24:05,000
the real engine level where you need
to have where you need to fix bugs.

1183
01:24:05,000 --> 01:24:11,920
So so it's the open source database
world is an illusion. And I'm

1184
01:24:11,960 --> 01:24:14,159
not being negative. I'm not anti
open source. I don't want to come

1185
01:24:14,159 --> 01:24:16,399
across that way really not. It's
just it's a marketing strategy. Get it

1186
01:24:16,439 --> 01:24:19,880
in the hands of developers so that
they can go build their next product,

1187
01:24:19,960 --> 01:24:25,119
hopefully become the next Google or you
know, and then and then they can

1188
01:24:25,199 --> 01:24:28,319
start paying for stuff. You know. That's the whole marketing gimmick of it.

1189
01:24:28,800 --> 01:24:31,359
But the reality is the open source
versions are not secure. They don't

1190
01:24:31,399 --> 01:24:39,680
scale. They they're they they don't
provide the tons of the let's see,

1191
01:24:40,720 --> 01:24:44,520
the secure at scale are the big
ones. But you're also getting tools,

1192
01:24:44,840 --> 01:24:48,000
the tool sets for the backup,
the recoveries, the management. Those are

1193
01:24:48,039 --> 01:24:54,159
only enterprise versions and those you have
to have in a database. The vendorsor

1194
01:24:54,239 --> 01:24:57,479
is not stupid. They know you
go open source for so long and then

1195
01:24:57,520 --> 01:25:00,640
eventually you're going to pay them.
But the developer, it's a it's a

1196
01:25:00,680 --> 01:25:04,880
total marketing thing to suck the developer
in because they get we all have dreams

1197
01:25:05,199 --> 01:25:09,039
of I'm gonna be the next Google. I'll use all this free software to

1198
01:25:09,039 --> 01:25:13,199
get myself up and running. But
in a production environment when the thing goes

1199
01:25:13,279 --> 01:25:16,800
down, can you fix the bugs? No, you're gonna You're gonna immediately

1200
01:25:16,800 --> 01:25:20,319
get a support contract with the vendor. So yeah, they know that story.

1201
01:25:20,359 --> 01:25:26,640
So it's it's a game, a
game. Yeah. The goal is

1202
01:25:26,720 --> 01:25:30,880
to make it easier to purchase the
subscription than to refactor your code to use

1203
01:25:30,880 --> 01:25:34,279
something else. Oh yeah, which
is not a hard goal to achieve,

1204
01:25:34,560 --> 01:25:40,039
right, And to me, I
call it a trojan horse. You know

1205
01:25:40,199 --> 01:25:43,439
you come in, it's free,
it's open source, you know, and

1206
01:25:43,560 --> 01:25:46,159
then it's in the organization. Next
thing you know, Wow this is expensive.

1207
01:25:46,520 --> 01:25:51,520
Wow this is hard while we're locked
in. Oh too bad, so

1208
01:25:51,640 --> 01:25:58,199
sad, And then the vendor is
for happy. They're playing the long game.

1209
01:25:58,239 --> 01:26:00,960
It takes a long time for this
to happen. Was praying a really

1210
01:26:00,000 --> 01:26:04,079
long game here? Oh yeah,
I mean you would think at this point

1211
01:26:04,159 --> 01:26:11,159
people would start to realize that this
is the pattern and maybe consider that when

1212
01:26:11,199 --> 01:26:15,039
they're going after certain technologies. But
it doesn't seem like that's the case.

1213
01:26:15,279 --> 01:26:18,520
They're still deluded that the price tag
for the source code is there, it's

1214
01:26:18,960 --> 01:26:26,000
zero dollars or franks or yeah.
I think that. I think that our

1215
01:26:26,039 --> 01:26:29,840
industry is still so new, that
we have so many new people coming into

1216
01:26:29,960 --> 01:26:35,439
it every year, that those lessons
aren't being translated. There's too many people

1217
01:26:35,520 --> 01:26:41,319
for people like us. There's too
many people entering every year for us to

1218
01:26:42,840 --> 01:26:46,920
share our stories with all of them, to keep repeating those to help them

1219
01:26:47,000 --> 01:26:54,560
prevent repeating our mistakes. Well,
and engineers are notoriously bad at making costs.

1220
01:26:56,239 --> 01:26:58,960
I mean, I know where it
comes from. It's oh that money

1221
01:26:58,960 --> 01:27:01,399
would come out of mind right,
I don't want to pay that money for

1222
01:27:01,479 --> 01:27:05,800
it, and they don't understand the
business justification and what really goes into the

1223
01:27:05,800 --> 01:27:11,319
total cost of ownership. Right.
Yeah, engineers are not good business people,

1224
01:27:11,359 --> 01:27:14,640
and it's it's a good thing because
business people are not good engineers.

1225
01:27:14,680 --> 01:27:18,039
I mean there's exceptions, of course, but the engineer is going to go,

1226
01:27:18,079 --> 01:27:20,199
I could just build this myself.
Why do I I can build my

1227
01:27:20,239 --> 01:27:25,039
own backup solution. I got build
my own operations manager, you know,

1228
01:27:25,039 --> 01:27:27,600
I could build my own security solutions. So the engineer goes, I could

1229
01:27:27,600 --> 01:27:30,520
work my way around this problem.
Well, as a company, you're like,

1230
01:27:30,680 --> 01:27:32,800
I'm not paying you to do that. That's way more money than paying

1231
01:27:32,840 --> 01:27:35,920
a vendor to do this for me. And how do I know you're going

1232
01:27:35,960 --> 01:27:39,479
to do security? Right? How
do I know you even know what a

1233
01:27:39,520 --> 01:27:44,239
backup solution is? I mean,
how many software developers know the cycle that

1234
01:27:44,279 --> 01:27:47,680
the backup schedule you should really follow
on a database and how that really should

1235
01:27:47,680 --> 01:27:51,279
work the best practices there? Well, ninety nine point nine percent developers have

1236
01:27:51,359 --> 01:27:56,239
no clue, so they couldn't even
begin to build that solution. So yeah,

1237
01:27:56,279 --> 01:28:00,239
developers are it's not it's delusion,
but it's more ignorance. And I

1238
01:28:00,239 --> 01:28:03,119
don't mean that they're ignorant. I'm
not saying that. I mean just lack

1239
01:28:03,159 --> 01:28:09,600
of knowledge, lack of experience.
It's easy to imagine yourselves because the developers

1240
01:28:09,640 --> 01:28:12,159
are awesome. I mean, I'm
a developer macrot right, we could build

1241
01:28:12,159 --> 01:28:15,319
anything, and you're like, I
could build that. I love building that.

1242
01:28:15,520 --> 01:28:18,840
Let me build that for you.
But as a business decision, you've

1243
01:28:18,880 --> 01:28:21,640
got to really think that through because
you don't want your developers. You want

1244
01:28:21,640 --> 01:28:26,479
your developers to build your product,
your value added product that you're going to

1245
01:28:26,520 --> 01:28:30,000
sell, not build infrastructure, not
build the lower level stuff. Yeah,

1246
01:28:30,000 --> 01:28:36,640
and that's a lesson learned through time
and experience, the difference between could I

1247
01:28:36,680 --> 01:28:41,039
build it and should I build it? Oh? Yeah, for sure.

1248
01:28:41,319 --> 01:28:46,880
That's hard because I want to build
everything, right, I mean every day.

1249
01:28:47,960 --> 01:28:50,359
And we have this problem at fair
Com too because we are in a

1250
01:28:50,479 --> 01:28:56,000
total engineering shop. So we want
to build everything ourselves. And I have

1251
01:28:56,039 --> 01:28:58,239
to say, you know what,
let's get an open source for that one.

1252
01:28:58,279 --> 01:29:00,399
But let's bet it carefully, you
know, Let's don't reinvent the wheel

1253
01:29:00,479 --> 01:29:03,760
every time, because that's what we
want to do in our nature. So

1254
01:29:03,840 --> 01:29:10,720
let me go build that cool thing. So yeah, it's hard. Managing

1255
01:29:10,720 --> 01:29:13,880
to engineers is hard to because you
gotta say, nope, you can't do

1256
01:29:13,960 --> 01:29:15,520
that, you can't do that,
we're going to buy this, you know.

1257
01:29:16,279 --> 01:29:20,039
But you really have to make those
good decisions as a software company.

1258
01:29:21,760 --> 01:29:26,520
And I mean that's where the fallacy
is though, right, Like we have

1259
01:29:26,560 --> 01:29:29,520
some backlog of work and we can
get through it, right like, you

1260
01:29:29,560 --> 01:29:31,640
know, it's just it's just these
three or four things and then we're done,

1261
01:29:31,760 --> 01:29:35,000
and maybe we can move on to
new things. And realizing that there's

1262
01:29:35,079 --> 01:29:40,079
a whole list of other issues and
tasks that are going to come up associated

1263
01:29:40,119 --> 01:29:45,960
with managing that technology us as you
start to build things out. It's so

1264
01:29:45,039 --> 01:29:49,039
true when you're a naive about something, you think it at a ten thousand

1265
01:29:49,079 --> 01:29:53,279
foot level, it looks easy.
Well, backup can't be that hard.

1266
01:29:53,840 --> 01:29:56,119
Well then, you know, just
call the data to a new location.

1267
01:29:56,239 --> 01:30:00,119
Done right, done, done.
That's that's what Mango said to do in

1268
01:30:00,159 --> 01:30:01,960
the beginning. Yeah, just cop
just just copy our data. But what

1269
01:30:02,000 --> 01:30:05,279
if your data is in transition and
it's half written a disc When you copy

1270
01:30:05,319 --> 01:30:11,079
it, you're copying, you're copying
broken data. You know, it's not

1271
01:30:11,439 --> 01:30:14,760
you have to cuiesce that database,
so it's not writing the disc while you're

1272
01:30:14,760 --> 01:30:16,960
copying it. But then what if
your database is huge and you're trying to

1273
01:30:17,000 --> 01:30:20,479
copy all that data all the time, you'll never get it copied in time.

1274
01:30:20,840 --> 01:30:24,920
You know, you're right out of
time. So so you need a

1275
01:30:25,000 --> 01:30:28,439
copy what's changed? Well how do
you do that? And you know once

1276
01:30:28,479 --> 01:30:31,039
you go down this rabbit hole.
But it's but that's foot levels. Just

1277
01:30:31,039 --> 01:30:35,239
copy the data, piece of cake. Is there is there actually a solution

1278
01:30:35,399 --> 01:30:40,640
to this in the database base where
writing to the journal and the actual table

1279
01:30:41,239 --> 01:30:45,760
like can somehow be strongly consistent so
that the backup being taken irrelevant like will

1280
01:30:45,760 --> 01:30:50,560
always be one hundred percent consistent.
Or it's just some small percentage chance that

1281
01:30:50,600 --> 01:30:55,199
the journal will have data that's not
actually in the database or something like that.

1282
01:30:55,600 --> 01:30:58,600
Well, in fact, you hit
the nail on the head the the

1283
01:30:58,600 --> 01:31:01,319
the ideas you cuiesce your data,
which means stop writing to the data files,

1284
01:31:02,359 --> 01:31:06,359
but keep writing to the journal,
so the journal it gets ahead of

1285
01:31:06,359 --> 01:31:12,000
the data files. But you could
copy now the data files safely or make

1286
01:31:12,000 --> 01:31:15,399
an incremental copy of what's changed in
the data files quickly over somewhere else.

1287
01:31:15,800 --> 01:31:20,520
Then then you unques the database at
that point you mark in your journal.

1288
01:31:21,359 --> 01:31:25,279
You've already marked in your journal where
you started a backup, and then you

1289
01:31:25,319 --> 01:31:29,600
could copy the journal files over too. So the restoration, you're restoring the

1290
01:31:29,680 --> 01:31:33,680
data files first, then you restore
the journal from that point in time and

1291
01:31:33,680 --> 01:31:38,399
now you and then you replay the
journal to catch the database up. So

1292
01:31:38,520 --> 01:31:45,720
that's the technique all the major databases
use. But that no single databases start

1293
01:31:45,760 --> 01:31:49,720
out ignoring the journal completely and just
did dumb things like we'll just copy the

1294
01:31:49,720 --> 01:31:55,319
files over here. They've gotten better
now, but you know, because they're

1295
01:31:55,359 --> 01:32:00,920
customers who have told them your data
is corrupt, so they they're gradually fixing

1296
01:32:00,960 --> 01:32:05,319
stuff like that. But yeah,
that's the difference between the database backup and

1297
01:32:05,359 --> 01:32:11,319
the database restore. One doesn't care
if it you corrupt. Yeah right,

1298
01:32:11,359 --> 01:32:15,800
the backup doesn't care. Oracle spent
a fortune on when they do their backup

1299
01:32:15,840 --> 01:32:17,760
this. The Oracle is really good
about not corrupting data that they're in.

1300
01:32:17,880 --> 01:32:24,640
So spare comp we built technologies designed
to not lose the data because corrupt data

1301
01:32:24,640 --> 01:32:28,079
is a big problem. So in
Oracle is doing the backup, they're reading

1302
01:32:28,159 --> 01:32:32,720
every block of data and validating it
to make sure that the all the safeties

1303
01:32:32,720 --> 01:32:36,840
they built into that block are there
so they're not so if the field data

1304
01:32:36,880 --> 01:32:41,079
is off or something that you could
tell, they detect it and then they

1305
01:32:41,079 --> 01:32:45,640
market. So you know when your
backups have corrupted data in them, so

1306
01:32:45,680 --> 01:32:49,319
you can start dealing with the issue. Because if the worst thing in the

1307
01:32:49,319 --> 01:32:54,359
world is you have a backup that's
three months old and you just had ransomware

1308
01:32:55,000 --> 01:32:59,199
and you got to restore and that
all that data is corrupted somehow, and

1309
01:32:59,239 --> 01:33:02,800
you're like, uh, what do
I do? See, Yeah, these

1310
01:33:02,800 --> 01:33:08,439
are these are the things that are
real. The answer there is you polish

1311
01:33:08,520 --> 01:33:12,399
up your LinkedIn profile. You're lucky
you're not the business owner, right,

1312
01:33:12,439 --> 01:33:16,439
That's that's where you're Yeah. DBAs
get fired over that kind of thing,

1313
01:33:16,600 --> 01:33:20,439
or or at least depending on what's
going on, you know, sometimes they

1314
01:33:20,479 --> 01:33:26,720
do sometimes down. But I mean, I've mortified that database company could be

1315
01:33:26,880 --> 01:33:31,239
walking around out there without having a
backup strategy that is actually paying attention to

1316
01:33:31,920 --> 01:33:36,560
live data streams that are still coming
in in a high throughput, high volume

1317
01:33:36,640 --> 01:33:41,119
environment Like that just seems for me, like, who are you that you

1318
01:33:41,119 --> 01:33:45,439
think you can just run a database, uh and as a service and and

1319
01:33:45,640 --> 01:33:49,560
you know walk away like this just
seems like a promise that's by default being

1320
01:33:49,760 --> 01:33:55,680
needs to be made. Yeah,
totally. Here's an example. We Firkom

1321
01:33:55,680 --> 01:34:00,239
also has another product called RTG,
which is our Cobal modernization solution. Turns

1322
01:34:00,279 --> 01:34:02,960
out that Cobyl writes data the exactly
way I M does. So what we

1323
01:34:03,159 --> 01:34:09,399
is we stuck our database, which
is that highly available mission critical database underneath

1324
01:34:09,439 --> 01:34:13,560
a Cobyl program, and we and
the Cobyl file handling routines just go to

1325
01:34:13,640 --> 01:34:17,840
our product directly. Well, the
vendors are buying our products to go out

1326
01:34:17,840 --> 01:34:21,520
of their Cobyl apps because they can't
rewrite the Cobyl app. It's the means

1327
01:34:21,520 --> 01:34:24,760
of loes of code, millions of
dollars. It's just too risky. Their

1328
01:34:24,760 --> 01:34:29,199
whole business, the financial industry wrote
everything in cobyl s little snow secret.

1329
01:34:29,239 --> 01:34:32,199
All your favorite banks you know,
are are running Cobyll programs for all your

1330
01:34:32,279 --> 01:34:39,199
data because it's at is a controversial
word there, Yeah, well yes,

1331
01:34:39,920 --> 01:34:43,760
or all you're hated or whatever,
then yeah, all the your So the

1332
01:34:43,800 --> 01:34:47,039
one of the one of these big
financial companies is coming to us and they

1333
01:34:47,119 --> 01:34:50,880
can service all their current customers.
But they want to go to tier one.

1334
01:34:51,199 --> 01:34:55,720
They sell baking software to Tier one
to Tier two and three systems.

1335
01:34:55,720 --> 01:34:59,319
They want to go to tier one, and they're the largest baking software system

1336
01:34:59,359 --> 01:35:03,479
in the world. But there are
certain huge customers they can't service because they

1337
01:35:03,560 --> 01:35:08,079
run a Cobyl and the filesystem can't
scale to what they need. So they're

1338
01:35:08,079 --> 01:35:11,640
putting our product right underneath the COBAL
which is a plug and play. Our

1339
01:35:11,720 --> 01:35:14,680
tg stets were ready to go because
you just plug us right in under the

1340
01:35:14,800 --> 01:35:16,840
Cobyl engine. You don't change a
line of Cobyl code. It just works,

1341
01:35:17,119 --> 01:35:21,640
and then our database scales it so
all the things you're talking about backup

1342
01:35:21,880 --> 01:35:27,640
recovery. Cobyl can't do any of
that stuff. They back up corruptive files

1343
01:35:27,680 --> 01:35:30,920
all the time. But what we
could do is we now bring the technology

1344
01:35:30,960 --> 01:35:33,680
to the table to create a storage
system, to create the database. Create

1345
01:35:33,720 --> 01:35:39,680
a storage system snapshot, which these
are huge, multi terabyte you know,

1346
01:35:40,079 --> 01:35:44,840
like eighty terabyte databases. They're huge. You can't back those up by copying

1347
01:35:44,880 --> 01:35:48,279
files, so you have to do
storage snap shots of those things, and

1348
01:35:48,359 --> 01:35:54,359
then you can then uncreates your database
and then copy the transaction logs over too.

1349
01:35:54,439 --> 01:35:59,560
Startur snapshot the transaction logs, and
then the storage system snap shot can

1350
01:35:59,600 --> 01:36:01,039
restore your data. You save the
snapshots, and then if you want to

1351
01:36:01,039 --> 01:36:05,479
restore it, you just revert to
the snap shot, apply the transaction logs.

1352
01:36:05,600 --> 01:36:10,920
You're back up and running, and
Cobalt files can't do any of that

1353
01:36:10,960 --> 01:36:15,279
system. But you put the Faircom
database underneath it, you instantly transform that

1354
01:36:15,680 --> 01:36:21,880
these legacy Cobol systems into modern systems. The only reason COBAL is dying is

1355
01:36:21,920 --> 01:36:26,760
because it's not the language. Language
isn't bad. It's the data systems was

1356
01:36:26,960 --> 01:36:30,399
where the data was built into the
data processing was built into the language.

1357
01:36:30,439 --> 01:36:32,960
You open files, you write the
files that they didn't. They didn't do

1358
01:36:33,039 --> 01:36:38,920
what c did and separate data from
the language. They kept data in the

1359
01:36:38,960 --> 01:36:45,000
language together. So the answer is
put a real mission critical database underneath your

1360
01:36:45,000 --> 01:36:47,359
COBOL system. And now your Cobol
system rocks and rolls just like every other

1361
01:36:47,399 --> 01:36:50,800
system in the world. And you
know, whether it's Java or c Sharp

1362
01:36:51,239 --> 01:36:56,199
or Go or whatever. Language,
that's all COBAL is is a language.

1363
01:36:56,479 --> 01:37:02,600
Now the data system modernized instantaneously because
we have all the mission critical scalable features

1364
01:37:03,079 --> 01:37:09,079
that COBAL needs that centered the hood. So that's the power of having a

1365
01:37:09,159 --> 01:37:15,239
real mission critical database under your in
your solution. Wow. Yeah, Well

1366
01:37:15,880 --> 01:37:17,359
we could go on forever. Maybe
we could come back and talk some more,

1367
01:37:17,399 --> 01:37:25,159
because there's the IoT world is exciting
and there's an IoT and I really,

1368
01:37:25,279 --> 01:37:30,159
just for my own personal curiosity,
I want to dig in. I

1369
01:37:30,159 --> 01:37:34,960
want to have you back on the
show and dig in to the LDS work

1370
01:37:35,039 --> 01:37:38,960
that you're doing, because you've already
mentioned that you had like a team of

1371
01:37:39,000 --> 01:37:46,279
like sixty DBAs and like a thousand
engineers and that transmitting money around the globe

1372
01:37:46,359 --> 01:37:53,079
was too slow using existing systems,
so you built your own money transfer system.

1373
01:37:53,119 --> 01:37:55,760
Like, to me, that's just
fascinating. And the fact is it's

1374
01:37:55,880 --> 01:38:02,840
like the overlap between the church and
technology there, I think is just really

1375
01:38:02,880 --> 01:38:05,640
really fascinating. So I want to
have you back on just to talk about

1376
01:38:05,680 --> 01:38:10,560
that. Oh cool, Yeah,
it was. It was an awesome place

1377
01:38:10,920 --> 01:38:16,560
because they are so technology focused and
cutting edge in the technology world because it's

1378
01:38:16,560 --> 01:38:21,680
all about the members and making their
lives better and so using technology to do

1379
01:38:21,720 --> 01:38:27,760
that super important. So yeah,
and the church, Yeah, we talked

1380
01:38:27,760 --> 01:38:30,760
about that the other the next episode. That'll be good, right on,

1381
01:38:30,880 --> 01:38:35,399
right on. Have you ever wished
that you had a group of people that

1382
01:38:35,439 --> 01:38:39,960
were just as passionate about writing code
as you are. I know I did.

1383
01:38:40,039 --> 01:38:42,640
I did that for most of my
career. I'd go to the meetups,

1384
01:38:42,680 --> 01:38:45,600
I try and create other opportunities,
and it was just really hard,

1385
01:38:45,800 --> 01:38:47,399
right the meetups. I got some
of that, but they were only like

1386
01:38:47,479 --> 01:38:50,600
once or twice a month, and
it was just really hard to find that

1387
01:38:50,640 --> 01:38:55,159
group of people that I connected with
and really wanted to, you know,

1388
01:38:55,239 --> 01:38:58,760
talk about code a lot, right, I mean, I love writing code.

1389
01:38:58,800 --> 01:39:02,359
I think it's the best. And
so I've decided to create this community

1390
01:39:02,880 --> 01:39:06,640
and create a worldwide community that we
can all jump in and do it.

1391
01:39:06,680 --> 01:39:11,560
So we're going to have two workshops
every week. One of those or two

1392
01:39:11,600 --> 01:39:14,279
of those every month are going to
be Q and A calls right where you

1393
01:39:14,279 --> 01:39:17,079
can get on you can ask me
or me and another expert questions. The

1394
01:39:17,119 --> 01:39:21,600
rest of them are going to be
focused on different aspects of career or programming

1395
01:39:21,760 --> 01:39:26,319
or things like that. Right,
So it'll go anywhere from like deployments and

1396
01:39:26,359 --> 01:39:30,640
containers all the way up to managing
your four oh one K and negotiating your

1397
01:39:30,000 --> 01:39:33,439
benefits package. Well, we'll cover
all of it. Okay, and then

1398
01:39:33,439 --> 01:39:38,760
we're also going to have meetups every
month for your particular technology area. So

1399
01:39:38,800 --> 01:39:42,159
we have shows about JavaScript, to
react, angular view, and so on.

1400
01:39:42,520 --> 01:39:44,800
We're going to have meetups for all
of those things. I'm going to

1401
01:39:44,840 --> 01:39:47,319
revive the freelancer show. We'll have
one about that right so you can get

1402
01:39:47,359 --> 01:39:51,760
started freelancing or continue freelancing if that's
where you're at. And I'm working on

1403
01:39:51,840 --> 01:39:59,239
finding authors who can actually do weekly
video tutorials on some thing for ten minutes.

1404
01:39:59,479 --> 01:40:02,000
This relate again to those technology areas
so that you can stay current,

1405
01:40:02,079 --> 01:40:05,560
keep growing. So if you're interested, go to toppendevs dot com, slash

1406
01:40:05,640 --> 01:40:12,039
sign up and you can get in
right now for thirty nine dollars. When

1407
01:40:12,079 --> 01:40:15,560
we're done, that price is going
to go up to seventy five dollars,

1408
01:40:15,000 --> 01:40:19,880
and the thirty nine dollars price gets
you access to two calls per week.

1409
01:40:20,720 --> 01:40:25,600
The full price at one hundred and
fifty dollars, which is going to be

1410
01:40:25,600 --> 01:40:29,680
seventy five dollars over the next few
weeks. That price is going to get

1411
01:40:29,720 --> 01:40:32,239
you access to all of the calls
and all of the tutorials and everything else

1412
01:40:32,279 --> 01:40:38,359
that we put out from top endevs
along with member pricing for our remote conferences

1413
01:40:38,399 --> 01:40:42,359
that are coming up next year.
So go check it out topendevs dot com

1414
01:40:42,359 --> 01:40:50,319
slash sign up. So let's move
on to picks or In last week we

1415
01:40:50,319 --> 01:40:56,600
talked about movies, Did you bring
anything anything new this week? I'm working

1416
01:40:56,640 --> 01:41:00,439
on it, you know. I
of course had to spend all my time

1417
01:41:00,840 --> 01:41:03,840
since last episode actually thinking about what
my pick is going to be this time,

1418
01:41:04,960 --> 01:41:08,960
which is not a movie, so
it's slightly more interesting. I think

1419
01:41:09,000 --> 01:41:12,640
my pick this time is going to
be a local stack, which is a

1420
01:41:12,920 --> 01:41:16,439
technology that takes AWS offline so you
can do local development work. And I

1421
01:41:16,439 --> 01:41:20,119
think they're doing a lot of interesting
things there and trying to build parity for

1422
01:41:20,319 --> 01:41:23,840
what is running an AWS I can
see is a huge challenge. I mean,

1423
01:41:23,840 --> 01:41:28,399
obviously it's not mission critical level of
stuff. But one of the reasons

1424
01:41:28,439 --> 01:41:31,920
I bring this up is because we
just create my company it just completed a

1425
01:41:31,920 --> 01:41:36,920
collaboration with them super successful where we
released an authorist extension for local stack to

1426
01:41:38,479 --> 01:41:43,439
amp up the security on the authentication
authorization side. So I think great team,

1427
01:41:43,520 --> 01:41:45,560
awesome stuff that they're doing. If
you don't know what local stack is

1428
01:41:45,560 --> 01:41:49,640
and you're using aws, you definitely
have to check it out right on.

1429
01:41:50,079 --> 01:41:55,199
Very cool. All right, Mike, what you bring for us this time?

1430
01:41:55,600 --> 01:41:59,880
Well, you said something kind of
personal. Whatever. So I'm a

1431
01:42:00,039 --> 01:42:03,560
I got my PhD in music theory
and my bachelor's in music composition. So

1432
01:42:03,600 --> 01:42:09,000
I'm a musician at heart. I
work technology because that's where the money is,

1433
01:42:09,039 --> 01:42:12,760
and my mind thinks that way too. That I love it. But

1434
01:42:12,840 --> 01:42:15,479
I played the piano, and so
one of my favorite piano pieces, the

1435
01:42:15,560 --> 01:42:20,479
Rockmando off Piano Concectial number two.
I like so many, but that is

1436
01:42:20,600 --> 01:42:25,199
just an amazing piece of music.
And when I listen to music like that,

1437
01:42:26,199 --> 01:42:30,960
I actually it's like programming. Now. It sounds weird, but I

1438
01:42:30,000 --> 01:42:35,359
see structure everywhere. It's layers upon
layers of If you think of objectority programming,

1439
01:42:35,359 --> 01:42:40,199
that's what a music composition is.
Is like an objectorated program with layers

1440
01:42:40,279 --> 01:42:44,680
upon layers of objects nesting with each
other in real time, with beautiful sounds.

1441
01:42:45,760 --> 01:42:50,239
And so I love I love bridging
the world of computers and music.

1442
01:42:50,319 --> 01:42:55,079
That's just kind of way my brain
works. That's cool. I've never thought

1443
01:42:55,079 --> 01:42:58,520
of it that way, but yeah, that makes a lot of sense.

1444
01:42:59,239 --> 01:43:04,159
Do you have like specific background music
that you use when you're working. Uh.

1445
01:43:04,239 --> 01:43:09,600
Yeah, none. If I turned
on music, my braid goes straight

1446
01:43:09,600 --> 01:43:12,840
into the music, forget everything else
because I'm I, like I said,

1447
01:43:12,840 --> 01:43:15,760
I got a PhD music theory,
so my brain's an analytical brain. I

1448
01:43:15,760 --> 01:43:19,640
don't just right here music. My
braid is analyzing music, and so it

1449
01:43:19,680 --> 01:43:24,600
takes over my whole braid. So
no, I can't, you know,

1450
01:43:24,760 --> 01:43:27,399
in the exact same way. Like
there are so many times I used to

1451
01:43:27,399 --> 01:43:30,720
listen to music while I was doing
things and I would have to take my

1452
01:43:30,760 --> 01:43:32,960
headphones off so I could think,
and I think there's nothing to this,

1453
01:43:33,199 --> 01:43:36,359
Like people who are driving cars,
which are super common, turning down the

1454
01:43:36,439 --> 01:43:40,800
radio so they know where to pull
over on the side of road. So

1455
01:43:41,039 --> 01:43:44,399
you know there's something there for sure. Yeah, no, I agree.

1456
01:43:44,479 --> 01:43:47,199
The The only exception, like,
the only thing I can listen to in

1457
01:43:47,239 --> 01:43:54,239
the background and stay focused on work
for me is Pink Floyd's Dark Side of

1458
01:43:54,279 --> 01:43:59,000
the Moon. And I don't know
why that is continuously Yeah, yeah,

1459
01:43:59,039 --> 01:44:03,000
yeah, it's one of my playlist
and I just repeat it and and it

1460
01:44:03,159 --> 01:44:08,880
just plays, but it puts me
in flow state. But any any other

1461
01:44:08,960 --> 01:44:14,359
song and I'm paying attention to the
music. Yeah, there's something like just

1462
01:44:14,439 --> 01:44:16,439
white noise in general, all that
it can be used to stimulate. So

1463
01:44:16,520 --> 01:44:18,800
you know, maybe this for you, you know, with your brain waves,

1464
01:44:18,880 --> 01:44:21,239
is just how to get you in
that state. I you know,

1465
01:44:21,359 --> 01:44:26,560
it can be anything, and for
you it's this one. Yeah. Cool.

1466
01:44:26,640 --> 01:44:30,359
Well, I brought two picks to
the show today. The first one

1467
01:44:30,399 --> 01:44:33,840
the same one that I picked last
week. Platform Con coming up. I

1468
01:44:33,840 --> 01:44:39,960
think it's coming up in May,
five day virtual conference about platform engineering and

1469
01:44:40,039 --> 01:44:44,560
all the aspects of that. Luca
who's been a previous guest on the show,

1470
01:44:44,680 --> 01:44:47,439
he'll be back on the show in
March to talk about platform Con.

1471
01:44:47,479 --> 01:44:53,720
But it's really great speakers lined up
there, so at platform con dot com

1472
01:44:53,840 --> 01:44:57,399
check that out. Totally free,
five day virtual event. And then the

1473
01:44:57,439 --> 01:45:05,199
other thing not technical related at all, but recently I put on a throttle

1474
01:45:05,199 --> 01:45:10,800
body space or a cold air intake
and a mass airflow sensor on my truck

1475
01:45:10,920 --> 01:45:15,560
to improve the performance of it.
Bought all of them from American Trucks dot

1476
01:45:15,600 --> 01:45:19,119
com and it was super cool because
you tell it which vehicle you have and

1477
01:45:19,319 --> 01:45:28,199
the website re updates itself to only
show stuff that is compatible with your exact

1478
01:45:28,279 --> 01:45:30,119
vehicle, so you don't buy something
that's not going to work. But then

1479
01:45:30,159 --> 01:45:35,600
they also have on every product page
they have videos showing you, you know,

1480
01:45:35,640 --> 01:45:39,319
how to install it, what the
performance is going to be like before

1481
01:45:39,359 --> 01:45:43,000
and after where they'll put the truck
on the dino and show you the output.

1482
01:45:43,079 --> 01:45:46,920
But just a really well done website. So yeah, American Trucks dot

1483
01:45:46,920 --> 01:45:50,520
com. Does it come with the
vision pro you know that you can put

1484
01:45:50,560 --> 01:46:00,800
that on. Cool note, but
that's actually a pretty cool idea. Cool

1485
01:46:00,960 --> 01:46:03,159
All right, Well, I believe
we have an episode. Mike, thanks

1486
01:46:03,159 --> 01:46:09,800
so much for being on the show. This has been there's been information overload

1487
01:46:09,960 --> 01:46:16,800
in every positive aspect of the term. Yeah you really you did a great

1488
01:46:16,880 --> 01:46:24,520
job of the highlighting the role that
DBAs have had and the fact that that

1489
01:46:24,520 --> 01:46:28,920
that need still exists. Yeah for
sure. So thank you for thank you

1490
01:46:28,920 --> 01:46:32,079
for coming on, and we'll check
in and have you back up back on

1491
01:46:32,119 --> 01:46:35,760
the show because I want to have
that follow up conversation with you. Cool.

1492
01:46:35,960 --> 01:46:44,720
I have some burning questions in that
area. All right, Larren,

1493
01:46:44,800 --> 01:46:46,520
thanks for joining me, love having
you on the show. Man, looking

1494
01:46:46,520 --> 01:46:51,359
forward to many many future episodes and
everyone listening. Thank y'all for listening,

1495
01:46:51,560 --> 01:46:53,920
and we'll see y'all next week.