Screaming in the Cloud - DynamoDB The Database of Choice for Serverless Applications with Alex DeBrie

Episode Date: June 11, 2020

About Alex DeBrieAlex is an author and self-employed AWS trainer and consultant focused on serverless & cloud-native technologies. He has been recognized as an AWS Data Hero for his community work with DynamoDB and other database technologies. In a previous job, he worked at Serverless, Inc., creators of the Serverless Framework. If you go even further back in his employment history, you'll see Alex had a brief stint as a corporate lawyer.Links ReferencedThe DynamoDB Book: https://www.dynamodbbook.com/The DynamoDB Guide: https://www.dynamodbguide.com/Twitter: https://twitter.com/alexbdebrieBlog: https://www.alexdebrie.com/

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. Are you better than the average bear with AWS? This is Screaming in the Cloud. expert on AWS IQ today and help customers with their problems. Visit snark.cloud slash IQ to learn more. Do you know what your cloud is doing when you're listening to this podcast? Turbot does. Give Turbot permission to record every configuration change, tag every resource, remove security threats, and delete unused, not to mention costly, resources.

With Turbot watching over your cloud, you can enjoy my rants more and worry less. With Turbot, you can discover everything and remediate anything. Tune in to their upcoming episode on June 24th to learn more. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Alex Debris, who's an author and self-employed AWS trainer and consultant with a focus on serverless and cloud-native technologies. But most importantly, he's the author of the brand-sparkling new book called The DynamoDB Book. Alex, welcome to the show. Thanks for having me on, Corey.

No, thanks for taking the time to speak with me. It's nice seeing folks in the community who are putting out books around AWS services, especially some of the more venerable services that are not iterating quite as rapidly as something newly released. It feels like if I were to write a book about anything released in the last three years, it would almost certainly be out of date before I ever got it to my editor, let alone shelves. But DynamoDB has been with us for a while, and it seems to be relatively stable. So let's start at the beginning. What the heck inspired you to write a book about Amazon's second best database? The first, of course, being Route 53.

Well, yeah, I knew you already had Route 53 cornered, so I had to choose a different tack there. But really, for me, it was just using DynamoDB and especially using it incorrectly over a number of years was how I got into DynamoDB. So I've been using it probably for about four years now and mostly been using it with serverless technologies like AWS Lambda because it fits really well with Lambda. But modeling with DynamoDB is quite a bit different than modeling with a relational database. So for my first two years, I thought I could do it pretty well. And I was mostly modeling it in a relational way. And then two years ago,

I watched Rick Houlihan's reInvent talk about how to model with DynamoDB, and it kind of blew my mind. As a result of that, then I made a different site called dynamodbguide.com, which was just basically dissecting Rick's talk and taking it from a 600-level talk down to maybe like a 200 or 300-level talk. And walking through how you think about DynamoDB, how to use it, what the API is like, things like that. I would say even at that point, I didn't really understand DynamoDB. But since that time, I've had a lot of work with the community and folks at AWS and things like that to where I've continued to learn more about it. And I still feel like there's a gap in how to model with DynamoDB. So I wanted to fill that gap and write a book. And really what you were talking about was one of the main considerations where DynamoDB has stabilized to some extent to where it's not going to be changing quickly to where

if I do release a book, it's not going to be totally irrelevant by the next reinvent. You might need to tweak around the edges, but I think it should be something that'll work for a couple of years at least. It's always interesting to me to see where things tend to come from. I mean, as it turns out, about, I want to say, what was it, 20, math is hard, in the fall of 2018 is where I first became acquainted with Rick. And as it turns out, I was giving the opening keynote of LatencyConf in Perth, Australia, and he was giving the closing keynote. And then we wound up on a panel, which was interesting, but I had never heard of him before that moment. And oh, some exec from AWS. Great. I'm sure this will be an interesting talk where they go on about leadership principles or something. Yes, it was very much not that. The first half of the talk was awesome.

