1
00:00:14,439 --> 00:00:18,679
What's up, y'all? This is
the Adventures in DeVos podcast. I'm your

2
00:00:18,719 --> 00:00:23,679
host, well Button, and I
have the co host with the most Warren

3
00:00:23,800 --> 00:00:26,960
Parade. What's up? Worn?
Hey? I liked how you had to

4
00:00:27,000 --> 00:00:32,840
look to the side to remember your
name before, right, It's so focused

5
00:00:32,880 --> 00:00:36,039
on remember and all the other stuff
I have to do for the intro that,

6
00:00:36,119 --> 00:00:39,079
like my own name is like,
no, brain's got no room for

7
00:00:39,119 --> 00:00:46,880
that. Yeah, I'm warning.
I'm the CTO authoress. You know,

8
00:00:47,679 --> 00:00:51,320
I had to be careful when I'm
talking in conferences because I'll often look at

9
00:00:51,320 --> 00:00:54,439
my computer even if I have no
reason to do that, and like,

10
00:00:54,520 --> 00:00:57,280
I know what the words are that
I have to say, but it's just

11
00:00:57,320 --> 00:01:00,200
so distracting to have something else there
at the same time, for sure.

12
00:01:00,920 --> 00:01:07,239
All right, Joining us today in
the studio Tyson Trautman, VP of Engineering

13
00:01:07,280 --> 00:01:12,359
over at Fauna, former GM from
AWS, Code Pipeline and Code Deploy,

14
00:01:14,120 --> 00:01:19,560
Senior engineering manager at Riot Games and
so on and so forth. What's going

15
00:01:19,599 --> 00:01:22,359
on, Tyson? Hey, good
morning, Super excited to be here,

16
00:01:23,280 --> 00:01:26,680
dude, I'm excited to have you
here. It's kind of we've had a

17
00:01:26,719 --> 00:01:32,480
theme going recently, not planned or
intentional but it definitely has turned into a

18
00:01:32,480 --> 00:01:37,159
theme where we've been talking in the
last couple episodes about databases, and so

19
00:01:37,200 --> 00:01:42,079
you're going to talk with us today
about the bottlenecks and challenges that developers have

20
00:01:42,280 --> 00:01:47,120
with databases. And one of the
common things we've talked about in the last

21
00:01:47,120 --> 00:01:52,359
few episodes is how there used to
be this career path called a DBA or

22
00:01:52,480 --> 00:01:59,719
database administrator, and that just seems
to have mostly disappeared. So give us

23
00:01:59,719 --> 00:02:01,680
a little bit about your background and
your thoughts on the state of the database

24
00:02:01,799 --> 00:02:07,799
today. Yeah, for sure.
I mean I'll say, like you know,

25
00:02:07,920 --> 00:02:12,240
DBAs are certainly still out there.
They're still feeling a very important function

26
00:02:12,400 --> 00:02:15,080
at a lot of different companies,
including you know, back when I was

27
00:02:15,479 --> 00:02:20,879
leading the Infrastructure Platform group at Riot
Games, you know, we were kind

28
00:02:20,919 --> 00:02:23,919
of a sequel shop had you know, a lot of DBAs as part of

29
00:02:24,000 --> 00:02:30,039
kind of the broader group just managing
our database instances. But definitely a trend

30
00:02:30,080 --> 00:02:32,599
that's changing, for sure. You
know, even like when I at that

31
00:02:32,680 --> 00:02:37,879
time at Riot, we were thinking
very much about you know, moving towards

32
00:02:37,960 --> 00:02:43,479
automation using things like declarative schema and
some of the you know, things that

33
00:02:43,520 --> 00:02:46,599
I think we'll talk about here and
bringing continuous delivery to the database. You

34
00:02:46,639 --> 00:02:52,039
know, that kind of remove that
need for a specific individual that's like,

35
00:02:52,719 --> 00:02:55,759
you know, laser focused on the
database, you know, running scripts manually

36
00:02:57,199 --> 00:03:00,360
on a specific database instance, like
those types of things. You know,

37
00:03:00,360 --> 00:03:04,639
it kind of gets into this moving
towards this uh you know, cattle not

38
00:03:04,840 --> 00:03:09,319
pets kind of mantra. You know, that's kind of more been more commonplace

39
00:03:09,360 --> 00:03:14,520
in other areas of software engineering,
for sure. Yeah, because like when

40
00:03:14,520 --> 00:03:19,919
it comes to the world of pets, like databases worthy most prized pet for

41
00:03:19,960 --> 00:03:23,599
a long time, still still are
a lot of places. Yeah, yeah,

42
00:03:23,680 --> 00:03:25,560
speak because since we're live by the
way, mine may you know,

43
00:03:25,599 --> 00:03:31,759
come bursting through the door at any
means excellent literal pets, not the database

44
00:03:31,800 --> 00:03:38,840
pets, right on, right on. That works. Yeah. So you

45
00:03:38,919 --> 00:03:44,400
know, I think that whole trend
towards automation has has made it a lot

46
00:03:44,479 --> 00:03:49,080
easier to interact with the database,
especially you know, I know that o

47
00:03:49,280 --> 00:03:54,800
rms are very contested and hotly debated, but I gotta admit, like having

48
00:03:54,919 --> 00:04:01,240
something that generates roll forward and roll
back statements for my database is kind of

49
00:04:01,439 --> 00:04:09,319
nice, even if I don't get
the opportunity to specifically tune and test that

50
00:04:09,439 --> 00:04:13,599
query. Like for the most part, it tends to do the right thing

51
00:04:14,560 --> 00:04:17,199
in most cases for me. Yeah, it depends. I mean, so

52
00:04:18,439 --> 00:04:25,199
there's no question that if you want
to bring the best practices of continuous livery

53
00:04:25,199 --> 00:04:29,279
to the database, you know there's
a few specific things the pieces that you're

54
00:04:29,319 --> 00:04:30,759
going to need. And we've been
thinking, you know, spending a lot

55
00:04:30,800 --> 00:04:32,959
of time thinking about this and kind
of how it applies to to fauna specifically,

56
00:04:33,560 --> 00:04:38,319
but more generally, like you know, uh, one of the you

57
00:04:38,319 --> 00:04:43,360
know, what you're trying to do
in the database when you know to apply

58
00:04:43,439 --> 00:04:46,240
these practices of continuous delivery. And
first of all, when you make schema

59
00:04:46,360 --> 00:04:49,800
changes, you have to be able
to validate those schema changes against your existing

60
00:04:49,879 --> 00:04:56,920
data against services that call the database. And then you have to be able

61
00:04:56,959 --> 00:05:00,639
to replicate the transition process to make
sure there's no issues get from A to

62
00:05:00,720 --> 00:05:04,639
B. And then and you have
to be able to do those things in

63
00:05:04,759 --> 00:05:10,319
all of your different in different environments, right ranging from kind of local development

64
00:05:10,480 --> 00:05:14,000
all the way to production. And
so you know, will the capabilities you

65
00:05:14,040 --> 00:05:17,000
were just talking about, which is
you know, some kind of mechanism to

66
00:05:17,120 --> 00:05:25,279
go and programmatically apply schema changes is
absolutely a critical requirement. There are others

67
00:05:25,319 --> 00:05:28,040
as well. We could get into
that, but for sure, you know,

68
00:05:28,079 --> 00:05:32,360
whether it's whether you're manually issuing querries
you know, through an RM to

69
00:05:32,399 --> 00:05:39,120
do things like manipulate data maybe you
know, potentially manipulate schema, or whether

70
00:05:39,160 --> 00:05:42,839
you're using something like uh, you
know, in fauna terms. What we've

71
00:05:42,879 --> 00:05:45,560
recently launched is are what we call
the fun of schema language, which is

72
00:05:45,560 --> 00:05:51,399
a declarative language for defining schema and
getting to a known state, you know,

73
00:05:51,439 --> 00:05:55,439
declare I'll say, I'll put in
a little plug. Declarative is typically

74
00:05:55,480 --> 00:06:00,120
where it's at for these types of
applications, because you know, there are

75
00:06:00,120 --> 00:06:04,560
a lot of ways when you're imperatively
describing sort of infrastructure that you can get

76
00:06:04,560 --> 00:06:10,680
yourself in trouble or you can get
into, you know, kind of a

77
00:06:10,879 --> 00:06:14,120
these little edge cases, and so
there are some issues that you can run

78
00:06:14,160 --> 00:06:16,839
into there. But that's just just
a little little plug. Yeah, And

79
00:06:17,120 --> 00:06:21,240
so just to clarify thereby declarative,
you mean you're just saying this is what

80
00:06:21,319 --> 00:06:26,439
I want the end state to be, Like, I don't really really care

81
00:06:26,759 --> 00:06:29,920
about what happens in between, as
long as it ends up like this,

82
00:06:30,639 --> 00:06:34,480
that's right exactly. I want you
know, I want these database all these

83
00:06:34,480 --> 00:06:39,399
fontorms, but I want these databases, these collections with this field level schema

84
00:06:40,199 --> 00:06:44,360
and then you know, even getting
into more exotic concepts like we support the

85
00:06:44,439 --> 00:06:47,920
notion of like user defined functions and
check constraints and you know, all these

86
00:06:47,920 --> 00:06:51,040
other kind of cool things that you
can you know that we can get into.

87
00:06:51,120 --> 00:06:56,680
But but yeah, the entire the
ability to define that whole data model,

88
00:06:57,720 --> 00:07:00,120
the schema for that data model,
and know that you're going to get

89
00:07:00,120 --> 00:07:05,160
into that state, you know,
without necessarily having to describe like here are

90
00:07:05,160 --> 00:07:10,319
fifty different transformation stuffs I'm going to
run and I hope that it all works

91
00:07:10,319 --> 00:07:13,439
out given the data in the database, and you know, to get to

92
00:07:13,480 --> 00:07:17,959
get into that state for sure,
yeah, or learning the specific syntax or

93
00:07:17,959 --> 00:07:24,519
whatever variant of SQL your database platform
happens to be using and hoping that it

94
00:07:24,639 --> 00:07:30,360
either does it correctly or errors out
not something in between, right, Yeah,

95
00:07:30,600 --> 00:07:33,519
yeah, for sure. Cool.
So so it sounds like we're funny.

96
00:07:33,519 --> 00:07:40,920
You're setting the stage for people to
to move because I feel like there

97
00:07:40,959 --> 00:07:46,319
was this trend about a decade or
so ago where we put all of the

98
00:07:46,360 --> 00:07:50,480
business logic in the code, like
your your constraints and your your validations and

99
00:07:50,519 --> 00:07:55,839
things like that. Whenever prior to
that, you know, that was the

100
00:07:55,920 --> 00:08:00,480
role of the DBA, and databases
have really powerful tools for managing that type

101
00:08:00,480 --> 00:08:05,040
of stuff quickly and efficiently. But
it sounds like you're giving that control back

102
00:08:05,079 --> 00:08:09,439
to the database, but in a
way that makes it easier for developers to

103
00:08:09,639 --> 00:08:13,199
leverage the things that databases do.
Well. Yeah, that's I think that's

104
00:08:13,360 --> 00:08:16,560
a fair assessment for sure. I
mean, we try it to be too

105
00:08:16,600 --> 00:08:20,079
prescriptive, like we want to meet
developers where they are, right, you

106
00:08:20,120 --> 00:08:26,759
know, I think, but certainly
bringing those capabilities to the database so that

107
00:08:26,800 --> 00:08:28,959
if you want, you know,
you can put some of that logic with

108
00:08:30,040 --> 00:08:35,559
your data. You know, there
are very powerful benefits that come with that

109
00:08:35,720 --> 00:08:39,600
too, right, Like so for
example, you know, for modern kind

110
00:08:39,639 --> 00:08:46,799
of responsive applications, performance is a
huge deal. So the you know,

111
00:08:46,840 --> 00:08:50,320
the ability to go and run a
bunch of compute over your data, you

112
00:08:50,360 --> 00:08:56,960
know, on the database is potentially
a game changer for performance performance standpoint versus

113
00:08:58,000 --> 00:09:01,000
like you know, doing a whole
bunch of run trips around trips and running

114
00:09:01,000 --> 00:09:03,519
that compute on the client, right, So for sure, yeah, having

115
00:09:03,600 --> 00:09:07,600
that that those capabilities available, and
then also you know another thing with being

