Subscribe
Share
Share
Embed
Alex DeBrie is the founder of DeBrie, LLC, a cloud-native training and AWS consulting company with a focus on DynamoDB and serverless technologies. He’s also the author of The DynamoDB Book, a 450-page tome that offers tips, strategies, and more about data modeling in DynamoDB. Prior to starting his own company, Alex was an engineer at Serverless Inc. and Hudl. Before that, he worked as an associate attorney for a law firm in Nebraska after earning his J.D. from the University of Virginia School of Law.
Join Corey and Alex as they discuss what got Alex so interested in DynamoDB in the first place, why Alex isn’t worried about AWS pricing, why you should view your cloud provider as a partner instead of an enemy, the many hats Alex wore at Serverless, Inc., why Dynamo is the database of choice for serverless applications, why auto-scaling doesn’t work quite as well with DynamoDB as it does for EC2, the most egregious uses of DynamoDB Alex has encountered to date, how Alex made the leap from law school to engineering and tech, the time Alex was the number two Django contributor on Stack Overflow over a six-month period even though he’d never done any real production, and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: 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.
Corey: Are you better than the average bear with AWS? If you're listening to this podcast, the answer is almost certainly yes. Want to turn those skills into money? If you're US-based and have an AWS certification, sign up as an expert on AWS IQ today and help customers with their problems. Visit snark.cloud/iq to learn more.
Corey: 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.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Alex DeBrie, 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.
Alex: Thanks for having me on, Corey.
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.
Alex: 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 in a relational way. And then, two years ago, I watched Rick Houlihan’s re:Invent talk about how to model what they—DynamoDB in, 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 a 2 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 re:Invent. You might need to tweak around the edges, but I think it should be something that will work for a couple years at least.
Corey: It's always interesting to me to see where things tend to come from, and 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 given the opening keynote of Latency Conf 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.
Alex: It's so true. I mean, he’s just pretty amazing, just in the amount of stuff that he knows and how quickly he conveys it, and then spits it out. But yeah, he's really become, sort of, a cult hero over the last couple years due to his re:Invent talks.
Corey: 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 datastore, when we've seen from Oracle what happens when you have a datastore 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?
Alex: Yep, I think that's a good point, you know, and I think a lot of people are worried about lock-in, and 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 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 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 rearchitecting my system 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 infrastructures, code, all that stuff. That makes it worth it for me to opt into that ecosystem.
Corey: 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 datastore to migrate that to I don't know, Cassandra, for example?
Alex: Yeah, that's a great question. I’ve—
Corey: Or possibly Redis, or possibly Route 53.
Alex: Yeah, 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, so 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 datastores. 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 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 it might be harder than, 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.
Corey: 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?
Alex: 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 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.
Corey: Before you started writing this book, you—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.
Alex: Yep, exactly. Yes, I was at Serverless for about two and a half years. I 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, did that for a while, and then actually was on the engineering team at Serverless 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 Serverless Framework, and just the serverless community, and all that stuff.
Corey: 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 at 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 View 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.
Alex: 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 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. 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 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 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.
Corey: One of the things I've always appreciated about serverless was the idea that you weren't paying for instances 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?
Alex: 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 big game-changer where you don't have to specify any capacity upfront.
You just say, “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. The on-demand pricing is more costly if, in the theoretical case, you 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-provisioned 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.
Corey: 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 do so quickly, safely, and at scale.
Visit circle.ci/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 CodeBuild/Deploy/Pipeline suite of services, but trust me, circle.ci/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.
Corey: The strange part for me has always been in trying to predict capacity. Now, of course, like anything, DynamoDB offers auto-scaling these days which, like most forms of auto-scaling 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?
Alex: I think my first recommendation is really evaluate whether auto-scaling at all works for you. I think it works 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 30, 40, 50 percent, 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 price pricing if you're only getting sub 30% utilization out of it. So, I think auto-scaling works for some people that have pretty predictable scale-up patterns, but I would advise against it in most cases, I think.
Corey: One of the, I guess, more interesting pieces that I tend to see with any AWS service—and frankly, I’m not going to bound that 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 DynamoDB that you have seen to date?
Alex: Oh, man, that's a good question. So, I think first, a couple of egregious misuses. The classic one is people that try to implement what I call “Faux SQL,” where you're trying to implant a relational pattern on top of NoSQL. 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 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'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 schemaless 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 schemaless doesn't mean 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 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, 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 upfront 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.
Corey: 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 while, “Welp, 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.
Alex: 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 a HTTP request, where a user is 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 partitions keys, which is a big mistake. And maybe it works when they're developing, and they only have 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 3000 read requests or 1000 write requests per second on that given partition, which again, is not your entire table as a whole, it's just the single partition. So, if you're going to be more than 3000 reads per second, which is a pretty high volume—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—remember, most people are not going to be in that use case of 3000 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.
Corey: 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 be extensible in a modern way. And I'm looking at this thinking, there are now almost 4000 links that live in that database and doing a modification on all those 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 4000 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 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.
Alex: 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, 4000 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're not going to be anywhere near that, and even so it’ll 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.
Corey: 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?
Alex: Yeah, I still think there's just an education gap around DynamoDB generally, and I think that's getting better. I've got dynamodbguide.com out there, I've got the book that's out, and also the re:Invent 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 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. 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, and 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, as the saying goes, and when you're attacking a particular access pattern, you just think about 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 other people have had to do the hard way, to where you can pick that up and accelerate your learnings in a similar way.
Corey: Yeah. DynamoDB the hard way is always fun. It seems like DynamoDB the easy way is to call you.
Alex: I like that. I like that, it's a good catchline.
Corey: 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?
Alex: Yeah, yeah, not not a computer science degree at all. I actually have a liberal arts degree; economics, polisci, 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 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 farmer's fields to help them figure out when they need to irrigate, things like that. So, 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 hanging out on Stack Overflow and trying to figure things out. Trying to build this application, but 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 asked 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 to 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, genuine 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. I 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.
Corey: Phenomenal. I think that—talk 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.
Alex: [laughs] I love it. Yeah, they weren't hiring for me in that case, yep.
Corey: [laughs] Now, it's always interesting to see in 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 has 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.
Alex: Yeah, I totally agree. I mean, there's 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, 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.
Corey: Yeah, for some things like regulated professions, there's really not another option.
Alex: Exactly.
Corey: sort of like no one yet has let me try my hand at being an amateur surgeon.
Alex: Yep, [laughs] 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 Shaw. That was one of the first resources I did, and I just worked through all those examples, and then just trying 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.
Corey: 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?
Alex: 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 @AlexBDeBrie. I also blog at AlexDeBrie, so that's confusing because they're different. But if you want to Google Alex DeBrie, I'll probably come up in 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.
Corey: Excellent. Alex, thank you so much for taking the time to speak with me today. I appreciate your time as always.
Alex: Thanks, Corey. Thanks for having me.
Corey: Alex DeBrie, 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 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.
Announcer: 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.