Dax Raad: Improving Cloud Devex with Serverless Stack, Transitioning into Serverless from K8s, and AWS NFTs

About Dax

Dax is an engineer and entrepreneur that has spent the last decade building technology and teams at early stage startups. A majority of that time was spent as a consultant working for dozens of companies using different technologies across infrastructure, frontend and backend.

Most recently he's been bitten by the serverless bug and is working on Serverless Stack to improve the last mile experience of deploying full-stack serverless applications on AWS.

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

Transcript

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

Dax: Hey, Adam. Thanks for having me. Really excited to be here.

Adam: Yeah, thank you for joining. It was sort of a last minute schedule change. So you were very flexible to hop on today as opposed to next Tuesday. And I'm appreciative of that. So I want to start with just your story, so your background in tech. How did you get into the cloud? Just all of it.

Dax: Yeah, sure. So I'm pretty new to the AWS community. And I've been using AWS my whole career. But it wasn't until this past year that it really got into it. So for my background, I got started, I would probably say, 10 or 12 years ago. My dad's a software engineer. So, it was kind of always been around technology. And when I was 16 or 17, he was working for a financial firm here in New York. And they were prototyping a Hadoop deployment. I don't know. Do you remember Hadoop and big it was?

Adam: Oh yeah.

Dax: And it was like the thing everyone was using?

Adam: Yeah.

Dax: Yeah. So he was in charge of prototyping that. So, he brought home like a rack of servers and he put in our basement and it was really legit set up. I think it was eight servers and even had, I forgot what they're called, but it's like a rack that you pull out. It has a monitor on a mouse on it to get into the servers and everything. So he had in our basement and he probably prototype with it for three or four months. And he was like, "Okay, it's yours now." The company paid for it. But they're letting us keep it.

Adam: So cool.

Dax: Yeah. So it was really awesome for me to have access to. And so, I mess with those servers. That's how I learned Linux. I would be in my bedroom at night, on my laptop doing stuff down there. I would break something or run down the stairs in the middle of the night and hard reboot stuff. It felt really cool. I felt like I was a hacker or something.

Dax: So yeah. That was my initial intro into tech. So it was all around managing the servers, deploying software on them, fully managing these physical machines. And then, as I started working, I ended up starting my own company with a friend, and I was roughly 20 years old. When you're 20, you'll spend five hours to save $5. So we were like, "Okay, let's just deploy our stuff to the servers here in the basement."

Dax: So I'll get the website and everything. My first company was being served out of my parents' basement quite early. So we did that. And then that was around when AWS was getting a little more popular. I think they'd been around for a while. It was probably around 2011 or so. So we started hear about it. I heard about EC2 and the concept of being able to turn off a machine at night when you're not using it. I pay for it. I was like, "Wow, that's amazing. That's so cool."

Dax: So we started to use AWS. And I think S3 was out around that time too. So I use S3 as well. But for the most part, that was it. Anytime we needed another service, we use RabbitMQ, or we use Cassandra. We went to another company that had a managed service offering for that. So from my point of view was AWS is just for running VMs and then you go to other places for the other stuff.

Dax: So that was kind of my perspective on it, at least for a while. My whole career has been at early stage startups. Did a lot of consulting for a lot of different companies. These companies don't have dev ops. When you're smaller, dev ops is just your responsibility. You spend 15% of your time on it. So I was still interested in all of that, but only to the extent that I needed to automate as much as possible. And so, I don't have to deal with it. Yeah. So worked at a bunch of companies, various different setups. And that's when I found Kubernetes.

Dax: And at the time, my perception of cloud was it's a bunch of VMs you need to manage. And because I was a consultant, I didn't always get to say that, "Hey, we're using AWS or, hey, we're using Google cloud." To be honest, I was lazy. I didn't want to learn. It'll be a specific things. I didn't want to learn [crosstalk 00:04:19] things. So when Kubernetes came out, I was like, "Oh cool. I can learn this once. And I don't have to care about anything about the specific vendors that these companies are on."

Dax: And the funny thing was, I actually failed to learn Kubernetes a bunch of times. I remember sitting down trying to learn it and being just like, "What the hell is this?" In my head, I can think of a container. And you're like, "Okay, I want to deploy a container." And there's four abstractions in the way of that. So I tried and tried. And, eventually, I got it. But I remember failing a bunch of times over the course of a year.

Dax: Eventually got really comfortable with it. And then from that point on, I completely checked out from anything that was going on in AWS or any of the other clouds. And I'm working at a few companies applying Kubernetes all the way up until my last role was a company called Boulevard. They were using ECS. And I remember I joined. So I joined as a director of engineering.