116
00:09:07,600 --> 00:09:11,080
able to run that compute as part
of a transaction on the database. It's

117
00:09:11,120 --> 00:09:16,000
even the next level, uh kind
of benefit once you get into these real

118
00:09:16,039 --> 00:09:18,879
operational use cases. Right. So
for sure, having those capabilities there so

119
00:09:18,919 --> 00:09:22,759
that folks can reach for them,
you know, if they want them when

120
00:09:22,759 --> 00:09:26,120
their application calls for it is absolutely
something that we're focused on. And so

121
00:09:26,240 --> 00:09:33,000
I think a lot of that is
there's probably a pretty large educational component to

122
00:09:33,080 --> 00:09:39,720
that because unless you have experience or
a lot of background expertise in database servers,

123
00:09:39,720 --> 00:09:43,840
these are all things that you potentially
didn't know database servers were capable of

124
00:09:43,919 --> 00:09:52,120
doing. So how has that shaped
how you how you approach this problem?

125
00:09:52,200 --> 00:09:54,000
Yeah, yeah, I mean in
some ways, so what you said is

126
00:09:54,039 --> 00:09:58,799
true, although in some ways,
you know, there's the kind of you

127
00:09:58,840 --> 00:10:01,480
know, everything old is new again, right, you know, people sort

128
00:10:01,519 --> 00:10:07,480
procedures since the beginning of time,
you know, and I think there are

129
00:10:07,480 --> 00:10:11,440
different kinds of ebbs and flows in
terms of you know, uh, the

130
00:10:11,519 --> 00:10:15,799
kind of hot application architecture of the
day, and you know some of the

131
00:10:15,879 --> 00:10:16,960
sometimes these trends you look back and
you say, hey, we did we

132
00:10:16,960 --> 00:10:20,559
didn't have it so wrong with some
of these things that were going on previously.

133
00:10:22,080 --> 00:10:24,039
But but for sure, I mean, yeah, you're you know.

134
00:10:24,679 --> 00:10:28,240
Uh. One of the things that's
been interesting about my journey upon a for

135
00:10:28,320 --> 00:10:33,799
sure is you know, you you
can build a really amazing product, and

136
00:10:35,080 --> 00:10:37,279
you know, as a consumer,
I feel that, you know, using

137
00:10:37,320 --> 00:10:39,480
the product, there's no question that
database we're building is the database I would

138
00:10:39,559 --> 00:10:43,399
use if I left to start a
company tomorrow. But you still have to

139
00:10:43,720 --> 00:10:48,320
tell that story to the market and
help people understand what's compelling about it.

140
00:10:48,679 --> 00:10:52,000
And you know, this cool stuff
that we're doing, you know, you're

141
00:10:52,000 --> 00:10:54,200
doing kind of in a vacuum,
doesn't matter. What matters is how it

142
00:10:54,240 --> 00:10:58,919
maps to actual requirements of software developers
and moves the needle makes them more productive,

143
00:11:00,200 --> 00:11:03,120
their life easier, mixed the applications
that they're building, you know,

144
00:11:03,279 --> 00:11:07,159
more secure, more available, more
performant. And so yeah, there's a

145
00:11:07,159 --> 00:11:11,720
big educational component. I mean a
lot of that is in docs. You

146
00:11:11,759 --> 00:11:13,360
know, I think when you're building
these types of apps, the quality of

147
00:11:13,360 --> 00:11:18,480
your docks is a huge deal.
Examples. All of those types of things

148
00:11:18,480 --> 00:11:20,320
are you know, big, big
area of investment, no question. I

149
00:11:20,320 --> 00:11:24,440
feel like you said something super controversial. So and I don't know if I

150
00:11:24,440 --> 00:11:28,200
want to let you jump over that. What what? What is? What?

151
00:11:28,039 --> 00:11:30,679
What is old is new again?
I feel like there's a whole swath

152
00:11:30,720 --> 00:11:37,039
of engineers out there at orgs and
companies who would swear by the stored procedures

153
00:11:37,039 --> 00:11:41,559
have always been wrong and will always
be wrong into the future. I'm curious,

154
00:11:41,639 --> 00:11:46,720
like there's no I don't think there's
a particularly right answer here, but

155
00:11:46,759 --> 00:11:50,200
maybe there's like some sort of spectrum
and this is what belongs in at the

156
00:11:50,279 --> 00:11:54,440
database layer, and this is what
belongs more at the domain or business logic

157
00:11:54,480 --> 00:11:58,360
outside in your application. Any thoughts
like where is that line that actually needs

158
00:11:58,360 --> 00:12:03,039
to be drawn? Yeah, I
mean it's a great point. I think

159
00:12:03,080 --> 00:12:05,720
the I try to stay away from
some of the kind of more you know,

160
00:12:07,279 --> 00:12:09,720
Zelody kind of religious debates like that
again, you know, to me,

161
00:12:09,840 --> 00:12:13,720
I think, you know, Warren, it really comes down to like

162
00:12:13,960 --> 00:12:18,120
the use case and what you're trying
to do with the requirements your application.

163
00:12:18,200 --> 00:12:22,879
Are sure, but you know,
and we could get into some kind of

164
00:12:22,879 --> 00:12:26,320
specific examples there. But I think
one of the problems with store procedures in

165
00:12:26,360 --> 00:12:33,960
the past is it was this entirely
separate code, you know, application code

166
00:12:33,000 --> 00:12:37,960
that sat kind of outside your app, so and it was it had a

167
00:12:39,320 --> 00:12:43,799
separate life cycle from your application.
There was no you know, kind of

168
00:12:45,000 --> 00:12:50,080
it single life cycle in terms of
like continuous delivery and how you get that

169
00:12:50,120 --> 00:12:54,360
application and production and to think about
things like versioning between client and server,

170
00:12:54,639 --> 00:12:56,840
and so a big part of what
we've been focused on, you know,

171
00:12:56,879 --> 00:13:03,120
with our recent launches with on a
schema languageeste is solving that problem by putting

172
00:13:03,120 --> 00:13:05,000
that logic together. So you know, the typical pattern when you're using FSL

173
00:13:05,039 --> 00:13:11,519
to describe you know, your data
is that code lives in your repo with

174
00:13:11,559 --> 00:13:16,240
your application code. It's version together. You know, that's what we do

175
00:13:16,279 --> 00:13:18,519
internally. We take a heavy dependency
on fauna. We eat our own dog

176
00:13:18,559 --> 00:13:20,960
food, drink our own champagne.
You know, however you want to put

177
00:13:20,960 --> 00:13:24,279
it, and that's you know,
that's certainly kind of the best practice that

178
00:13:24,279 --> 00:13:26,480
we follow as well. Everything right
together. So I think, you know,

179
00:13:28,200 --> 00:13:31,559
part of the answer is it depends
on the application and the specific requirements

180
00:13:31,600 --> 00:13:35,960
of the application. But another part
of it is the problems that people had

181
00:13:35,000 --> 00:13:39,039
at that point in time can be
solved through better products and better tooling around

182
00:13:39,080 --> 00:13:43,240
those products as well. No,
I'm totally with you, Like I remember

183
00:13:43,320 --> 00:13:48,799
on non trivial number of times,
writing some giant framework to manage getting storage

184
00:13:48,799 --> 00:13:54,159
procedures written in your get repository into
ms sql at the time and making sure

185
00:13:54,159 --> 00:13:58,639
they were executing the right order,
intertwined with whatever schema changes you also had.

186
00:14:00,120 --> 00:14:03,799
And then there's no way to really
live validate that without running it for

187
00:14:03,919 --> 00:14:09,120
real and making sure that it hits
some arbitrary query plan so that it's optimized,

188
00:14:09,200 --> 00:14:13,600
or even that it's using real fields
like dive in like a couple types

189
00:14:13,720 --> 00:14:16,679
just aren't there in most databases when
you think about it. Yeah, for

190
00:14:16,679 --> 00:14:20,600
sure, you nailed it. And
that's why I mean to me, what

191
00:14:20,639 --> 00:14:24,960
good looks like here is you know
again, you need the you need the

192
00:14:26,039 --> 00:14:28,360
you need the declarative tools that where
you can in any environment. You know,

193
00:14:28,399 --> 00:14:31,279
so in funt of terms, you
can spin up in UH an instance

194
00:14:31,320 --> 00:14:37,000
of fauna locally in in our Docker
container and you can use FSL to apply

195
00:14:37,039 --> 00:14:39,480
schema there. So you can use
this for even like local integration testing.

196
00:14:41,039 --> 00:14:46,720
But so you have the ability to
apply declarative schema it works in any environment.

197
00:14:46,879 --> 00:14:50,000
And then you have you know,
tools to load data as well,

198
00:14:50,039 --> 00:14:54,720
because like we mentioned earlier, you
need to validate schema changes against existing data.

199
00:14:54,759 --> 00:14:58,080
And we do that through you know, we have uh two kind of

200
00:14:58,080 --> 00:15:03,519
two mechanisms there back up and restore, backup and copy tool in the live

201
00:15:03,639 --> 00:15:07,600
environment, and then we also have
a data import tool where you can sort

202
00:15:07,639 --> 00:15:11,320
of play arbitrary data to load that
into a database. But then you know,

203
00:15:11,639 --> 00:15:15,399
you start wiring this thing up in
automation as part of your CD pipeline,

204
00:15:15,399 --> 00:15:18,039
and all of a sudden, these
tests are running locally again against the

205
00:15:18,080 --> 00:15:22,080
doctor container or something, or against
the live service if you prefer, you

206
00:15:22,120 --> 00:15:28,000
know, in your integration environments where
you're seeing actual consuming services in you know,

207
00:15:28,159 --> 00:15:33,960
under potentially real world load, you
know, with those schema changes with

208
00:15:33,080 --> 00:15:37,399
the new version of your your UDF
or your store procedure as that's going to

209
00:15:37,440 --> 00:15:41,519
production. And then you know you
can even safely apply those changes using that

210
00:15:41,559 --> 00:15:43,960
same tooling all the way out in
production again, which is what we do.

211
00:15:43,080 --> 00:15:48,000
So super powerful concepts. So I'm
going to ask a really dumb question

212
00:15:48,080 --> 00:15:52,679
and hope that the listeners of the
podcast who might actually have the same question

213
00:15:52,759 --> 00:15:58,440
can appreciate the fact that I'm taking
one for the team here is is Fauna

214
00:15:58,519 --> 00:16:03,879
its own database engine or is it
something that sits on top of other database

215
00:16:03,919 --> 00:16:08,039
engines. It's its own database engine. It is a it's a net new

216
00:16:08,279 --> 00:16:14,799
novel database that was built, you
know, effectively kind of from the ground

217
00:16:14,919 --> 00:16:19,120
up. It was deeply inspired by
There's an interesting research paper that came out

218
00:16:19,120 --> 00:16:25,840
of Yale years ago by Danie Labodi
who's an advisor at Fauna and a few

219
00:16:25,879 --> 00:16:30,840
others. That was kind of an
interesting spin on how to do how to

220
00:16:30,919 --> 00:16:37,159
run distributed transactions in a very different
model than like the typical kind of two

221
00:16:37,159 --> 00:16:41,600
phase commit model that Spanner and other
like truly distributed databases use. So that's

222
00:16:41,639 --> 00:16:45,720
kind of at the heart of Fauna. That's what we call it distributed transaction

223
00:16:45,840 --> 00:16:52,799
engine. You know, it's a
big component of Fauna. It handles multi

224
00:16:52,840 --> 00:16:57,919
region replication with the strongest possible level
of consistency guarantee. So that's kind of

225
00:16:57,919 --> 00:17:02,000
a secret sauce, you know,
in the core the guts of the product.

226
00:17:03,120 --> 00:17:07,000
Again, we don't like, you
know, sort of abstract nerdery.

227
00:17:07,039 --> 00:17:08,880
We like to tie back to real
world application requirements. But the reason that

228
00:17:08,920 --> 00:17:12,079
matters is, you know, number
one, people want multi regional application for

229
00:17:12,200 --> 00:17:15,680
performance. If I can do fast
reads from the local region, that's a

230
00:17:15,680 --> 00:17:21,279
really big deal for a lot of
modern applications. Right. It's also the

231
00:17:21,319 --> 00:17:26,440
best possible dr story if you literally
have multiple regions running in an active active

232
00:17:26,440 --> 00:17:32,319
configuration. You know, we see
examples where our good friend USC one is