And the second half of the talk, I had to be excused for because my brain was full. It's so true. I mean, he's just pretty amazing just in the amount of stuff he knows and how quickly he conveys it and spits it out. But yeah, he's really become sort of a cult hero over the last couple of years due to his reInvent talks. A lot of different directions we can go with this. But let's start, I guess, with a common one that I've gotten, where I'm a fan of DynamoDB. In that it's a great NoSQL database. You could call it a key value store. You could call it a bunch of things. I'm

calling it a database because I know it offends some of the most pedantic people in the world. But it is a lock-in story. There's nothing that has Dynamo's model anywhere else that I'm aware of. So what is it that makes it, I guess, okay to go for a level of lock-in around a data store? I mean, we've seen from Oracle what happens when you have a data store that is locked into one particular proprietary provider and how that can wind up causing constraints down the road. What makes Dynamo exempt from that, or isn't it? Yep. I think that's a good point, you know, and I think a lot of people are worried about lock-in, especially the ones that have the battle scars from previous generations, like you're saying. I don't have those battle scars, so maybe I'm naive. But the big thing for me, I think, is I think AWS and really Amazon more broadly has shown such a commitment to delivering value for the customer and not trying to squeeze them for everything that they're worth. So, you know, you don't see price increases on AWS services. You generally see things get better over time. So I'm a little less worried about the pricing aspect. And for me, you know, I've mostly opted

into the AWS serverless ecosystem. So things like Lambda and API Gateway and all that. And all that is stuff I couldn't move to another cloud anyway. So I'm going to be, you know, re-architecting my systems if I move at that point anyway. So I think at that point, it really makes sense to go all in and use what works best. And I just think the other things you get from DynamoDB are so much clearly better than the other databases out there, whether that's the pricing model or how well the connection model works with Lambda or how easily it works with infrastructure as code, all that stuff. That makes it worth it for me to opt into that ecosystem. So I guess one of the big questions from a technical perspective is,

I built something on top of DynamoDB. How painful is it to migrate that to a different data store, to migrate that to, I don't know, Cassandra, for example? Yeah, that's a great question. Or possibly Redis or possibly Route 53. Exactly. That's a really good question. And as I've been working on the book and communicating with people about it, the big question I always get is around migrations. And I'd say more of the question has been around migrating within DynamoDB because you usually design your DynamoDB table

to work with specific access patterns. And then some people are asking, what if my access patterns change? How do I migrate that? And I have some content in the book around that. In terms of migrating to another database, I think it's going to be pretty similar to any time that you're migrating

across different types of databases. So if you're migrating from something relational, like MySQL or Postgres into MongoDB or DynamoDB, you're going to need to do an ETL process that reshapes your data to make it work for the other data stores. So the same is going to be true for Dynamo, right? There's nothing really that has the exact same data model as DynamoDB, although Cassandra is pretty close.

But yeah, really, if you're moving out of DynamoDB, although Cassandra is pretty close. But yeah, really, if you're moving out of DynamoDB to anything else, it's going to involve some sort of ETL process where you're pulling that data out, you're reshaping it in a shape that works for this new database that you're using, and then putting it in there. So I think it's not really any different. The one thing that might be harder than that is if you're moving from one relational database to another relational database, that's going to be pretty straightforward. But if you're really moving across data models like that, it's going to be about the same. One of the, I guess, questions then becomes, is it better to start treating it as the most naive

possible data model that you can come up with in the event that you want to potentially migrate off of it someday? Or once you've made a decision, does going all in make sense in a way that it may not have historically with other things? I would say go all in. I mean, I'm a big cloud native advocate, I would say, and really take advantage of the features of your cloud provider and treat your cloud provider as a partner rather than maybe an adversary or someone to be wary of. So I would say go all in with it. You know, I don't think it's going to make it that much easier if you have a very naive DynamoDB implementation as compared to a complex one and you want to take it out. You're still going to be doing the ETL stuff, which is going to be making sure you're writing the right script and