Dax: I had a conversation with their lead dev ops person and he was showing me how they use ECS and how they would spin up a container for every environment, et cetera. And I asked them… Oh, well, ECS is really expensive even for a little developer environment. It's going to cost you X dollars a month. And in my head, that's how I always thought about costs. What is the literal AWS bill? And he replied to me with something that was really simple. But it kind of changed the way I thought about everything.

Dax: He was like, "Yeah, it is expensive. But we have to be PCI compliant." And when we go through PCI compliance, we get to say, "Hey, we don't have access to the hosts. So you have to take AWS's certification and everything." It's less burden on us. And I was like, "Oh, that is true. Who cares if it's another $80 extra a month, if you're saving thousands of dollars in engineering time?"

Dax: So something clicked for me there. I was like, "Wow. The way I've been thinking about cost this whole time, I've just been missing the most expensive part of business, which is people and the amount of time that they're spending on managing our infrastructure." And it was around that time I started getting more active on Twitter. I saw kind how to run the serverless community. It was really interesting. I was like, "Oh, they're talking about it, makes lot of sense."

Dax: And then I remember telling my fiancé. I was telling her like, "Oh, reading about all this new stuff, and I don't think it's for me. But it's cool. It's really interesting." And you're like, "Well, you just need to learn about something new." You're kind of hoping that you don't have to learn something new. So, I was kind of in that mindset. But I just kept seeing, and I kept thinking about it. And I was like, "All right, I'm going to go all in." Let's see what it's to build full-stack serverless. And it was a big reset.

Dax: I felt like a beginner again, which felt good because I was kind of itching for something new anyway. Yeah. This was back last December. So I started to learn how to build full-stack applications on AWS with serverless, just a mountain of stuff. I think you need to learn to really do that well.

Adam: Absolutely.

Dax: And that's what led me to find Serverless Stack, which is where I work now. And yeah. I was looking for help in doing that, found that project around right when they launched, started to contribute a little bit to it. The team, they actually invested in them originally. And then, I went, "Hey, you want to earn your money back by coming to work here?" I was like, "Yeah. Cool."

Adam: That's awesome. So let's dive a little into Serverless Stack. So you've joined back in August, I think. Is that right?

Dax: Yeah. That's right.

Adam: Could you kind of tell me, well, first for anyone on the call, who's not familiar, what is Serverless Stack? What is sort of the premise and the goal?

Dax: Yeah. So Serverless Stack is a framework that is built on top of AWS CDK. So for those of you that aren't familiar, AWS CDK is an infrastructure as code tool, lets you describe your infrastructure using typically TypeScript. But also they support Python and Java. And I think .NET as well. And you can do stuff like spin-up servers, spin-up Lambda functions, almost anything that's in AWS, you can spin up programmatically.

Dax: And SST is an abstraction on top of that, that simplifies a lot of that, but also adds a bunch of additional features, really focused on one getting from zero to one. So I'm someone new that doesn't really know AWS. How can I start using this stuff quickly? And then two, there's a lot of friction building serverless applications. I think that developer experience, people have come to expect in non-serverless. It's hard to get that in the serverless environment. And we try to bridge a lot of those gaps.

Dax: So things like hot reloading. Whenever you make a code change, that needs to be updated immediately. And so, you get the same feedback that you get from a traditional application. So like live debugging, even set break points on your Lambda functions and do things like that. There's a bunch of backend stuff. But also deploying your front end in a way that's correct through CloudFront and performing and things like that. So the goal is to make that first experience easy. But because we're built on CDK, we want to make sure that if your company is successful, you're not looking at a big migration one day. You can just dig in deeper and go into the stuff that we were maybe hiding a little bit from you and access the full power of CDK directly.

Adam: That's where I feel like this gets really difficult, right? You look at Amplify. And I feel Amplify, for me, it has not been an easy process to sort of migrate out. And I know they're focused on making that better, and they talk about graduating out of Amplify. But I think that's the delicate balance of providing a nice developer experience, but not sort of creating this nightmare scenario when you try to go past the boundaries, when you try to kind of push and customize. And I think it seems you guys are focused on that. You're doing a good job.

Adam: I know the live reload stuff is what sort of drew me in. And I've been kind of following Serverless Stack for a while. Could you kind of talk? I know you wrote a whole blog post about it. And I totally understood it. I don't need you to explain it to me. But if you could just explain for the audience because they probably didn't get it. How does that work?

