Alex DeBrie: DynamoDB Adoption, Creating Info Products, and Transitioning into Tech

About Alex

Alex is a trainer and consultant focused on helping people using cutting-edge, cloud-native technologies. He specializes in serverless technologies on AWS, including DynamoDB, Lambda, API Gateway, and more. Alex is an AWS Data Hero and the author of The DynamoDB Book and the creator of DynamoDBGuide.com.

You can find him online on his website, Twitter, and GitHub.

Transcript

Adam: Hey, everyone. Welcome to AWS FM, a live audio show with guests from around the AWS community. I am your host, Adam Elmore. And today I'm joined by Alex DeBrie. Hi, Alex.

Alex: Hey Adam, how are you? Thanks for having me.

Adam: I'm doing well. Thanks for joining. I've been so excited to have you on, somebody that I've looked up to for a long time within the AWS community. And you're the author of the DynamoDB Book. And I want to call out here at the beginning that at the end of the episode we're going to do a couple of giveaways. We'll give away two copies of the DynamoDB Book. So, stick around and we'll be doing a random drawing here at the end. Yeah. So let's start there. I kind of wanted to, obviously we're going to talk about DynamoDB but there's so much content out there you speaking, writing about DynamoDB though I want to make sure we kind of cover some other topics. So some things that came to my mind, one is sort of, this journey of writing the DynamoDB Book and sort of getting it out there, the whole process kind of just that whole story. If you could kind of share some, just wherever you want to start on that.

Alex: Yeah, sure. Man, I still feel like I totally fell into Dynamo by accident and just really lucked out in a lot of ways there. So, in terms of the writing and stuff, my background I was working at Serverless Inc that makes the service framework and I was on the growth team for a while. So I was just like interacting with a lot of people and they're trying to figure out how to use Serverless And a lot of times it's like a little bit on how to use our tool and a lot about how the heck do I use AWS and what are all these different services. I just ended up writing a bunch of blog posts on like, "Hey, here is how you do this somewhat hard thing."

Alex: It makes it easier for you but it's hard to understand how all these different pieces connect together. So, I just wrote some of those posts around that stuff and met some great friends that way. Also just so many people using DynamoDB in the early days, I think partly because it was the easiest demo to show. It's like, oh, you can provision a cloud formation, you can get some key value store and write a blog post about my service application. But a lot of other reasons Dynamo works really well with Serverless. So then, I'm seeing more people do that. And I'm like, okay, it's sort of working for me, it's sort of not. Then I see Rick Houlihan's talk at re:Invent and just blows my mind I'm like how all this stuff is supposed to work.

Alex: So I just watched that a bunch of times and started creating Dynamo content including, DynamoDB Guide, which that was... Basically I watched Rick's re:Invent talk and then over the Christmas holiday one year I spent like two weeks just working on this micro site 30 pages about DynamoDB, DynamoDB Guide. I'm trying to explain some of these concepts in a way that I could understand and learn it. That was the first time I published something under my own name rather than under the Serverless, Inc names. That was scary for me to be like, "Hey, I made this thing and did it." Feels like by far the best thing I ever did sort of career wise. It just like helped me in a lot of ways. I got to meet a lot of interesting people from that.

Alex: It reminds me of, I can't remember if it's patio11 or Schwicks or somebody, but there's this sort of notion of friend catchers and the internet is this giant place, right, and do things that catch you friends that are interested in similar things as you or just building this community and DynamoDB Guide is definitely an awesome friend catcher for me. I just got to meet cool people, which is great. I'm in Omaha, Nebraska, you're in Missouri there's not a ton of tech people in my area, especially in the AWS space but because of this I got to meet all sorts of interesting people some of who were on this call and you of course and just like a lot of interesting things. So that was a ramble for [crosstalk 00:03:44]

Adam: No, that's good. And I wanted to get to it later in the show but I just have to point out that we do have the sort of Midwest connection here in the US. There's not a lot of... I don't know, I talk about it occasionally with folks. It's like not a lot of tech literacy and I don't know... One of the things I want to ask you on the call just a curiosity of mine I don't know if anyone else cares about this, but what do you tell people when they ask you what you do at the grocery store or whatever?