all that stuff. It'll be a little easier with the naive model. But really, I don't see a lot of people actually migrating clouds very often or even switching databases very often. So I think it makes sense to optimize for the common scenario of that you're going to be on this database for a while and making sure you're building something that really works well for it. Before you started writing this book, or maybe when you did start writing this book, you were at serverless framework, which is where I first started encountering you in that whenever I have trouble with open source projects, my default support method is to whine about how dumb I am on Twitter and hope someone takes pity on me. Much to your everlasting chagrin, you did.

Yep, exactly. Yes, I was at Serverless for about two and a half years. Just left there at the beginning of 2020 here. But yeah, I did a few different things at serverless. I started on the growth team first as a data engineer and then as head of growth where I was working with some great folks there to just make content mostly and engage with the community because I think serverless and the serverless framework made it a lot easier to use AWS, but you still needed to learn quite a bit of AWS to get the value out of that. So we were

working to make that available to folks that were starting to dip their toes into the AWS ecosystem. So I did that for a while, and then I actually was on the engineering team at Servalist for about a year, year and a half there as well. So yeah, I had a great time there. I really loved working on the Servalist framework and just the Servalist community and all that stuff. It seems like it's a fantastic way of dipping your toes into something that is very finicky to put together manually. I started using it, and personally, I never went back. It was the sort of thing that just sort of made sense

and, I guess, aligned with my entire half-baked understanding of a lot of these concepts, and it papered over things that I didn't really need to understand super deeply. Something that was similar to that in some respects, I guess, was the ill-fated two weeks I spent playing around with the Amplify CLI and Amplify Framework or Amplify Library, whatever it is that we're calling it,

that AWS has released, that effectively you wind up importing it into a React or a Vue project, and you tell it what you need. It builds a bunch of backend services and then spits out the JavaScript component that interacts with those services, which on the one hand is awesome, and on the other is the exact opposite of what I needed because I tend to understand the infrastructure pieces, but not how to actually do anything useful in frontend. But what was interesting about that is how much it was using things like Dynamo under the hood,

which in some cases, it never even bothered to tell you. Yeah, it is interesting. You're really seeing Dynamo, I think, be the database of choice for a lot of these serverless applications. And part of that is because, you know, they're very infrastructure-as-code first. So whether that's the serverless framework or SAM

or the Amplify CLI that you're talking about, they're all using infrastructure as code. And DynamoDB works really well for that where you can provision your table and it's all ready to go and start interacting with it as compared to something like a relational database where maybe you can provision that database, but now you need to have something else

outside of your normal infrastructure as code workflow where you need to be creating users in that database, creating tables, indexes, all that stuff, which can be tricky. But so I think that infrastructure as code friendly feel is a big part of it. But also, and really the big thing is the connection model where, you know, if you're using Lambda, like a lot of these serverless projects are, and you have this hyper ephemeral compute where it's spinning up only when a request comes in and then it goes away. It's faster if you can use something that has a stateless HTTPS connection model rather than making sure you're in the right private network to access your

relational database and then setting up that connection pool, making that request and making sure you're not having too many connections as well. And I think that's the big reason why you're seeing so many people use Dynamo with serverless. It is that connection model problem. And really, I was hopeful for a while that the relational database problem would be solved in serverless. I've sort of given up on that. And I think for most people, it's going to be much faster for you to learn how to model in Dynamo than it is for someone else to build a relational database that really works with the serverless compute. One of the things I've always appreciated about serverless was the idea that you aren't paying, for instance, to sit around idle.

You effectively pay for what you use, and that's it. With Dynamo, now, it winds up having an on-demand capacity model, where you only pay for things that it uses and it scales to zero. But even before that, the capacity model it's always had has never been instance-based. It's been about reads and writes, specifically throughput. And that pricing model is, as best I can tell, unlike virtually any other database on the planet. Am I missing anything? No, I think it's really

awesome and pretty amazing, right? Because when you're thinking about your database, usually you're building out this new application. You think, how big do we need to scale this database? And you're thinking, well, how many users and requests are we going to be getting per second? And then you try and map those requests into CPU and RAM and network and all that stuff, which doesn't really convert well. So mostly you're just guessing and hand-waving and buying some instance and being wrong and either overpaying or throttling