Dax: Yeah. So the goal for us is, in general, we're proponents of running as much of this stuff in the cloud as possible. Trying to recreate the cloud environment locally, especially for serverless is pretty difficult. So that's definitely our primary way of operating. But there's some things like your Lambda function code that we set to make a little compromise on. Let's actually run that locally because that makes it so any changes that you make are reflected very quickly.

Dax: So the way this works is it's pretty clever. I didn't come up with it. I found Serverless Stack and I saw their approach. And I was like, "Oh, that's brilliant." Instead of deploying real Lambda function, so if you have a Lambda function that you would deploy, we deploy a fake Lambda function. What this fake Lambda function does is when it gets a request to be invoked, instead of processing it there, it posts a message to a web socket API, which your machine is connected to. That message comes down. The function code is then executed locally. And the response is forwarded back up in the Lambda function response. So nearly everything is running on AWS, except for that little execution.

Dax: And the only work we need to do is make sure that the code running locally thinks as an AWS. And that blog post I wrote covers how it's actually really easy to trick your function and thinking it's an AWS. It's a very simple protocol. It's three end points that it's looking for, to receive the request and post either in error or successful response. So, yeah, we're able to recreate that environment locally, and your function thinks as an AWS and even uses the same permissions it has in production. So there's none of those issues of it works locally, they deploy it and nothing works. All the permissions are broken. So yeah, we try to replicate that as close as possible.

Adam: So brilliant. And I think there is this big sort of debate, at least in the circles I'm in on Twitter and I'm going to have Brian LaRue on next month, I think, talking architect and begin, and they have a different take on the sort of local dev experience. But there's that cloud versus local. And I love that balance that Serverless Stack is taking where your API gateway is deployed to the cloud. You've got your staging environment or whatever. But it's calling code running on your machine. That's pretty genius. I'm a big fan.

Adam: But I can remember a while back saying if I were an investor, which I'm not. But if I were, I would throw money at these folks and you guys have a fantastic investor base. I didn't realize some of the investors behind Serverless Stack. So you're Y Combinator, but SV Angel, Greylock. It's a world-class set of investors back in the company. I don't know why I expected less. It's super impressive what you guys are doing. But I had no idea. So you guys are sort of set up, and I think you just raised around.

Dax: Yeah, exactly. I think this was a small round. I wasn't too involved in this. But actually I was involved as an investor. But I wasn't too involved in actually raising a round. But the goal was raised just enough to get the fund raised on quickly so we can really grow the community and hit the benchmarks we need to hit for [inaudible 00:13:39].

Adam: So, there's a few different pieces to Serverless Stack here. So there's the open source framework, which is, as you said, built on the CDK. But then you also have the serverless guide. And then, I want to talk about Seed. So Seed is sort of a commercial offering. That's sort of the beginning equivalent in Serverless Stack world where you're sort of hosting for customers. Could you explain a little bit about that?

Dax: Yeah. So Seed today is a CI tool. And if I understand the history of it correctly, this was something as Jay and Frank, the founders of SST, as they were building the guide and helping companies build with serverless, they had requests, "Hey, we need a CI tool. It's focused on this." So that's what Seed is. It's a CI tool that was originally built around serverless framework. So it was the deploy. You're still in this framework application. And it would do a bunch of efficient things, only updating stuff that actually changed. And then as they shifted to build SST, now Seed also deploys your SST applications. And it's a different take on a typical CI tool. It's really focused on serverless. That's what it is today.

Dax: And to be honest, as a company, our focus is more around the open source framework. Seed is still growing and we still invest time in it and it's doing well. But today, we want to get more people on board. And it's a production with SST. Down the road, they will graduate and use Seed. But I think Seed will evolve beyond more than just a CI tool.

Dax: I think there's a lot of gaps in the AWS console experience like, Cloud Dash, for example, like, or Dynobase, there's a bunch of companies filling in those difficult gaps. We want to also do that because we know what you're deploying. We can build some pretty good management tooling around that. And that's what we're hoping to see eventually evolves into.

Adam: Makes perfect sense. And I guess in terms of SST, the framework, you've just rolled out recently Next.js support. So now, is this a CDK construct that I can just point at my Next.js app and it deploys all the cool stuff into AWS?

Dax: Yeah, exactly. And I know you're familiar with that because you made Nest. And to be honest, we looked a lot at Nest and poked around there. [crosstalk 00:15:53] going on. So, I appreciate that.

