What's up, y'all? This is the Adventures in DeVos podcast. I'm your
host, well Button, and I have the co host with the most Warren
Parade. What's up? Worn? Hey? I liked how you had to
look to the side to remember your name before, right, It's so focused
on remember and all the other stuff I have to do for the intro that,
like my own name is like, no, brain's got no room for
that. Yeah, I'm warning. I'm the CTO authoress. You know,
I had to be careful when I'm talking in conferences because I'll often look at
my computer even if I have no reason to do that, and like,
I know what the words are that I have to say, but it's just
so distracting to have something else there at the same time, for sure.
All right, Joining us today in the studio Tyson Trautman, VP of Engineering
over at Fauna, former GM from AWS, Code Pipeline and Code Deploy,
Senior engineering manager at Riot Games and so on and so forth. What's going
on, Tyson? Hey, good morning, Super excited to be here,
dude, I'm excited to have you here. It's kind of we've had a
theme going recently, not planned or intentional but it definitely has turned into a
theme where we've been talking in the last couple episodes about databases, and so
you're going to talk with us today about the bottlenecks and challenges that developers have
with databases. And one of the common things we've talked about in the last
few episodes is how there used to be this career path called a DBA or
database administrator, and that just seems to have mostly disappeared. So give us
a little bit about your background and your thoughts on the state of the database
today. Yeah, for sure. I mean I'll say, like you know,
DBAs are certainly still out there. They're still feeling a very important function
at a lot of different companies, including you know, back when I was
leading the Infrastructure Platform group at Riot Games, you know, we were kind
of a sequel shop had you know, a lot of DBAs as part of
kind of the broader group just managing our database instances. But definitely a trend
that's changing, for sure. You know, even like when I at that
time at Riot, we were thinking very much about you know, moving towards
automation using things like declarative schema and some of the you know, things that
I think we'll talk about here and bringing continuous delivery to the database. You
know, that kind of remove that need for a specific individual that's like,
you know, laser focused on the database, you know, running scripts manually
on a specific database instance, like those types of things. You know,
it kind of gets into this moving towards this uh you know, cattle not
pets kind of mantra. You know, that's kind of more been more commonplace
in other areas of software engineering, for sure. Yeah, because like when
it comes to the world of pets, like databases worthy most prized pet for
a long time, still still are a lot of places. Yeah, yeah,
speak because since we're live by the way, mine may you know,
come bursting through the door at any means excellent literal pets, not the database
pets, right on, right on. That works. Yeah. So you
know, I think that whole trend towards automation has has made it a lot
easier to interact with the database, especially you know, I know that o
rms are very contested and hotly debated, but I gotta admit, like having
something that generates roll forward and roll back statements for my database is kind of
nice, even if I don't get the opportunity to specifically tune and test that
query. Like for the most part, it tends to do the right thing
in most cases for me. Yeah, it depends. I mean, so
there's no question that if you want to bring the best practices of continuous livery
to the database, you know there's a few specific things the pieces that you're
going to need. And we've been thinking, you know, spending a lot
of time thinking about this and kind of how it applies to to fauna specifically,
but more generally, like you know, uh, one of the you
know, what you're trying to do in the database when you know to apply
these practices of continuous delivery. And first of all, when you make schema
changes, you have to be able to validate those schema changes against your existing
data against services that call the database. And then you have to be able
to replicate the transition process to make sure there's no issues get from A to
B. And then and you have to be able to do those things in
all of your different in different environments, right ranging from kind of local development
all the way to production. And so you know, will the capabilities you
were just talking about, which is you know, some kind of mechanism to
go and programmatically apply schema changes is absolutely a critical requirement. There are others
as well. We could get into that, but for sure, you know,
whether it's whether you're manually issuing querries you know, through an RM to
do things like manipulate data maybe you know, potentially manipulate schema, or whether
you're using something like uh, you know, in fauna terms. What we've
recently launched is are what we call the fun of schema language, which is
a declarative language for defining schema and getting to a known state, you know,
declare I'll say, I'll put in a little plug. Declarative is typically
where it's at for these types of applications, because you know, there are
a lot of ways when you're imperatively describing sort of infrastructure that you can get
yourself in trouble or you can get into, you know, kind of a
these little edge cases, and so there are some issues that you can run
into there. But that's just just a little little plug. Yeah, And
so just to clarify thereby declarative, you mean you're just saying this is what
I want the end state to be, Like, I don't really really care
about what happens in between, as long as it ends up like this,
that's right exactly. I want you know, I want these database all these
fontorms, but I want these databases, these collections with this field level schema
and then you know, even getting into more exotic concepts like we support the
notion of like user defined functions and check constraints and you know, all these
other kind of cool things that you can you know that we can get into.
But but yeah, the entire the ability to define that whole data model,
the schema for that data model, and know that you're going to get
into that state, you know, without necessarily having to describe like here are
fifty different transformation stuffs I'm going to run and I hope that it all works
out given the data in the database, and you know, to get to
get into that state for sure, yeah, or learning the specific syntax or
whatever variant of SQL your database platform happens to be using and hoping that it
either does it correctly or errors out not something in between, right, Yeah,
yeah, for sure. Cool. So so it sounds like we're funny.
You're setting the stage for people to to move because I feel like there
was this trend about a decade or so ago where we put all of the
business logic in the code, like your your constraints and your your validations and
things like that. Whenever prior to that, you know, that was the
role of the DBA, and databases have really powerful tools for managing that type
of stuff quickly and efficiently. But it sounds like you're giving that control back
to the database, but in a way that makes it easier for developers to
leverage the things that databases do. Well. Yeah, that's I think that's
a fair assessment for sure. I mean, we try it to be too
prescriptive, like we want to meet developers where they are, right, you
know, I think, but certainly bringing those capabilities to the database so that
if you want, you know, you can put some of that logic with
your data. You know, there are very powerful benefits that come with that
too, right, Like so for example, you know, for modern kind
of responsive applications, performance is a huge deal. So the you know,
the ability to go and run a bunch of compute over your data, you
know, on the database is potentially a game changer for performance performance standpoint versus
like you know, doing a whole bunch of run trips around trips and running
that compute on the client, right, So for sure, yeah, having
that that those capabilities available, and then also you know another thing with being
able to run that compute as part of a transaction on the database. It's
even the next level, uh kind of benefit once you get into these real
operational use cases. Right. So for sure, having those capabilities there so
that folks can reach for them, you know, if they want them when
their application calls for it is absolutely something that we're focused on. And so
I think a lot of that is there's probably a pretty large educational component to
that because unless you have experience or a lot of background expertise in database servers,
these are all things that you potentially didn't know database servers were capable of
doing. So how has that shaped how you how you approach this problem?
Yeah, yeah, I mean in some ways, so what you said is
true, although in some ways, you know, there's the kind of you
know, everything old is new again, right, you know, people sort
procedures since the beginning of time, you know, and I think there are
different kinds of ebbs and flows in terms of you know, uh, the
kind of hot application architecture of the day, and you know some of the
sometimes these trends you look back and you say, hey, we did we
didn't have it so wrong with some of these things that were going on previously.
But but for sure, I mean, yeah, you're you know.
Uh. One of the things that's been interesting about my journey upon a for
sure is you know, you you can build a really amazing product, and
you know, as a consumer, I feel that, you know, using
the product, there's no question that database we're building is the database I would
use if I left to start a company tomorrow. But you still have to
tell that story to the market and help people understand what's compelling about it.
And you know, this cool stuff that we're doing, you know, you're
doing kind of in a vacuum, doesn't matter. What matters is how it
maps to actual requirements of software developers and moves the needle makes them more productive,
their life easier, mixed the applications that they're building, you know,
more secure, more available, more performant. And so yeah, there's a
big educational component. I mean a lot of that is in docs. You
know, I think when you're building these types of apps, the quality of
your docks is a huge deal. Examples. All of those types of things
are you know, big, big area of investment, no question. I
feel like you said something super controversial. So and I don't know if I
want to let you jump over that. What what? What is? What?
What is old is new again? I feel like there's a whole swath
of engineers out there at orgs and companies who would swear by the stored procedures
have always been wrong and will always be wrong into the future. I'm curious,
like there's no I don't think there's a particularly right answer here, but
maybe there's like some sort of spectrum and this is what belongs in at the
database layer, and this is what belongs more at the domain or business logic
outside in your application. Any thoughts like where is that line that actually needs
to be drawn? Yeah, I mean it's a great point. I think
the I try to stay away from some of the kind of more you know,
Zelody kind of religious debates like that again, you know, to me,
I think, you know, Warren, it really comes down to like
the use case and what you're trying to do with the requirements your application.
Are sure, but you know, and we could get into some kind of
specific examples there. But I think one of the problems with store procedures in
the past is it was this entirely separate code, you know, application code
that sat kind of outside your app, so and it was it had a
separate life cycle from your application. There was no you know, kind of
it single life cycle in terms of like continuous delivery and how you get that
application and production and to think about things like versioning between client and server,
and so a big part of what we've been focused on, you know,
with our recent launches with on a schema languageeste is solving that problem by putting
that logic together. So you know, the typical pattern when you're using FSL
to describe you know, your data is that code lives in your repo with
your application code. It's version together. You know, that's what we do
internally. We take a heavy dependency on fauna. We eat our own dog
food, drink our own champagne. You know, however you want to put
it, and that's you know, that's certainly kind of the best practice that
we follow as well. Everything right together. So I think, you know,
part of the answer is it depends on the application and the specific requirements
of the application. But another part of it is the problems that people had
at that point in time can be solved through better products and better tooling around
those products as well. No, I'm totally with you, Like I remember
on non trivial number of times, writing some giant framework to manage getting storage
procedures written in your get repository into ms sql at the time and making sure
they were executing the right order, intertwined with whatever schema changes you also had.
And then there's no way to really live validate that without running it for
real and making sure that it hits some arbitrary query plan so that it's optimized,
or even that it's using real fields like dive in like a couple types
just aren't there in most databases when you think about it. Yeah, for
sure, you nailed it. And that's why I mean to me, what
good looks like here is you know again, you need the you need the
you need the declarative tools that where you can in any environment. You know,
so in funt of terms, you can spin up in UH an instance
of fauna locally in in our Docker container and you can use FSL to apply
schema there. So you can use this for even like local integration testing.
But so you have the ability to apply declarative schema it works in any environment.
And then you have you know, tools to load data as well,
because like we mentioned earlier, you need to validate schema changes against existing data.
And we do that through you know, we have uh two kind of
two mechanisms there back up and restore, backup and copy tool in the live
environment, and then we also have a data import tool where you can sort
of play arbitrary data to load that into a database. But then you know,
you start wiring this thing up in automation as part of your CD pipeline,
and all of a sudden, these tests are running locally again against the
doctor container or something, or against the live service if you prefer, you
know, in your integration environments where you're seeing actual consuming services in you know,
under potentially real world load, you know, with those schema changes with
the new version of your your UDF or your store procedure as that's going to
production. And then you know you can even safely apply those changes using that
same tooling all the way out in production again, which is what we do.
So super powerful concepts. So I'm going to ask a really dumb question
and hope that the listeners of the podcast who might actually have the same question
can appreciate the fact that I'm taking one for the team here is is Fauna
its own database engine or is it something that sits on top of other database
engines. It's its own database engine. It is a it's a net new
novel database that was built, you know, effectively kind of from the ground
up. It was deeply inspired by There's an interesting research paper that came out
of Yale years ago by Danie Labodi who's an advisor at Fauna and a few
others. That was kind of an interesting spin on how to do how to
run distributed transactions in a very different model than like the typical kind of two
phase commit model that Spanner and other like truly distributed databases use. So that's
kind of at the heart of Fauna. That's what we call it distributed transaction
engine. You know, it's a big component of Fauna. It handles multi
region replication with the strongest possible level of consistency guarantee. So that's kind of
a secret sauce, you know, in the core the guts of the product.
Again, we don't like, you know, sort of abstract nerdery.
We like to tie back to real world application requirements. But the reason that
matters is, you know, number one, people want multi regional application for
performance. If I can do fast reads from the local region, that's a
really big deal for a lot of modern applications. Right. It's also the
best possible dr story if you literally have multiple regions running in an active active
configuration. You know, we see examples where our good friend USC one is
having issues and you know, and so just keep cruising, cruising right along.
But then you know, doing all that with strong consistency is really the
huge deal because as developers, I mean, you know, it's very expensive
to reason about these different edge cases that you can hit in your application code,
right, And to me, that's a bit like people talk about,
oh, you know we have a strong ish level of consistency garantee. Well
I'll either have to reason about these funky edge cases that I can get into
or I don't write. Yeah, and with with Wanta, you don't.
So that's kind of the the guts of it when you talk database engine.
That's kind of the the some of the secret sauce innovation that we've been focused
on. That's cool. So what almost sounds like rethinking the database based on
considerations that are relevant now but weren't whenever most of our common data base platforms
were created. Yeah, I mean, I think for sure the considerations that
weren't relevant when folks were running you know, you know single ins or single
instance uh you know postcress instances or you know primary secondary type configurations that are
really still there, you know, with you know, with some of the
bigger players that folks are are using today. You know, for some apps,
that's fine, that's you know, for some there's some applications where you
know you're not going to hit this insane scale where you're gonna suddenly have to
start thinking about partitioning. And then you got to start thinking about, oh,
well, I was using Postgress because of the strong transaction support, but
now I can't do post you know, or a cross partition transactions. How
do I solve that? And you know, there's a ton of interesting innovation
there I don't want to put you know, they're like very cool tools for
specific kinds of jobs, but you know, for applications where scale and potentially
multi region replication or a strong requirement right out the gate, I think Fauna
is is you know, in pretty unique air up there with a few other
offerings that are really kind of ground up, Like let's think about how to
do distributed transactions, you know, in a in a first class way.
That's a hard thing that just you can't just take that and bolt it on.
You brought up documentation before, and I feel like there's a direct link
here. Actually something on my mind a lot is I feel like Authors has
done something similar in the security domain, and the novel aspects that we've added
to hopefully remove the confusion from users sometimes get in their own way, like
they have expectations that a database requires a commit uh transaction step, that replicating
across regions with some sort of replication agent like is there by design, and
some of the more experienced engineers get caught up with expecting those things to be
in place. Do you see that a similar problem exists for Anna? You
know, I don't. I think people are usually if you build it,
I think we've built it in a way that feels pretty intuitive because with Fauna,
you know, so with traditional databases, you know, whether that's let's
say a SEQL based database or that's something like Mango, you know, you're
you're, you're your transaction model is kind of tightly coupled to the session,
right, and so that's to your point more and that's like what you're the
mental models, what you're used to. You have to do things like session
managment management, et cetera. With Fauna, you're just sending us for a
SHPE requests. Basically, an AHPE request essentially contain some code that you run
as part of a transaction. And so I guess my experience there in this
particular domain, it so sounds a little bit different, is uh. It's
the way we've implemented is pretty intuitive. So folks get there and they're like,
hey, this is cool. I don't have to you know, I
don't I don't have to think about these things like session management. I don't
have to think about is this code running in the context of a transaction?
When do I, you know, commit the effectively commit that transaction. It's
just I'm sending a transaction, I'm getting a response back, and I can
do that in the shape that my application expects it, and that feels pretty
intuitive. That's I think has been my experience while watching folks when they first
pick up the product. No. The reason I asked is because there was
a a lifetime ago there was an instance where I was working with an engineer
on GCP's Firebase, and there's a bunch of promises that firebase makes with instantaneous
commits, none have to worry about concurrence or anything like that. And it's
that that really felt counterintuitive that these databases that are on opposite sides of the
world won't have any sort of race condition. And I guess that's not.
Like the way you've designed fauna is much more seamless than that that it makes
it obvious when there is going to be potentially a problem, uh, and
when there's not and no one has to worry about anything. Yeah, I
mean to be clear, like there's no free lunch of engineering, right,
so we try to promise something that doesn't you know, and the trade off
that you're making, uh, you know, when you're doing things like effectively
running this type of active active configuration where you have multi regioner application with strong
consistency, like you can't cheat the speed of light, so there, you
know, there are performance trade offs to that, you know. There what
we've done is try to optimize to that frontier of what's possible so that you're
pushing you know, if you're if you're doing rights through the transaction pipeline in
the US and in fauna, you know, you're talking mid double digit milliseconds
right of replication time and reads can be served from the local regions so very
fast like low single single digit milliseconds, And in practice, that trade off
is very attractive for most applications, especially when you can avoid these like multi
round trip like multi transaction scenarios where you have application code running on a client
like it's it's it's not you know but there, But I just want to
be clear, like there's always going to be you mentioned the fire store case
not you know for sure, if you if you're if if for whatever reason,
you think your your application is fine with eventual consistency, that's a different
model and you can achieve a different performance profile. You know, you know
where where warranted. I'd say buyer beware because a lot of times you think
your application is okay, you know, eventual consistency is an acceptable model for
your app, and then you end up planning out it's not so. But
yeah, just want to be I want to be honest. There no it
makes a lot of sense really. So you said that interacting with Fauna is
HTTP a p I Is that right? That's right? Yeah, Yeah,
it's done a lot of interesting where I don't know if we want to go
there, but we've done a lot of there's a lot of innovation in FAUNA
kind of in how we route to the database as well, which has been
a super interesting set of challenges. You know, typically like most kind of
an afterthought for a lot of database providers, but thinking about you know,
the point, because we're so performance focused, thinking about that trip from the
application to the database as well as something that we've focused on on quite a
bit, right, Yeah, that makes sense because using that pattern has you
you end up getting a lot of being able to take advantage of a lot
of work that other people are doing in that same space instead of reinventing that
work. Yeah. Absolutely, for sure. Backing on top of each GDP
is so much easier than TCP backets quick or even if you're going to implement
your own quick uh communication productol m, Yeah, no question. You know,
I actually took a look at FUNA before this. I was curious and
I'm looking at that and then I'm looking back at the cloud provider, and
I'm wondering, like, when what is it going to be that one of
the cloud providers offers me a database that actually achieves as much as these external
providers get. And you know, I just see such a huge discrepancy,
and I you know, I'm surprised that they haven't made a lot of progress
in this area. Yeah, I mean so first of all, I'll say,
like, you know, effectively all of the kind of hyper scalers are
you know, fantastic partners. You know, today we're in the AWS marketplace,
where in the GCP marketplace you know, will be an azure down the
road as well. And you know, Fauna by definition, we have we
have our what we call our public region groups called region group as we replicated
across regions by default. But you can also deploy something called virtual Private Fauna,
which is still serverless but single tenant like VM level isolation, and you
can pick your cloud providers and your footprint. So pretty cool offering for like
larger enterprises that need more isolation. But but yeah, you know, I
think the reality is like those large providers, if I take my former employer,
you know, AWS, I'm saying this is a as somebody who's no
longer with AWS, but they have very successful offerings, you know, DYNO,
dB RDS, et cetera, that are out there, and those things
have a lot of inertia and they continue to do work to make those things
better. But you know those are those are you know, multi billion dollar
businesses, you know, in and of themselves, and so it gets harder
to go and compete with a startup in the in a weird way there because
you don't have any competing interests at a startup like we're just setting out to
try to build the best possible database for modern application developers, whereas I think
at some of those you know, we've all anyone who's operating in the context
of a larger, uh, you know company. Once you have those revenue
streams, there are different kind of goals and you have to cater to that
existing audience, right. You know, Mango, which is a fantastic product
obviously has been around for a long time, been very success full, still
growing leaps and bounds. You know, they can't they can't throw out the
on prem business, right, you can't throw out the baby with the bathwater,
And so you have these kind of existing businesses that are very successful.
You know, a great thing for those those enterprises that they have to serve
and focus on. But I think to your point, I think it makes
it a little bit harder to go and build something that's kind of a generational
leap, right that's significantly better for application developers. And but you know,
in fairness, we do see that they're pretty there's a lot of hunger from
those from those companies to go and partner, and you know, they want
there to drive the best outcome for their customers and if that ends up being
you know, we have a close running conversation with the Lambda team at AWS
for example, because there's a lot of synergy between Fauna and Lambda where the
data is at the edge where you can run your Lambda functions. You don't
have to maintain sessions, which is fantastic from those kind of ephemeral environments that
can just go away. So yeah, they're good partners for us, you
know, and like I said, we're right there in their marketplace, so
you can buy us alongside the first It sounds like, you know, a
bunch of innovators dilemma, but also innovation is coming if you pick the right
providers. Yeah, yeah, for sure, absolutely that what kind of design
changes or design approaches require mental shift to take on something like fauna where you've
got you know, a server list serveralist database with your data sitting on the
edge. In terms of so when you say design shift, you mean from
the consuming application. Yeah, Like, if you're architecting an application, are
there any considerations that you are there things that you may you may make it
down the road and say, oh wow, if I'd done this, I
would have been a lot happier. Yeah, good question, just thinking you
know, the there are there are kind of these very mod and application architectures
that Fauna in a way is sort of you know, uniquely suited to serve.
But you don't have to be using one of those architectures for you know,
to take advantage of a database like you know, Fauna or some of
these other like very modern databases we have. We have plenty of customers that
are running you know, a more traditional application architecture where they have like a
single region app server you know, sitting in you know, pick a region
that's accessing fauna, and they're not necessarily taking advantage of multi region application.
Other than the fact that it's there as part of a dr story, So
they could fail over, you know, if they're they're apps in region,
but if their app was up for some reason and you know, some service
dependency brought us down in a region, that traffic could fail over and roped
to another region. But you know, I think, but, but no,
I think the answer is like, we work just fine with those types
of like you know, more traditional architectures, or if you're building if you're
some new startup that's very forward thinking, you're building something greenfield, and you
know you want to take advantage of all these new awesome offerings. Run compute
out at the edge. You know you can do that, and fauna pairs
very nicely with that with those types of architectures as well, right because we're
going to have your data there, server lists, you don't need to manage
to think about scaling, you know, managing instances, et cetera, those
types of concerns. So I think I think we've I don't think they're you
know, I can't think of any specific gotcha's or something that you should have
in mind as you adopt these kind of modern databases. I think they you
know, roll pretty well in the existing paradigm. But then as you get
towards these these newer architectures, you know, they can they can really shine.
So if someone spent the last twenty years building MS SQL and now I
shifted to RDS, there's not like it still sort of works pretty much the
same if they were to switch to FAUNA other than get all the benefits and
there's not a lot of potential pitfalls with this sort of different database engines that
are out there today, that's right. Yeah, I mean the you know,
the downside is you have to go and and you're gonna have to migrate
application, yeah for sure, and you know and your yeah, your data,
you know, I mean you may have to. I mean we have
some we have some tools that do you you can export, import data,
do some different things. I think we'll continue to get better. There hasn't
been you know, top very top of stack focus for us. We've been
kind of more focused on innovating the core product. But but yeah, for
sure, now I think if you're you know, if you bite the bullet
on that migration, there's a whole bunch of benefits that that that come with
it. For sure. I mean we you know, we have existing customers
that have come from you know, you name it. I'd say recently,
more of the focus for folks that are coming to Fauna are people who jumped
from relational databases to document databases because they believe in the document model. They're
not a fan of r ms. They don't like this document you know,
relational impedance mismatch. But then all of a sudden, you know, they're
running on Go fire Store whatever, Dynamo, Cosmos, TB, and they
missed the relational some of the relational capabilities they had with their relational database.
They don't they're not ready to go document, but they want these relational capabilities,
you know. Fun of fundamentally is what we call document relational. It's
this kind of new paradigm where we store data as documents on disc but it
has the capabilities that you typically expect from our relational database. So for example,
the ability to define first class relationships across uh, you know, documents
and and kind of uh uh you know, and access those documents the ways
that you would expect with the relational database. So yeah, so there's a
lot of excitement for those folks that see this as like, all right,
kind of the best of both worlds. I don't have to I've jumped in
the document model, but I get all these capabilities that were that were the
good part of my postgrass database. And it's not like a partially QL on
top of Dynamoe deb That's right, that's right. Yeah, yeah cool.
So one of the big challenges I think with a lot of a lot of
larger databases is you always end up in a situation where you're doing et L.
You know, it's pretty common to et al your data out for analytics.
How did y'all approach that? Yeah, We've got a few options there,
you know, Like first of all, we support so there's a Fauna
air Byte connector that some of our customers use Airbyte open source product. They
have managed offering, so you can use air Byte too, you know.
They're they're the connectors they have to you know, to pump data from Fauna
to your analytical database of choice. You know. We we also support uh
streaming, so you can stream changes to documents or sets in Fauna. So
different mental model, you know, the you know, air Byte is kind
of the more traditional, like I want to push batch updates to my analytical
database. Streaming is more commonly used for these kind of you know, responsive
apps where you want to push changes to a client or something. But we
do have some customers that for these different use cases actually want to leverage streaming
to push changes to sets too, you know, a different a different,
a different database. So those are kind of the most common patterns. I'd
say, you know, it's not there today, but we're thinking a lot
about. I felt like one of the buzzwords that reinvent this year was like
zero et L. You know, there were Amazon was approaching. It was
announcing zero et L for all this database in this database, which really,
you know, my mental model like that, you know, you're still doing
ETL. It's really I think it's more just kind of like managed et L,
these kind of uh, you know, higher level connectors between databases where
more of that is managed just behind the scenes and it just works. You
don't have to think about it, you know, you don't have to necessarily
bring in a third vendor or manage something yourself. And so that's something that
we're thinking a lot about now, is what that would look like, you
know, to create these kind of more managed ETL connections to some cloud providers.
Nothing there you know it's in product today, but something that's it's certainly
on our on our radar screen, Like we're talking about streaming to say big
quarry or red shift something like that, or to stove like for instead about
the customer needed to do anything extra, that's right, you know what if
you could just do some kind of an off handshake to that provider and you
know, maybe give us a little bit of metadata about I guess you're getting
into describing transform. So there's you know, same sets of defaults where things
just work right. Like that's I think you know this. I'll say like
Amazon went way down the path of this, like a specific database for every
possible scenario, and then quickly realize, well, that's creates a big headache
when you're thinking about moving data around. And so they have these different offerings
like blue and other things to you to move data between services. But I
think there's a lot of uh folks that aren't content with that situation. Yeah
you got you got us in this situation. Now help me move data around
more seamlessly without you know, I don't want teams of engineers that are just
doing un differentiated heavy lifting building tools to move data from a to b so
uh yeah, I think that's part of what created this problem that's now resulting
in like zero ETL. I'll say, by the way, too, like
we're more bullish on uh innovation at the database let layer that can unlock a
more general, generally suitable database. Right, so fauna, you know,
we even see people starting to push the bounds where they're issuing you know what
traditionally looks more like analytical queries on top of FAUNA. I know we're not
optimized for those use cases, but you know, I'll say, uh,
new databases like FUNA are very powerful, and I think you know, we're
getting away to some extent from that mold of like, oh, I need
seven different databases for all these specific use cases, and I have to think
about replicating data between them. I have to think about keeping data and saying,
you know, et cetera. Oh for sure. So so rather than
etaling the data at all, just build the database so that they can meet
those needs in the same platform. Yeah, yeah, yeah, depending.
I mean, you know, again, I don't want to get back to
you know, you know, use car salesman here. I'm not saying that
architectural trade offs you make you build a share that will make them more suited
for a specific set of use cases. But it's very clear that customers don't
want a whole you know, database portfolio, right, and you see this,
but other you see this going the other way too. I mean you
see, you know, Snowflake, for example, you know, launch their
uni store offering where they sort of try to bolt the transaction pipeline onto your
analytical database. You know, I haven't played with it. I've heard you
know, their performance issues, things like that, et cetera. But for
some people it's compelling. If you're right there, your primary workloads are analytical,
you need transactions for some specific use cases. You know, that can
be compelling. And so I think there are you know, we're certainly not
the only ones. There are a lot of vendors thinking about this. You
know, how do I bring more functionality potentially into into fewer offerings to make
life easier for customers. I think that's super important because at least historically with
Snowflake, I haven't looked at it recently, to be honest, getting the
data in was sort of a challenge. So offering more functionality doesn't necessarily change
that. The zero ETL connection on the actual database application side is super like
a lot really valuable. Yeah, yeah, I agree. I guess you
could say databases aren't pokemon, you don't have to collect them all. True.
I agree with I really got to get the applause to plug in working
on this because it's just awkward. I didn't. I should have brought me
my snare DROM and my crash I could have, given it's downstairs, though,
so we can't make that happen. I mean, I feel like there's
a duality there though, because the more sort of fundamental engine aspects that a
database engine offers, it has to be trading off something right, Like I
do have to pay more because the data has to be replicated very quickly to
a different format, or you pay some sort of latency on processing in order
so that it can actually figure out what the optimal execution is. Like,
we have this problem, so we primarily use dynamouod V a lot, but
we also have some graph needs and I still haven't found a good like I
love it graph database for us to sort of bet on and I'm not sure
that's something that Vaunta does, but a lot of them don't do that.
It's not an easy thing. Yeah, I mean, you're you're absolutely right.
I think the question is, you know, you there's going to be
you know, the frontier that you can get to, right in terms of
how much you can do based on the architectural decisions that you've made. For
sure, the question is can you get you know, eighty percent of the
way they're in the same database where for specific use cases it's good enough.
I mean you mentioned graphs that it's an interesting example we could dive into.
You know, faun is not neo for j right, Like, we don't
have a first class concept of edges between the sort of documents or entities in
our database. You could model that in documents and fan us, you know,
because we support this ref field type you know, where you can effectively
uh, you know, denormalize as part of a query across documents. These
relational capabilities we're talking about, you can model a lot of these graph use
cases and people do this, right, Like, we see an interesting customer
that's using kind of relationships that you would think about as more of a graph
type use case to fetch related entities to go and inject into an ll M
as part of an AI app. Right, like, you know, so
there are things you can do there, you know. Now, are we
going we made a different set of architectural decisions than NEO for J So are
we ever going to be as good for the P ninety nine P one hundred
graph use case. No, that's not our goal. But if your data
is already in fauna and if you like our capabilities as just a general purpose
operational database, and then all of a sudden you have these graph use cases,
you know, is are the requirements that P and A nine P one
hundred use case where you need to go and etl data into a purpose build
database. I don't. For some people the answer of yes, and that's
totally cool. We want to support those use cases have convenient tools available.
But for a lot of folks the answer is no. And if we have
the right set of capabilities, you know, we can we can unlock those
use cases for them, you know, without adding the management overhead of kind
of another offering. That's a really that's a really good point. And I
just want to set the records rate. We don't use we don't use Java
for ours. But uh no, I mean there there's there's some joke here
about like Yeah, for sure the Bredo curve that you can make it look
like it and I even feel like the graph database are much too slow for
the usage of graph that most people have, right Like, even if it
is relationship based, you probably can achieve a much faster results at using Fauna
than pulling out the P one hundred graph database solution and putting your data in
that it's just usually not as fast in most cases. Yep, yeah,
definitely true. So more in question over to you, what was the deciding
factors that pushed you to choosing Dynamo for your data? You know, I
feel like this comes up a lot, and primarily I think the sort of
data that we're saving is sort of relationship aspect. But we store the roles
and identities for individual users and the permissions that are associated with them, and
that lends itself a lot to a key value store. There is a relationship
aspect there, but as I said, it is sort of like this eighty
twenty principle where most of the data does not benefit from being highly relation enough.
Also, an ease of usage something that came up previously, and I
want to ask Tyson here is like when do you hire a DBA, like
for whatever you words you associated with the acronym DBA when you hire one,
like, we don't have one. I don't want to get into the business
of having to get one. I don't think it scales for us. And
so things like DynamoDB Fauna, these no SQL or PSEUDOOSEQL document stores that offer
key value aspects I feel like have a much lower complexity, a much lower
barrier to entry for application engineers than you say, trying to spin up an
RDS, which also doesn't replicate well. Dynamo offic with global tables. We
offer global solutions as a global company, and having multi regions that are active
active configurations is like a huge importance for us. Yeah, I'll say,
I mean, so there's a few interesting ways to go there. First off,
in the Dynamoe because I thought this was fun, fun question to chase
down a little bit. You know, you're absolutely right, Like Dynamo is
very a great tool for super fast kV access, predictable latency. You know,
even at several you know, several nines, you're still getting very predictable
latency. It's interesting because having been at Amazon, you know where most apps
internally now are being built on Dynamo. There's this almost religion to it where
you're saying, again, we can't build a performance enough, scalable enough general
purpose database, so we have to fall back to a tool like Dynamo.
It's effectively at the end of the day kV access and then build a lot
of complex application logic to go and support that, right because we have kind
of a lesser consistency model, you know, limited access patterns. You mentioned
global tables for multi regional application, but when you go to global tables there's
a lot of Gatcha's, I mean, they're expensive, you know, eventual
consistency again even more limited in terms of access patterns and what you can do.
And so you know, for sure, I think, you know,
Dynamo is an amazing tool for what it is for those specific use cases.
But we see a lot of interest from customers that they want that predictable kV
access which other tools like want to provide. But then you know, they
don't want to have to think about transactions in their application code. They don't
they don't want to have to think about you know, they want to support
very flexible access patterns where a lot of times you know in Dynamo even kind
of the the adopted mantra of Dynamo, things like single table design. You
know, you really have to which has been involuntarily, You really have to
understand your access patterns upfront, and so maybe you know you you you come
up with your data model and things work fine for that initial use case,
but then you go to build the next feature and you're like, oh crap,
I'm screwed. You know, it doesn'ts not gonna support this. So
there are a lot of gotchas there there. You know, I think great
service for what it is. For sure, I can say firstthand is somebody
used for an aw services like you know, they're always going to get a
lot of uplift because they're integrated with IM CloudWatch, cloud Trail, they're right
there in the ecosystem. But I do think it's worth for a lot of
folks that are just diving in, you know, taking a peek at some
of the more modern offerings that are out there, like Fauna and say,
you know, just because because not only are they going to work for that
initial use case, even if it's just KB storage providing super low latency you
know kV, but they're going to scale to those access patterns without you,
you know, requiring you to kind of understand all those access patterns up front.
So that's my little spiel. Warn't you've gone into a separate question,
which is about hiring DVAS. I don't know. We could go ahead.
I don't know about you either. I mean, you mentioned a lot of
really interesting things there. I think that what I'll say is we definitely have
a bimodal distribution where it's very easy with things like Dinamo dB for a very
simple app to get up and running without the complexity we' and then there's this
lull in the middle or you don't want to be in. And we're at
the point on the other side where we sort of fundamentally know how dynamodd works
as though it was we implemented it at the service level, because we know
where the edge cases are and we're figuring out how to get around them or
understand how partitioning even works because we're at that scale and we have tons of
application code that wraps it to make it as effective as possible. So yeah,
I mean, at the second mode at long tail, you for sure
if you're using Dynamoe to b at scale you will, you will know how
it works for real, and you will have a lot of application code to
deal with that. Yeah. Absolutely, there's no question, I mean for
sure. And then once you're in that state, you know, we talked
to a lot of companies that are there, say, we built up expertise,
we have a lot of application code around it. You know, it's
working, we have there's for sure pain. The question is like, when
does that pain get too high? You know. We talked to a company
that was a big Dynamald customer, you know, and it was taking them
like literally I think days to build you know, new gsis. They're running
in GSI limits, et cetera. And so they were like out of the
point where they were. You know, it's like, Okay, this is
literally no longer tenable. We have to explore other options because it's not working
for our use case. But that's pretty extreme, you know, And there
are a lot of companies that are in the state that you're in where Dynamo
is working great. It's a very powerful tool. They've built up internal expertise
and they've built these kind of this layer of their application on top of that.
That's necessity you know, for their specific use case. Uh, and
then may be fine, Like I'm not that's that's you know, I could
could be the right spot for them to be in, you know, I
think I guess my point was more around there's a lot of people that dive
in because they're there in the ABS ecosystem. It's a convenient tool without necessarily
understanding that they're going to have to go and do what you guys did for
which is a lot of application, you know, or a lot of investment
around the database to make it work for your specific use case. And you
may not need to do that, like if you do, there may be
kind of other more modern databases out there that handle some of that, you
know, what i'd consider to be more un differentiated. Have you lifting for
some use cases not for all use cases? On you know, on on
your behalf, So that that was more what I was was was pushing.
Yeah, I totally agree. I do want to dig into the DBA thing
though. What do you think the role of the DBA is moving forward?
Like from here moving forward? Do you think it still exists? Is there
a particular place where it makes sense? Yeah? I think I mean so
DBA has traditionally understood which is like a human, you know, thinking about
pets on a kind of a very one off basis, like thinking about database
instances like you know that that will exist, you know, for a while,
just essentially to service this these kind of legacy applications that are written on
top of you know, single instance, my SQL postgress whatever, you know,
SQL server instances that will be around again. We'll be around for a
long so there we demand for that, you know. But I think looking
forward, I think what you're going to see is, you know, software
engineers with you know, some domain expertise in terms of data and data modeling,
because that's a big field and nobody can be, uh, you know,
a software engineer with general expertise across every area. But you're gonna see
software engineers with with that kind of expertise, you know, who are helping
enterprises at scale to think about their data architecture, you know, and how
data is consumed across you know a complex soa or whatever whatever that architecture looks
like, right, But they're going to be doing it in scalable ways.
They're going to be taking advantage of things like you know, these the faunic
capabilities that are referenced earlier, where it's going to feel more like writing application
code traditionally has. They'll be using all these practices like you know what we
call schemas code more similar to infrastructure as code. You know, it'll be
bringing that cattle nut pets kind of mindset to to the database, so that
that there's going to be more and more of a need for folks in that
kind of role, which looks more like you know, software engineer with some
expertise in data and data modeling. You're integrating with the database layer than you
are figuring out how to optimize one. I mean, obviously, you know,
I think that's a great answer. I mean, the cloud providers or
the faunas of the world, right, if you want to be a DBA,
maybe that's where you go, right to these products that are offering this
primarily at scale, so that companies don't have to think about what their engineers
are going to have to know in order to put data in a database somewhere.
Oh yeah, for sure. I mean, but the people that we're
hiring, you know, like the it's actually it's hard to go and recruit
for these these roles. But you know, people folks with deep database sme
that are yeah, that are actually going to get in and think about you
know, uh, you know, improve performance of sort of the transaction pipeline,
you know, store the storage engine. Uh, for sure, I
mean those are that's a there's there's a there's a limited pool of people that
have are you know, I have spent time solving those challenges in the real
world. They're very highly sought after, and we would rather hire those people,
uh, you know, so that you don't have to think about those
kinds of hard challenges, for sure. Is the way that we think about
it, Like, we want to take as much of that sort of complexity
as as reasonably possible and solve those challenges in a common way so that you
know, more and more, I mean, our the primary goal of what
we're doing is trying to allow uh, these application development teams to go and
innovate and focus on their application and not you know, again not do this
you know, undifferentiated heavy lifting. I mean, you know, one of
the things I saw in a past life when I was a leading the code
pipeline and code deplay teams at Amazon. It was interesting because you know,
at that time we were competing, we had built an interesting offering at kind
of a lower layer than kind of the githubs and the get labs of the
world, with you know, things like actions that they were that were launched,
and that was compelling for like the p one hundred of enterprises that wanted
to go and innovative. That layer weren't kind of like what we were talking
about top of Adnamo right where it actually matters and you need to go and
do this, you know, build these specific release capabilities in your application.
But the bulk of people were coming to us and they're saying, hey,
make this, make this really easy. Make it easier for me to release
safely like Amazon does, but for my enterprise without me having to staff an
internal team of eight people, you know, to build this layer on top
of you know, say cook pipeline or whatever the tool you know, Jenkins,
whatever the tools that they're using. I heard that repeatedly from every every
enterprise that we talked to, and you can think about what we're doing in
some ways this kind of analog in in the you know, the the database
that are different. I like it you drove barrel between you know, code,
Pipeline and Jenkins, because you know those are at the same level for
me, they're different for sure. But yeah, we could go down a
whole rabbit hole there for sure. But I would say, like the common
thing is, you know, when I was when I was leaving the infrastructure
group at Riot, you know, we had innovated a lot on top of
Jenkins for reasons, and you know, so I guess the parallel is that,
you know, those lower level, less opinionated offerings that are very powerful,
but in practice you end up needing to staff you know, a group,
a team or a group of people to think about how to take that
and apply it to your specific domain. And you end up building these layers
you know, on top or in your application to handle you know, to
take that and integrate it into your use case. That's the common I guess
the common thread I was trying to try to I'm totally with you there.
Actually it was my job at a previous instance to actually migrate the organization to
you start using get and along with that was turn off Jenkins and actually start
using I get lab at the time, and there was a whole number of
challenges with that, but for sure, no one was going to do that
work if it requires building on top of the equivalent of Code Pipeline, Yeah,
for sure. I mean, also in fairness, I think we Amazon
it's interesting, you know, internally, I think Amazon spends more time thinking
about things like release safety than any any company on the planet. I feel
fairly confidence saying that. And you know, Code Pipeline has interesting capabilities inspired
by that internal learning that I think made it the best offering. If you
were a large enterprise with unique release requirements, meaning you need to release across
regions, and you know, you need to think about let's say four plus
nines of availability, et cetera. You know, I think we had optimized
in some ways for those sets of capabilities, more so than just like you
know, it's the typical developer that's using GitHub actions. For example, it's
totally fine to spin up containers to run you know, release pipelines that actually
have no knowledge of other executions in the pipeline because they're only releasing once at
a time and maybe once a day, you know, or whatever. It's
not there's not this complex sequencing. So we were thinking about those kinds of
use cases, you know that that are super interesting but more relevant to the
p one hundred of of you know, release automation, and again getting back
to the kind of no free lunch theme, you make trade offs to do
that, and ease of use is one of the babies that could sacrifice sometimes
as part of as part of those trade offs. No, I think I
think you're absolutely right there. I think that highlights one of the one of
the needed or one of the neees of using managed providers. Like as a
managed provider, you know, I'm looking not just for management of the infrastructure,
but also like some guidance on how to effectively use the product. Mm
hmm, yep, yeah, I mean, yeah, No, I agree.
I mean I think the there's sort of tiers to what you mean and
managed I mean, this is true of serverlists too, right, Like people
use the term serverlists that I've described just about everything todays it's become a little
bit whitewashed. Yeah, you know, you know, we say all the
time that we see APIs as kind of the highest possible layer of serverleists because
literally, you know, your its request response, specified input output, and
you're not you know, thinking about any of those lower level concerns. But
you're getting to is interesting point well, which is you can even go higher
than that, which is, you know, thinking about things like documentation,
instruction and learning and all those things as sort of part of that core offering
as well. To take the abstraction if even hire, which I think is
a good point. Yeah, to use the I think I used this quote
in last week's episode too, from Jurassic Park. You spend so much time
thinking about if you could, You never stop to think if you should.
And I think that's one of the opportunities managed providers have is to to answer
that or provide some insight into whether or not you should be taking this approach.
Yeahhen you said Jurassic I'm a disappointment, he said, Jurassic Park.
I thought you were going to go Samuel L. Jackson and say hold on
to your butts. Are rebooting the servers, right, Yeah, I mean
there's there's a limited number of Samuel L. Jackson quotes you can use on
the podcast. I'm a big fan of all of them, but there's a
of them. Uh, where are we asso there? Yeah, well,
you know we're coming up on an hour here, So how about a quick
summary on who's the who the ideal user of fauna is and what they can
expect by trying out the service. Yeah, I mean, you know,
really i'd say the ideal, h you know, fauna user is someone who's
building modern Apple locations that store operational data, right. I think that's a
pretty that's pretty general. I mean we see there are certainly specific verticals where
we see you know, more adoptions if you talk about those, but you
know, it's a pretty generally applicable product for you know, these these different
transactional workloads. You know, particularly if you if you you know, applications
that have very high performance requirements, responsive applications, et cetera, applications that
have high availability and security requirements. You know, where because we manage things
for you, you know, typically we're going to be more available than if
you go and try to manage your own database. I think those are a
few areas where where we really shine, right And when you say high performance,
you're talking like Nasdaq level high performance. Would you go that high?
Yeah? I mean we have we have folks that have built you know,
different financial kind of you know, like cryptocurrency for example. We have folks
that have built like trading applications, uh, you know, streaming streaming data
using our events streaming. But again the main focus there is that because the
way that we do multi regional application and the way that we have that data
there, and even the optimizations we've done at the routing layer, you know,
we can just get you to that data very quickly to do things,
to make decisions based on that data, or to render that data. So
yeah, you know latency sensitive applications. I mean well, from the from
the knowledge that I have about this, a lot of the order books are
usually tried to be saved in memory anyway, so you persisting them to a
database. I mean, you could pick anything. It seems like Fana would
be just as good a choice as anything else, whatever makes sense for the
actual application. I got you right on cool. Well, before we move
on to picks, Tyson. People want to learn more about you, interact
with you, find out more about Fauna. What's the best way for them
to do that? Yeah, for fun, I mean funa dot com.
You know, reach out to us, interact with us on social media,
email, drop me line whatever. I guess I'm less interesting, but I'm
around occasionally. That mostly works. I'm not much of a social media guy,
but but yeah, I'm I'm around on the platform, so it feel
free to drop me a line. All right, awesome, let's do some
picks, Warren, I want to kick us off. He always likes picking
on me to go first. So that's that's really why he needed another host
in here, so that start the time. Yeah. Yeah, So mine's
going to be something for my personal life. I know that as a DevOps
advocate, optimization uh is such a huge part of what we do, and
especially automation as well, but optimization primarily, and so this is about picking
socks. I have to say that if you're someone that loses some socks every
once in a while to the washing machine or dryer monster, just when the
next time you're out and you need some more socks, just get like twenty
pairs of whatever it is. You'll never have to think about it again.
And when you lose one of them, you won't even know and it won't
even matter. From that, get a whole doesn't matter, just throw it
away. So especially favorite socks, I gotta say just absolutely fantastic. Has
changed my life right on. It's a great pretty socks for and I'm like
order the same kind and bulk from Amazon, and every time they start getting
a little chevy and chuck them out and go Yeah, that's that's definitely the
thing to do. I tried doing it with shoes one time. That was
a mistake. I would not recommend buy any more than one of the same
kind of shoe. But they also deteriorate over time. So if you really
do like something you've got and you know it's gonna get worn out in the
future, get it. Get multiple extra pairs, right on fair advice,
Tyson, What you got for a pick? Well, I'm gonna, I'm
I'm so, I'm told I can go pretty broad here. I'm gonna yeah,
for sure, this is a bit out there. But I'm a wine
guy. My my biggest hobby when I'm not not not making software, we
actually make make a bit of wine. I love. There's something I think
very rewarding when your day job is thinking about software and something that's intangible from
like pretty much of work in and making something that you know you pour into
a glass and and enjoy at the end of the day. So, uh,
my pick, I'm gonna give a shout out. I live in the
state of Washington. There's some pretty amazing wine being made up here, and
so if you want to try some good Washington wine. I'll give a shout
out to a friend of mine who mixed wine at a winery called the Bapiano
Silver in Walla. Walla does a great cave and a great Sara. So
if you're looking for to experiment with some really good Washington wine, you can
go in and uh and check them out right on. Awesome cool for me,
my pick I. I live on the the edge of the country,
and so I go for long runs out in the countryside pretty often, and
there's a lot of people who have dogs out there and no fences and no
leashes, and most of the time the dogs are cool, but occasionally you
get some dogs that are pretty territorial. And so I recently picked up the
Viper Tech heavy duty stun gun, and the thing is just so cool because
you know, like I'm going to try to avoid, you know, becoming
the target of the dog's aggression. And if a dog does come after me,
I don't want to hurt it, but you know, at the same
time, I don't want to get hurt either, And so I did a
lot of research and a few people suggested stun guns, you know, a
taser number one, because you can just click it and the noise is enough
to deter most dogs, but then if it escalates, you know, you've
got the ability to tase them as well. And so yeah, I picked
up the Viper Tech, just ordered it on Amazon and it's it's pretty cool.
I haven't actually used it yet, haven't had to use it yet other
than just you know, seeing a few dogs and sure enough, you know,
you click it and they're like, ah, yeah, okay, we're
done. So how heavy is it? It's super light, Like carrying it
in my hand doesn't doesn't even register. Got it cool? So yeah,
I was worried about that, you know, worried about carrying it and having
it just become cumbersome. But it hasn't been by any means. So there
you go. Got socks, wine and a stun gun from today's episode.
What could go wrong? All these things together? Right? Awesome? Well,
Tyson, thanks for joining us. It's been super insightful and pretty entertaining,
so appreciate it. Yeah, it was my pleasure. Thank you for
having me. Uh yeah, it's love fun, cool right on burn.
Thanks for joining me once again. Thanks for holding up the co host role
and showing up. Appreciate it and to all the listeners, Thank y'all for
listening, and we will see y'all next week MHM.