233
00:17:32,359 --> 00:17:38,160
having issues and you know, and
so just keep cruising, cruising right along.

234
00:17:40,640 --> 00:17:42,519
But then you know, doing all
that with strong consistency is really the

235
00:17:42,640 --> 00:17:47,680
huge deal because as developers, I
mean, you know, it's very expensive

236
00:17:47,759 --> 00:17:52,720
to reason about these different edge cases
that you can hit in your application code,

237
00:17:52,799 --> 00:17:55,640
right, And to me, that's
a bit like people talk about,

238
00:17:55,640 --> 00:18:00,519
oh, you know we have a
strong ish level of consistency garantee. Well

239
00:18:00,519 --> 00:18:03,279
I'll either have to reason about these
funky edge cases that I can get into

240
00:18:03,400 --> 00:18:06,319
or I don't write. Yeah,
and with with Wanta, you don't.

241
00:18:06,440 --> 00:18:08,480
So that's kind of the the guts
of it when you talk database engine.

242
00:18:08,519 --> 00:18:14,039
That's kind of the the some of
the secret sauce innovation that we've been focused

243
00:18:14,079 --> 00:18:21,599
on. That's cool. So what
almost sounds like rethinking the database based on

244
00:18:22,960 --> 00:18:27,160
considerations that are relevant now but weren't
whenever most of our common data base platforms

245
00:18:27,160 --> 00:18:32,759
were created. Yeah, I mean, I think for sure the considerations that

246
00:18:32,759 --> 00:18:37,839
weren't relevant when folks were running you
know, you know single ins or single

247
00:18:37,839 --> 00:18:45,319
instance uh you know postcress instances or
you know primary secondary type configurations that are

248
00:18:45,319 --> 00:18:48,920
really still there, you know,
with you know, with some of the

249
00:18:48,960 --> 00:18:52,400
bigger players that folks are are using
today. You know, for some apps,

250
00:18:52,440 --> 00:18:57,160
that's fine, that's you know,
for some there's some applications where you

251
00:18:57,200 --> 00:19:02,359
know you're not going to hit this
insane scale where you're gonna suddenly have to

252
00:19:02,359 --> 00:19:04,400
start thinking about partitioning. And then
you got to start thinking about, oh,

253
00:19:04,480 --> 00:19:10,240
well, I was using Postgress because
of the strong transaction support, but

254
00:19:10,279 --> 00:19:12,480
now I can't do post you know, or a cross partition transactions. How

255
00:19:12,480 --> 00:19:15,440
do I solve that? And you
know, there's a ton of interesting innovation

256
00:19:15,480 --> 00:19:18,400
there I don't want to put you
know, they're like very cool tools for

257
00:19:18,519 --> 00:19:26,359
specific kinds of jobs, but you
know, for applications where scale and potentially

258
00:19:26,400 --> 00:19:30,039
multi region replication or a strong requirement
right out the gate, I think Fauna

259
00:19:30,200 --> 00:19:33,319
is is you know, in pretty
unique air up there with a few other

260
00:19:33,359 --> 00:19:36,400
offerings that are really kind of ground
up, Like let's think about how to

261
00:19:36,440 --> 00:19:40,440
do distributed transactions, you know,
in a in a first class way.

262
00:19:40,480 --> 00:19:41,759
That's a hard thing that just you
can't just take that and bolt it on.

263
00:19:42,960 --> 00:19:47,680
You brought up documentation before, and
I feel like there's a direct link

264
00:19:47,720 --> 00:19:51,599
here. Actually something on my mind
a lot is I feel like Authors has

265
00:19:51,640 --> 00:19:56,640
done something similar in the security domain, and the novel aspects that we've added

266
00:19:56,880 --> 00:20:00,480
to hopefully remove the confusion from users
sometimes get in their own way, like

267
00:20:00,640 --> 00:20:08,119
they have expectations that a database requires
a commit uh transaction step, that replicating

268
00:20:08,160 --> 00:20:14,640
across regions with some sort of replication
agent like is there by design, and

269
00:20:14,680 --> 00:20:18,519
some of the more experienced engineers get
caught up with expecting those things to be

270
00:20:18,680 --> 00:20:23,759
in place. Do you see that
a similar problem exists for Anna? You

271
00:20:23,799 --> 00:20:30,480
know, I don't. I think
people are usually if you build it,

272
00:20:30,559 --> 00:20:33,400
I think we've built it in a
way that feels pretty intuitive because with Fauna,

273
00:20:33,519 --> 00:20:37,599
you know, so with traditional databases, you know, whether that's let's

274
00:20:37,599 --> 00:20:41,880
say a SEQL based database or that's
something like Mango, you know, you're

275
00:20:42,079 --> 00:20:48,480
you're, you're your transaction model is
kind of tightly coupled to the session,

276
00:20:48,640 --> 00:20:51,319
right, and so that's to your
point more and that's like what you're the

277
00:20:51,359 --> 00:20:52,640
mental models, what you're used to. You have to do things like session

278
00:20:52,640 --> 00:20:56,200
managment management, et cetera. With
Fauna, you're just sending us for a

279
00:20:56,200 --> 00:21:00,000
SHPE requests. Basically, an AHPE
request essentially contain some code that you run

280
00:21:00,039 --> 00:21:04,559
as part of a transaction. And
so I guess my experience there in this

281
00:21:04,599 --> 00:21:10,240
particular domain, it so sounds a
little bit different, is uh. It's

282
00:21:10,359 --> 00:21:12,519
the way we've implemented is pretty intuitive. So folks get there and they're like,

283
00:21:12,519 --> 00:21:15,400
hey, this is cool. I
don't have to you know, I

284
00:21:15,400 --> 00:21:18,480
don't I don't have to think about
these things like session management. I don't

285
00:21:18,480 --> 00:21:21,599
have to think about is this code
running in the context of a transaction?

286
00:21:21,839 --> 00:21:26,440
When do I, you know,
commit the effectively commit that transaction. It's

287
00:21:26,559 --> 00:21:30,680
just I'm sending a transaction, I'm
getting a response back, and I can

288
00:21:30,720 --> 00:21:33,240
do that in the shape that my
application expects it, and that feels pretty

289
00:21:33,359 --> 00:21:38,160
intuitive. That's I think has been
my experience while watching folks when they first

290
00:21:38,160 --> 00:21:41,480
pick up the product. No.
The reason I asked is because there was

291
00:21:41,519 --> 00:21:47,680
a a lifetime ago there was an
instance where I was working with an engineer

292
00:21:47,920 --> 00:21:52,359
on GCP's Firebase, and there's a
bunch of promises that firebase makes with instantaneous

293
00:21:52,799 --> 00:21:57,160
commits, none have to worry about
concurrence or anything like that. And it's

294
00:21:57,240 --> 00:22:02,559
that that really felt counterintuitive that these
databases that are on opposite sides of the

295
00:22:02,559 --> 00:22:07,240
world won't have any sort of race
condition. And I guess that's not.

296
00:22:07,519 --> 00:22:11,799
Like the way you've designed fauna is
much more seamless than that that it makes

297
00:22:11,799 --> 00:22:15,839
it obvious when there is going to
be potentially a problem, uh, and

298
00:22:15,880 --> 00:22:18,720
when there's not and no one has
to worry about anything. Yeah, I

299
00:22:18,759 --> 00:22:21,920
mean to be clear, like there's
no free lunch of engineering, right,

300
00:22:21,960 --> 00:22:26,119
so we try to promise something that
doesn't you know, and the trade off

301
00:22:26,160 --> 00:22:30,119
that you're making, uh, you
know, when you're doing things like effectively

302
00:22:30,160 --> 00:22:33,160
running this type of active active configuration
where you have multi regioner application with strong

303
00:22:33,240 --> 00:22:37,279
consistency, like you can't cheat the
speed of light, so there, you

304
00:22:37,279 --> 00:22:42,039
know, there are performance trade offs
to that, you know. There what

305
00:22:42,119 --> 00:22:47,359
we've done is try to optimize to
that frontier of what's possible so that you're

306
00:22:47,400 --> 00:22:49,559
pushing you know, if you're if
you're doing rights through the transaction pipeline in

307
00:22:49,799 --> 00:22:56,759
the US and in fauna, you
know, you're talking mid double digit milliseconds

308
00:22:56,839 --> 00:23:00,440
right of replication time and reads can
be served from the local regions so very

309
00:23:00,480 --> 00:23:07,880
fast like low single single digit milliseconds, And in practice, that trade off

310
00:23:07,920 --> 00:23:11,480
is very attractive for most applications,
especially when you can avoid these like multi

311
00:23:11,559 --> 00:23:15,880
round trip like multi transaction scenarios where
you have application code running on a client

312
00:23:15,960 --> 00:23:18,200
like it's it's it's not you know
but there, But I just want to

313
00:23:18,200 --> 00:23:21,960
be clear, like there's always going
to be you mentioned the fire store case

314
00:23:22,000 --> 00:23:26,039
not you know for sure, if
you if you're if if for whatever reason,

315
00:23:26,119 --> 00:23:30,200
you think your your application is fine
with eventual consistency, that's a different

316
00:23:30,240 --> 00:23:33,200
model and you can achieve a different
performance profile. You know, you know

317
00:23:33,240 --> 00:23:37,640
where where warranted. I'd say buyer
beware because a lot of times you think

318
00:23:37,680 --> 00:23:40,839
your application is okay, you know, eventual consistency is an acceptable model for

319
00:23:40,880 --> 00:23:44,240
your app, and then you end
up planning out it's not so. But

320
00:23:44,440 --> 00:23:47,359
yeah, just want to be I
want to be honest. There no it

321
00:23:47,440 --> 00:23:55,240
makes a lot of sense really.
So you said that interacting with Fauna is

322
00:23:55,599 --> 00:23:59,279
HTTP a p I Is that right? That's right? Yeah, Yeah,

323
00:23:59,400 --> 00:24:00,160
it's done a lot of interesting where
I don't know if we want to go

324
00:24:00,160 --> 00:24:03,720
there, but we've done a lot
of there's a lot of innovation in FAUNA

325
00:24:03,920 --> 00:24:07,880
kind of in how we route to
the database as well, which has been

326
00:24:07,920 --> 00:24:11,799
a super interesting set of challenges.
You know, typically like most kind of

327
00:24:11,799 --> 00:24:15,680
an afterthought for a lot of database
providers, but thinking about you know,

328
00:24:15,000 --> 00:24:19,319
the point, because we're so performance
focused, thinking about that trip from the

329
00:24:19,319 --> 00:24:23,640
application to the database as well as
something that we've focused on on quite a

330
00:24:23,680 --> 00:24:30,240
bit, right, Yeah, that
makes sense because using that pattern has you

331
00:24:30,240 --> 00:24:33,960
you end up getting a lot of
being able to take advantage of a lot

332
00:24:34,000 --> 00:24:37,640
of work that other people are doing
in that same space instead of reinventing that

333
00:24:37,680 --> 00:24:42,240
work. Yeah. Absolutely, for
sure. Backing on top of each GDP

334
00:24:42,440 --> 00:24:48,200
is so much easier than TCP backets
quick or even if you're going to implement

335
00:24:48,240 --> 00:24:53,039
your own quick uh communication productol m, Yeah, no question. You know,

336
00:24:53,079 --> 00:24:56,119
I actually took a look at FUNA
before this. I was curious and

337
00:24:56,559 --> 00:25:00,279
I'm looking at that and then I'm
looking back at the cloud provider, and

338
00:25:00,359 --> 00:25:03,319
I'm wondering, like, when what
is it going to be that one of

339
00:25:03,319 --> 00:25:07,680
the cloud providers offers me a database
that actually achieves as much as these external

340
00:25:07,720 --> 00:25:11,079
providers get. And you know,
I just see such a huge discrepancy,

341
00:25:11,079 --> 00:25:15,279
and I you know, I'm surprised
that they haven't made a lot of progress

342
00:25:15,279 --> 00:25:19,240
in this area. Yeah, I
mean so first of all, I'll say,

343
00:25:19,319 --> 00:25:22,400
like, you know, effectively all
of the kind of hyper scalers are

344
00:25:22,759 --> 00:25:29,000
you know, fantastic partners. You
know, today we're in the AWS marketplace,

345
00:25:29,000 --> 00:25:32,000
where in the GCP marketplace you know, will be an azure down the

346
00:25:32,079 --> 00:25:33,680
road as well. And you know, Fauna by definition, we have we