Adam: One of my questions, I guess, is, did you sort of build it from scratch or are you building on top of the serverless plugin that I sort of used with Nest?

Dax: Yeah. So Frank was the mastermind behind all this. He spent two crazy weeks. He was digging into all of this. But the gist of it is, so, we initially tried to build on top of the same underlying server items called Serverless Next.js or something. But there were certain features that didn't work fully correctly. And I think the way that they [inaudible 00:16:25] open source project, it's hard for them to prioritize some of these minor things. But for us we, that is the purpose of our company existing.

Dax: So Frank ended up working a good amount of it and rewriting a lot of it. And it's kind of built upon what's already there. And we got some of those weirder Next.js features working. It's still not perfect. But it's never going to be as good as launching on Parcel. But if you're looking to launch an AWS, it's pretty much a drop in replacement.

Adam: Yeah. And being in the CDK ecosystem, I think, is a huge advantage. I think that's generally one of my sort of favorite parts of SST is that it is built on the CDK. And as a big CDK fan, if you're already building out applications with the CDK, it feels much more natural to kind of just improve your dev experience by incorporating these SSD constructs. And now to be able to do it with Next.js, I may not even use Nest anymore honestly. To know that there's really smart people working on that problem and making it better because I do have a problem with sort of third-party whenever I jumped into her Parcel, it just feels disconnected from the rest. If I'm building out the API side in CDK, I just kind of want to keep it all in AWS account. But that's been tough to do traditionally.

Dax: Yeah. And that's kind of the tragedy with AWS. I'm on the same boat. I want everything I deployed to be in AWS because it's one thing that manage. Gluing together disparate things is difficult. But a lot of those services are really good. Parcel is really great.

Adam: Oh yeah. It's super good.

Dax: Yeah. And it kind of sucks that we have to give up those to keep everything on AWS. I think our job is easy in the sense that we can look at these great experiences that other companies have created and try to understand, "Okay, how can we recreate something close inside AWS?"

Adam: I mean, I use Parcel for the AWS FM website. I'm sort of all over the map. I use Nest for a lot of stuff. I use that. I've used other services. I think I'm just a big Next.js fan. Not Amplify, I guess, deploys similar things. So there's a lot of ways to deploy your Next.js. But to have that CDK proximity is nice to me.

Dax: Yeah, exactly.

Adam: One of the things I wanted to talk about, I think yesterday there was this tweet. I can't remember who tweeted it. But sort of an S1 filing for Expensify and this idea of startup and venture capital waste and how serverless sort of can come in and save the day. But you see that. and it's their IPO'ing, I guess, for context. So Expensify built some crazy stuff, a lot of proprietary. There's custom hardware involved and their own data centers or they're leasing servers, I guess, at a data center. They built a lot of impressive infrastructure from a technical standpoint. But I guess that's my question for you is how does serverless sort of come and save the day and save a whole lot of venture capital dollars?

Dax: Yeah. So I'm going to start this off by saying I am a 100% guilty of all of the stuff that I'm going to talk about now. I have spent a lot of time building my own frameworks. There was a period of time where I used to do a lot of elixir work. We built our own framework there. It was a fully real-time database. To be honest, a lot of stuff that they were talking about in that report, I was like, "Hey, we didn't go that crazy. But we were close."

Dax: And to my defense, the thing I'll say is it's really exciting. It's really fun to do. And when you can tune a lot of your tooling to what exactly how your team operates, there are some benefits. That said, I ultimately don't think that generally is the right approach. I think the key realization for me was when I went to go build my own thing, it was mostly because I was afraid of reading the docs of something that already existed. If I really sat down and thought about it, it's easier to start from scratch and build up and know everything you're doing versus sitting down and reading through documentation and like, "how do step functions work?", and, "what is express workflow?" and all these little different things.

Dax: But that's really an upfront cost that you do once. And if you're willing to stomach that and do it, while you get back is a ton of time, because there's whole teams at AWS just focused on making the stuff better. Something you choose to deploy now is going to be better a year from now. And the less you can manage unless you have to create from scratch, that unlocks more time. And I think it's easy to fall into the trap of saying, "Well, I want to do this custom. I can just put in 10% more effort than I usually do and build this custom thing." And you probably have the motivation to do that. And it seems to make sense.

Dax: But that 10% effort can go anywhere. I haven't seen a single company where it's been like, "Oh, we're done with our roadmap. What do we do?" So if you're not putting this custom database from scratch, you're going to be building different features. You're going to be expanding new verticals. There's all sorts of stuff that will compete for your time. And I think it's definitely something that lower level technical things are attractive. But a lot of business problems are really attractive too. And a lot of those have technical implications.