Alex: Yeah. I almost always say I'm a computer programmer because that's just like the easiest thing for people to understand. Software engineer, I think sounds too pompous and just people are like, "What does that mean?" And so I say computer programmer, and then that works for 90% of people. And then there's another 8% of people that are like, "Oh, I know someone else that does this. What kind of stuff are you working I might tell them." And then every once in a while you just like stumble around someone that like has heard of AWS and I'm like [crosstalk 00:04:32]. And then we talk about that. I go with the broadest, easiest level first and then wait for people to... If they want to dig in more and hear more about that then I'll go into more depth.

Adam: Yeah. I don't even know if I say programmer. I say computers first and then sort of latch onto that. So you wrote the DynamoDB Guide and then how long after that before you wrote or started the Dynamo DB Book?

Alex: That is a good question. Let me think. Okay. So I think I released DynamoDB Guide in January, 2018 and then it was like July or August of 2019. So the next year, a year and a half later that I really started to get serious and be like, I think there is a thing here. I mean, when I wrote DynamoDB Guide, I did not know what I was doing at all, but again, that friend catcher, people would reach out to me with questions and I'd be like, I don't know how to solve that but let me think about it and all that. So I that just like... I became a focal point for some class of people that would sum up upon that and we'd just hash stuff over. And so that was great to do that.

Alex: And then after a year and a half of some of that and I even worked with the AWS team and some of the marketing teams on their material and stuff, and I was like, okay, I think there's enough for a book here. And I knew I was going to get named a data hero that fall and I was like, okay, around that announcement would be kind of a good time to announce it. So, I started working on it. I think I announced it when I was announced as a data hero, which is like September of 19, but then I was not making any progress on it because I was still working at Serverless. I was super busy and then that December at re:Invent I was like, okay, I need to go full time on this. I think there's a good space for it.

Alex: That felt like a leap of faith just in the sense of... I think my wife believed in me and I believed I could be useful but a lot of people were like, "Wait, why are you like quitting a tech job that pays some money so you can write a book for four months or something like that. And who writes books, who reads books, who pays for books? And especially like in niche technical book, who does that?"

Alex: I sort of talked with some of the people at AWS, in the marketing department and even with them, I think there's some skepticism that was going to be useful or not like skepticism, but just not any excitement or something like that. I think that was part of it just making sure I'm okay. I really think there's a space this listening to Adam Laban and some other people that have had successful info product launches. I was like, I think the economics make sense for this. I think there's a hole in this specific area and I think it works so, yeah. Go ahead.

Adam: I mean, it's gone well now. I feel like if anything, you've got the Cognito Book being written. I feel like the could sort of start like a whole series of AWS services and the book for that thing because it's the DynamoDB Book that's pretty cool.

Alex: Yep. I'm hopeful. I like to see that stuff like the Cognito Book from David Wells, there's also the IM... I can't remember it's called the IM book maybe or my IM Guide from, oh I can't remember, Rowan. A lot of good stuff coming out. And I think some opinionated guides or just at least specific to certain to use cases and saying, "Hey, here are the features that matter. Here's the ones that don't." Because I think it's hard for AWS to do that. And people rag on their documentation and it's just a hard job they have. They have to appeal to everyone, cover all those features and they can't really say, "Use this part, don't use this part." Or things like that. I think the documentation for a lot of services is pretty good and once you know AWS and it's great reference material, but again, if you want some sort of opinionated onboarding type thing, it's just a harder thing for them to do so...

Adam: Yeah, so talking DynamoDB, one of the things I wanted to ask you is sort of your view of adoption within the broader, we'll say broader web community, because there's so many different technical communities. And I think being on Twitter sort of biases toward this sort of web dev community. I constantly feel like it's underutilized. Do you think that's true or do you think you see a lot more of sort of DynamoDB adoption from your position?

Alex: Yeah. But I also see like an even more biased view than you do. I see all the time people are like, "Yeah, I love Dynamo." And stuff like that and tweeting stuff out. So then it's like, I get a biased view that's going better than I think it is. I think it is continuing to pick up momentum in the Serverless community. That's been true early on where a lot of people started using it and some dropped it in frustration. I think it's just around understanding how to use it and some of the feature type things, but I think that's continuing to get better. And I think one thing that's good is just like a growing awareness in the community of the trade offs of Dynamo and what those are and why those matter.