347
00:25:33,720 --> 00:25:37,599
have our what we call our public
region groups called region group as we replicated

348
00:25:37,680 --> 00:25:42,440
across regions by default. But you
can also deploy something called virtual Private Fauna,

349
00:25:42,519 --> 00:25:47,920
which is still serverless but single tenant
like VM level isolation, and you

350
00:25:47,920 --> 00:25:51,559
can pick your cloud providers and your
footprint. So pretty cool offering for like

351
00:25:51,640 --> 00:25:56,240
larger enterprises that need more isolation.
But but yeah, you know, I

352
00:25:56,240 --> 00:26:03,160
think the reality is like those large
providers, if I take my former employer,

353
00:26:03,319 --> 00:26:06,079
you know, AWS, I'm saying
this is a as somebody who's no

354
00:26:06,079 --> 00:26:08,279
longer with AWS, but they have
very successful offerings, you know, DYNO,

355
00:26:08,440 --> 00:26:14,279
dB RDS, et cetera, that
are out there, and those things

356
00:26:14,319 --> 00:26:17,359
have a lot of inertia and they
continue to do work to make those things

357
00:26:17,400 --> 00:26:21,559
better. But you know those are
those are you know, multi billion dollar

358
00:26:21,680 --> 00:26:26,720
businesses, you know, in and
of themselves, and so it gets harder

359
00:26:26,880 --> 00:26:33,240
to go and compete with a startup
in the in a weird way there because

360
00:26:33,279 --> 00:26:36,440
you don't have any competing interests at
a startup like we're just setting out to

361
00:26:36,440 --> 00:26:40,519
try to build the best possible database
for modern application developers, whereas I think

362
00:26:40,839 --> 00:26:44,240
at some of those you know,
we've all anyone who's operating in the context

363
00:26:44,279 --> 00:26:48,720
of a larger, uh, you
know company. Once you have those revenue

364
00:26:48,720 --> 00:26:52,839
streams, there are different kind of
goals and you have to cater to that

365
00:26:52,960 --> 00:26:56,759
existing audience, right. You know, Mango, which is a fantastic product

366
00:26:56,759 --> 00:27:00,200
obviously has been around for a long
time, been very success full, still

367
00:27:00,240 --> 00:27:06,279
growing leaps and bounds. You know, they can't they can't throw out the

368
00:27:06,359 --> 00:27:07,799
on prem business, right, you
can't throw out the baby with the bathwater,

369
00:27:07,839 --> 00:27:11,559
And so you have these kind of
existing businesses that are very successful.

370
00:27:11,759 --> 00:27:15,880
You know, a great thing for
those those enterprises that they have to serve

371
00:27:15,920 --> 00:27:19,039
and focus on. But I think
to your point, I think it makes

372
00:27:19,039 --> 00:27:23,720
it a little bit harder to go
and build something that's kind of a generational

373
00:27:23,839 --> 00:27:29,359
leap, right that's significantly better for
application developers. And but you know,

374
00:27:29,400 --> 00:27:30,920
in fairness, we do see that
they're pretty there's a lot of hunger from

375
00:27:30,920 --> 00:27:37,039
those from those companies to go and
partner, and you know, they want

376
00:27:37,079 --> 00:27:40,880
there to drive the best outcome for
their customers and if that ends up being

377
00:27:41,119 --> 00:27:45,200
you know, we have a close
running conversation with the Lambda team at AWS

378
00:27:45,240 --> 00:27:48,640
for example, because there's a lot
of synergy between Fauna and Lambda where the

379
00:27:48,680 --> 00:27:52,359
data is at the edge where you
can run your Lambda functions. You don't

380
00:27:52,400 --> 00:27:55,880
have to maintain sessions, which is
fantastic from those kind of ephemeral environments that

381
00:27:55,920 --> 00:28:00,279
can just go away. So yeah, they're good partners for us, you

382
00:28:00,319 --> 00:28:03,599
know, and like I said,
we're right there in their marketplace, so

383
00:28:03,759 --> 00:28:07,000
you can buy us alongside the first
It sounds like, you know, a

384
00:28:07,000 --> 00:28:11,079
bunch of innovators dilemma, but also
innovation is coming if you pick the right

385
00:28:11,079 --> 00:28:18,599
providers. Yeah, yeah, for
sure, absolutely that what kind of design

386
00:28:18,519 --> 00:28:26,720
changes or design approaches require mental shift
to take on something like fauna where you've

387
00:28:26,759 --> 00:28:32,599
got you know, a server list
serveralist database with your data sitting on the

388
00:28:32,680 --> 00:28:36,839
edge. In terms of so when
you say design shift, you mean from

389
00:28:36,839 --> 00:28:41,160
the consuming application. Yeah, Like, if you're architecting an application, are

390
00:28:41,160 --> 00:28:47,240
there any considerations that you are there
things that you may you may make it

391
00:28:47,279 --> 00:28:48,640
down the road and say, oh
wow, if I'd done this, I

392
00:28:48,640 --> 00:28:55,000
would have been a lot happier.
Yeah, good question, just thinking you

393
00:28:55,079 --> 00:29:00,599
know, the there are there are
kind of these very mod and application architectures

394
00:29:00,680 --> 00:29:06,200
that Fauna in a way is sort
of you know, uniquely suited to serve.

395
00:29:06,839 --> 00:29:11,240
But you don't have to be using
one of those architectures for you know,

396
00:29:11,279 --> 00:29:12,960
to take advantage of a database like
you know, Fauna or some of

397
00:29:12,960 --> 00:29:18,079
these other like very modern databases we
have. We have plenty of customers that

398
00:29:18,119 --> 00:29:23,960
are running you know, a more
traditional application architecture where they have like a

399
00:29:25,000 --> 00:29:30,119
single region app server you know,
sitting in you know, pick a region

400
00:29:30,359 --> 00:29:33,119
that's accessing fauna, and they're not
necessarily taking advantage of multi region application.

401
00:29:33,200 --> 00:29:36,799
Other than the fact that it's there
as part of a dr story, So

402
00:29:36,960 --> 00:29:40,359
they could fail over, you know, if they're they're apps in region,

403
00:29:40,400 --> 00:29:42,960
but if their app was up for
some reason and you know, some service

404
00:29:42,960 --> 00:29:48,559
dependency brought us down in a region, that traffic could fail over and roped

405
00:29:48,559 --> 00:29:52,200
to another region. But you know, I think, but, but no,

406
00:29:52,279 --> 00:29:53,920
I think the answer is like,
we work just fine with those types

407
00:29:53,960 --> 00:30:00,960
of like you know, more traditional
architectures, or if you're building if you're

408
00:30:02,000 --> 00:30:04,960
some new startup that's very forward thinking, you're building something greenfield, and you

409
00:30:06,000 --> 00:30:10,160
know you want to take advantage of
all these new awesome offerings. Run compute

410
00:30:10,200 --> 00:30:15,160
out at the edge. You know
you can do that, and fauna pairs

411
00:30:15,240 --> 00:30:18,039
very nicely with that with those types
of architectures as well, right because we're

412
00:30:18,039 --> 00:30:22,480
going to have your data there,
server lists, you don't need to manage

413
00:30:22,480 --> 00:30:25,519
to think about scaling, you know, managing instances, et cetera, those

414
00:30:25,559 --> 00:30:29,480
types of concerns. So I think
I think we've I don't think they're you

415
00:30:29,519 --> 00:30:32,079
know, I can't think of any
specific gotcha's or something that you should have

416
00:30:32,160 --> 00:30:34,839
in mind as you adopt these kind
of modern databases. I think they you

417
00:30:34,880 --> 00:30:37,799
know, roll pretty well in the
existing paradigm. But then as you get

418
00:30:37,839 --> 00:30:41,640
towards these these newer architectures, you
know, they can they can really shine.

419
00:30:42,119 --> 00:30:48,119
So if someone spent the last twenty
years building MS SQL and now I

420
00:30:48,200 --> 00:30:52,359
shifted to RDS, there's not like
it still sort of works pretty much the

421
00:30:52,400 --> 00:30:56,000
same if they were to switch to
FAUNA other than get all the benefits and

422
00:30:56,279 --> 00:31:02,880
there's not a lot of potential pitfalls
with this sort of different database engines that

423
00:31:02,920 --> 00:31:04,799
are out there today, that's right. Yeah, I mean the you know,

424
00:31:04,839 --> 00:31:07,400
the downside is you have to go
and and you're gonna have to migrate

425
00:31:07,440 --> 00:31:12,000
application, yeah for sure, and
you know and your yeah, your data,

426
00:31:12,039 --> 00:31:14,440
you know, I mean you may
have to. I mean we have

427
00:31:14,440 --> 00:31:15,920
some we have some tools that do
you you can export, import data,

428
00:31:17,039 --> 00:31:19,599
do some different things. I think
we'll continue to get better. There hasn't

429
00:31:19,640 --> 00:31:22,240
been you know, top very top
of stack focus for us. We've been

430
00:31:22,319 --> 00:31:27,680
kind of more focused on innovating the
core product. But but yeah, for

431
00:31:27,720 --> 00:31:30,319
sure, now I think if you're
you know, if you bite the bullet

432
00:31:30,319 --> 00:31:33,920
on that migration, there's a whole
bunch of benefits that that that come with

433
00:31:34,000 --> 00:31:37,640
it. For sure. I mean
we you know, we have existing customers

434
00:31:37,680 --> 00:31:41,640
that have come from you know,
you name it. I'd say recently,

435
00:31:42,640 --> 00:31:47,839
more of the focus for folks that
are coming to Fauna are people who jumped

436
00:31:47,839 --> 00:31:52,519
from relational databases to document databases because
they believe in the document model. They're

437
00:31:52,519 --> 00:31:53,839
not a fan of r ms.
They don't like this document you know,

438
00:31:53,880 --> 00:31:59,400
relational impedance mismatch. But then all
of a sudden, you know, they're

439
00:31:59,480 --> 00:32:04,440
running on Go fire Store whatever,
Dynamo, Cosmos, TB, and they

440
00:32:04,519 --> 00:32:08,599
missed the relational some of the relational
capabilities they had with their relational database.

441
00:32:08,680 --> 00:32:13,279
They don't they're not ready to go
document, but they want these relational capabilities,

442
00:32:14,480 --> 00:32:16,319
you know. Fun of fundamentally is
what we call document relational. It's

443
00:32:16,319 --> 00:32:22,079
this kind of new paradigm where we
store data as documents on disc but it

444
00:32:22,119 --> 00:32:27,079
has the capabilities that you typically expect
from our relational database. So for example,

445
00:32:27,720 --> 00:32:32,880
the ability to define first class relationships
across uh, you know, documents

446
00:32:34,160 --> 00:32:38,119
and and kind of uh uh you
know, and access those documents the ways

447
00:32:38,119 --> 00:32:42,480
that you would expect with the relational
database. So yeah, so there's a

448
00:32:42,519 --> 00:32:44,759
lot of excitement for those folks that
see this as like, all right,

449
00:32:44,799 --> 00:32:46,319
kind of the best of both worlds. I don't have to I've jumped in

450
00:32:46,359 --> 00:32:50,640
the document model, but I get
all these capabilities that were that were the

451
00:32:50,680 --> 00:32:54,799
good part of my postgrass database.
And it's not like a partially QL on

452
00:32:54,880 --> 00:33:05,000
top of Dynamoe deb That's right,
that's right. Yeah, yeah cool.

453
00:33:05,640 --> 00:33:09,680
So one of the big challenges I
think with a lot of a lot of

454
00:33:09,759 --> 00:33:14,640
larger databases is you always end up
in a situation where you're doing et L.

455
00:33:15,039 --> 00:33:19,240
You know, it's pretty common to
et al your data out for analytics.

456
00:33:19,680 --> 00:33:23,319
How did y'all approach that? Yeah, We've got a few options there,

457
00:33:24,720 --> 00:33:28,680
you know, Like first of all, we support so there's a Fauna

458
00:33:28,759 --> 00:33:31,920
air Byte connector that some of our
customers use Airbyte open source product. They

459
00:33:31,920 --> 00:33:37,119
have managed offering, so you can
use air Byte too, you know.

460
00:33:37,160 --> 00:33:40,279
They're they're the connectors they have to
you know, to pump data from Fauna

461
00:33:40,359 --> 00:33:47,279
to your analytical database of choice.
You know. We we also support uh