and jamming up your application. Whereas with Dynamo, if you can actually do that capacity planning, you can provision the reads and writes that you need to handle it and you won't be overpaying. And if you don't have a good sense of your capacity, you can provision a bunch of capacity and overpay for a little while and get a sense of your baseline usage and then scale it down to

smaller read and write capacity as needed. So yeah, like you're saying, even before that on-demand came out, it was pretty flexible and much easier to do capacity planning than with other databases. But now with on-demand, I mean, that's a, that's a big game changer where you don't have to specify any capacity up front. You just say, you know, I have a database and you handle reads and writes and I'll throw them at you and it'll handle it for you. So that's pretty incredible. You know, the on-demand pricing is more costly if, if, you know, in the theoretical case, you could get full utilization, but most people just aren't getting full utilization. And that's true whether it's

DynamoDB or a relational database or anything else, because usually you're way over provision so that you don't jam up your database. So I find out for most people, I think it's a pretty good pricing option. And in the worst case, at least, it's something you can turn on at the beginning and not have to think about capacity planning for a while until you've set that baseline. If you're like me, one of your favorite hobbies is screwing up CI-CD. Consider instead looking at CircleCI. Designed for modern software teams, CircleCI's continuous integration and delivery platform helps developers push code with undeserved confidence. Companies of all shapes and sizes use CircleCI to take their software from bad idea to worse delivery,

but to do so quickly, safely, and at scale. Visit circle.ci slash screaming to learn why high-performing DevOps teams use CircleCI to automate and accelerate their CI-CD pipelines. Alternately, the best advertisement I can think of for CircleCI is to try to string together AWS's code build deploy pipeline suite of services. But trust me, Circle.CI slash screaming is going to be a heck of a lot less painful, and it's where you're ultimately going to end up anyway. Thanks again to CircleCI for their support of this ridiculous podcast. The strange part for me

has always been in trying to predict capacity. Now, of course, like anything, DynamoDB offers autoscaling these days, which, like most forms of autoscaling, gives you exactly what you need 20 minutes after you needed it. So you wind up

in these sudden burst scenarios where suddenly you'll wind up with a bunch of things being throttled as a result. That, for better or worse, is a lot easier to manage with something like Dynamo, but it's still there and it's still obnoxious. What have you found that makes for a reasonable approach to start minimizing the impact of that sort of thing? I think my first recommendation is really evaluate whether autoscaling at all works for you. I think it works in pretty well for EC2 or different things like that. But for DynamoDB, I found it to not

work quite as well because you do need more of an even scale-up period. Because like you're saying, it takes a little time before you sort of trigger your threshold and then it actually starts scaling up and that might be too late for you. And now you're getting throttled and you have unhappy users. So first of all, that scale-up might not be as fast as you want. And then number two, you probably have a target utilization of maybe pretty low, maybe like 30, 40, 50% to where as soon as it hits that, now it's going to start scaling up to make sure you're doing that far enough in advance. And at that point, if you're looking at a 30 or 40% target utilization, well, I think at that point, you might as well use DynamoDB on demand because now you're being

pretty competitive with that on demand pricing if you're only getting sub 30% utilization out of it. So, you know, I think autoscaling works for some people that have pretty predictable scale-up patterns, but I would advise against it in most cases, I think. One of the, I guess, more interesting pieces that I tend to see with any AWS service, or frankly, I don't think it's bound to AWS, any service at all, is how people can misuse it in weird and creative ways. So I guess I have two questions for you. First, what do people misunderstand the most about DynamoDB? And secondly, what is the most egregious misuse of Dynamo, where you're trying to implement a relational pattern on top of no SQL. So you're not really using SQL there. You know, I see that happen. I actually think it's not the end of the world in terms of patterns. If you do have like a highly relational model and you're pretty new to Dynamo and you want to dip your toes in the water that way, I think it can work, but you know, you're not really getting all the scaling benefits and