Alex: And some people don't want to take on DynamoDB's downsides and then that's totally fine with me. I mean, it's interesting because MongoDB is very similar in a lot of ways but just completely philosophically different. And because of that it's like, you can't say one is right or one is wrong. I don't think about those. It's just like, hey, what works for your scenario and like... I don't think MongoDB would work well for AWS internally, because they're at a scale where I think that would be problematic for them or DynamoDB I think fits really well with their needs. They have a huge engineering team. They want to make sure these things are in scale consistency and sort of enforce that works great. But if you're like a smaller startup getting started and you're not going to have those immediate scaling concerns, you have a pretty small team to enforce some of these things. I can't tell you that Mongo is wrong there so, yeah.

Adam: So, from your perspective you do a lot of consulting work. You've probably seen some Dynamo implementations that maybe would be surprising. We all know about amazon.com and the shopping cart or whatever. Could you tell us about any kind of implementations that maybe would surprise us? things people are doing with DynamoDB or customers that are using it that maybe aren't publicly super talked about?

Alex: Yeah. I'm trying to think. I never know on this stuff because I don't know if I can talk about [crosstalk 00:10:49] I just don't even know the rules on some of that stuff.

Adam: Maybe not one of your clients. Do you even know of just people using Dynamo that would make me feel better about DynamoDB adoption. I know it doesn't need me to feel good about it but-

Alex: If you want to talk about other big clients, I know Intercom uses it and they vlogged about switching from some of their stuff to Dynamo to handle some of those things that are pretty high scale. And one thing I saw pretty recently is a lot of times Rick Houlihan will show this charts showing they can generate internally and it just sort of shows your partition access across time and across partitions in Dynamo and you basically want a pretty even access both across time and across partitions to your table. And he always shows this one example chart. He's like, "Hey, this is a great well distributed chart." And I just found out recently that that's from Intercom.

Adam: Oh, nice.

Alex: So he was mentioned that with... He had an exchange with someone on Twitter from Intercom about that and he said he still uses their chart. So, that's pretty interesting to see that background.

Adam: No, I didn't know that Intercom... I hadn't seen any of that so-

Alex: Yeah, they have a good post if you want to about switching to Dynamo for certain to use cases. Yep, so...

Adam: Yeah, now that'd be super helpful. You've mentioned sort of the downsides or the tradeoffs, I guess with DynamoDB. Did you see, I guess yesterday Jack Ellis, the CEO founder of Fathom Analytics, they sort of wrote this post about moving away from DynamoDB. Have you seen that? Do you have any takes on that?

Alex: I mean he's off my Christmas card list for sure. No, I know Jack, he's a good guy. We've been talking about doing this book together about Dynamo and Laravel as well. I understand it. They have a hard to use case. They have one of the hardest to use cases to handle in sort of all of data access which is like, "Hey, I want to show fast, giant aggregations." That's a hard problem and a hard scalability problem. It sounds like SingleStore is working out well for them. I don't know enough about SingleStore So I can't comment on that. I always expect if you want fast, large aggregations you basically just need to pay out the nose but it seems like SingleStore is working pretty well for them. So in that case, that's great to hear more power to them. As part of that they even had to switch up some of their architecture.

Alex: They had to switch off the Lambda to Heroku just so they could get more persistent connections to SingleStore. They're doing well and they have a lot of scale that they need to work out and because of that you need to approach things differently and aggregations is not going to be DynamoDB's strong suit, especially very flexible aggregations, right. They want be able to say between this time and this time, which is totally user set and if it has this flag and this page or whatever, show me the total counts over time, it's something that you can't really pre-calculate with Dynamo and then it gets difficult.

Adam: Yeah. So that was way too diplomatic and not a hard take enough for me but I'm going to let it slide. So I guess that's sort of a very specific use case where DynamoDB maybe isn't a good fit. Are there more common use cases that you would say Dynamo really doesn't make sense here?

Alex: I would say the ones that are the trickiest would be... Hey, if you have pretty complex filtering requirements over sort of large data sets so, if you're running a CRM and someone might have 10,000 or 20,000 or 50,000 contacts in their CRM and they've each got 30 different columns and you want to be able to say, hey, where the last time I accessed them is greater than this and the customer type is that and all sorts of... All these filters, all of which can be optional or included, it's hard to do that because Dynamo is going to excel at fixed access patterns and you might think, hey, I want to filter my CRM. That's a fixed access pattern, but it's not. It's actually, you need to be more specific than that.