Dax: Yeah. I think I saw that report and I was like, "Wow, this is such an extreme opposite to where my mindset is now." I can't be going anywhere close to this and the amount of money and resources and time they spend. It was also funny because I think they put it in the report to intentionally sound impressive and complicated. So I guess I think for a lot of people reading, they're like, "Oh wow. That's great technology. That's going to give them an advantage." But I think the people working in the space, it's like, "Oh, that's almost a bad thing that you included that in there." I didn't want to know that.

Adam: And I think that's the disconnect and where I hope if a venture capitalist ever hears this episode stumbles onto some AWS podcast that I think the people that are in the space that are especially doing serverless that they've got that mindset now. We read that and have a very different opinion than I think venture capitalists or Wall Street, this is a company IPO'ing. And I think there are a lot of people that hear that and think that's impressive like, "Okay, here's money. Do more things." And I should say like, "I don't know these people," and I'm sure I've done way worse in my years of technology.

Adam: But it is sort of in stark contrast to this serverless movement. And I do hope that we can unlock a whole lot of efficiency in terms of solving real people's problems by sort of adopting these serverless practices in this mindset.

Dax: Yeah, exactly. I think we're all building on top of other people, and serverless is just the next generation of that much bigger scale.

Adam: Yeah. Exciting stuff. I did want to ask you as wells, speaking of exciting trends, you had said earlier that you kept seeing serverless and decided to kind of go all in on serverless. You've also kind of dabbled with Web3 and I want to talk about you've got some AWS NFTs. Can you talk about that? Is that-

Dax: Yeah. Happy to talk about that.

Adam: Yeah. So they're sort of cubes. They live on a blockchain, and they have the AWS logos services, which I'm fond of the database logos very [crosstalk 00:23:35].

Dax: As I can see behind you.

Adam: Yeah. I got them on my wall. Yeah. So tell me about this NFT project.

Dax: Yeah. So know, I think we've all seen this concept of a Web3 has been blowing up a lot in the past few months. It's kind of confusing for me because I thought this already happened back in 2016 or 2017. That's when I first heard about this concept like, "Oh, we can build these systems with this different architecture." I got really into it back then. And from my point of view back then, everybody on the planet was really into it back then.

Dax: Literally every single person I talked to was talking about Web3 or launching an ICO or investing in an ICO. And that to me felt peak hype. And there are parts that are genuinely interesting. I think some of the architectures of really owning your data and what some of the encryption paradigms can enable, they're cool. They're a cool way to build stuff and services in the future. But if you go one step further and start to understand, okay, now that we have this new architecture that has constraints around it, that has UX constraints, that has technical constraints, once I started digging more into that, I was like, "Okay, this is cool. But it's extremely impractical. And there's a lot of strong limitations."

Dax: And then there are other type of limitations where it's like, "Oh, if we hammer at this enough, we're going to break through." There's kind of fundamental distributed systems limitation. So still interested, but kind of cooled my excitement on it. And I went back to doing now boring Web2 stuff. And then, the past six months, I just started seeing all these tweets, like, "Anyone smart is leaving Web2 and going into Web3. The best developers I know are going to Web3."

Dax: And I'm like, "There's a mountain of work left to do in Web2." There's so much inefficiency and stuff that needs to be built. So I didn't really get what was going on. And I was like, "Was I wrong about those constraints? Did all that stuff change all of a sudden?" And it turns out it didn't. It's more or less the same. There's better tooling around it. But the fundamental constraints are still there. But I was like, "Okay, let me dabble in it again." These NFT things are big.

Dax: And I actually was inspired by you because I remember seeing your tweet, like, those things that you printed out behind me. And I was like, "That's really funny and really crazy." And that kind of inspired me. Okay. What if I published a bunch of NFTs for every single Amazon? It's not every single but I think 50 of them are. So, it's a little weekend project. And I don't want to just publish a picture of somebody make it 3D and rotate and make it look cool. So weekend project. My fiancé was busy doing something else. So I had some time to myself and launch those.

Dax: So if any of you listening want to go and pay thousands of dollars for it and make me rich, please, feel free to do that.

Adam: Yeah. I hear people pay thousands of dollars, hundreds of thousands of dollars to these things. So maybe. I've got Nader Dabit coming on next month. I expect if I'm ever going to be sold on Web3, he's going to have to do it because I am very much a skeptic. I think all the things you said were much more rooted in an understanding of the underlying technology. But hearing you say it is the reason that I'm skeptic, which is most of the people that I sort of respect have seen measured about it and sort of let's pump the brakes.