462
00:33:47,319 --> 00:33:53,480
streaming, so you can stream changes
to documents or sets in Fauna. So

463
00:33:53,599 --> 00:33:57,240
different mental model, you know,
the you know, air Byte is kind

464
00:33:57,279 --> 00:34:01,559
of the more traditional, like I
want to push batch updates to my analytical

465
00:34:01,599 --> 00:34:07,280
database. Streaming is more commonly used
for these kind of you know, responsive

466
00:34:07,280 --> 00:34:09,840
apps where you want to push changes
to a client or something. But we

467
00:34:09,840 --> 00:34:15,280
do have some customers that for these
different use cases actually want to leverage streaming

468
00:34:15,360 --> 00:34:20,280
to push changes to sets too,
you know, a different a different,

469
00:34:20,400 --> 00:34:25,400
a different database. So those are
kind of the most common patterns. I'd

470
00:34:25,440 --> 00:34:29,360
say, you know, it's not
there today, but we're thinking a lot

471
00:34:29,360 --> 00:34:30,960
about. I felt like one of
the buzzwords that reinvent this year was like

472
00:34:31,119 --> 00:34:36,199
zero et L. You know,
there were Amazon was approaching. It was

473
00:34:36,559 --> 00:34:39,719
announcing zero et L for all this
database in this database, which really,

474
00:34:39,719 --> 00:34:42,599
you know, my mental model like
that, you know, you're still doing

475
00:34:42,599 --> 00:34:45,239
ETL. It's really I think it's
more just kind of like managed et L,

476
00:34:46,320 --> 00:34:52,639
these kind of uh, you know, higher level connectors between databases where

477
00:34:52,679 --> 00:34:55,679
more of that is managed just behind
the scenes and it just works. You

478
00:34:55,679 --> 00:34:59,239
don't have to think about it,
you know, you don't have to necessarily

479
00:34:59,280 --> 00:35:04,519
bring in a third vendor or manage
something yourself. And so that's something that

480
00:35:04,519 --> 00:35:07,280
we're thinking a lot about now,
is what that would look like, you

481
00:35:07,360 --> 00:35:10,880
know, to create these kind of
more managed ETL connections to some cloud providers.

482
00:35:10,920 --> 00:35:15,679
Nothing there you know it's in product
today, but something that's it's certainly

483
00:35:15,679 --> 00:35:19,280
on our on our radar screen,
Like we're talking about streaming to say big

484
00:35:19,360 --> 00:35:22,559
quarry or red shift something like that, or to stove like for instead about

485
00:35:22,599 --> 00:35:25,960
the customer needed to do anything extra, that's right, you know what if

486
00:35:25,960 --> 00:35:30,920
you could just do some kind of
an off handshake to that provider and you

487
00:35:30,960 --> 00:35:32,559
know, maybe give us a little
bit of metadata about I guess you're getting

488
00:35:32,559 --> 00:35:36,599
into describing transform. So there's you
know, same sets of defaults where things

489
00:35:36,760 --> 00:35:42,559
just work right. Like that's I
think you know this. I'll say like

490
00:35:42,599 --> 00:35:45,239
Amazon went way down the path of
this, like a specific database for every

491
00:35:45,440 --> 00:35:50,840
possible scenario, and then quickly realize, well, that's creates a big headache

492
00:35:50,840 --> 00:35:53,000
when you're thinking about moving data around. And so they have these different offerings

493
00:35:53,039 --> 00:35:58,840
like blue and other things to you
to move data between services. But I

494
00:35:58,840 --> 00:36:06,079
think there's a lot of uh folks
that aren't content with that situation. Yeah

495
00:36:06,119 --> 00:36:09,400
you got you got us in this
situation. Now help me move data around

496
00:36:09,440 --> 00:36:13,199
more seamlessly without you know, I
don't want teams of engineers that are just

497
00:36:13,239 --> 00:36:17,000
doing un differentiated heavy lifting building tools
to move data from a to b so

498
00:36:17,440 --> 00:36:22,840
uh yeah, I think that's part
of what created this problem that's now resulting

499
00:36:22,880 --> 00:36:24,880
in like zero ETL. I'll say, by the way, too, like

500
00:36:24,920 --> 00:36:31,360
we're more bullish on uh innovation at
the database let layer that can unlock a

501
00:36:31,440 --> 00:36:36,280
more general, generally suitable database.
Right, so fauna, you know,

502
00:36:36,320 --> 00:36:38,159
we even see people starting to push
the bounds where they're issuing you know what

503
00:36:38,239 --> 00:36:42,239
traditionally looks more like analytical queries on
top of FAUNA. I know we're not

504
00:36:42,239 --> 00:36:45,400
optimized for those use cases, but
you know, I'll say, uh,

505
00:36:46,159 --> 00:36:50,400
new databases like FUNA are very powerful, and I think you know, we're

506
00:36:50,440 --> 00:36:53,239
getting away to some extent from that
mold of like, oh, I need

507
00:36:53,880 --> 00:36:58,199
seven different databases for all these specific
use cases, and I have to think

508
00:36:58,239 --> 00:37:00,840
about replicating data between them. I
have to think about keeping data and saying,

509
00:37:01,079 --> 00:37:05,719
you know, et cetera. Oh
for sure. So so rather than

510
00:37:05,800 --> 00:37:08,760
etaling the data at all, just
build the database so that they can meet

511
00:37:08,960 --> 00:37:14,559
those needs in the same platform.
Yeah, yeah, yeah, depending.

512
00:37:14,559 --> 00:37:15,159
I mean, you know, again, I don't want to get back to

513
00:37:15,719 --> 00:37:20,159
you know, you know, use
car salesman here. I'm not saying that

514
00:37:20,400 --> 00:37:23,480
architectural trade offs you make you build
a share that will make them more suited

515
00:37:23,480 --> 00:37:29,280
for a specific set of use cases. But it's very clear that customers don't

516
00:37:29,320 --> 00:37:35,519
want a whole you know, database
portfolio, right, and you see this,

517
00:37:35,559 --> 00:37:37,480
but other you see this going the
other way too. I mean you

518
00:37:37,519 --> 00:37:43,239
see, you know, Snowflake,
for example, you know, launch their

519
00:37:43,400 --> 00:37:46,000
uni store offering where they sort of
try to bolt the transaction pipeline onto your

520
00:37:46,000 --> 00:37:52,159
analytical database. You know, I
haven't played with it. I've heard you

521
00:37:52,199 --> 00:37:54,199
know, their performance issues, things
like that, et cetera. But for

522
00:37:54,199 --> 00:37:58,760
some people it's compelling. If you're
right there, your primary workloads are analytical,

523
00:37:59,639 --> 00:38:01,800
you need transactions for some specific use
cases. You know, that can

524
00:38:01,840 --> 00:38:05,360
be compelling. And so I think
there are you know, we're certainly not

525
00:38:05,400 --> 00:38:07,559
the only ones. There are a
lot of vendors thinking about this. You

526
00:38:07,599 --> 00:38:13,719
know, how do I bring more
functionality potentially into into fewer offerings to make

527
00:38:13,800 --> 00:38:16,800
life easier for customers. I think
that's super important because at least historically with

528
00:38:17,039 --> 00:38:21,280
Snowflake, I haven't looked at it
recently, to be honest, getting the

529
00:38:21,360 --> 00:38:25,519
data in was sort of a challenge. So offering more functionality doesn't necessarily change

530
00:38:25,559 --> 00:38:31,199
that. The zero ETL connection on
the actual database application side is super like

531
00:38:31,239 --> 00:38:37,039
a lot really valuable. Yeah,
yeah, I agree. I guess you

532
00:38:37,039 --> 00:38:42,320
could say databases aren't pokemon, you
don't have to collect them all. True.

533
00:38:44,639 --> 00:38:46,960
I agree with I really got to
get the applause to plug in working

534
00:38:47,000 --> 00:38:52,880
on this because it's just awkward.
I didn't. I should have brought me

535
00:38:52,039 --> 00:38:58,360
my snare DROM and my crash I
could have, given it's downstairs, though,

536
00:38:58,400 --> 00:39:00,320
so we can't make that happen.
I mean, I feel like there's

537
00:39:00,679 --> 00:39:07,719
a duality there though, because the
more sort of fundamental engine aspects that a

538
00:39:07,840 --> 00:39:10,840
database engine offers, it has to
be trading off something right, Like I

539
00:39:10,920 --> 00:39:15,519
do have to pay more because the
data has to be replicated very quickly to

540
00:39:15,719 --> 00:39:20,480
a different format, or you pay
some sort of latency on processing in order

541
00:39:20,639 --> 00:39:23,000
so that it can actually figure out
what the optimal execution is. Like,

542
00:39:23,119 --> 00:39:28,719
we have this problem, so we
primarily use dynamouod V a lot, but

543
00:39:28,760 --> 00:39:31,840
we also have some graph needs and
I still haven't found a good like I

544
00:39:31,880 --> 00:39:37,440
love it graph database for us to
sort of bet on and I'm not sure

545
00:39:37,679 --> 00:39:39,519
that's something that Vaunta does, but
a lot of them don't do that.

546
00:39:40,679 --> 00:39:44,840
It's not an easy thing. Yeah, I mean, you're you're absolutely right.

547
00:39:45,320 --> 00:39:47,760
I think the question is, you
know, you there's going to be

548
00:39:50,960 --> 00:39:52,519
you know, the frontier that you
can get to, right in terms of

549
00:39:52,519 --> 00:39:57,800
how much you can do based on
the architectural decisions that you've made. For

550
00:39:57,840 --> 00:40:00,159
sure, the question is can you
get you know, eighty percent of the

551
00:40:00,199 --> 00:40:04,719
way they're in the same database where
for specific use cases it's good enough.

552
00:40:04,760 --> 00:40:07,280
I mean you mentioned graphs that it's
an interesting example we could dive into.

553
00:40:07,639 --> 00:40:10,360
You know, faun is not neo
for j right, Like, we don't

554
00:40:10,400 --> 00:40:15,960
have a first class concept of edges
between the sort of documents or entities in

555
00:40:16,000 --> 00:40:21,480
our database. You could model that
in documents and fan us, you know,

556
00:40:21,519 --> 00:40:27,599
because we support this ref field type
you know, where you can effectively

557
00:40:28,039 --> 00:40:30,000
uh, you know, denormalize as
part of a query across documents. These

558
00:40:30,039 --> 00:40:35,800
relational capabilities we're talking about, you
can model a lot of these graph use

559
00:40:35,840 --> 00:40:39,239
cases and people do this, right, Like, we see an interesting customer

560
00:40:39,840 --> 00:40:44,039
that's using kind of relationships that you
would think about as more of a graph

561
00:40:44,119 --> 00:40:47,239
type use case to fetch related entities
to go and inject into an ll M

562
00:40:47,320 --> 00:40:50,840
as part of an AI app.
Right, like, you know, so

563
00:40:51,360 --> 00:40:54,400
there are things you can do there, you know. Now, are we

564
00:40:54,480 --> 00:41:00,480
going we made a different set of
architectural decisions than NEO for J So are

565
00:41:00,519 --> 00:41:02,960
we ever going to be as good
for the P ninety nine P one hundred

566
00:41:04,239 --> 00:41:07,039
graph use case. No, that's
not our goal. But if your data

567
00:41:07,079 --> 00:41:10,440
is already in fauna and if you
like our capabilities as just a general purpose

568
00:41:10,440 --> 00:41:14,719
operational database, and then all of
a sudden you have these graph use cases,

569
00:41:14,760 --> 00:41:16,760
you know, is are the requirements
that P and A nine P one

570
00:41:16,840 --> 00:41:21,679
hundred use case where you need to
go and etl data into a purpose build

571
00:41:21,719 --> 00:41:22,639
database. I don't. For some
people the answer of yes, and that's

572
00:41:22,679 --> 00:41:28,199
totally cool. We want to support
those use cases have convenient tools available.

573
00:41:29,119 --> 00:41:30,880
But for a lot of folks the
answer is no. And if we have

574
00:41:30,920 --> 00:41:34,639
the right set of capabilities, you
know, we can we can unlock those

575
00:41:34,679 --> 00:41:37,840
use cases for them, you know, without adding the management overhead of kind

576
00:41:37,880 --> 00:41:40,639
of another offering. That's a really
that's a really good point. And I

577
00:41:40,719 --> 00:41:44,559
just want to set the records rate. We don't use we don't use Java