Alex: I want to filter by customer type. I want to filter by customer type and data access. It can do that really well. But if you have those really flexible ones, again, that's a hard problem to do generally, but Dynamo is going to be kind of tricky at that one. So that aggregations is another one. And then the other thing is, hey, if you're really good at you understand my SQL, you understand Postgres really well and you're not going to be hitting high scale or you know the sort of foot guns to avoid and some of those things like, again, more power to... I don't want to besmirch anyone if they [crosstalk 00:15:12] so...

Adam: And I think that's some of the pushback I have heard just like in conversations with folks is like, we have experience with SQL. We know how to work with Postgres or my SQL and the tooling is all there. How do you feel about DynamoDB, the sort of developer experience? There is tools out there, Dynobase, there's the NoSQL Workbench. How do you see that evolving? Do you have any thoughts on that?

Alex: Yeah, I'm pretty bullish on this area just because Dynamo has been around for nine or 10 years, whatever, but I think the first six of those years, it's mostly people with enormous scale problems, writing Java, things like that, the super heavy back end engineers or DBAs doing that stuff. But now with Serverless you're seeing this different crop of people coming in to use Dynamo. And these are people that, more JavaScript, just like a better sense of DX and just like a much larger community, I think. And you're seeing whether it's client libraries like onetable and DynamoDB toolbox and a bunch of different client libraries. That way or like Rafal is doing with Dynobase like the AWS team has with NoSQL. You're just seeing more people that are good at that stuff get into it.

Alex: I'd love to see in terms of toolings perspective something that connects both the modeling with the operational stuff. So, Dynobase does a great job on the operational stuff. Hey, my table is already there. I want to query it in a particular way, handle some of that stuff and do it. And NoSQL is pretty good the modeling part but I think mirroring those would be good. And you see Rafal with Dynobase moving in that direction right now. I think there's a lot of potential there where if you can generate your model, have those examples, export those to your things but then also query based on those access patterns in Dynobase and handle that, that would be pretty slick.

Adam: Yeah. It's sort of like he's moving into the single-table. Well, he's coming on next week. We're going to talk a lot about Dynobase I'm sure.

Alex: Perfect.

Adam: But he did just sort of announce this new feature, which is folks around single-table design and kind of getting into the run time side where he's like... I think before maybe Dynobase generated code but now we're talking about libraries that would actually sort of be in your Lambda functions or whatever. In terms of single-table design. One of the things that I know has been a hang up for me is I really like AppSync. So I really like building out GraphQL APIs. And I feel like single-table... Is it inherently opposed to a GraphQL schemer? Is there a way to marry those two?

Alex: I think it depends on who you ask of it. Rich Buggy has done some good content in this area and shows how he does the single-table design with AppSync. My sense is you don't get quite as many of the advantages. It's a little harder I think to do with AppSync. You sort have to eject out some of AppSync's niceties to get that to work. So if you're interested in doing that, you can do it. You also sometimes might have to run against, I would say, how GraphQL is designed to work like maybe do some look aheads and feel like, say like, hey, do I want to fetch related items while I'm doing this stuff?

Alex: So, some of the more standard parts of single-table design might not work as well as AppSync, but I think it's a good system to use together. The big thing there with GraphQL and having these resolvers. I think the hard part you get into is if you have these really nested resolvers or you have to make so many queries to satisfy it and that's going to be true whether it's Postgres or whether it's DynamoDB, but Dynamo is going to be good at handling that stuff. It's just like some different patterns than a single-table design usually.

Adam: Yeah. And I've read your book. So I think I know the answer to this, but I'm going to ask it anyway. Do you think single-table design is like a trade off or is it just always the best approach?

Alex: I'm probably more trade off type person. I think much more important than single-table is understanding the data modeling principles and making sure you're modeling specifically or DynamoDB. And that generally means, hey, you're not accessing off your true attribute values, you're accessing based off these combined values or short of special values that are done just for data access, right. So I really believe in splitting up your DynamoDB items into what I call indexing attributes or application attributes. That's what you actually use in your application. You're not querying directly off of those generally, but indexing attributes are like, hey, this is how I access my data efficiently. With Dynamo you're just thinking about efficient access and then you offload the rest to your application and do stuff there.

Alex: So, I think if you're thinking about it that way and you still want to use multiple tables, that's fine with me. The thing I would say there is if you're thinking about that way, you also realize that combining it into a single-table is not that big of a deal. You don't really think about tables or not tables at that point. I think there are some more operational factors to think about with sometimes multiple tables might be just easier to reason about that way or easier to use. Whether it's streams and you want to have some different patterns based on different items or whether it's you occasionally need to do full scans of a particular item and that's easier if it's just segmented into a different table. I think that can all work. And so, when I'm thinking about tables it's more operational concerns rather than specific modeling concerns.