Adam: But then, there are the people that I respect that are really into it. So it's a delicate thing for me. It's hard to understand where it's all headed because I do want to just kind of get swept away and when I see some of the people that I admire chasing after it.

Dax: Yeah. I mean, it's tough because you hear all, or you see all the historical news articles that from years ago that say things like, "The internet is just a fad or the iPhone is meaningless," and you don't want to be on that side looking forward. But that said, I do feel like I saw this hype cycle happen already. And I think you've been in tech for a while. You see these cycles come and go. Something about crypto, it's so fast. The cycle will happen in two years and repeat. So I think with the amount of money in it, I think everyone has stuff invested and that kind of takes some emotions to a different place. So yeah, it's tough to make sense of a lot of it. And even for myself was on a lot of digging. I still feel pretty confused.

Adam: Well, you said it just a minute ago. And Boris, when he was on the show said it that there's still plenty to do in Web2. So we can all rest assured we've got lots to work on and AWS land and lots of cool things still to build and lots of problems to solve. Yeah. So I'm going to ask you just a handful of kind of random short questions. So do you have a favorite tech blog?

Dax: Favorite tech blog? To be honest, no. My favorite tech bug is Twitter. I just go on Twitter and have the thousands of people read stuff and funnel it to me. So that's my go-to.

Adam: Yeah. I love it. Yeah. It's all aggregated and filtered. What about people in the cloud that you've either looked up to or sort of mentored you since you've kind of got into the cloud?

Dax: Yeah. Good question. I love Alex DeBrie's work. I think when I read the DynamoDB book, it really crystallized a bunch of things for me. I think the way he explained all of those things, I think, it's amazing. And I think it was super helpful for people that had a certain view of non-relational databases. I think it's one of the most misunderstood things in tech. And I think that book recommend it to every single person. Yeah. I think it does a great job demystifying a lot of that stuff and kind of fix some of the incorrect understandings.

Adam: Yeah. That just took me back to the moment. I think I followed you on Twitter, was you tweeted something about kind of the history of MongoDB and sort of the bad rap that it gave Dynamo. I'd totally forgotten that that was you.

Dax: Yeah. Exactly. For whatever reason, I've never really used relational database much in my career, just weird coincidence of the places I've worked at. So I've used databases like Mongo, like Cassandra. And pretty much all types of companies are able to do all types of things. And the last company was at was hardcore relational database.

