WEBVTT

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.