Adam: Yeah. Well, I've got theburningmonk on tomorrow. I know he has opinions about this as well. I'm sure we'll kind of cover some of that. [crosstalk 00:20:41]

Alex: I was going to say, I'll have burning ears while he's [inaudible 00:20:48]. You should ask him about the background on his name, by the way. I just found that out in like [crosstalk 00:20:54]

Adam: Yeah. That's one thing I wondered if I could find that on the internet somewhere. I was very curious.

Alex: Yep. So, that was that.

Adam: We'll save that one for tomorrow a little teaser. So, I wanted to talk a little about your background. So you have kind of a nontraditional background in tech coming from practicing law. You were a lawyer.

Alex: Practice, yeah.

Adam: Could you tell us a little bit about your story there?

Alex: Yeah. Practiced briefly there. So, basically, yeah, I went to law school after I graduated. My wife and I both went to law school together, partly because I didn't know what else to do but I didn't have a tech or programming background before law school. I took one introduction to computer science class in college and just hated it. It wasn't actually any coding. It was sort of writing pseudo code in a notebook and thinking about loops and stuff. So, not fun. So I just didn't do any more of that, even though I was kind of interested in computers and stuff, but then yeah, I was doing law school and I really enjoyed law school. We both did. Met some great friends there and I also think it's just super fascinating. You learn a lot about how society works and just different things.

Alex: And worked at law firms in the summer. While I was there, I met a friend at my law firm that was into tech. And so he had this idea of like, his dad was a farmer. He wanted to put sensors in farmers fields to check their soil moisture and send that up somewhere. We process it, we'd show them in a webpage and they could figure out whether you're [inaudible 00:22:20] or not. So, and then my brother-in-law, he's a data science guy. So they're like, "Hey, let's do this together." He's sort of learning programming. So they're working on it. I wanted to help. And I was like, "Well, I can write the business plan or something like that which is totally useless." So I did that and it was fine.

Alex: And then I was like, "Okay, I still want to be involved. What can I do?" And they bought me Two Scoops of Django, which is this book on Django.

Adam: Yeah, I'm familiar.

Alex: Okay. Yeah. So DJango is this Python web framework, right. And they're like, "Hey, learn Python, read this book and start working on our webpage for us." Right. So, I started doing that during my last year of law school, which like your last year of law school is a joke you don't really... Most people have jobs by that point so the grades don't matter anymore and things like that. So I had a lot of free time, so I'm just doing that and I really enjoyed it and just kept working. It's very consuming. And we had a kid at that time, my wife was pregnant again, but that was what I wanted to be doing and things like that.

Alex: So kept working on that the summer when I took the bar. I worked as a lawyer for nine months and then... But I just kept wanting to do tech and so then I made a switch and jumped but it's funny at my law firm, right, we had these junky windows laptops, I couldn't do any... But not laptops but like desktops, right. And sometimes I'd have some downtime I'm like, oh, I want to be working on tech and I couldn't do that, but so I would use Cloud Nine, which was not a part of AWS at that point. It was the funny, independent thing for [inaudible 00:23:56]. So I used Cloud Nine to keep working on my tech when I was at my law firm without in installing Python on some windows desktop from [crosstalk 00:24:05]. Yeah.

Adam: So, with your background in law, I've got a very important question for you. In your lawyer opinion, I'm putting you on the spot, is AWS FM going to get taken down? Do I have a shelf life here where AWS is going to come after me and this thing's all gone?

Alex: Well, first of all, I shouldn't be a pining on this because not only am I not a lawyer, but I am a suspended lawyer because I stopped paying my dues. So they sent me a letter. I got a letter from the Nebraska Supreme Court saying I am suspended [crosstalk 00:24:35].

Adam: I'll take that.

Alex: I don't know. My wife did more of the trademark stuff. I would say, no. I would say they probably could, but hopefully they won't. I think they're decent about letting the community sort of do some of that stuff. I have DynamoDB Guide and I show the logo giant on the screen. I have DynamoDB [inaudible 00:24:52] and they don't do anything. So I hope they'd be good about it but I don't know. That's interesting if they actually wanted to.

Adam: Yeah. I don't know. The colors might be a little... The logo might be a little much. We'll see, hopefully I can get away with this or rebrand.