Dax: They use it really, really intensively. And the conversations there, their perception of non-relational database was very strange to me. They would kind of understand things like, "Oh, there are certain things that are impossible to do in them." Most things that we need to do are impossible. And it's a tough conversation to have because in my head, I'm like, "But I did those things." I'm like, Didn't I do those? [crosstalk 00:30:05 company. Yeah. That's what I question my own understanding too. But, yeah, I think then I remembered, okay. I think there's a big backlash from the early days of Mongo that I think still exist today.

Adam: Yup. No, I think you nailed it on that thread. And I hadn't thought about sort of my problems with the term NoSQL because I just know when people say NoSQL, there's a connotation there, and there's still a bad taste. I think that was early in my startup days, Mongo was kind of hitting its hype cycle. And I can remember having conversations. Should we be doing this? I don't know. It sounds important. Next question I had for you is favorite emerging trend in tech. We talked about Web3. Any other big emerging trends that you're excited about?

Dax: Yeah. I'm really excited about some of these event-driven architecture things. This isn't new. It's been around for a while. But I've just been seeing a lot more activity there. I don't know if you've seen AsyncAPI. It's a spec. It's specification for APIs where everything's asynchronous where you're emitting events. It's going to go do some processing and then reply back to you with events.

Dax: The specifications for that is super interesting. The tooling around that has been really great. The guy behind EventBridge Canon, he's been posting. I think Dave... I forgot his name exactly. But he's been posting the work he's doing on tooling around AsyncAPI and it looks awesome. I think it's more than just a technology. It's a way for you to talk to domain experts in whatever you're doing and have a common language to understand here are the different workflows in this industry. The tooling and energy I've seen around that has been really interesting. I haven't really deployed too much of it myself. But it's something I'm keeping an eye out on.

Adam: But what about favorite AWS service?

Dax: Oh, favorite AWS service. Interesting. Hmm. I think I'm going to have to go with Dynamo again. Yeah. I think one of the big questions with serverless is everyone's interested in serverless, people not using serverless coming into serverless. There aren't actually a lot of database options that are really serverless-friendly. I think most databases like Postgres, MySQL really built for the era of long running processes that connect to them and do transactions. And you can use them with Lambdas and things like that.

Dax: But Dynamo is the most accessible, truly serverless database. It really works really well in a serverless. That said, we had been doing a lot of work lately at SST to make relational databases more accessible and would probably be launching some of that over the next few weeks. But yeah, I think it's a great tool, and I try to use it as much as possible except for the few cases where it doesn't really work for the workload.

Adam: Yeah. Just looking through your Twitter timeline, I had seen that you had this blog post up on relational databases and serverless. So it was interesting to hear… I don't know. I got on the call, not knowing you are sort of all in DynamoDB.

Dax: Yeah. It's tricky though because there are certain workloads that don't fit well to it. So any type of admin-type interface where you're looking across a large set of data, I need to sort and filter it by various set of attributes. It's very tabular. It's hard to use Dynamo in those situations. So I totally get why people want to use relational databases.

Dax: And also I think some people just like them better, and that's a valid reason to use it. They're more comfortable with it. That's where their skillset is. So yeah, we found this great library called Kysely which is a TypeScript library. It's a good TypeScript SQL query builder, really, really great typing. We just added support for RDS data API for it. I think RDS data API makes it a lot easier to use a Postgres or MySQL in a serverless environment. And we did some experimenting and some benchmarking with it. It's looking really nice. So it seems to be a good option that we're going to have for relational and serverless.

Adam: Yeah. I do know that there's a lot of people out there that just don't have the experience, don't want to sort of put that work in on Dynamo. But I do hope that people do give it the time. And I think it's a new way of thinking about data access or it's not maybe the thing you thought it was if you're coming from the MongoDB scaling issue days.

Dax: Yeah, exactly.

Adam: So I want to play the game. I'm just calling it the game now. For anyone who's joined, never been on the show when we've played the game, it's basically every service 200-plus AWS services, they're either prefixed with AWS or Amazon. And Dax is going to have a minute to get as many of them right as he can. I'm going to name some services and he's going to tell us if it's Amazon or AWS. Yep. So Dax, are you ready?

Dax: Yep. It's going to be most stressful minute of my life, I think.

Adam: So far, the time to beat Ben Brits had nine in a minute. And yesterday or Tuesday, Yvonne Roberts got seven. So those are the only two scores. You're guaranteed third place. No pressure here.

Dax: Cool.

Adam: They can only be so bad. All right, here we go. Minute on the clock. OpsWorks.

Dax: AWS.

Adam: Trusted Advisor.

Dax: Amazon.

Adam: Config.

Dax: Amazon.

Adam: Direct Connect.

Dax: Amazon. Oh, man.

Adam: CloudFront.

Dax: Amazon.

Adam: Amplify.

Dax: AWS.

Adam: Athena.

Dax: Amazon.

Adam: Ground Station.

Dax: Amazon.

Adam: SQS.

Dax: Amazon.

Adam: SNS.

Dax: Amazon.

Adam: GameLift.

Dax: AWS.

Adam: WorkSpaces.

Dax: Amazon. [crosstalk 00:36:28].

Adam: Okay Yeah. I think you got six.

Dax: Yeah. I mean it's a 50/50 shot.

Adam: Yeah, exactly. For a minute there, you'd miss three in a row. And I thought, "Well, it'd be actually kind of impressive if you could just miss a ton of them like getting them exactly wrong."

Dax: The problem is that there's no strategy to this because the gaming is truly random unless there's some secret formula they use at AWS.

Adam: Yeah. I have not picked up on the formula after three attempts at this game. Oh, man. Boris Tayne asked, we had a live question here, "Where do you see the sort of infrastructure derive from code movement, a la serverless cloud? Where do you see that headed?"

Dax: Yeah. So I think this is an area I think about a lot because there's a lot of tools that are coming out that reduce the amount you have to know. So we even talked about this for SST, how do you get people don't know anything up and running quickly? And I think what serverless cloud has built is very focused on that. I appreciate what they're doing and I like the angle they're taking. I personally don't know if that is going to work for most situations as they get bigger.

Dax: I think a lot of these solutions when you focus really hard on the zero to one solution, it's easy to accidentally introduce a situation where they, a year down the road or two years down the road, migrate out. You've been a tech for a while. I've been at so many companies that it started with Heroku. And then, they blew up. And they had to do this painful migration onto AWS. And having gone through that a few times, I'm very cautious when using tools like that, at least to build like a software company. If you're using those to build software for situations where you're not really a software company, it makes total sense, but if you're an agency like I explained to a bunch of websites, things like that.

Dax: And I liked the fact that at the end of the day, there's lowering the barrier for people to even get interested in this space, which is good. I'm not too sure if... I think Brian LaRue kind of covered this concept real well in a tweet. You can for a lot from your code, but it gets really tricky to deal with certain types of changes. If you stop referencing a database, you tear down the database. No, you need to keep that around.

Dax: We need to sort that state somewhere. And it kind of slowly rebuild up the typical IAC situation we have today. And I think even with the IAC situation we have today, it's not perfect. There's still weird situations you can get into where something depends on our thing in this tricky situation with CloudFormation.

Dax: So I think a layer that goes even further, it's going to be tough answering these a lot of situations. But yeah, I like where things are today. And I'm like, "I want to get that experience running smoother," and we'll see where it can go from there.

Adam: Yeah. It's really exciting times. I feel there are so many different groups working on sort of the developer experience and serverless. And I feel we've just got a lot of new things to play with. It seems like every month and that's exciting. But, generally, I think I fall where you do, which is I've had to deal with the kind of graduating out of something and know that can be pretty painful. So to the extent that that's sort of first class in a framework, they're thinking about that and making sure that you're just building on stuff that's sort of first-class whether it's CDK or CloudFormation. I think that helps a lot.

Dax: Yeah, exactly.

Adam: I guess the last thing I'd to get from you, Dax, before we go, and it's been great to have you on, do you have any hot takes for me? Technology hot takes, cloud hot takes, anything, really.

Dax: Yeah. I have a lot of these and I feel like 90% of them end up being wrong. So I have to figure out which one.

Adam: Well, that's impressive, just like the game, if you got them all wrong, that's-

Dax: Yeah. That's true. It's certainly the opposite of what I'm thinking.

Adam: Exactly.

Dax: Yeah. The thing I've been thinking about for a while now, actually, and this is kind of broad. But I think engineering is often seen, especially software engineering is seen as this scientific assessment of a situation. And then you kind of analyze the situation. You rationally come to a solution that you decide to go with. And I think that perception of that, I think you, a lot of times, hear people say like, "Oh, I use the right tool for the right job." And I think it's built on top of that perception. I think that's only partially true. I think we tried to do that.

Dax: But a lot of what we do is we do because we like it, and it's fun. And I think that's a completely valid way to make these decisions. And I think a lot is the baits that people get into where, "Well, you should be using this for this situation. You should be using that for that situation." They're predicated on the premise that we're all making these very logical decisions. But like I said, there was a time where I built a real-time distributed database in Elixir. There was really no rational reason for that. I learned a lot.

Dax: We shipped a great product on top of it. The underlying reason was we felt like doing that. And I felt like learning about that. So we decided to do it. And I think that's a completely valid reason to pick anything. And some people like certain styles of technology. And it's totally fine. Those people that love PHP and are doing a ton of and PHPs still. And there's no objective way to analyze the situation.

Adam: No. See, you're kind of giving a stamp of approval to the Expensify folks. That was the extreme version of like, "Just do what makes you happy," and you might IPO someday.

Dax: Yeah. Ultimately, I wouldn't have done what they did. And it is really impressive on paper, what they did. But they did it because they were interested in it and I liked it. It wasn't because it gave them some advantage or disadvantage. So, yeah. That's all I can say on that.

Adam: Well, I started a podcast because I liked it. And I'm glad I brought you on the show because this was fantastic, Dax. Thank you so, much for taking the time. Just a ton of fun.

Dax: Appreciate it. I'd had a great time, and I look forward to next few guests you have on.

Adam: Yeah. So on that note, I guess a little bit of show housekeeping, join the Discord, please. I've put a banner on the website. I'm doing everything I can. I'm tweeting about it. I want to see everybody in the Discord so that you guys can tell me that this is all okay, and I should keep doing this. I feel like I threatened them. I'm going to stop doing the show all the time. I'm just trying to get your five-star reviews. And that's another thing. Give it a five-star review. I don't know why people ask for that. I still don't know. I don't know if there's an insider like podcast, Discord that I could join and they'd tell me, like, "Why do you need five-star reviews?" But I'm going to keep asking, give the show a five star review. Yeah, I think that's it. Thanks again, everyone, for joining.

Dax: Thanks.