you're not getting the true benefits of DynamoDB. I think the second and more pernicious one is thinking that NoSQL and schema-less means very flexible data modeling and data access patterns. And DynamoDB is pretty unforgiving that way. You really need to model your database ahead of time to handle the queries that you want. So NoSQL and Schemeless doesn't mean sort of freeform whatever. And I think part of that comes from MongoDB because I think at smaller scales, Mongo is more flexible and more developer friendly. If you do have like a pretty small application, there's a lot of flexibility around query patterns and just query and data access in general to where people thought NoSQL meant very flexible data access, and that's just not going to happen with DynamoDB. So I think

that's where people really get in trouble there, is not knowing their access patterns up front and not designing for those access patterns. Now, second question, the worst abuse I've ever seen. Let me think on that one a second. Because for better or worse, I don't see DynamoDB cropping up on most of my cost consulting engagements as a tremendous driver of waste. Sure, there's an optimization series of steps you can take around significantly large DynamoDB environments, but it's not one of those scenarios where, well, 80% of your Dynamo spend is being wasted. Knock it off in virtually every case. It's hard to screw up in an economic sense with Dynamo without really trying. Yep, that's true.

If I think about sort of the worst patterns I've seen, I'd put it at two ends of the spectrum. One is sort of relying on the scan operation in any hot path. So if you have like a HTTP request where a user's actually waiting on the response, it's almost a bad idea to use the scan operation. People do it because they think that's the only way they can get across their data that's across different partition keys, which is a big mistake. And maybe it works when they're developing and they only have, you know, 50 items in their table. But then when they get some serious usage in there, then it gets pretty slow.

The second example I have, I think, is when you read about these fancy access patterns and especially access patterns that are designed for very high scale tables and you try to apply it on a low scale table. So the example I'd use here is there's a pattern called write sharding or read sharding where a partition in DynamoDB, which is a very small segment of your database, think like a particular user's data items. There's a limit of 3,000 read requests or 1,000 write requests per second on that given partition, which again is not your entire table as a whole. It's just a single partition. So if you're going to be more than 3000 reads per second, which is a pretty high volume, you know, now we're talking about amazon.com and Lyft and Uber and all those very high scale applications. But if you're going to be over

something like that, then you might need to shard up a particular partition. So a particular user or something like that into different partitions and then do like a scatter gather query on those where you query all those partitions and put it back together. That pattern is, you know, remember, most people are not going to be in that use case, right, of 3,000 accesses per second on a particular user or something like that. Most people aren't going to have those. But I see people try to implement some of those uber high scale design patterns at pretty low volumes when they don't need them. And it

really complicates your logic and it's probably a little bit slower as well. So I think that's the other place where I see people make mistakes. It's weird when you start off designing something, and this I think is probably one of the failure modes that DynamoDB has. Back around two and a half years ago, two years ago, somewhere in that range, I decided that it was time to actually build something custom to write my last week in AWS newsletter. And all of the links live in DynamoDB.

As it turns out, I had made a number of decisions then that didn't actually wind up working for the current generation of how I generate these things. So the schema that I came up with, such as it was, when I was designing this, hasn't lent itself super well to being extensible in a modern way. And I'm looking at this thinking, there are now almost 4,000 links that live in that database,

and doing a modification run on all this would be incredibly challenging and very expensive. And then I realized, wait a minute, it's a lot in the context of all the material that I've written that now lives inside of that database, but it's only 4,000 items in this thing. It is a megabyte or so on a disk. I have continuous backup turned on for this,

and the total dynamo spend on this thing is nobody cares money. We're talking pennies a month. And I'm realizing that I don't actually have a big data problem or even an old data problem compared to virtually anyone else out there. It's just I'm stuck in the mindset of seeing things a certain way. Taking a step back and getting some much-needed perspective has been incredibly valuable on that. And heck, you've helped me with that through a series of conversations we've had over the past year, starting to reimagine how things could work differently. Yep. Yeah, exactly. I think people do sort of think, oh man, that's a lot of data I'm going