Alex: Yeah. I was thinking it should be AWS AM, right, because we're just like a talk show. [crosstalk 00:25:08]. But that's not going to solve your trademark problems [crosstalk 00:25:18].

Adam: Also I don't think the domain is the thing.

Alex: Yeah, you got all kinds of problems there.

Adam: Yeah. So, the Two Scoops of Django, the author, Roy, is a husband and wife, Roy Greenfield, is that right?

Alex: Yep.

Adam: So we had a [crosstalk 00:25:31]. Oh, Daniel. Yeah. Thank you. So he worked at a company, an insure tech startup that I then joined, I think after he had already left, but we've worked at the same place. So I'm very familiar with him and his work and it was just sort of the Python shop.

Alex: I love it. That was such a useful book for me and it's weird because it has come full circle because now he's bought the DynamoDB Book. We've talked on some of that and it's just like it's so weird to meet your heroes sometimes and [crosstalk 00:25:59]

Adam: ...the show has been an opportunity for me to meet my heroes. It's so great to have you on for this. I think we do have a connection, another sort of shared similarity. I think I had Paul Swale on the first episode and you're also sort of an independent AWS consultant. I'd love to hear some of that journey for you. One question I have for you specifically is, does everybody just come to you for DynamoDB? Is it like, "Hey Alex, we want to do this thing with Dynamo and you're the DynamoDB guy." Or do you get like, "Hey, can you help me with my load balance or whatever?"

Alex: I don't get a lot of load balance or stuff. I get a mix of DynamoDB and Serverless just because a lot of people know me from Serverless stuff from my blog post on servers.com and work there. So, I would say it's probably 75 25 Dynamo verse Serverless at the moment. But it's a lot of people that are using Dynamo with Serverless too and so it sort of even blends together at that point. But yeah, mostly Dynamo stuff which I'm really enjoying. And it's making me think of like, oh I want to re-explain this from the book I want to...

Alex: There are all these things I want to update from the book and just never have time to do and another thread just related from consulting, the interesting thing I've been sort of wrapping around my head and I need to formalize this some way is... One thing I like about Dynamo is just how easy it is to calculate out the questions. A lot of people are like, "Hey, we want to do this. Is that going to be expensive or not [inaudible 00:27:29]?" And it's like you can actually figure that out. You have this many items, you want to do this with it. You know exactly what the right capacity cost is or re-capacity if you're doing on demand, you can, in a spreadsheet, calculate that out and show that.

Adam: Now, is that even possible, in a traditional relational data store?

Alex: I mean, not that I know how. We have Frank on here I see. And Frank we always go back and forth on relational and Dynamo and he's a good guy. So maybe he would know some of that stuff. I don't know if we'll have to pull him on here, pull him up on stage or not. But yeah, that seems hard to me to know some of that stuff. And another thing too, is sometimes people tell me stuff I'm like, "Oh man, that's a lot of items. Is that going to work? How's this going to work if I'm fetching this many items?" And I'll run through it, I'm like, "Oh actually that's three queries worth of items that you limited down to these attributes. I don't know. Like there are all just ways you can, you can sort of think about how you want to, you can weigh the trade offs easy with, with easier with Dynamo, I think without having to do sort of a bunch of load testing or something like

Adam: It's got more of that predictable sort of performance that we all love. So, I can remember your post when you went sort of independent, how long ago was that? That hasn't been- [inaudible 00:28:47]

Alex: I mean, it's sort of a weird step there. So, last January, January, 2020 is when I left Serverless to go write the DynamoDB Book and basically spent most of the next four months writing the book. I took a few consulting contracts in there too just to keep myself sane and because I'm just writing all day and this is driving me nuts. So, I did a little bit of programming there too, but mostly doing that. Then I did consulting for three or four months. And then actually, I think I got a little stir crazy and the aimlessness of it was getting to me.

Alex: So I joined Steady for a few months which is a great company, a lot of great people. Yeah. So I was at Steady for five months and I was like, you know what, I did like being on my own, especially the flexibility around, we have four kids and just being able to go to their school stuff and not that Steady or other tech companies don't let you do that, but it's just like, when I'm at a job and I have these other people, I just feel this intrinsic responsibility to be there and be on all the time and its harder for me to separate that. So, going on my own, I really like the flexibility so-

Adam: Yeah, definitely.

Alex: Anyway, along with the answer to say, a little more than a year and a half with a five month respite in there.