578
00:41:45,320 --> 00:41:52,000
for ours. But uh no,
I mean there there's there's some joke here

579
00:41:52,079 --> 00:41:58,320
about like Yeah, for sure the
Bredo curve that you can make it look

580
00:41:58,400 --> 00:42:01,000
like it and I even feel like
the graph database are much too slow for

581
00:42:01,159 --> 00:42:05,599
the usage of graph that most people
have, right Like, even if it

582
00:42:05,679 --> 00:42:09,079
is relationship based, you probably can
achieve a much faster results at using Fauna

583
00:42:09,280 --> 00:42:14,559
than pulling out the P one hundred
graph database solution and putting your data in

584
00:42:14,599 --> 00:42:17,679
that it's just usually not as fast
in most cases. Yep, yeah,

585
00:42:17,920 --> 00:42:22,639
definitely true. So more in question
over to you, what was the deciding

586
00:42:22,719 --> 00:42:28,400
factors that pushed you to choosing Dynamo
for your data? You know, I

587
00:42:28,400 --> 00:42:31,719
feel like this comes up a lot, and primarily I think the sort of

588
00:42:31,800 --> 00:42:38,880
data that we're saving is sort of
relationship aspect. But we store the roles

589
00:42:38,920 --> 00:42:44,519
and identities for individual users and the
permissions that are associated with them, and

590
00:42:44,559 --> 00:42:47,639
that lends itself a lot to a
key value store. There is a relationship

591
00:42:47,679 --> 00:42:52,639
aspect there, but as I said, it is sort of like this eighty

592
00:42:52,719 --> 00:42:59,559
twenty principle where most of the data
does not benefit from being highly relation enough.

593
00:43:00,079 --> 00:43:02,880
Also, an ease of usage something
that came up previously, and I

594
00:43:02,880 --> 00:43:07,320
want to ask Tyson here is like
when do you hire a DBA, like

595
00:43:07,360 --> 00:43:12,679
for whatever you words you associated with
the acronym DBA when you hire one,

596
00:43:12,760 --> 00:43:15,039
like, we don't have one.
I don't want to get into the business

597
00:43:15,079 --> 00:43:16,920
of having to get one. I
don't think it scales for us. And

598
00:43:17,000 --> 00:43:24,559
so things like DynamoDB Fauna, these
no SQL or PSEUDOOSEQL document stores that offer

599
00:43:24,639 --> 00:43:30,760
key value aspects I feel like have
a much lower complexity, a much lower

600
00:43:30,920 --> 00:43:36,199
barrier to entry for application engineers than
you say, trying to spin up an

601
00:43:36,239 --> 00:43:40,320
RDS, which also doesn't replicate well. Dynamo offic with global tables. We

602
00:43:40,440 --> 00:43:45,480
offer global solutions as a global company, and having multi regions that are active

603
00:43:45,519 --> 00:43:51,800
active configurations is like a huge importance
for us. Yeah, I'll say,

604
00:43:51,840 --> 00:43:53,360
I mean, so there's a few
interesting ways to go there. First off,

605
00:43:53,360 --> 00:43:57,760
in the Dynamoe because I thought this
was fun, fun question to chase

606
00:43:57,800 --> 00:44:01,400
down a little bit. You know, you're absolutely right, Like Dynamo is

607
00:44:01,559 --> 00:44:08,679
very a great tool for super fast
kV access, predictable latency. You know,

608
00:44:08,760 --> 00:44:14,159
even at several you know, several
nines, you're still getting very predictable

609
00:44:14,280 --> 00:44:19,559
latency. It's interesting because having been
at Amazon, you know where most apps

610
00:44:19,599 --> 00:44:23,679
internally now are being built on Dynamo. There's this almost religion to it where

611
00:44:24,320 --> 00:44:30,320
you're saying, again, we can't
build a performance enough, scalable enough general

612
00:44:30,360 --> 00:44:35,599
purpose database, so we have to
fall back to a tool like Dynamo.

613
00:44:35,639 --> 00:44:39,480
It's effectively at the end of the
day kV access and then build a lot

614
00:44:39,519 --> 00:44:45,400
of complex application logic to go and
support that, right because we have kind

615
00:44:45,400 --> 00:44:51,960
of a lesser consistency model, you
know, limited access patterns. You mentioned

616
00:44:51,960 --> 00:44:53,960
global tables for multi regional application,
but when you go to global tables there's

617
00:44:53,960 --> 00:44:58,239
a lot of Gatcha's, I mean, they're expensive, you know, eventual

618
00:44:58,239 --> 00:45:01,239
consistency again even more limited in terms
of access patterns and what you can do.

619
00:45:02,920 --> 00:45:06,039
And so you know, for sure, I think, you know,

620
00:45:06,119 --> 00:45:08,320
Dynamo is an amazing tool for what
it is for those specific use cases.

621
00:45:08,480 --> 00:45:15,599
But we see a lot of interest
from customers that they want that predictable kV

622
00:45:15,679 --> 00:45:20,800
access which other tools like want to
provide. But then you know, they

623
00:45:20,800 --> 00:45:24,280
don't want to have to think about
transactions in their application code. They don't

624
00:45:24,280 --> 00:45:27,599
they don't want to have to think
about you know, they want to support

625
00:45:27,719 --> 00:45:31,719
very flexible access patterns where a lot
of times you know in Dynamo even kind

626
00:45:31,760 --> 00:45:37,159
of the the adopted mantra of Dynamo, things like single table design. You

627
00:45:37,199 --> 00:45:40,199
know, you really have to which
has been involuntarily, You really have to

628
00:45:40,280 --> 00:45:46,239
understand your access patterns upfront, and
so maybe you know you you you come

629
00:45:46,280 --> 00:45:51,679
up with your data model and things
work fine for that initial use case,

630
00:45:51,719 --> 00:45:53,599
but then you go to build the
next feature and you're like, oh crap,

631
00:45:53,639 --> 00:45:58,639
I'm screwed. You know, it
doesn'ts not gonna support this. So

632
00:45:58,840 --> 00:46:01,639
there are a lot of gotchas there
there. You know, I think great

633
00:46:01,679 --> 00:46:06,119
service for what it is. For
sure, I can say firstthand is somebody

634
00:46:06,239 --> 00:46:07,639
used for an aw services like you
know, they're always going to get a

635
00:46:07,679 --> 00:46:12,039
lot of uplift because they're integrated with
IM CloudWatch, cloud Trail, they're right

636
00:46:12,039 --> 00:46:16,760
there in the ecosystem. But I
do think it's worth for a lot of

637
00:46:16,760 --> 00:46:22,239
folks that are just diving in,
you know, taking a peek at some

638
00:46:22,280 --> 00:46:23,559
of the more modern offerings that are
out there, like Fauna and say,

639
00:46:23,599 --> 00:46:27,039
you know, just because because not
only are they going to work for that

640
00:46:27,079 --> 00:46:30,159
initial use case, even if it's
just KB storage providing super low latency you

641
00:46:30,199 --> 00:46:35,920
know kV, but they're going to
scale to those access patterns without you,

642
00:46:35,920 --> 00:46:37,639
you know, requiring you to kind
of understand all those access patterns up front.

643
00:46:37,639 --> 00:46:40,400
So that's my little spiel. Warn't
you've gone into a separate question,

644
00:46:40,400 --> 00:46:43,320
which is about hiring DVAS. I
don't know. We could go ahead.

645
00:46:43,960 --> 00:46:45,400
I don't know about you either.
I mean, you mentioned a lot of

646
00:46:45,440 --> 00:46:50,519
really interesting things there. I think
that what I'll say is we definitely have

647
00:46:50,559 --> 00:46:53,719
a bimodal distribution where it's very easy
with things like Dinamo dB for a very

648
00:46:53,719 --> 00:46:59,079
simple app to get up and running
without the complexity we' and then there's this

649
00:46:59,199 --> 00:47:00,400
lull in the middle or you don't
want to be in. And we're at

650
00:47:00,440 --> 00:47:06,159
the point on the other side where
we sort of fundamentally know how dynamodd works

651
00:47:05,960 --> 00:47:12,159
as though it was we implemented it
at the service level, because we know

652
00:47:12,199 --> 00:47:15,360
where the edge cases are and we're
figuring out how to get around them or

653
00:47:15,719 --> 00:47:21,559
understand how partitioning even works because we're
at that scale and we have tons of

654
00:47:21,599 --> 00:47:25,039
application code that wraps it to make
it as effective as possible. So yeah,

655
00:47:25,079 --> 00:47:29,840
I mean, at the second mode
at long tail, you for sure

656
00:47:29,880 --> 00:47:31,440
if you're using Dynamoe to b at
scale you will, you will know how

657
00:47:31,519 --> 00:47:35,480
it works for real, and you
will have a lot of application code to

658
00:47:35,519 --> 00:47:37,400
deal with that. Yeah. Absolutely, there's no question, I mean for

659
00:47:37,440 --> 00:47:39,599
sure. And then once you're in
that state, you know, we talked

660
00:47:39,599 --> 00:47:43,960
to a lot of companies that are
there, say, we built up expertise,

661
00:47:44,360 --> 00:47:45,639
we have a lot of application code
around it. You know, it's

662
00:47:45,639 --> 00:47:50,239
working, we have there's for sure
pain. The question is like, when

663
00:47:50,280 --> 00:47:53,119
does that pain get too high?
You know. We talked to a company

664
00:47:53,159 --> 00:47:58,119
that was a big Dynamald customer,
you know, and it was taking them

665
00:47:58,159 --> 00:48:00,519
like literally I think days to build
you know, new gsis. They're running

666
00:48:00,519 --> 00:48:02,719
in GSI limits, et cetera.
And so they were like out of the

667
00:48:02,719 --> 00:48:05,239
point where they were. You know, it's like, Okay, this is

668
00:48:05,280 --> 00:48:09,360
literally no longer tenable. We have
to explore other options because it's not working

669
00:48:09,360 --> 00:48:12,440
for our use case. But that's
pretty extreme, you know, And there

670
00:48:12,480 --> 00:48:15,679
are a lot of companies that are
in the state that you're in where Dynamo

671
00:48:15,760 --> 00:48:20,599
is working great. It's a very
powerful tool. They've built up internal expertise

672
00:48:20,639 --> 00:48:23,599
and they've built these kind of this
layer of their application on top of that.

673
00:48:23,599 --> 00:48:27,880
That's necessity you know, for their
specific use case. Uh, and

674
00:48:27,920 --> 00:48:30,440
then may be fine, Like I'm
not that's that's you know, I could

675
00:48:30,519 --> 00:48:34,760
could be the right spot for them
to be in, you know, I

676
00:48:35,400 --> 00:48:37,840
think I guess my point was more
around there's a lot of people that dive

677
00:48:37,880 --> 00:48:42,679
in because they're there in the ABS
ecosystem. It's a convenient tool without necessarily

678
00:48:42,800 --> 00:48:45,519
understanding that they're going to have to
go and do what you guys did for

679
00:48:45,719 --> 00:48:50,440
which is a lot of application,
you know, or a lot of investment

680
00:48:50,559 --> 00:48:53,880
around the database to make it work
for your specific use case. And you

681
00:48:53,960 --> 00:48:55,639
may not need to do that,
like if you do, there may be

682
00:48:57,519 --> 00:49:00,159
kind of other more modern databases out
there that handle some of that, you

683
00:49:00,199 --> 00:49:02,400
know, what i'd consider to be
more un differentiated. Have you lifting for

684
00:49:02,599 --> 00:49:07,840
some use cases not for all use
cases? On you know, on on

685
00:49:07,880 --> 00:49:10,239
your behalf, So that that was
more what I was was was pushing.

686
00:49:10,519 --> 00:49:15,920
Yeah, I totally agree. I
do want to dig into the DBA thing

687
00:49:15,960 --> 00:49:21,719
though. What do you think the
role of the DBA is moving forward?

688
00:49:21,719 --> 00:49:23,159
Like from here moving forward? Do
you think it still exists? Is there

689
00:49:23,159 --> 00:49:29,480
a particular place where it makes sense? Yeah? I think I mean so

690
00:49:29,719 --> 00:49:36,639
DBA has traditionally understood which is like
a human, you know, thinking about

691
00:49:36,679 --> 00:49:38,840
pets on a kind of a very
one off basis, like thinking about database