to have. And they think about the pricing or they're not thinking specifically about what that pricing actually means. But yeah, 4,000 items seems like a lot, but then you go look at even the on-demand pricing, which like we said, is going to be more than your provision capacity. And I believe it's a quarter per million reads from a table. So, you know, you're not going to be anywhere near that. And even so, it'd only be a quarter. So yeah, the pricing really works out for a lot of folks. And I find out is for a lot of people, especially building smaller serverless applications, which you see a lot, the pricing is not going to get you as much as other things like API Gateway might or different other parts of your application.

I think the hardest part is that people have a hard time, at least I have a hard time, because I'm the most common type of developer, by which I mean bad at it. And it's hard for people in my position, at least, to step outside of our own use cases at times and imagine what other people's use cases look like. Being a consultant is definitely helpful in that regard. Every year that I do this, I feel like I'm getting three years of experience just because of the

different variety of environments that I tend to see. You're an independent consultant yourself. What have you, I guess, learned from your customers as you've gone through it? Yeah, I still think there's just an education gap around DynamoDB generally. And I think that's getting better. You know, I've got dynamodbguide.com out there. I've got the book that's out. And also, you know, the reInvent talks from Rick Houlihan are great. And I think you're just seeing more of a community develop.

But there's still not enough out there. And one thing I've been really grateful for over the last couple of years as I've put some of this stuff out there and then had people reach out to ask for help around DynamoDB is, like you're saying, it really accelerates your learning. And one thing I see is there's so much uniqueness around how you have to model your DynamoDB table, where if you have a relational database, there's likely one way to model it, right? You have a different table for each of your entities. You have the relationships between them

as modeled by foreign keys, and you're pretty good to go. But with Dynamo, it's a little more art than science to where you need to design that data model for your application. You need to know all these little tips and tricks. So I've had a great time working with clients and just other folks in the community over the last couple of years, figuring some of those out. Most of those are encapsulated in the book. So I have a thing

that I call strategies, where you really just need to know all these different micro strategies about how to model in DynamoDB. And those are just different tools in your toolbox, you know, as the saying goes. And when you're attacking a particular access pattern, you just think about, you know, what are the contents of that access pattern? And then how can I put together a few different strategies to help handle that? So I'm hopeful that the book will have some of the learnings that I've had to do the hard way and a lot of people, other people have had to do the hard way to where you can pick that up and accelerate your learnings, you know, in a similar way. Yeah, DynamoDB, the hard way is always fun. It seems like DynamoDB, the easy way way to where you can pick that up and accelerate your learnings in a similar way.

Yeah. DynamoDB, the hard way is always fun. It seems like DynamoDB, the easy way is to call you. Yeah. I like that. I like that. That's a good catch line. So origin stories are always interesting and you're deep in the weeds of database design and architecture. So what's your backstory? Computer science degree, where'd you go? Yeah. Not a computer science degree at all. I actually have a liberal science degree, where'd you go? Yeah. Yeah. Not, not a computer science degree at all. I actually have a liberal liberal arts degree, economics, poli sci, that sort of thing. And then I went to law school. So my wife and I, we got married right after college and we both went to law school together. And, you know, I did that, you know, I was doing law school and

during your summers of law school, you usually go work at a law firm. I was doing that. I met a friend there who he was a lawyer, but he was also into the tech scene and sort of got me into that. Actually started working on a startup with him and my brother-in-law where we were putting soil moisture sensors into farmers' fields to help them figure out when they needed to irrigate, things like that. So, you know, sort of an early Internet of Things application, we thought anyway. So they were starting to work on that.

I asked how I could help and they said, well, you could write a business plan. So I did that, which was a lot of wasted writing for no purpose really. But as I sort of got into the project, I was enjoying it and asked how I could help. And they said, you could learn to code if you wanted to. So this was my last year of law school. I had about a semester left. And your last semester of law school is pretty casual. You're mostly just running out the clock. So I spent most of my time in class, like hanging out on Stack Overflow and trying to figure things out, you know, trying to build this application. But