Adam: Yeah. Well, if you're going to be anywhere for five months, Steady would be the place.

Alex: Exactly. Yeah.

Adam: I think every one of my guests now at this point has worked or will work at Steady.

Alex: It's true. Yeah. [crosstalk 00:30:19]. They're a great place so...

Adam: And you worked from home a long time then I guess. Were you at home with Serverless?

Alex: Yep. Yeah. So, Serverless was based in San Francisco when I got there with some remote folks. I think I was the first US based... Yeah, there were two of us hired at the same time. They were the first US based remote folks. We also had some remote folks in Europe and things like that. But yeah, it became more just distributed as we went. But yeah, I've been working at home for, jeez, I can't even think now, probably about four and a half years. About five years. Four or five years, somewhere in there. And yeah, I like that. Well, at our old house we did not have the, the space so I actually had to go to my in-laws house and just use one of their spare bedrooms. So it's sort like I'm going to the office every day and do that.

Alex: Which was good. It helped separate stuff. Now we have a new house and I have an office here and it's good but it's tempting to be always on. I think the big thing for me is, I used to take my laptop everywhere and then just work from downstairs, open it and things like that. Here I have my laptop closed and hooked up to my monitor and all that stuff and it's like, I can't really work without the monitor now and I'm not going to move the monitor. So it's like, I have to be in my room in the office to do that. And it's easier to separate work from life a little bit.

Adam: Yeah. I mean, I've worked from home for a long time. I feel like the last year it's harder than it ever has been and I think... Yeah, I don't know if it's a stir craziness but being in the Midwest, working from home has been fantastic because there's not... I mean, as you know, there's not a lot of local opportunities in the type of stuff that we do.

Alex: Yeah. Definitely.

Adam: I know it's surely out there, but-

Alex: The remote work discussion is like a fraught one and I'm not going to say remote work is like the only way. I'm super grateful for the opportunities it's given me because again, we're going to be in Omaha. That's where we have roots and it's given me a lot of opportunities. I think there are benefits to being in an office that I'm not going to get and I totally acknowledge that. So, I get people want to do the office too but I do like the flexibility of remote and the opportunities it's given me.

Adam: Yeah. And on that note, so what are sort of the future plans for Alex DeBrie? Are you going to write another book? Are you writing another book and I just didn't know it? Are you all in on the consulting?

Alex: I don't know. I ask myself that a lot, I've thought for a while about doing a Serverless course, just because I think I'd be interested in doing that.

Adam: I'd be interested in taking it.

Alex: No, I don't think so. But the hard part too is I've been doing so much with just Dynamo lately that I have been doing less with Serverless and I'm where my knowledge is atrophying. If I did a big project, that would probably be it, but I don't know. I can't decide. I'd also like to do a product and stuff like that and just stay focused on doing some coding there. So I don't know. It's hard for me to say so in that respect I'm mostly on cruise control, I would say I probably wouldn't do a book unless it really felt right. And I think Dynamo felt right in the sense that I think a lot of the stuff in Dynamo is not going to be changing for a couple years.

Alex: They'll add some new features and stuff. We'll change a little bit, but it's mostly going to change around the edges and those core principles are really going to work and that's why I think the book was useful. And also I think the linear nature of the book made sense for that. But if you did a book one Serverless and there have been some good ones out there but it's hard just because the space is still moving so quickly and different things happening now it's hard to stay up to date with that unless you're updating pretty frequently. And then how do you get it to people?

Adam: It has been so great to have you, Alex, I've looked forward to this. I mean, I think when I started the idea of this show, it was like you were on my short list of people I'd love to just get on the phone with, and why not do it with other people listening in where they can hear all the things I'm going to get to hear. Yeah, it's been great.

Alex: Thank you. I appreciate that. Yeah. I've been meaning to get on a call and meet you too because we've interacted in DMs a little bit and on Twitter, but like actually getting to see and talk to each other has been great. So yeah, for sure, it's been fun.

Adam: We'll do it again sometime. I'm not put planning on stopping. I have sort of booked out a whole lot of these. I'm kind of committed at this point. I don't know. Sometimes I regret it and then... But it's been so much fun. So, thank you to everyone that's joining. Thanks for hopping on live with us. And obviously we'll put it up on the podcast platform for everyone else to enjoy later.

Alex: Cool.

Adam: Thanks again for joining and thanks I Alex.

Alex: Yep. Thanks all.