692
00:49:38,880 --> 00:49:45,039
instances like you know that that will
exist, you know, for a while,

693
00:49:46,000 --> 00:49:51,280
just essentially to service this these kind
of legacy applications that are written on

694
00:49:51,320 --> 00:49:55,440
top of you know, single instance, my SQL postgress whatever, you know,

695
00:49:55,480 --> 00:49:59,760
SQL server instances that will be around
again. We'll be around for a

696
00:49:59,800 --> 00:50:04,840
long so there we demand for that, you know. But I think looking

697
00:50:04,880 --> 00:50:08,320
forward, I think what you're going
to see is, you know, software

698
00:50:08,320 --> 00:50:15,039
engineers with you know, some domain
expertise in terms of data and data modeling,

699
00:50:15,079 --> 00:50:20,719
because that's a big field and nobody
can be, uh, you know,

700
00:50:21,079 --> 00:50:23,719
a software engineer with general expertise across
every area. But you're gonna see

701
00:50:23,719 --> 00:50:30,000
software engineers with with that kind of
expertise, you know, who are helping

702
00:50:30,119 --> 00:50:35,679
enterprises at scale to think about their
data architecture, you know, and how

703
00:50:35,800 --> 00:50:39,639
data is consumed across you know a
complex soa or whatever whatever that architecture looks

704
00:50:39,679 --> 00:50:44,000
like, right, But they're going
to be doing it in scalable ways.

705
00:50:44,039 --> 00:50:49,000
They're going to be taking advantage of
things like you know, these the faunic

706
00:50:49,039 --> 00:50:52,559
capabilities that are referenced earlier, where
it's going to feel more like writing application

707
00:50:52,679 --> 00:50:57,800
code traditionally has. They'll be using
all these practices like you know what we

708
00:50:57,840 --> 00:51:02,159
call schemas code more similar to infrastructure
as code. You know, it'll be

709
00:51:02,159 --> 00:51:07,920
bringing that cattle nut pets kind of
mindset to to the database, so that

710
00:51:07,920 --> 00:51:09,280
that there's going to be more and
more of a need for folks in that

711
00:51:09,400 --> 00:51:15,360
kind of role, which looks more
like you know, software engineer with some

712
00:51:15,400 --> 00:51:22,000
expertise in data and data modeling.
You're integrating with the database layer than you

713
00:51:22,079 --> 00:51:24,159
are figuring out how to optimize one. I mean, obviously, you know,

714
00:51:24,159 --> 00:51:29,039
I think that's a great answer.
I mean, the cloud providers or

715
00:51:29,960 --> 00:51:31,800
the faunas of the world, right, if you want to be a DBA,

716
00:51:31,880 --> 00:51:36,039
maybe that's where you go, right
to these products that are offering this

717
00:51:36,800 --> 00:51:40,079
primarily at scale, so that companies
don't have to think about what their engineers

718
00:51:40,079 --> 00:51:44,760
are going to have to know in
order to put data in a database somewhere.

719
00:51:45,280 --> 00:51:46,000
Oh yeah, for sure. I
mean, but the people that we're

720
00:51:46,039 --> 00:51:50,039
hiring, you know, like the
it's actually it's hard to go and recruit

721
00:51:50,039 --> 00:51:53,559
for these these roles. But you
know, people folks with deep database sme

722
00:51:54,280 --> 00:51:57,719
that are yeah, that are actually
going to get in and think about you

723
00:51:57,719 --> 00:52:02,199
know, uh, you know,
improve performance of sort of the transaction pipeline,

724
00:52:02,400 --> 00:52:06,519
you know, store the storage engine. Uh, for sure, I

725
00:52:06,559 --> 00:52:09,320
mean those are that's a there's there's
a there's a limited pool of people that

726
00:52:09,360 --> 00:52:13,000
have are you know, I have
spent time solving those challenges in the real

727
00:52:13,079 --> 00:52:16,840
world. They're very highly sought after, and we would rather hire those people,

728
00:52:17,280 --> 00:52:20,480
uh, you know, so that
you don't have to think about those

729
00:52:20,519 --> 00:52:22,800
kinds of hard challenges, for sure. Is the way that we think about

730
00:52:22,840 --> 00:52:25,480
it, Like, we want to
take as much of that sort of complexity

731
00:52:25,599 --> 00:52:31,559
as as reasonably possible and solve those
challenges in a common way so that you

732
00:52:31,599 --> 00:52:35,119
know, more and more, I
mean, our the primary goal of what

733
00:52:35,119 --> 00:52:38,280
we're doing is trying to allow uh, these application development teams to go and

734
00:52:38,320 --> 00:52:42,760
innovate and focus on their application and
not you know, again not do this

735
00:52:43,119 --> 00:52:46,000
you know, undifferentiated heavy lifting.
I mean, you know, one of

736
00:52:46,039 --> 00:52:51,679
the things I saw in a past
life when I was a leading the code

737
00:52:51,679 --> 00:52:57,039
pipeline and code deplay teams at Amazon. It was interesting because you know,

738
00:52:57,079 --> 00:52:59,760
at that time we were competing,
we had built an interesting offering at kind

739
00:52:59,800 --> 00:53:02,760
of a lower layer than kind of
the githubs and the get labs of the

740
00:53:02,800 --> 00:53:07,159
world, with you know, things
like actions that they were that were launched,

741
00:53:07,159 --> 00:53:10,960
and that was compelling for like the
p one hundred of enterprises that wanted

742
00:53:12,000 --> 00:53:14,039
to go and innovative. That layer
weren't kind of like what we were talking

743
00:53:14,039 --> 00:53:15,840
about top of Adnamo right where it
actually matters and you need to go and

744
00:53:15,880 --> 00:53:21,760
do this, you know, build
these specific release capabilities in your application.

745
00:53:22,079 --> 00:53:23,239
But the bulk of people were coming
to us and they're saying, hey,

746
00:53:23,239 --> 00:53:27,119
make this, make this really easy. Make it easier for me to release

747
00:53:27,159 --> 00:53:30,760
safely like Amazon does, but for
my enterprise without me having to staff an

748
00:53:30,760 --> 00:53:35,519
internal team of eight people, you
know, to build this layer on top

749
00:53:35,559 --> 00:53:37,360
of you know, say cook pipeline
or whatever the tool you know, Jenkins,

750
00:53:37,360 --> 00:53:42,079
whatever the tools that they're using.
I heard that repeatedly from every every

751
00:53:42,800 --> 00:53:45,559
enterprise that we talked to, and
you can think about what we're doing in

752
00:53:45,559 --> 00:53:49,199
some ways this kind of analog in
in the you know, the the database

753
00:53:49,239 --> 00:53:52,199
that are different. I like it
you drove barrel between you know, code,

754
00:53:52,199 --> 00:53:55,320
Pipeline and Jenkins, because you know
those are at the same level for

755
00:53:55,440 --> 00:53:59,159
me, they're different for sure.
But yeah, we could go down a

756
00:53:59,159 --> 00:54:00,559
whole rabbit hole there for sure.
But I would say, like the common

757
00:54:00,559 --> 00:54:02,840
thing is, you know, when
I was when I was leaving the infrastructure

758
00:54:02,880 --> 00:54:07,400
group at Riot, you know,
we had innovated a lot on top of

759
00:54:07,480 --> 00:54:12,639
Jenkins for reasons, and you know, so I guess the parallel is that,

760
00:54:12,880 --> 00:54:16,039
you know, those lower level,
less opinionated offerings that are very powerful,

761
00:54:16,159 --> 00:54:21,719
but in practice you end up needing
to staff you know, a group,

762
00:54:21,880 --> 00:54:23,840
a team or a group of people
to think about how to take that

763
00:54:23,880 --> 00:54:28,159
and apply it to your specific domain. And you end up building these layers

764
00:54:28,760 --> 00:54:32,400
you know, on top or in
your application to handle you know, to

765
00:54:32,719 --> 00:54:36,960
take that and integrate it into your
use case. That's the common I guess

766
00:54:37,000 --> 00:54:39,320
the common thread I was trying to
try to I'm totally with you there.

767
00:54:39,320 --> 00:54:45,719
Actually it was my job at a
previous instance to actually migrate the organization to

768
00:54:45,840 --> 00:54:52,119
you start using get and along with
that was turn off Jenkins and actually start

769
00:54:52,199 --> 00:54:54,800
using I get lab at the time, and there was a whole number of

770
00:54:54,920 --> 00:54:58,880
challenges with that, but for sure, no one was going to do that

771
00:54:58,960 --> 00:55:05,960
work if it requires building on top
of the equivalent of Code Pipeline, Yeah,

772
00:55:06,000 --> 00:55:09,000
for sure. I mean, also
in fairness, I think we Amazon

773
00:55:09,000 --> 00:55:13,400
it's interesting, you know, internally, I think Amazon spends more time thinking

774
00:55:13,400 --> 00:55:16,239
about things like release safety than any
any company on the planet. I feel

775
00:55:16,239 --> 00:55:22,199
fairly confidence saying that. And you
know, Code Pipeline has interesting capabilities inspired

776
00:55:22,199 --> 00:55:27,679
by that internal learning that I think
made it the best offering. If you

777
00:55:27,679 --> 00:55:31,079
were a large enterprise with unique release
requirements, meaning you need to release across

778
00:55:31,119 --> 00:55:37,159
regions, and you know, you
need to think about let's say four plus

779
00:55:37,239 --> 00:55:40,159
nines of availability, et cetera.
You know, I think we had optimized

780
00:55:40,159 --> 00:55:45,920
in some ways for those sets of
capabilities, more so than just like you

781
00:55:45,920 --> 00:55:50,719
know, it's the typical developer that's
using GitHub actions. For example, it's

782
00:55:50,760 --> 00:55:55,679
totally fine to spin up containers to
run you know, release pipelines that actually

783
00:55:55,719 --> 00:56:01,320
have no knowledge of other executions in
the pipeline because they're only releasing once at

784
00:56:01,360 --> 00:56:04,320
a time and maybe once a day, you know, or whatever. It's

785
00:56:04,320 --> 00:56:07,119
not there's not this complex sequencing.
So we were thinking about those kinds of

786
00:56:07,199 --> 00:56:12,239
use cases, you know that that
are super interesting but more relevant to the

787
00:56:12,280 --> 00:56:17,079
p one hundred of of you know, release automation, and again getting back

788
00:56:17,079 --> 00:56:21,079
to the kind of no free lunch
theme, you make trade offs to do

789
00:56:21,079 --> 00:56:23,039
that, and ease of use is
one of the babies that could sacrifice sometimes

790
00:56:22,880 --> 00:56:25,920
as part of as part of those
trade offs. No, I think I

791
00:56:25,960 --> 00:56:34,360
think you're absolutely right there. I
think that highlights one of the one of

792
00:56:34,400 --> 00:56:37,320
the needed or one of the neees
of using managed providers. Like as a

793
00:56:37,320 --> 00:56:44,280
managed provider, you know, I'm
looking not just for management of the infrastructure,

794
00:56:44,320 --> 00:56:49,400
but also like some guidance on how
to effectively use the product. Mm

795
00:56:49,480 --> 00:56:54,320
hmm, yep, yeah, I
mean, yeah, No, I agree.

796
00:56:54,400 --> 00:57:00,599
I mean I think the there's sort
of tiers to what you mean and

797
00:57:00,679 --> 00:57:01,920
managed I mean, this is true
of serverlists too, right, Like people

798
00:57:02,000 --> 00:57:07,239
use the term serverlists that I've described
just about everything todays it's become a little

799
00:57:07,239 --> 00:57:12,039
bit whitewashed. Yeah, you know, you know, we say all the

800
00:57:12,039 --> 00:57:15,400
time that we see APIs as kind
of the highest possible layer of serverleists because

801
00:57:15,440 --> 00:57:21,800
literally, you know, your its
request response, specified input output, and

802
00:57:21,800 --> 00:57:23,599
you're not you know, thinking about
any of those lower level concerns. But

803
00:57:23,599 --> 00:57:27,599
you're getting to is interesting point well, which is you can even go higher

804
00:57:27,639 --> 00:57:30,039
than that, which is, you
know, thinking about things like documentation,

805
00:57:30,239 --> 00:57:34,559
instruction and learning and all those things
as sort of part of that core offering

806
00:57:34,639 --> 00:57:36,920
as well. To take the abstraction
if even hire, which I think is

807
00:57:36,960 --> 00:57:40,400
a good point. Yeah, to
use the I think I used this quote

