Latest / Agentic Conversations (formally mlops.community) / The Rise of Serverless Databases // Alex DeBrie // MLOps Podcast #147

Transcript

The Rise of Serverless Databases // Alex DeBrie // MLOps Podcast #147 · Agentic Conversations (formally mlops.community)

0:00
I am Alex debris. I'm a independent consultant, so
0:03
I'd say founder at debris advisory.
0:05
I do like dynamodb AWS Consulting generally.
0:09
In terms of coffee, I drink two cups of caffeinated black coffee
0:13
in the morning. Use it Aeropress for that.
0:15
And the rest of the day I'll probably drink like 3 or 4 cups
0:18
of instant decaf. A generic not good coffee at all
0:22
and that's my, that's my coffee batter.
0:25
Hello everyone, welcome back to another Emmy.
0:27
Laughs Community podcast. I am your Demetrios.
0:31
And today, I am joined by none other than Abby and Alex.
0:36
We spoke to today all about databases, oh my God, this was
0:41
such a deep dive for me, knowing so little about this, but I knew
0:45
he would deliver. I mean, the guy wrote a book on
0:49
dynamodb and you could just tell, when we were talking to
0:52
him, he was in in Spanish, they say into salsa.
0:55
He was in his salsa as take, could say when he Talking about
1:00
dynamodb and just databases in general, I learned a ton.
1:04
What were some of your key? Takeaways Evie for me, it was to
1:07
the first one, please. The way he explained the cap
1:10
Europe, because I've left like that is something which I
1:13
learned the conventional way, which is why you have to pick
1:16
between these three choices, which is consistency,
1:20
availability, and persistence. I was like, oh my God, we are
1:23
acquiring. But the way he explained it was
1:25
whenever you have failure. What do you choose between two
1:29
properties? He's a vulnerability
1:30
inconsistency in you decide. According so first, I was
1:34
thinking more. So about the world problem in
1:36
machine learning perspective, which is what would be the use
1:39
case has been be bird. Say consistency matters that,
1:42
I've been more. So for example, let's say we're
1:44
working financial data, may be consistency of our deer across
1:48
different oats a little bit more as compared to let's say we're
1:51
working on ads or some sort of a bank knocking application, then
1:57
the availability would be more important as Good consistency,
2:01
for example, let's say we are working for the weather forecast
2:04
availability would be more important and the second is
2:07
basically the part where he reserved talking about, will TP
2:11
morse's old up. So now what's that was very
2:14
interesting. I loved his quote where she
2:21
basically said look when I'm evaluating databases.
2:24
I'm not looking for features. I'm not going down a checklist
2:28
and saying what kind of features does this database have?
2:31
I actually prefer my database to be very opinionated and do what
2:38
it says it's going to do on the tin and it makes complete sense
2:43
why he dove into To dynamodb so much.
2:47
And he really stressed how dynamodb is very opinionated,
2:52
but it gives you what it gives you.
2:55
And it says it's going to give you no matter if you're dealing
2:57
with small or large scale and I loved how he explained that in a
3:02
way that even someone like myself was able to understand
3:05
and pick up on without really knowing too much about the
3:10
database world. So I am going to just get right.
3:15
To it. I think we should let Alex tell
3:19
us all about his story and what he's done.
3:23
We also are going to see. Hopefully Alex can give us a few
3:28
copies of his book to give away to some of the people that are
3:32
writing us very kind reviews. So if you or actually, if you
3:37
want to write mean, reviews will still give you some books.
3:39
We don't care. We're not going to bias the
3:41
reviews. We want to hear the truth about
3:44
what you think about this. Podcast.
3:45
So, if you are listening to this podcast and you want to help us
3:50
out, it would mean the world if you gave us a review and you
3:53
left, just a few words on iTunes or Spotify or wherever you tune
3:57
in to this podcast because that way we can help the podcast grow
4:03
and you might even get a book out of it.
4:06
And so that's that sign up to our newsletter to sign up to
4:11
join us at virtual events or in real life events.
4:15
Over 30 cities around the globe, and without further Ado, Abby, I
4:20
think it's time to get into the conversation.
4:23
Let's get and shit out. Thanks, you made from studying
4:34
love, becoming an attorney to becoming a data engineer.
4:38
What on Earth is that is just like a weird path.
4:43
Right? So yeah, my wife and I We both
4:45
went to law school. We were doing law school
4:47
together and I lost schools, three years.
4:50
And during the Summers of law school, you actually do work at
4:53
law firms or some sort of job. So I went over to the law firm,
4:56
my first summer and I met a guy there who was like, super attack
4:59
got me into Tech. I'm always like checking Tech
5:01
news and things like that, but still not doing a lot.
5:04
And then my last year of Law School, third year, he and my
5:07
brother-in-law started working on this.
5:09
This startup, he owes me like a data science, AG type thing and
5:12
I want to be involved in dark. Well, you can you Write the
5:15
business plan which is like not a useful part of it, but I like
5:18
did that. And and then there are.
5:20
And then I got done with that and I'm like, well, I still want
5:23
to be involved like, what I do and I, well, you can learn to
5:25
learn to code or something like that.
5:26
So they like bought me a book on Jango, which like the python web
5:30
framework to scoop size. They bought me that and set it
5:32
to me. And I just like that whole third
5:35
year, of law school. I, I just spent trying to learn
5:37
how to code and, like, build this website for this, this data
5:40
science, a good thing that we were doing and that's how I
5:42
learned it. And so, then I went I They took
5:45
the bar work to the lawyer for nine months, but I'm still like
5:48
programming all the time at home, like that way more even at
5:52
work, I sometimes would be slow at work and we had like these
5:54
old bad Windows machines that I kind of program on it.
5:57
But I was using it was called he was Cloud Nine which is this is
6:01
before that ended up getting bought by AWS.
6:03
But it was like this in browser IDE that you could use to
6:06
program you like clone your git repo into it and do it.
6:09
So I can't work on this Jakey Windows machine.
6:11
I'm using cloud and I am like Internet Explorer 9 or whatever.
6:15
Find at program and keep learning whenever I have some
6:18
down time and then after nine months or so.
6:21
I was like I just I just got to make the jump so that when I
6:24
left, I left the law and went to sports video company that I was
6:28
doing data engineering form. That was based in Nebraska,
6:30
which is where I'm from, the AG tech company didn't work out.
6:34
It didn't work out, like, none of us had the the time or money
6:39
to, like really commit to it because my, my buddy, he was
6:42
still working at the law firm. My brother-in-law, he He's like
6:45
what I would do it but like we gotta get some money for you to
6:48
do that and none of us were willing to make the commitment.
6:50
So he he wouldn't got a real job too.
6:53
So none of us was was able to commit, but it was a really good
6:56
learning experience for me, just thing.
6:59
But why specifically dear Engineering in know that there's
7:02
always a need for people to come in and manage that data?
7:05
And that's all miss one of the core functions and at eternity,
7:10
but again, there for anybody who's trying to learn our Nana
7:14
program from Get-go was like full stack development, why dear
7:19
Junaid? Yeah.
7:20
Why couldnt do full stack development?
7:21
So I've just like my design, I is just terrible.
7:24
I can't form a me. I got I just I still can't do
7:27
HTML very well. I need to use a template that
7:29
someone is generated or things like that.
7:31
So that was never an option for me.
7:33
I felt like, but like the the stuff we're doing for the data
7:36
science thing, it was I was doing most of the back end stuff
7:38
and just like enough front end to get by.
7:40
But it was most like displaying charts and data and different
7:42
things like that and then manipulating data in databases
7:45
Has it is a lot of python. It was a lot of AWS when I win
7:48
the interviewed at this company huddle, this is a sports video
7:51
company, I wasn't interviewing as a data engineer specifically.
7:55
I was interviewing as an infrastructure engineer, so
7:57
basic like a platform team, just helped everyone use AWS better
8:00
and manage that sort of stuff. And then, pretty quickly after I
8:03
got there, they were spinning up a data engineering team, and I
8:07
just got involved with that. And so I was one of the, they
8:11
had like a bunch of different tools they were using.
8:13
None of it was, was working super well, not.
8:15
Vote with no one was full-time committed to it and they're
8:16
like, hey, let's just get three or four people and and get them
8:19
dedicated on it. So we did that, I knew a lot of
8:22
AWS and a lot of python, which is kind of a, the lingua Franca
8:25
of data engineering at that point.
8:27
So a lot of red shift, a lot of polling data out of production
8:30
database has a lot of parsing logs and putting it in different
8:33
places and and that sort of thing and I I learned to tell
8:36
him there was it was a lot of fun.
8:37
I enjoyed it. And but this was how long ago
8:42
was this? So that was me.
8:45
See 20 I think 2014 is when I graduated law school.
8:49
So 2015 I started at hot all and I worked there for two years
8:54
during day engineering. And at the very end of that I
8:57
started using like AWS Lambda and surrealist stuff and getting
9:01
into that. And I was using this tool called
9:04
the service framework to deploy my Lambda functions.
9:07
I saw that that company was hiring and I was like, okay I'm
9:09
going to go, I'm going to see if I can work for them.
9:11
So I worked for them remotely 42.
9:13
And a half years. And that's why I really went
9:15
down like the service Rabbit Hole, I got into.
9:17
That's how I got into dynamodb because a lot of people using
9:20
Dynamo with with Lambda and their service applications and
9:23
and that spawned a whole new chapter.
9:25
Yeah, but who that's perfect. Segue into one of the things
9:29
that we definitely wanted to talk about was serverless.
9:32
And also time to Modi be, I mean, I know you wrote a whole
9:36
book on dynamodb and we're going to get into that and go deep
9:40
there. But let's just talk about
9:41
serverless and some of the patterns, you've Seeing and also
9:45
what interested you like. When you saw serverless, why did
9:49
that stick out? And then, why did you want to go
9:51
deeper there? And then, what have you been
9:53
learning since you went down the rabbit hole?
9:56
Yeah, absolutely. It's hard to tell with service
9:59
means because it's really been expanded in in a lot of ways by
10:02
by different people, including like the marketers, I'd say just
10:06
call everything surveillance now.
10:08
So like for me it was it was a tedious Lambda which is like
10:12
this managed event-driven function based compute, where
10:15
rather than like having to go spin up a server, initialize the
10:19
code on that server and then have it start either processing
10:22
from a queue or take HTTP requests or whatever.
10:24
What I do is I just packaged up a zip file.
10:26
I love my code and say, Here's the entry point to my code and
10:29
then say, whenever X event happens, I want you to like
10:33
trigger my, my code, my function Handler that I've told you with
10:37
that event and all sort of processing.
10:38
I can react to that event and that could be, they got
10:41
messages. And sqs, Q can be messages in a
10:44
stream like a Kafka streamer. Can you stream?
10:47
It can be HTTP. Request, just anything then
10:49
driven. And like for us at when I was
10:51
doing data engineering, that was super helpful.
10:53
Like, one of the big problems we had was we had this log,
10:56
Provider. We're sending them all this law,
10:58
these logs and then every like five minutes, they would send us
11:01
like a dump file of just like here.
11:03
The logs you send us in the fat in the past five minutes and
11:05
they put it in the S3 and it was in like we wanted to be
11:08
processing those as they came in, but we had no way to be able
11:11
to do that easily. But then Lambda came out in the
11:13
one of the first events they had was S3 notifications.
11:15
So you could just set this up on your bucket and say every time
11:18
someone puts a file into my S3 bucket trigger this Lambda
11:22
function, I can handle it. And now we could just say we got
11:24
rid of all this infrastructure we could just say okay now Now
11:26
that that happens like hold on that file, parse it chub it
11:29
somewhere else and reacted out super easily rather than doing
11:31
like more of a sort of batch based reconciliation project.
11:35
So like that made it way easier for me and then I'm seeing all
11:37
these other places, it's useful and started get into that.
11:40
And I was like, I really think this is going to be a big thing
11:42
if it with my model of how applications were bill, I hadn't
11:45
been around for a long time. So, I was building stuff on
11:48
Heroku. That was like, what we build our
11:49
first thing on, and I think he of stateless compute and then
11:52
the in stateful database is somewhere, like, I didn't have
11:55
some of the baggage of Prior infrastructure.
11:57
So so him to really fit well with my mental model that way.
12:01
And again, placing this, this is like before airflow was a thing
12:06
and it was something that just came out and you, yeah, I think
12:10
airflow was pretty new. I, so, when I was doing data,
12:13
engineering Luigi, I don't know if little Yugi is already a lot
12:16
of high project Eric burn, I don't know how to say his last
12:20
name, but like he created this at Spotify and that we use a ton
12:24
of Luigi for like our data pipelines.
12:25
Moving and process. Um data moving stuff around
12:27
airflow came out after that and other things as well.
12:30
But yeah, it was it was a while back yet.
12:33
So one of the questions because you started talking about event,
12:37
German architectures is where the big challenges according to
12:41
new in 12 opening machine learning applications in and
12:45
terminology and the Frameworks in stuff.
12:47
Or how do we adopt it? Yeah, sure.
12:50
So I mentioned the term event-driven and, and it's hard
12:53
because I use it in the sense of a driven.
12:56
For Lambda or it's like they're only going to spin up Mike and
12:59
few when an event happens which could be asynchronous events
13:01
like messages streams. It could also be HTTP request,
13:04
right? But it's sort of like my compute
13:06
only exists when I have an event that needs to do it.
13:09
There's also this notion of event-driven architecture with
13:11
that, which I think is, like, very common with service
13:14
applications. So you see a sort of converged,
13:16
but it, event-driven is like more asynchronous, right?
13:18
You're passing messages, especially like, Pub sub type
13:22
things. That's where you see a lot of
13:23
Kafka type things coming out and we're seeing we're Seeing a lot
13:27
of that, especially in the cloud and with just more data and more
13:30
users, that you can have seen a lot of that sort of stuff.
13:33
So it's fun to see. It's fun to see the patterns
13:34
coming out around that. I still think it some of the
13:38
patterns feel immature, just around the like, okay, I want to
13:42
have these sort of decoupled, producers and consumers.
13:44
That's part of the event driven, as I can broadcast this message
13:47
out as a producer and I don't know about my consumers and they
13:50
can consume it, but it can make it difficult to like, if you
13:52
need to evolve that schema, how do you do that?
13:54
How do you notify your consumers of that's happening?
13:56
How do you just share? Scheme is generally and things
13:58
like that and we're getting more and more of those patterns but
14:01
it's still, I think it's more difficult for people to learn
14:04
than a traditional request/response, rest API based
14:07
stuff where it's like, hey man, I can, I can implement the, my
14:11
my structure on this, this API endpoint and tell you what's
14:13
gonna come back. And it's going to break right
14:15
away. If if I try to consume it and it
14:17
doesn't so still working on patterns there but yeah, it's,
14:20
it's fun to see it. The nice thing about
14:22
event-driven is it, can, it can scale better.
14:25
You can decouple these These things are different ways and
14:27
you can use that same piece of data in a lot of different ways,
14:30
especially in, like these machine learning pipelines data
14:32
engineering pipelines to to create these smarter features
14:35
recommendations or things like that and because I think we are
14:39
going in a very interesting direction to talk about
14:42
Bachelor, so streaming. That's when one of the things,
14:45
one of the Hot Topics. How do you feel about that big
14:49
debate on Joan to don't in? Don't call it streaming, if it
14:55
works as slow as At. Yeah.
14:58
And I've been a little bit out of the dating injuring game so
15:01
you all probably know that better than I do.
15:03
I know like when I was back doing data engineering work we
15:06
did do a lot of more batchi type work especially like when
15:10
pulling from our production databases that would be more
15:14
batch oriented type stuff. We did have some sort of
15:16
streaming stuff especially around like, logs and things
15:19
that are more continuously coming in.
15:20
I was like, screenings. Great.
15:22
If you can, if you can make it work, but it adds like a lot of
15:25
a lot of difficulties. Especially around each mutable
15:28
data, right? Like you have these data
15:30
warehouses or data Lakes on S3 and it's like if you have a
15:35
mutable events coming in, that's one thing.
15:37
If you have mutable data, like, changing those on things that
15:40
are not meant for small updates, but are meant for just like
15:43
giant batch up like, more continuous ingestion.
15:46
It's harder to handle updates and things like that.
15:48
That was a difficulty. I know when I was still in that
15:50
game, I'm a little. I'm a little bit out of that
15:52
game now, but I don't know. Why are you, are you all seeing
15:54
difficulty? Like, what do you see from the
15:56
batch? Screaming side if for me I still
15:59
prefer back to the case again dealing with variables here
16:04
especially with like production with us is questionable for me,
16:08
but the models that you're working with the data quality
16:10
matters so much. So unless you really need to use
16:14
streaming and plus, I mean it's something I feel like a person
16:18
coming into and we haven't really arrived better.
16:20
Maybe we will, by the end of this year mentioned, a lot of
16:23
you worked with Annabeth. So what were the few challenges?
16:26
That you personally seen and where were the few would ups for
16:30
you. And yeah, so when I was doing
16:32
data engineering, it is wasn't for a lot of ml type stuff, but
16:35
it was more for just like internal analytics have come, if
16:38
a PM wants to see how many people are using this feature,
16:40
or maybe we're a deprecated feature, how many people are
16:43
using it or different things like that?
16:45
And I would say we had two big categories of data, right?
16:48
We had like our production databases, this would be users
16:52
teams videos people at uploaded different things like that in
16:55
our application. Those These are fairly mutable,
16:58
right? And then we had events log tied
17:01
data where she's like hey someone watch this video,
17:03
someone did this and that second type of data super easy for us.
17:08
Like we get, we can handle with streaming which was like semi
17:10
screaming for us because we only get those those sort of files
17:13
from our log processor. A few minutes.
17:15
But when it came in we just like then turned it into a stream
17:18
that people could use and also put it at rest in S 3 or in red
17:22
shift, things like that but then our databases are production
17:25
databases that's a lot harder to A handle Shin streaming for
17:28
especially like they used a lot of Mongo DB at that point and
17:32
it's just kind of tricky to how you handle that setting.
17:35
We had some databases that were like one that was over a
17:37
terabyte and just like, how do you manage the existing state?
17:41
But you're getting a stream of updates and we had to work
17:44
around some of that stuff. I think mutability in your sort
17:48
of data engineering is tricky. Like redshift is not built for
17:51
small updates. S3 is not built for small
17:54
updates, they're built for big files or Or big uploads of files
17:59
did. So I gotta kind of a taste of
18:03
what it means to be a LinkedIn influencer and it was because I
18:08
completely ripped off a buddy of mine, David Hershey, when he
18:12
wrote a blog post for the ml Ops Community blog and it was on
18:18
like the phases of real-time and basically like streaming
18:24
architecture for machine learning, right?
18:26
And so it talked about how you start with batch and then you
18:30
try and go like batch streaming and then you go, like real time
18:33
streaming and how much complexity is added along the
18:38
way. And so, I took his post and I
18:42
punched it up a little, and made it into this little LinkedIn
18:46
post with the highlights. And then I've never had
18:49
something go. So, viral in my life, I felt
18:52
like I was going to get invited to the Grammys or something
18:55
afterwards or at least the In Creator awards.
18:58
Did not happen. I'm still waiting for that.
19:00
In case anybody out there is wondering, but the theme of
19:05
streaming has definitely gotten onto people's minds.
19:09
I think stream like real-time streaming real-time ml people
19:14
that I talk to even if they're not doing it, they think they
19:17
should be doing it. And one of the biggest problems
19:21
were barriers to entry is that it's just a complex Beast right
19:25
now. Where it's at and who knows?
19:28
There's a lot of very well funded startups that are trying
19:31
to make it a lot easier for us, but we'll see how that plays out
19:36
and how easy they can make it because there is like these what
19:40
you're talking about, there's so much complexity involved in
19:44
whether it's the database or it's the alright.
19:46
Are you going to grab some coffee?
19:48
Inflame can throw it in there, but this is like, kind of
19:51
changing gears. I think there is a great piece
19:57
that we can dive into and something that I would love to
20:00
hear your thoughts on when it comes to just like data
20:05
infrastructure and especially when you're looking at like do
20:09
have strong thoughts on the modern data infrastructure or
20:15
how things are set up these days and with respect to like because
20:20
I know you like to play very much in database land and so how
20:25
databases kind of are helping you see the rest of the field
20:31
per se Yeah, that's a that's a good question.
20:35
Let me think on that. So when I think back to like my
20:38
data engineering days, I think a few things we always want to
20:41
have as much codified as you could have.
20:43
Right? So we had our Luigi pipelines
20:45
and it would go, but we have our sort of raw data somewhere and
20:48
they would go through a few different stages.
20:50
So, as much of that at the very end of my time, doing that DBT
20:55
was becoming a thing, which I see a lot of people using it and
20:58
how you can codify those Transformations and doing elt
21:02
type patterns, right? Where you're loading it into a
21:03
Database and then transforming it and different things like
21:05
that. But again, all codified.
21:08
And and the big other thing I learned, I think, from data
21:09
engineering was around immutability, especially when
21:12
you're moving these big data sets around, having these
21:14
different sort of stages and not not changing stuff in place as
21:18
much, but maybe like you have your raw data somewhere, not S3,
21:20
and then it's cleaned. It one step somewhere else and
21:23
the clean one step somewhere else.
21:24
So then you can, if you need to rerun from one particular step,
21:27
you can throw one away and rerun it and and fix the bug that way.
21:31
So think of your Transformations are pretty functional and then
21:35
you have your state. Just just intermediate steps
21:37
somewhere, things like that. So one thing I would say is I
21:40
got out before snowflake took off and and the interesting
21:43
thing to me I were talking about this a little bit before but
21:46
like Snowflake and Dynamo which I was involved.
21:49
I think we're like the early stages.
21:51
Different ends oltp for Dynamo LOL app for snowflake but the
21:54
early stages of like Databases data infrastructure.
21:59
That was truly built for the cloud and like what the cloud
22:02
can do in the elasticity of the cloud and and things like that
22:05
rather than saying, hey the traditional databases that we've
22:08
had before. Let's just pull it into a cloud
22:11
Datacenter now right, let's pull my Sequel and post grads or or
22:14
redshift greenplum whatever those are into a data center.
22:18
Now you have ones that are like, okay, I'm using all these
22:19
different Primitives of the cloud.
22:21
I can use that elasticity and things like that.
22:23
And I think that's really exploded now over The past like
22:27
two or three years. Well, and that brings up
22:30
something that we were talking about before we hit record where
22:33
you were saying how we're quite mature into this Cloud
22:37
ecosystem, depending on which Enterprise you talk to, they
22:41
will have their thoughts or opinions on that.
22:44
Some of them I was just talking to a friend who shall remain
22:48
unnamed today and he was saying like, yeah, at this financial
22:53
institution, he works at they're still trying to get onto And
22:57
it's like very, very slow-moving.
23:00
But let's forget about those use cases, for a moment.
23:03
And let's talk about these more mature, use cases in the cloud
23:06
ecosystem and how especially when it comes to databases how
23:10
things have changed and you were talking about using these Cloud
23:14
Primitives. What does that mean for us?
23:16
As we're looking at databases. And as I mentioned before, it's
23:20
like a new day goes by and we get a new database each day.
23:25
Yeah, yeah. So To talk about I guess did
23:28
databases or data infrastructure that's taking advantage of these
23:31
Primitives. Like if you think of the cloud
23:33
part of it is just these different managed services that
23:35
the cloud providers give you and that can be the underlying
23:38
instances ec2 instances but also higher level services like sqs a
23:43
queue service or or S3, right? Like which is just a blob
23:47
storage if you ever need to store files or images or
23:50
documents or data files, whatever they are right.
23:53
S3 is just like this infinitely, scalable pay per use.
23:57
Highly available API for that point.
23:59
And so let's dive into like that part of it for specifically data
24:03
data warehousing, right? Like I use I used to use red
24:06
shift back when I was in my data engineering days and the way red
24:08
ship works is they're going to spin up a cluster of giant ec2
24:13
instances with giant disks attached to them and you you
24:17
load data into redshift and it's going to spread out across
24:20
instances on in your cluster on to those discs and it's going to
24:23
be querying those live and that worked.
24:25
And that's like the the sort of Traditional model, I would say
24:28
of data warehousing but then snowflake comes along and says,
24:30
like, why do we have these giant disk attached when we have S3,
24:34
which is like this infinitely, available, cloud storage blob
24:38
storage mechanism. Why don't I just use that for my
24:41
storage and then I'll have ec2 instances that have sums local
24:44
disks attached that they'll use for like hashing between queries
24:47
especially pops up, but they don't need to store all the data
24:50
on them. And what I need to do now is
24:52
scale up my computer to handle bigger queries, or or different
24:55
things like that, pull it in. Like now my compute is elastic,
24:59
right? Because ec2 is a service I can
25:01
scale up and down my storage is is elastic because I can just
25:04
put files to S3 as much as I need them.
25:06
And now we've got also that separation of compute and
25:08
storage and I'd like they just built for that in this in this
25:12
sort of new way. Right?
25:14
And it changed, I think he just liked the growth of snowflake
25:16
compared to the other data warehouses.
25:19
I think you can see people just like it does cost more in part
25:22
of that is like because people don't know how to model and
25:24
stuff like that. It's headed.
25:25
But like also it just like So much faster and easier to use
25:29
where you don't have to, like, think about your cluster or
25:30
you'll have to manage your cluster like you did in red
25:32
shift. You can just be like, no, I'm
25:33
just going to be loading data to you.
25:35
And I'm going to query it back and send you the bill at the end
25:37
of it in considering, there is a lot of action happening in the
25:42
database world. Do you feel like there will ever
25:45
be A snowflake that happens again, that type of thing that
25:51
just has a big boom and it gets so much adoption.
25:56
You have at Super interesting too because like you do see a
25:59
ton of different databases coming on all the time.
26:02
Every week There's a new I'm not you were tan and but it's it's a
26:07
high burden to to break through now because now you have to be
26:09
like, how do you promise the same sort of reliability and
26:12
future maturity? I built a database is different
26:14
than building other stuff, like you need certain level of trust
26:17
and all that. And then also if you have a
26:19
different query language or however you access it, that's
26:21
difficult. Now they have an education
26:23
problem with that. So it is tricky.
26:25
I fact there is there's also sweet spot of like data,
26:29
infrastructure new data but like we're like Mongo took off redis
26:33
took out elasticsearch, should off snowflake took off like
26:35
those that sort of era of databases like new sort of
26:38
database or data store type infrastructure that really took
26:42
off. But also I feel like some of
26:45
those weren't quite built for all the elasticity of the cloud.
26:48
I don't think elasticsearch, I don't think red is, I don't
26:50
think Mongo really were so I think we'll see some
26:53
Replacements in that area but it is, it is a high burden in terms
26:57
Of breaking through i1 way, you're seeing.
26:59
This is so many databases are trying to be postgres,
27:03
compatible MySQL compatible, different things like that.
27:05
And basically, I can give you new guarantees like all these
27:08
new sequel, things right. I can use some of these
27:10
Primitives of the cloud and and give you a lot of the sequel
27:13
stuff that you like with that exact same sequel API.
27:16
But now all the cloud scalability and performance are
27:19
two hits. So funny, it is like adding just
27:23
basically throwing more features, added or throwing more
27:26
capabilities and Out of it. We're doing these four different
27:30
things inside of our database and how that is now the value
27:34
prop. I don't know if that's like,
27:36
it's not strong enough that it and that also makes me nervous.
27:39
Like I actually like you when you're comparing and choosing a
27:43
don't you just like a checkbox like do they have this feature
27:45
to have that feature to have this feature?
27:47
Like honestly I want a database. I want a piece of infrastructure
27:50
that has an opinion, right? And it opinion on how the world
27:54
works or what this thing is designed for specifically Lee
27:57
then also like hopefully you can tell you what it's not designed
28:00
for what you shouldn't use it for, right?
28:02
Because I think if you try to have the the one-size-fits-all I
28:06
can do it all type of thing, like it's going to be probably
28:09
bad at a lot of them or, or you're going to start using it
28:13
from one of those things. And then you're not going to
28:14
find out that it's really bad for that thing until you're in
28:17
production. You're 2 years, down the road,
28:19
you have 100 gigs of data in there.
28:21
And now it's much harder to migrate out in your having all
28:24
kinds of problems. It is a collie pants down.
28:27
Yeah. Exactly.
28:32
Hey, I'm Vishnu. I'm a data scientist at first
28:35
hand, and I definitely think that you should subscribe to the
28:38
ml Ops coffee sessions podcast. It's the best podcast out there
28:42
to stay on top of what ml ABS actually is to talk to the true
28:46
thought leaders in the space. And oh, by the way, do we choose
28:49
is absolutely hilarious. What a weird guy should
28:52
definitely subscribe to the podcast.
28:59
Just think and this also makes me think of what will be the
29:03
future Revolution, India connectors as well as we are
29:07
expanding into this but also because we are getting so many
29:10
tools from not just on the TV side but also on the event
29:15
management side right now. What's next time connectors?
29:20
From two perspectives. One is, what do you think?
29:23
Would the next software be able to do with the?
29:25
Would that be something which already ties up?
29:28
There are software systems that we have, which is more like
29:30
integration kind of software or really something that defines
29:34
new dear types, which is what sort of allows us to be able to
29:40
probably do something better, which is like compressor idea
29:43
even. Yeah.
29:44
Or another thing I also wanted to ask was basically me Tenants
29:48
and upgrading the case of the constant changes and how do we
29:53
manage all of that stuff? Yeah.
29:55
Yeah, man, those are, those are great questions.
29:57
I would say that God maintaining I think like I think over the
30:01
next five or ten years, you're going to see way more managed
30:06
database Services fully managed ones where it's like, you
30:09
actually don't even think about software upgrades under the
30:12
hood. And like so when I think of just
30:15
an AWS, right? I love Dynamo I do a lot on
30:17
Dynamo but there's You can also like there's already a switch is
30:21
the relational database service. They will make a run and manage
30:24
postgrads MySQL SQL server for you.
30:25
Whatever. And I would say those, those are
30:28
like different in philosophy, right with it.
30:31
If they're managing a postgres instance for you, they're
30:33
managing it. But like, you know, the exact
30:35
version it is, you have an exact connection query, string to your
30:38
specific instance, somewhere that you can actually hit it.
30:41
You have like a slice of a server somewhere.
30:43
That's, that's managed for you. And if you want to upgrade minor
30:46
versions, major versions, you know, That happens whereas with
30:50
dynamodb like you don't have a specific server instance
30:53
somewhere. Right.
30:54
Dynamodb is this multi-tenant, region-wide service where
30:58
everyone. In u.s.
31:00
East one is basically running on the same infrastructure, whether
31:03
it's like my tiny app, whether that's lifts Rideshare, whether
31:06
that's amazon.com retail, right? It's like the same just giant
31:09
shared infrastructure and there's like different Services
31:12
involved in there and and and managing all this stuff, but
31:15
like you don't think about upgrades, right?
31:17
Because you're not upgrading, you'll see.
31:18
See, there are changing those systems all the time.
31:20
As those teams are working to either add features or add
31:22
reliability, or availability or whatever that is.
31:25
But you truly don't think about upgrades and I think you'll see
31:29
more of that as we go of just like, hey this is this is the
31:32
manager was now and then like if you want to make comparisons
31:35
outside of oltp you could say like in search right like
31:38
previously there was elasticsearch and there are
31:40
managed elastic search options but again you have a specific
31:43
server you have to upgrade that and deal with it whereas maybe
31:47
we'll get something like algo Leah.
31:49
Fully managed hosted service for you.
31:51
You get an API and they're going to be doing those upgrades and
31:54
improvements behind the seeds. And you don't have to think
31:56
about that step. So I think we'll see more and
31:58
more movement to that, that like fully managed F where, hey, that
32:01
that team is managing that for you managing those upgrades and
32:04
you don't really think about that.
32:05
Yeah, so this is fascinating because it there's a few things
32:09
that come to my mind. One is when it comes to manage
32:12
services. I think about the ml up space
32:16
and I wonder a lot about if managed services are going to
32:23
happen at the envelopes level or if it's going to be at a
32:27
different level and specifically because of like the security and
32:32
the data governance and everything that comes with like
32:35
messiness around data. But then I look at data
32:40
engineering and I look at exactly what you are saying and
32:42
how it might just be the ml Ops is not that mature yet.
32:47
And so, once we Get more mature, we will start to see more of
32:51
these managed services, and then the other piece that came to
32:54
mind, right away was the idea of all right?
32:57
Cool, it feels like we've found the right abstraction layer and
33:02
we're just going to manage it now.
33:03
It's not like we're going to take another abstraction layer
33:06
and put it on top and then put it on top.
33:08
It's like no this is good. We'll just like you don't have
33:11
to worry about it. Yeah I don't know enough about
33:13
the MLF space but my guess would be it's probably a little behind
33:16
the databases space and on some of That man stuff because like
33:19
if you look back there's database research Going Back.
33:22
40, 50 years on relational, databases on concurrency, on
33:26
transaction management and they're like, they're like, or
33:28
patterns that most of them follow.
33:31
And like, the admin of the cloud is changed some of that or
33:33
faster processors or ssds have changed some of that, but the
33:36
Core Concepts are like pretty well studied.
33:37
And in hand, all the words like ml still seems like a newer
33:41
space to me and especially like production rising and I like a a
33:44
scale that you can get with the internet there.
33:46
There's there's Google and Facebook.
33:48
Look and Amazon doing these sorts of things, but in terms of
33:51
like really shaking out, those patterns getting the research
33:54
and things like that, that would be my guest.
33:56
But I don't have enough confidence.
33:58
No, but also just like seeing some of the managed services
34:01
from the cloud providers things. I hear people use it sounds to
34:03
me. Hey, not quite there yet.
34:05
In terms of like really being easy to use and able to do some
34:09
of that stuff. Yeah.
34:11
And so let's jump into Dynamo a bit because I cannot have you
34:16
all on here. You read the whole book about
34:19
Dynamo and like, let's talk about it, man.
34:22
I really wanted to think about a just what exactly Drew you to
34:29
Dynamo. And you mentioned it before that
34:32
you got into it. You started using it a server
34:35
list. But why?
34:37
Like, write a whole book on it and then what?
34:42
What is the Allure of dynamite? Yeah, right like yeah.
34:44
Is it just because you had so much hours put into it instead?
34:48
I wanted to be like I got to share this with somebody.
34:51
Yeah, yeah. I've got down this path, I
34:53
better make others do it as well.
34:54
No, I think the thing for me is like I was so I was working for
34:58
Service Inc. We're working on service
34:59
framework and doing these sorts of things, and the way, Lambda
35:04
compute a Terrace Lambda, right? It's that event-driven compute
35:06
where it's always like, basically spinning up an instant
35:08
container instance. When you have an event ready,
35:10
willing to go, which means like initialization needs to be quick
35:13
at all. Sony.
35:14
Like it really prefers sort of I would say each CP based
35:18
Services. Right?
35:18
You'll be reaching out to HUD they Services because like when
35:21
your Lambda functions spins up, you don't know.
35:23
It's IP address. You can swipe list it, it's IP
35:26
address very easily to go access your private database or things
35:29
like that. So you want things that are HTTP
35:31
access and maybe rely on different mechanisms for
35:35
authentication. Authorization.
35:36
So that's like the other eye thing and in the real practical
35:38
thing is like it was hard to use a relational database with
35:41
Lambda for the first couple of years of Lambda because you had
35:43
to put your hand in a VP. See this added like this immense
35:46
cold start time of like 10 to 15.
35:48
Cancers, like if you're making HTTP requests and you have a 10
35:51
to 15 seconds of hanging, before he can even get to the database
35:54
land is not good. Yeah, it's not good.
35:56
So like people are like, okay, what can I do instead of of that
36:00
and Aiko Dynamo is like super easy.
36:02
The billing model fits Lambda the sort of scaling model, all
36:06
sorts of the it feels like using any other area service.
36:09
So a lot of people start using dynamodb because of that and
36:13
it's weird because they've now like fix that VPC cold, start
36:15
issue. But still dying though is I
36:16
think the the the data Base of choice for a lot of service
36:19
developers. Not everyone.
36:20
So got into Dynamo Dynamo is very different it's a nosql
36:24
database. So it's more like Mongo orcas
36:26
Andhra folks that work with those but very different than
36:29
relational databases. But I think what happens with
36:31
those equals like people were normalization.
36:34
They learned how to relational databases work and I try to
36:36
bring that exact same model to no Sequel and it's just not
36:38
going to not going to work very well and Dynamo is stricter than
36:42
most about making sure you're doing the nosql model rather
36:46
than doing the relational model. Where is like Mom Let you get
36:48
away with some of the relational flexibility type stuff Deimos at
36:52
going to write. And so why do you like that?
36:54
Why does that matter? Yeah, I like that kind of stinks
36:58
up front and that's why a lot of people don't like Dynamo but the
37:00
nice the benefit you get about Dynamo is predictability
37:03
predictability of latency response time basically
37:07
predictability of performance no matter your scale, right?
37:10
So if you're developing locally and is working with dynamodb and
37:13
you have kilobytes or megabytes of data, you're going to get
37:17
basically the same Response and performance profile that you'll
37:20
get ten years later when you have terabytes and terabytes and
37:23
terabytes or petabytes of data in there, you're going to get
37:26
the exact same performance profile rather than like if you
37:28
have a relational database or maybe MOG or something like
37:31
that. And you're doing these huge
37:33
joins across multiple tables, or you're doing aggregations.
37:35
And now you have, instead of a gig of data, you have many, many
37:38
gigs of data like that performance profile, totally
37:41
changes. And it's unpredictable, not
37:45
always a lot of people just get bit by relational.
37:48
Pieces as they scale up, its hard to know like which features
37:51
you can rely on which ones are going to be the same performs
37:54
profile and which ones are and you really need some expertise
37:56
there. Whereas Dynamo is just like
37:58
basically it's going to work the same and it teaches you like hey
38:01
these things don't scale these things do.
38:03
And if you want to do these sorts of things, here's how you
38:06
model for that instead and plan about that.
38:07
And so you like, think about performance and scalability and
38:11
those sorts of concerns early and then it's just like set it
38:14
and forget it, right? You, it goes into, prodding me,
38:16
like you're not going to get that performance degradation.
38:18
Over time, Staples one of the questions because up not really
38:21
use. Dynamo is what kind of data to
38:24
use ink dine with me. And one of the reasons I asked
38:27
you this question is because I know there are so size limit on
38:32
every single item which is what smaller than what you get let's
38:36
say in mongodb or Cassandra. Oh well she artists yep sure.
38:40
So like diamond size limit is 400 kilobytes for a single item
38:43
which is like still pretty big. Ironically big enough for that
38:47
they will prevent You from, I would say like, a specially in
38:50
like Mongo. Sometimes you get like it, if
38:53
you have it, if you're building a document that has a lot of
38:56
relations and you might Nest a bunch of stuff in there, and you
38:58
can get really big documents. I've seen people do that before,
39:01
where China was going to cut you off from that stuff or like in
39:03
postgres, sometimes. You put like some Blobby type
39:06
data when a binary data image data and they're like, hey, you
39:09
know, you should probably put that Nest 3 and have a pointer
39:11
to that instead rather than betting it in your database.
39:14
But what Dynamo is for Is basically oltp applications,
39:19
right? So if you split your world into
39:20
oltp, and olap. Olap, like, olap is your
39:24
analytics stuff, right? When someone internally says,
39:27
like what was our total sales last week or total sales by
39:30
region or like the things that you use Snowflake and redshift
39:32
and different things for that? So, app, oltp is like your user
39:36
facing Superfast, lots of concurrent, but super fast
39:40
operations, right? So, when you go into Twitter and
39:42
you're typing in a tweet, they're saying a database that's
39:45
oltp right. It is One likes that tweet or
39:47
retweet that teacher sends you a message all that is oltp so the
39:49
things that are happening very quickly but on like smaller
39:52
records and individual message or tweet rather than
39:55
aggregations, all of our sales that happened last week, right?
39:58
So Dynamo is strongly strongly. Strongly focused on oltp.
40:02
It's not good at 0 app at all you shouldn't use it for oh app.
40:04
But strong it is really good for for OTP like applications
40:08
because it gives you that predictable performance.
40:11
If you have millions of millions of users, you're still going to
40:13
get that same performance profile.
40:15
So for Sample. Like let's say if you're
40:17
building an online ads Marketplace for dynamodb, be
40:21
good for that one. Yeah.
40:22
Access absolute. I believe like I'm not exactly
40:24
positive. I think like a droll, and I
40:26
think a lot of it, I'm sure a lot of online ads Marketplace,
40:28
use that, because I'll usually, that's going to be.
40:30
I key value type look up, right? Give me this particular thing,
40:33
like, Daniel is really good at getting individual records by a
40:36
key or getting a set of Records by a sort of known key, right?
40:40
So, like if you go to amazon.com and you want to look up all the
40:44
orders for me as a customer. Mer.
40:46
It can get the set of Records all my orders for this
40:50
particular user Alex, right? They can do that.
40:52
That super efficiently and no matter how much data you have in
40:54
your application is going to be good at that sort of thing.
40:57
So I have heard a lot of comparisons and like people
41:02
talking about trade-offs between Dynamo and redis.
41:05
Can you break down how you view the two of those and when you
41:09
would go with one or the other? Yeah, so I was let's start with
41:12
relics. I think that one's like a little
41:14
narrower. Rather's is Superfast, right?
41:16
It's coming an in-memory database often used for caching
41:19
type workflows, or or data that is.
41:22
Okay. To be lost came to ephemeral in
41:24
some way. So caching maybe like a session
41:27
store. Your application may be a
41:29
feature store, if you're working in an ml type stuff, but if you
41:31
want to do lots of very fast operations, redis is going to do
41:36
that. It's not going to persist to
41:37
disk debt. Generally there are some options
41:40
to persist a disk and things like that.
41:41
But generally it's not going to be considered a persistent
41:45
database like like MySQL and postgres or dynamodb where dymo
41:48
is going to actually purchase that two discs between right and
41:51
guarantee the durability of your data in certain ways.
41:55
So, I say that that's gonna be the biggest difference, you will
41:57
get Better top-end performance at a redis, you're going to get
42:00
good enough performance, usually out of out of dynamodb.
42:03
But also guarantees around durability availability and just
42:07
predictability of performance would be the the big thing
42:10
there. There are managed redis
42:12
Solutions. But again, those are going to
42:14
fall into what I call the instant space world where it's
42:16
like they're they're cutting off a slice of a server somewhere
42:20
installing redis on it and giving you connection to that,
42:23
and rather than being like that, multi-tenant, region-wide
42:26
service at Dynamo DB. He is and because of that
42:28
scalability with redis is gonna be a little harder it's harder.
42:31
You usually have to like add a new node and short across that
42:34
maybe size up your node but now is all your existing data gone
42:37
and and things like that. So just like scalability is more
42:40
of a sort of instance based process rather than just sort of
42:43
like a knob, you can turn with Dynamo.
42:46
End. Seeing how there is a lot of
42:50
databases out there and we were just talking about many of them,
42:55
but I go through my head and I think about so many that I've
42:59
heard in the last month or two just in the NL space, right?
43:04
When you're looking at databases and when you're thinking about
43:08
which ones to use, what are some things that you have in mind?
43:11
And you're like, I loved what you said earlier.
43:15
When you mentioned, how you prefer Sure to have your
43:19
database be opinionated so that I guess that's one thing that
43:23
you're looking at but it's also you're not really checking out
43:27
features. You're more thinking about other
43:29
things what are these things that you have in mind?
43:32
Yeah, I mean it depends a lot on the use case but definitely like
43:35
I like databases that have an opinion and be like hey we're
43:38
good at this, right? Dynamo basically from the top
43:41
and from the product people in their Engineers they're like we
43:43
are focused on predictable performance and that means will
43:47
give you certain things and we won't give you certain things.
43:49
And even their API is much more restricted compared to other
43:53
nosql databases like Mongo. Mongo DB and dynamodb both nosql
43:57
databases both are sharding their data under the hood across
44:00
multiple different machines. But I would say like, Mongo or
44:03
dynamos authoritarian Mago is libertarian, like, Dynamo won't
44:07
let you do some things and, and thinks it's for your own good.
44:10
And like, what let you do that? Mongo's, like, hey, do it all,
44:13
like, whatever you want to do, and I expecting you to be
44:15
responsible with it. And if you, if you model it,
44:18
right, then you can get some of that predictable.
44:19
Performance type stuff that you might get with our links, it's
44:21
the same under the hood, but you can also sort of you can hurt
44:24
yourself by if you do want it wrong, like you have enough rope
44:27
to hang yourself there. So we got that's Dynamite.
44:29
Like, dynamos thing is like predictability of performance
44:31
above. Of all and availability and
44:34
durability with that redis is, is opinionated, as well.
44:36
I think a lot of people want more like persistence and stuff
44:39
around redis. And you've seen some of that
44:40
added bit registers like, hey we are cash, we're super fast.
44:43
We're single-threaded datastore that that does in memory
44:46
operations and gives you certain guarantees around that.
44:49
And if your data is bigger than this and hey you can you can
44:52
manage sharding across multiple machines or different things
44:54
like that. But it has those sorts of
44:56
opinions about like what guarantees and what performance
44:59
you want from your data. I think the big thing is For
45:02
whatever use case, you're doing, understand what your needs are
45:06
and and understand them like pretty specifically.
45:08
Usually there's like one or two core things you need and some
45:11
people think well I need fast access on my data by also want
45:14
to be able to run analytics and do full text search and like
45:16
well you can get all that in one database but you're probably not
45:18
going to be happy with the results.
45:20
Like what is the thing that matters for you here?
45:23
And then if you need to pull in a different data source to
45:25
handle some of the other things I recommend looking at that
45:28
rather than trying to make one do it all.
45:31
On the sick mode. You have a very interesting blog
45:34
post, Kaepernick app makes a beaver stir-fry and let's prove,
45:38
a lot of people wrong about. Okay yeah so cap.
45:42
Yeah. So cap is helpful but probably
45:44
overstated distributed systems database type thing and it's
45:49
it's basically saying in a distributed system that's
45:52
holding data and replicating data across multiple different
45:55
systems, you need to think you get two out of three properties,
46:00
right? You get partition tolerance
46:02
which means there can be like broken communication network
46:06
communication between your nodes.
46:08
Which like if you're describing your data you basically have to
46:10
take that as a given that sometimes the network
46:12
communication between your node will be disrupted and then it
46:16
says in the event of that, do you prefer consistency, or do
46:19
you prefer? Availability and consistency
46:22
means all the data are. All the nodes are showing the
46:25
same data returning, the same data for a given piece of data.
46:28
Because remember, we're replicating it across multiple.
46:31
Right? So if I log into a system, my
46:33
username and I set my user name to whatever particular value and
46:37
now you have a network partition, right?
46:38
And I want to go change that that username value, you could
46:42
either allow you to make that change.
46:44
Knowing that some of those nodes won't get that communication.
46:46
That's we can serve like inconsistent data across
46:49
different people who are querying that that would be
46:51
choosing availability because you're saying, hey except the
46:53
right, no matter what be available to accept that, right?
46:56
No matter what or ideally love all The other one would be
46:59
saying hey if there's a network partition know we want to have
47:02
consistent data across that so if we can't replicate it all
47:05
those then we won't accept the right.
47:07
Right? Because we want to have a
47:08
consistent answer across that. That's a poorly explained
47:11
version of the cafeteria and why it's been around for a while and
47:15
it gets brought up a lot in because we're seeing more
47:17
distributed databases, especially with the Advent of
47:19
the cloud world. And we're like, I'm people are
47:21
worried about that. I would say, I wrote up some
47:24
stuff around data consistency because there's also this notion
47:27
of a bench will consist of In C, which is related to this, but
47:30
not exactly. But then people plot like the
47:32
cap theorem all the time and what Capper No Cap is is trying
47:37
to explain like does the cap, theorem strictly applied to this
47:40
particular situation. And and if so, like what are
47:43
they? Choosing is the choosing
47:44
availability, are they choosing consistency and that scenario?
47:47
What the what the things are, that was kind of a fun one.
47:49
I wrote, thanks for bringing that without here.
47:52
I was thinking that you were some hip gen Z say I have no
47:57
cap. Okay, II.
47:59
Think I even said in that box with a smile.
48:01
So I'm like 3034. My wife has some brothers that
48:04
are like 12 years younger, so I can college right now.
48:06
So I know some of the fun terminology from them like No
48:11
Cap. Like I had never heard my age
48:13
friends say that, but I've heard them say that I kind of know
48:16
what it means, based on that. So, yes, and for the others that
48:19
are our age. Apparently, I found out that no
48:22
cap means no lie. So I'm not Lyin and so true.
48:26
Yeah, exactly. No lies.
48:28
So, So dude, before we jump I want to ask you a few questions
48:31
about the book in like first of all its might be a little meta
48:34
but I think you can get it on Amazon, right?
48:37
You can buy some look on him. Can't okay.
48:39
So I used to not have that Min. This is the first place.
48:41
I've even like announced it now because so I had mostly just
48:45
it's basically an e-book tight version and you can get it.
48:48
I have a site for then it directs you to gumroad and you
48:50
can just sit there people have been asking for like, a paper
48:52
copy for a long time and I look in the copies and it's like, no,
48:55
it's like 30 bucks to print if you're doing, like, small orders
48:58
of stuff and Don't want to charge that I could just eat a
49:01
lot of margin and stuff. So but then someone told me
49:04
about Kindle Direct publishing which is basically amazon.com.
49:08
You can upload on there. I'm not actually sending a
49:10
Kindle book through there even though it's called Kindle Direct
49:12
but they will fit your books on demand for you.
49:14
So I've I just upload my file, created the book and all that
49:17
stuff and now you can you can buy on Amazon if you want to.
49:20
So, it's available there for like, yeah.
49:23
So, I bought, like, 30 author copies, I have I have some
49:26
behind me assign you. If some signed copies that we
49:30
can give to their like on side but I can look at that.
49:33
This one is actually on. That is awesome.
49:35
Yeah, one thing I realized is like the font is way bigger than
49:38
I, then I realized but it's like an old person's but kind of but
49:44
yeah, exactly, that's classic. So that should be like the
49:50
catchphrase of the book. You can read it without glasses.
49:55
Yeah, I'm kind of worried for like the first person to buy By
49:58
it and like, review it and be like, why is this fall?
50:00
So huge, like, what's going on? One story at a page, you had a
50:03
page minimum you had to hit before the?
50:05
Yeah that's kind of like big font on my computer I when I'm
50:10
reading stuff and so I think I just like when I generated the
50:13
PDF file, it made it made a big and I didn't realize it was like
50:16
weirdos until it's on the book. And just yeah, even though Title
50:20
by TVs, are things, I so smart about books, I should play this
50:24
game. And what can we expect?
50:32
I mean, what is in the book? Yeah.
50:34
It's just, I think understanding how, how Dynamo Works how no SQL
50:38
works. I think it's very different from
50:40
like the normalized world. You're used to, and you don't
50:42
need to throw all that out, but you weren't to see like, hey
50:44
when can I relax? Some of the my principles around
50:47
normalization. Also, how do I design
50:49
specifically for my ACCESS pattern to show what I think, is
50:52
different from people, coming from a relational World in a
50:53
relational world, you think? About your objects.
50:56
You normalize, those create tables and do all that stuff and
50:59
then you think how am I going to access those objects?
51:01
That's when you add your queries and maybe some indexes things
51:03
like that whereas Dynamo it really specifically wants you to
51:07
model for your access patterns. So you think first like if I
51:10
have a user, how am I going to retrieve that user by user, name
51:12
by email address? What is that and use that as my
51:15
primary key and things like that?
51:17
So teaches you those principles it teaches you the Dynamo API
51:20
and and ID like ideally the, the reason it is, the way it is
51:24
right now. I want to push like Hey,
51:26
predictability of performance is what we're getting here.
51:28
Here's the underlying architecture was happening in
51:30
Dynamo because of that, here's the API, they give you.
51:33
And because of that here's how you have to model your data and
51:35
then you get all those real good benefits.
51:37
You just have to learn how to model it, a little differently
51:39
than before. So some of that stuff, a lot of
51:41
like strategy stuff I call it strategy.
51:43
So it's like, hey if you have one to many relationships, very
51:45
common thing, how do you model that?
51:47
And here are five different ways, depending on sort of your
51:49
unique needs on how you can do that.
51:52
Same thing, with many, many relationships, filtering sorting
51:55
things. Like that.
51:56
And then it has a bunch of just like deep walkthrough examples.
51:59
Like weary we rebuild a bunch of GitHub for that or I could
52:03
recite and things like that, just to show what that looks
52:05
like. That's awesome.
52:08
If you were to make some changes onto the rug, let's say you
52:12
decided, once again, I'm kind of pretty equal amount of
52:15
everything, you know, forget to sleep, but what would be the
52:19
chapters, you would be Outta Connor?
52:21
What would be the chapters? You would be expanding on?
52:24
I think. Like so one thing in Dynamo is,
52:25
is this concept called single table design where you put a lot
52:28
of different entities into a single dynamodb table rather
52:31
than Separate Tables like you would in a relational database.
52:34
And I think that's like one of the big mindset shifts are Wow,
52:37
this is so different. I think that could be useful.
52:39
I think it can be useful for like, teaching people how it
52:41
works particularly. But like, I think the book maybe
52:44
goes too far in the direction of, like, you have to do it this
52:46
way. I think, understanding of more
52:48
the principles of like modeling for your access patterns, things
52:50
like that, but if you don't have like, these sort of two or three
52:53
unique needs, it's fine to have multiple tables and and, and
52:57
things like that, and make it work that way.
52:59
So disgusting, I think some of the trade-offs and Nuance around
53:02
that, I would definitely do a lot.
53:04
Do a lot more on that. Yeah, that would be the big
53:06
butt. You're giving me nightmares just
53:08
even think about like every visiting and spending that much
53:11
time on the book. It was that I really love doing
53:14
it. Like, when I was in it, I was
53:15
like deep down into it but I like near the end.
53:18
I was like, I just gotta get this out and never touch it
53:21
again and it's hot. Like I want to do a revision but
53:23
it is really hard to like look at it and think the do I want to
53:26
redo this whole thing? How does it all tie together
53:28
things like that? Well then let's just imagine
53:31
that you didn't do a revision and you decided to write another
53:35
book. What would the next book be?
53:37
Oh man, I've so I've pondered for a long time of doing like a
53:42
general serverless book, or course things like that.
53:46
So three ideas that keep coming back to me, one would be like a
53:48
general sort of service ideas and course and things like that.
53:52
Focus on a devious Lambda. Answer was architectures.
53:54
The second one would be one called Amazon Cognito, which is
53:57
basically it's a user authentication Service from
54:01
Amazon from AWS and it gets a lot of Guff people, dealt love
54:05
it, but I think that's how diamonds.
54:06
Mo was before some people at AWS and myself, we started like
54:11
evangelizing how Dynamo actually works.
54:13
I wonder if Cognito is mostly an education problem rather than a
54:16
product problem and could use like a book that way.
54:19
And then I would like honest, I kinda want to do one called like
54:21
databases for developers or something like that.
54:23
I submitted a talk somewhere to do this where I just want to
54:26
talk about like seeking out these different databases and
54:29
like again like what are we here about?
54:32
SQL, no sequel. Caching, we hear about indexing
54:35
with elasticsearch where Houses. How do those differ?
54:38
How like, if I'm like a full stack developer and I don't have
54:40
time to learn all the nitty-gritty intricacies of
54:43
this. Like, one of the key principles
54:45
you should learn from each one to learn some of that stuff,
54:47
like, all the stuff that I learned slowly, and painfully
54:50
over the last eight years and like, in a bad way in the last
54:52
eight years. I guess specially not having a
54:55
computer science background, right?
54:56
I went to law school like the book that I wish I had then to
55:00
to do that. So yeah, it would be that sounds
55:02
so good. Yeah.
55:03
So I got to ask the high peak question.
55:06
Especially likes to it. You being so deep in the
55:10
database world and you inevitably have probably seen
55:14
like, the rest of us. How much chat GPT is taken over
55:17
the internet in the last month or two.
55:21
And so you aside from like the obvious, Answer, which would be
55:26
okay. Just getting chat.
55:28
You can see to help me right database queries.
55:32
What are some things that as you're looking at databases you
55:35
think potentially AI or maybe a few iterations down the line, a
55:44
chat GPT could help you with in this this world that you play
55:49
it. That's interesting.
55:51
Like why did? That's that's interesting.
55:53
I hear people talk about a lot is just sort of like smarter
55:56
indexing and things like that. I think a lot with a bike
55:58
relational databases, you have to set up these indexes and a
56:00
lot of times people cream more in taxes than they need, and
56:04
don't know which ones are getting use or create an index.
56:06
It is in particular effective. I think just understanding like
56:10
where you need those sort of indexing and helping with, if
56:13
you could understand your access patterns or even understand the
56:15
queries are actually going against your database and
56:17
smartly adapt to that. I'd heard people talk about
56:20
that. That seems far off.
56:21
For me, I always think there's like a trade-off between like
56:24
abstraction like the more abstract something is maybe it's
56:28
like easier to handle. You don't have to notice much.
56:30
But you also I think lose some performance or specificity
56:34
around that sort of those things.
56:35
And like I think with Dynamo You have to be more specific, you
56:39
have to learn how these things work.
56:40
But then you get those sort of performance benefits, whereas I
56:43
give your abstracting it more into like a normalized model
56:45
with relational databases. And using a query planner, you
56:47
lose some of that but maybe it gets to a point where the query
56:50
planner and the index. Planner it, all that stuff is
56:53
smart enough where we don't need to craft our our data models
56:56
anymore, and it can help us a lot with that.
56:58
So, that'd be, that'd be the thing I'd be looking out for
57:03
same with like data warehouses to write like understanding what
57:06
you're going to aggravate understand.
57:07
How you're going to be filtering stuff to Align data on disk and
57:10
in helpful ways just reducing like the cost of data model
57:13
because man, a lot of developers just do not want to learn data
57:16
modeling and circle live. Like I think it's so fascinating
57:19
it all the data stuff, but then like a lot of people were just
57:22
like I just want to get what it is and and get on to other stuff
57:24
and and and don't understand like the principles there how I
57:28
stood this has been awesome and thank you so much.
57:32
Absolutely thanks for having me. This has been, this has been
57:34
really fun. Great to meet you both and
57:35
thanks for having me on. Is Skyler.
57:44
I lead machine learning and health rhythms if you want to
57:47
stay on top of everything happening in ml.
57:49
Ops, subscribe to this podcast. Now.
57:54
Now, now, now now now Now.