like one thing I did is I would just hang out on Stack Overflow and wait for someone to ask a question about Django, which is the popular Python web framework. Someone would ask that question. I had no idea how to answer it. So I would just go Google it and search around and look through the source code and try and figure it out and try and answer it for them to the point where I was like the number two Django guy over a six-month period

or something like that for a while, even though I'd never done any real Django in production. But I think it was a really useful way for me to figure out how to debug code and read source code and figure problems out. So I really enjoyed doing it, and it was a good learning experience. Graduated law school and worked as a corporate lawyer

for almost a year, not quite a year, and then decided to make the jump into tech. So I was fortunate to get a job at a startup that was based in Nebraska, did some AWS and data engineering stuff there. And yeah, and the rest is history. So yeah, I used to be a corporate lawyer. I only made it about a year. And now I tell everyone I'm a suspended lawyer because I have no longer paid my legal dues. Phenomenal. I about unicorns. You are probably the only lawyer I've ever heard of who went to go work on databases but didn't take a job at Oracle.

I love it, yeah. They weren't hiring for me in that case, yep. Now, it's always interesting seeing the path that people walk and the assumption that everyone, oh, if you're doing thing X, you must have educational background Y. That really only matters the first few years. Then it's a question of where is your professional path led you? I don't see too many options where it makes sense for someone mid-career to go back and get an undergraduate degree in a particular area of study. It's easier in most cases for them to effectively lateral from wherever they happen to be towards whatever it is they want to be doing next. Yep. Yeah, I totally agree. I mean, there are so many resources out there to where you can really pick this stuff up if you want to. And with something like programming, it's easier than most fields to sort of prove that you know something. So even though I didn't have a CS degree or anything like that, I had worked on this IoT-ish application with a web front end, all that for a year. And in my interviews, I was able to speak coherently about different aspects

of AWS, things like that. So it was clear that I knew something. Also, at that same time when I was deciding to go into tech, I actually had another offer from a startup that would have been remote. And really how I got in with them is I was using their product and I realized their documentation and examples weren't very good. So I wrote some blog posts and examples for them to the point where they then offered me a job. So I would say in something like tech, it's easier than most places to prove your worth and get that start, even if you don't have the traditional credentials.

Whereas I couldn't have made that other switch. I couldn't have gotten an undergrad CS degree and then tried to convince a law firm to hire me on as a lawyer. That just wouldn't happen. Yeah, for some things like regulated professions, there's really not another option. It's sort of like no one yet has let me try my hand at being an amateur surgeon.

Yep, exactly. I don't know why, Corey. I think you can do it. But yeah, there's a lot of materials out there. You mentioned DynamoDB the hard way earlier, and really the resource that got me started was Learn Python the Hard Way by Zed Shah. That was one of the first resources I did and just worked through all those examples and then just tried to build something myself and also help others on Stack Overflow. So yeah, that path is definitely possible for people that don't have the traditional background, which is great. So if people want to learn more about what you have to say, where can they find you and where can they buy your book? A few different places. If you want to find me on Twitter, that's probably the best way to get in touch with me. So that's at Alex B. Debris.

I also blog at Alex Debris. So that's confusing because they're different. But if you want to Google Alex Debris, I'll probably come up on those places. If you're interested in DynamoDB more specifically, go to dynamodbbook.com. That's got a link for the book where you can buy that. And feel free to reach out if you have any questions on that stuff. I've also got dynamodbguide.com, which is more of an intro to DynamoDB, more about interacting with the API a little bit. So if you want to look at some free stuff before you take a look at the book, go ahead and check that out as well. Excellent. Alex, thank you so much for taking the time to speak with me today. I appreciate your time, as always. Thanks, Corey. Thanks for having me.

Alex Debris, author, AWS Data Hero, independent consultant. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. If you've hated this podcast, please leave a five-star review on Apple Podcasts and leave a comment explaining why you should never use a single table pattern. This has been this week's episode of Screaming in the Cloud. You can also find more

Corey at Screaminginthecloud.com or wherever fine snark is sold. This has been a HumblePod production. Stay humble.