808
00:57:40,440 --> 00:57:45,760
in last week's episode too, from
Jurassic Park. You spend so much time

809
00:57:45,800 --> 00:57:47,800
thinking about if you could, You
never stop to think if you should.

810
00:57:47,800 --> 00:57:53,000
And I think that's one of the
opportunities managed providers have is to to answer

811
00:57:53,039 --> 00:57:58,079
that or provide some insight into whether
or not you should be taking this approach.

812
00:57:58,960 --> 00:58:01,119
Yeahhen you said Jurassic I'm a disappointment, he said, Jurassic Park.

813
00:58:01,119 --> 00:58:04,320
I thought you were going to go
Samuel L. Jackson and say hold on

814
00:58:04,360 --> 00:58:12,320
to your butts. Are rebooting the
servers, right, Yeah, I mean

815
00:58:13,760 --> 00:58:15,920
there's there's a limited number of Samuel
L. Jackson quotes you can use on

816
00:58:15,960 --> 00:58:24,639
the podcast. I'm a big fan
of all of them, but there's a

817
00:58:24,840 --> 00:58:34,119
of them. Uh, where are
we asso there? Yeah, well,

818
00:58:34,400 --> 00:58:37,559
you know we're coming up on an
hour here, So how about a quick

819
00:58:37,599 --> 00:58:46,639
summary on who's the who the ideal
user of fauna is and what they can

820
00:58:46,719 --> 00:58:52,400
expect by trying out the service.
Yeah, I mean, you know,

821
00:58:52,480 --> 00:58:58,719
really i'd say the ideal, h
you know, fauna user is someone who's

822
00:58:58,760 --> 00:59:02,239
building modern Apple locations that store operational
data, right. I think that's a

823
00:59:02,280 --> 00:59:07,599
pretty that's pretty general. I mean
we see there are certainly specific verticals where

824
00:59:07,599 --> 00:59:10,000
we see you know, more adoptions
if you talk about those, but you

825
00:59:10,000 --> 00:59:15,519
know, it's a pretty generally applicable
product for you know, these these different

826
00:59:15,599 --> 00:59:21,639
transactional workloads. You know, particularly
if you if you you know, applications

827
00:59:21,639 --> 00:59:30,239
that have very high performance requirements,
responsive applications, et cetera, applications that

828
00:59:30,360 --> 00:59:36,519
have high availability and security requirements.
You know, where because we manage things

829
00:59:36,559 --> 00:59:39,039
for you, you know, typically
we're going to be more available than if

830
00:59:39,039 --> 00:59:43,519
you go and try to manage your
own database. I think those are a

831
00:59:43,519 --> 00:59:47,039
few areas where where we really shine, right And when you say high performance,

832
00:59:47,039 --> 00:59:52,000
you're talking like Nasdaq level high performance. Would you go that high?

833
00:59:52,079 --> 00:59:54,320
Yeah? I mean we have we
have folks that have built you know,

834
00:59:54,400 --> 01:00:00,639
different financial kind of you know,
like cryptocurrency for example. We have folks

835
01:00:00,639 --> 01:00:06,320
that have built like trading applications,
uh, you know, streaming streaming data

836
01:00:06,400 --> 01:00:12,400
using our events streaming. But again
the main focus there is that because the

837
01:00:12,440 --> 01:00:15,519
way that we do multi regional application
and the way that we have that data

838
01:00:15,559 --> 01:00:19,800
there, and even the optimizations we've
done at the routing layer, you know,

839
01:00:19,840 --> 01:00:22,960
we can just get you to that
data very quickly to do things,

840
01:00:22,960 --> 01:00:25,880
to make decisions based on that data, or to render that data. So

841
01:00:27,199 --> 01:00:30,880
yeah, you know latency sensitive applications. I mean well, from the from

842
01:00:30,920 --> 01:00:35,039
the knowledge that I have about this, a lot of the order books are

843
01:00:35,199 --> 01:00:39,159
usually tried to be saved in memory
anyway, so you persisting them to a

844
01:00:39,199 --> 01:00:42,440
database. I mean, you could
pick anything. It seems like Fana would

845
01:00:42,480 --> 01:00:45,199
be just as good a choice as
anything else, whatever makes sense for the

846
01:00:45,480 --> 01:00:51,960
actual application. I got you right
on cool. Well, before we move

847
01:00:52,000 --> 01:00:54,719
on to picks, Tyson. People
want to learn more about you, interact

848
01:00:54,719 --> 01:00:58,119
with you, find out more about
Fauna. What's the best way for them

849
01:00:58,119 --> 01:01:00,559
to do that? Yeah, for
fun, I mean funa dot com.

850
01:01:00,679 --> 01:01:04,719
You know, reach out to us, interact with us on social media,

851
01:01:04,960 --> 01:01:08,679
email, drop me line whatever.
I guess I'm less interesting, but I'm

852
01:01:08,679 --> 01:01:14,559
around occasionally. That mostly works.
I'm not much of a social media guy,

853
01:01:15,800 --> 01:01:19,400
but but yeah, I'm I'm around
on the platform, so it feel

854
01:01:19,440 --> 01:01:22,039
free to drop me a line.
All right, awesome, let's do some

855
01:01:22,119 --> 01:01:27,559
picks, Warren, I want to
kick us off. He always likes picking

856
01:01:27,599 --> 01:01:32,559
on me to go first. So
that's that's really why he needed another host

857
01:01:32,639 --> 01:01:38,800
in here, so that start the
time. Yeah. Yeah, So mine's

858
01:01:38,800 --> 01:01:43,400
going to be something for my personal
life. I know that as a DevOps

859
01:01:43,440 --> 01:01:49,079
advocate, optimization uh is such a
huge part of what we do, and

860
01:01:49,519 --> 01:01:53,159
especially automation as well, but optimization
primarily, and so this is about picking

861
01:01:53,199 --> 01:01:59,199
socks. I have to say that
if you're someone that loses some socks every

862
01:01:59,199 --> 01:02:04,639
once in a while to the washing
machine or dryer monster, just when the

863
01:02:04,639 --> 01:02:07,400
next time you're out and you need
some more socks, just get like twenty

864
01:02:07,440 --> 01:02:10,159
pairs of whatever it is. You'll
never have to think about it again.

865
01:02:10,239 --> 01:02:14,159
And when you lose one of them, you won't even know and it won't

866
01:02:14,159 --> 01:02:16,840
even matter. From that, get
a whole doesn't matter, just throw it

867
01:02:16,840 --> 01:02:22,840
away. So especially favorite socks,
I gotta say just absolutely fantastic. Has

868
01:02:22,920 --> 01:02:29,079
changed my life right on. It's
a great pretty socks for and I'm like

869
01:02:29,199 --> 01:02:31,800
order the same kind and bulk from
Amazon, and every time they start getting

870
01:02:31,800 --> 01:02:37,519
a little chevy and chuck them out
and go Yeah, that's that's definitely the

871
01:02:37,559 --> 01:02:38,840
thing to do. I tried doing
it with shoes one time. That was

872
01:02:38,880 --> 01:02:43,880
a mistake. I would not recommend
buy any more than one of the same

873
01:02:43,960 --> 01:02:47,719
kind of shoe. But they also
deteriorate over time. So if you really

874
01:02:47,760 --> 01:02:51,760
do like something you've got and you
know it's gonna get worn out in the

875
01:02:51,800 --> 01:02:57,840
future, get it. Get multiple
extra pairs, right on fair advice,

876
01:02:58,880 --> 01:03:01,239
Tyson, What you got for a
pick? Well, I'm gonna, I'm

877
01:03:01,320 --> 01:03:05,039
I'm so, I'm told I can
go pretty broad here. I'm gonna yeah,

878
01:03:05,079 --> 01:03:08,239
for sure, this is a bit
out there. But I'm a wine

879
01:03:08,320 --> 01:03:14,159
guy. My my biggest hobby when
I'm not not not making software, we

880
01:03:14,199 --> 01:03:17,679
actually make make a bit of wine. I love. There's something I think

881
01:03:17,800 --> 01:03:22,760
very rewarding when your day job is
thinking about software and something that's intangible from

882
01:03:22,760 --> 01:03:24,519
like pretty much of work in and
making something that you know you pour into

883
01:03:24,519 --> 01:03:29,239
a glass and and enjoy at the
end of the day. So, uh,

884
01:03:29,800 --> 01:03:30,400
my pick, I'm gonna give a
shout out. I live in the

885
01:03:30,440 --> 01:03:35,760
state of Washington. There's some pretty
amazing wine being made up here, and

886
01:03:35,840 --> 01:03:37,320
so if you want to try some
good Washington wine. I'll give a shout

887
01:03:37,320 --> 01:03:42,239
out to a friend of mine who
mixed wine at a winery called the Bapiano

888
01:03:42,360 --> 01:03:45,360
Silver in Walla. Walla does a
great cave and a great Sara. So

889
01:03:45,400 --> 01:03:49,960
if you're looking for to experiment with
some really good Washington wine, you can

890
01:03:50,000 --> 01:03:55,599
go in and uh and check them
out right on. Awesome cool for me,

891
01:03:57,960 --> 01:04:00,280
my pick I. I live on
the the edge of the country,

892
01:04:00,280 --> 01:04:04,239
and so I go for long runs
out in the countryside pretty often, and

893
01:04:05,039 --> 01:04:10,639
there's a lot of people who have
dogs out there and no fences and no

894
01:04:10,800 --> 01:04:14,320
leashes, and most of the time
the dogs are cool, but occasionally you

895
01:04:14,360 --> 01:04:18,440
get some dogs that are pretty territorial. And so I recently picked up the

896
01:04:19,000 --> 01:04:27,039
Viper Tech heavy duty stun gun,
and the thing is just so cool because

897
01:04:27,079 --> 01:04:30,199
you know, like I'm going to
try to avoid, you know, becoming

898
01:04:30,280 --> 01:04:33,880
the target of the dog's aggression.
And if a dog does come after me,

899
01:04:33,920 --> 01:04:35,760
I don't want to hurt it,
but you know, at the same

900
01:04:35,760 --> 01:04:39,599
time, I don't want to get
hurt either, And so I did a

901
01:04:39,599 --> 01:04:43,639
lot of research and a few people
suggested stun guns, you know, a

902
01:04:43,679 --> 01:04:47,159
taser number one, because you can
just click it and the noise is enough

903
01:04:47,159 --> 01:04:51,199
to deter most dogs, but then
if it escalates, you know, you've

904
01:04:51,199 --> 01:04:55,639
got the ability to tase them as
well. And so yeah, I picked

905
01:04:55,719 --> 01:05:00,679
up the Viper Tech, just ordered
it on Amazon and it's it's pretty cool.

906
01:05:00,280 --> 01:05:03,000
I haven't actually used it yet,
haven't had to use it yet other

907
01:05:03,079 --> 01:05:06,440
than just you know, seeing a
few dogs and sure enough, you know,

908
01:05:06,480 --> 01:05:09,719
you click it and they're like,
ah, yeah, okay, we're

909
01:05:09,719 --> 01:05:16,280
done. So how heavy is it? It's super light, Like carrying it

910
01:05:16,280 --> 01:05:21,519
in my hand doesn't doesn't even register. Got it cool? So yeah,

911
01:05:21,519 --> 01:05:25,519
I was worried about that, you
know, worried about carrying it and having

912
01:05:25,559 --> 01:05:30,559
it just become cumbersome. But it
hasn't been by any means. So there

913
01:05:30,559 --> 01:05:35,559
you go. Got socks, wine
and a stun gun from today's episode.

914
01:05:35,679 --> 01:05:44,920
What could go wrong? All these
things together? Right? Awesome? Well,

915
01:05:45,039 --> 01:05:48,280
Tyson, thanks for joining us.
It's been super insightful and pretty entertaining,

916
01:05:48,320 --> 01:05:51,119
so appreciate it. Yeah, it
was my pleasure. Thank you for

917
01:05:51,119 --> 01:05:55,440
having me. Uh yeah, it's
love fun, cool right on burn.

918
01:05:55,480 --> 01:05:59,119
Thanks for joining me once again.
Thanks for holding up the co host role

919
01:05:59,159 --> 01:06:02,719
and showing up. Appreciate it and
to all the listeners, Thank y'all for

920
01:06:02,760 --> 01:06:09,000
listening, and we will see y'all
next week MHM.