Episode #100: All Things Serverless with Jeremy Daly

May 10, 2021 • 96 minutes

On this very special 100th episode, Rebecca Marshburn interviews Jeremy about how he got started with serverless, why he started the Off-by-none newsletter and Serverless Chats, what he thinks is next for serverless and cloud, and so much more.

Watch this episode on YouTube:

About Rebecca Marshburn

Rebecca's interested in the things that interest people—What's important to them? Why? And when did they first discover it to be so? She's also interested in sharing stories, elevating others' experiences, exploring the intersection of physical environments and human behavior, and crafting the perfect pun for every situation. Today, Rebecca is the Head of Content & Community at Common Room. Prior to Common Room, she led the AWS Serverless Heroes program, where she met the singular Jeremy Daly, and guided content and product experiences for fashion magazines, online blogs, AR/VR companies, education companies, and a little travel outfit called Airbnb.

Twitter: @beccaodelay
LinkedIn: Rebecca Marshburn
Company: www.commonroom.io
Personal work (all proceeds go to the charity of the buyer's choice): www.letterstomyexlovers.com

Watch this episode on YouTube: https://youtu.be/VVEtxgh6GKI

This episode sponsored by CBT Nuggets and Lumigo.

Transcript

Rebecca: What a day today is! It's not every day you turn 100 times old, and on this day we celebrate Serverless Chats 100th episode with the most special of guests. The gentleman whose voice you usually hear on this end of the microphone, doing the asking, but today he's going to be doing the telling, the one and only, Jeremy Daly, and me. I'm Rebecca Marshburn, and your guest host for Serverless Chats 100th episode, because it's quite difficult to interview yourself. Hey Jeremy!

Jeremy: Hey Rebecca, thank you very much for doing this.

Rebecca: Oh my gosh. I am super excited to be here, couldn't be more honored. I'll give your listeners, our listeners, today, the special day, a little bit of background about us. Jeremy and I met through the AWS Serverless Heroes program, where I used to be a coordinator for quite some time. We support each other in content, conferences, product requests, road mapping, community-building, and most importantly, I think we've supported each other in spirit, and now I'm the head of content and community at Common Room, and Jeremy's leading Serverless Cloud at Serverless, Inc., so it's even sweeter that we're back together to celebrate this Serverless Chats milestone with you all, the most important, important, important, important part of the podcast equation, the serverless community. So without further ado, let's begin.

Jeremy: All right, hit me up with whatever questions you have. I'm here to answer anything.

Rebecca: Jeremy, I'm going to ask you a few heavy hitters, so I hope you're ready.

Jeremy: I'm ready to go.

Rebecca: And the first one's going to ask you to step way, way, way, way, way back into your time machine, so if you've got the proper attire on, let's do it. If we're going to step into that time machine, let's peel the layers, before serverless, before containers, before cloud even, what is the origin story of Jeremy Daly, the man who usually asks the questions.

Jeremy: That's tough. I don't think time machines go back that far, but it's funny, when I was in high school, I was involved with music, and plays, and all kinds of things like that. I was a very creative person. I loved creating things, that was one of the biggest sort of things, and whether it was music or whatever and I did a lot of work with video actually, back in the day. I was always volunteering at the local public access station. And when I graduated from high school, I had no idea what I wanted to do. I had used computers at the computer lab at the high school. I mean, this is going back a ways, so it wasn't everyone had their own computer in their house, but I went to college and then, my first, my freshman year in college, I ended up, there's a suite-mate that I had who showed me a website that he built on the university servers.

And I saw that and I was immediately like, "Whoa, how do you do that"? Right, just this idea of creating something new and being able to build that out was super exciting to me, so I spent the next couple of weeks figuring out how to do HTML, and this was before, this was like when JavaScript was super, super early and we're talking like 1997, and everything was super early. I was using this, I eventually moved away from using FrontPage and started using this thing called HotDog. It was a software for HTML coding, but I started doing that, and I started building websites, and then after a while, I started figuring out what things like CGI-bins were, and how you could write Perl scripts, and how you could make interactions happen, and how you could capture FormData and serve up different things, and it was a lot of copying and pasting.

My major at the time, I think was psychology, because it was like a default thing that I could do. But then I moved into computer science. I did computer science for about a year, and I felt that that was a little bit too narrow for what I was hoping to sort of do. I was starting to become more entrepreneurial. I had started selling websites to people. I had gone to a couple of local businesses and started building websites, so I actually expanded that and ended up doing sort of a major that straddled computer science and management, like business administration. So I ended up graduating with a degree in e-commerce and internet marketing, which is sort of very early, like before any of this stuff seemed to even exist. And then from there, I started a web development company, worked on that for 12 years, and then I ended up selling that off. Did a startup, failed the startup. Then from that startup, went to another startup, worked there for a couple of years, went to another startup, did a lot of consulting in between there, somewhere along the way I found serverless and AWS Cloud, and then now it's sort of led me to advocacy for building things with serverless and now I'm building sort of the, I think what I've been dreaming about building for the last several years in what I'm doing now at Serverless, Inc.

Rebecca: Wow. All right. So this love story started in the 90s.

Jeremy: The 90s, right.

Rebecca: That's an incredible, era and welcome to 2021.

Jeremy: Right. It's been a journey.

Rebecca: Yeah, truly, that's literally a new millennium. So in a broad way of saying it, you've seen it all. You've started from the very HotDog of the world, to today, which is an incredible name, I'm going to have to look them up later. So then you said serverless came along somewhere in there, but let's go to the middle of your story here, so before Serverless Chats, before its predecessor, which is your weekly Off-by-none newsletter, and before, this is my favorite one, debates around, what the suffix "less" means when appended to server. When did you first hear about Serverless in that moment, or perhaps you don't remember the exact minute, but I do really want to know what struck you about it? What stood out about serverless rather than any of the other types of technologies that you could have been struck by and been having a podcast around?

Jeremy: Right. And I think I gave you maybe too much of a surface level of what I've seen, because I talked mostly about software, but if we go back, I mean, hardware was one of those things where hardware, and installing software, and running servers, and doing networking, and all those sort of things, those were part of my early career as well. When I was running my web development company, we started by hosting on some hosting service somewhere, and then we ended up getting a dedicated server, and then we outgrew that, and then we ended up saying, "Well maybe we'll bring stuff in-house". So we did on-prem for quite some time, where we had our own servers in the T1 line, and then we moved to another building that had a T3 line, and if anybody doesn't know what that is, you probably don't need to anymore.

But those are the things that we were doing, and then eventually we moved into a co-location facility where we rented space, and we rented electricity, and we rented all the utilities, the bandwidth, and so forth, but we had Blade servers and I was running VMware, and we were doing all this kind of stuff to manage the infrastructure, and then writing software on top of that, so it was a lot of work. I know I posted something on Twitter a few weeks ago, about how, when I was, when we were young, we used to have to carry a server on our back, uphill, both ways, to the data center, in the snow, with no shoes, and that's kind of how it felt, that you were doing a lot of these things.

And then 2008, 2009, as I was kind of wrapping up my web development company, we were just in the process of actually saying it's too expensive at the colo. I think we were paying probably between like $5,000 and $7,000 a month between the ... we had leases on some of the servers, you're paying for electricity, you're paying for all these other things, and we were running a fair amount of services in there, so it seemed justifiable. We were making money on it, that wasn't the problem, but it just was a very expensive fixed cost for us, and when the cloud started coming along and I started actually building out the startup that I was working on, we were building all of that in the cloud, and as I was learning more about the cloud and how that works, I'm like, I should just move all this stuff that's in the co-location facility, move that over to the cloud and see what happens.

And it took a couple of weeks to get that set up, and now, again, this is early, this is before ELB, this is before RDS, this is before, I mean, this was very, very early cloud. I mean, I think there was S3 and EC2. I think those were the two services that were available, with a few other things. I don't even think there were VPCs yet. But anyways, I moved everything over, took a couple of weeks to get that over, and essentially our bill to host all of our clients' sites and projects went from $5,000 to $7,000 a month, to $750 a month or something like that, and it's funny because had I done that earlier, I may not have sold off my web development company because it could have been much more profitable, so it was just an interesting move there.

So we got into the cloud fairly early and started sort of leveraging that, and it was great to see all these things get added and all these specialty services, like RDS, and just taking the responsibility because I literally was installing Microsoft SQL server on an EC2 instance, which is not something that you want to do, you want to use RDS. It's just a much better way to do it, but anyways, so I was working for another startup, this was like startup number 17 or whatever it was I was working for, and we had this incident where we were using ... we had a pretty good setup. I mean, everything was on EC2 instances, but we were using DynamoDB to do some caching layers for certain things. We were using a sharded database, MySQL database, for product information, and so forth.

So the system was pretty resilient, it was pretty, it handled all of the load testing we did and things like that, but then we actually got featured on Good Morning America, and they mentioned our app, it was the Power to Mobile app, and so we get mentioned on Good Morning America. I think it was Good Morning America. The Today Show? Good Morning America, I think it was. One of those morning shows, anyways, we got about 10,000 sign-ups in less than a minute, which was amazing, or it was just this huge spike in traffic, which was great. The problem was, is we had this really weak point in our system where we had to basically get a lock on the database in order to get an incremental-ID, and so essentially what happened is the database choked, and then as soon as the database choked, just to create user accounts, other users couldn't sign in and there was all kinds of problems, so we basically lost out on all of this capability.

So I spent some time doing a lot of research and trying to figure out how do you scale that? How do you scale something that fast? How do you have that resilience in there? And there's all kinds of ways that we could have done it with traditional hardware, it's not like it wasn't possible to do with a slightly better strategy, but as I was digging around in AWS, I'm looking around at some different things, and we were, I was always in the console cause we were using Dynamo and some of those things, and I came across this thing that said "Lambda," with a little new thing next to it. I'm like, what the heck is this?

So I click on that and I start reading about it, and I'm like, this is amazing. We don't have to spin up a server, we don't have to use Chef, or Puppet, or anything like that to spin up these machines. We can basically just say, when X happens, do Y, and it enlightened me, and this was early 2015, so this would have been right after Lambda went GA. Had never heard of Lambda as part of the preview, I mean, I wasn't sort of in that the re:Invent, I don't know, what would you call that? Vortex, maybe, is a good way to describe the event.

Rebecca: Vortex sounds about right. That's about how it feels by the end.

Jeremy: Right, exactly. So I wasn't really in that, I wasn't in that group yet, I wasn't part of that community, so I hadn't heard about it, and so as I started playing around with it, I immediately saw the value there, because, for me, as someone who again had managed servers, and it had built out really complex networking too. I think some of the things you don't think about when you move to an on-prem where you're managing your stuff, even what the cloud manages for you. I mean, we had firewalls, and we had to do all the firewall rules ourselves, right. I mean, I know you still have to do security groups and things like that in AWS, but just the level of complexity is a lot lower when you're in the cloud, and of course there's so many great services and systems that help you do that now.

But just the idea of saying, "wait a minute, so if I have something happen, like a user signup, for example, and I don't have to worry about provisioning all the servers that I need in order to handle that," and again, it wasn't so much the server aspect of it as it was the database aspect of it, but one of the things that was sort of interesting about the idea of Serverless 2 was this asynchronous nature of it, this idea of being more event-driven, and that things don't have to happen immediately necessarily. So that just struck me as something where it seemed like it would reduce a lot, and again, this term has been overused, but the undifferentiated heavy-lifting, we use that term over and over again, but there is not a better term for that, right?

Because there were just so many things that you have to do as a developer, as an ops person, somebody who is trying to straddle teams, or just a PM, or whatever you are, so many things that you have to do in order to get an application running, first of all, and then even more you have to do in order to keep it up and running, and then even more, if you start thinking about distributing it, or scaling it, or getting any of those things, disaster recovery. I mean, there's a million things you have to think about, and I saw serverless immediately as this opportunity to say, "Wait a minute, this could reduce a lot of that complexity and manage all of that for you," and then again, literally let you focus on the things that actually matter for your business.

Rebecca: Okay. As someone who worked, how should I say this, in metatech, or the technology of technology in the serverless space, when you say that you were starting to build that without ELB even, or RDS, my level of anxiety is like, I really feel like I'm watching a slow horror film. I'm like, "No, no, no, no, no, you didn't, you didn't, you didn't have to do that, did you"?

Jeremy: We did.

Rebecca: So I applaud you for making it to the end of the film and still being with us.

Jeremy: Well, the other thing ...

Rebecca: Only one protagonist does that.

Jeremy: Well, the other thing that's interesting too, about Serverless, and where it was in 2015, Lambda goes GA, this will give you some anxiety, there was no API gateway. So there was no way to actually trigger a Lambda function from a web request, right. There was no VPC access in Lambda functions, which meant you couldn't connect to a database. The only thing you do is connect via HDP, so you could connect to DynamoDB or things like that, but you could not connect directly to RDS, for example. So if you go back and you look at the timeline of when these things were released, I mean, if just from 2015, I mean, you literally feel like a caveman thinking about what you could do back then again, it's banging two sticks together versus where we are now, and the capabilities that are available to us.

Rebecca: Yeah, you're sort of in Plato's cave, right, and you're looking up and you're like, "It's quite dark in here," and Lambda's up there, outside, sowing seeds, being like, "Come on out, it's dark in there". All right, so I imagine you discovering Lambda through the console is not a sentence you hear every day or general console discovery of a new product that will then sort of change the way that you build, and so I'm guessing maybe one of the reasons why you started your Off-by-none newsletter or Serverless Chats, right, is to be like, "How do I help tell others about this without them needing to discover it through the console"? But I'm curious what your why is. Why first the Off-by-none newsletter, which is one of my favorite things to receive every week, thank you for continuing to write such great content, and then why Serverless Chats? Why are we here today? Why are we at number 100? Which I'm so excited about every time I say it.

Jeremy: And it's kind of crazy to think about all the people I've gotten a chance to talk to, but so, I think if you go back, I started writing blog posts maybe in 2015, so I haven't been doing it that long, and I certainly wasn't prolific. I wasn't consistent writing a blog post every week or every, two a week, like some people do now, which is kind of crazy. I don't know how that, I mean, it's hard enough writing the newsletter every week, never mind writing original content, but I started writing about Serverless. I think it wasn't until the beginning of 2018, maybe the end of 2017, and there was already a lot of great content out there. I mean, Ben Kehoe was very early into this and a lot of his stuff I read very early.

I mean, there's just so many people that were very early in the space, I mean, Paul Johnson, I mean, just so many people, right, and I started reading what they were writing and I was like, "Oh, I've got some ideas too, I've been experimenting with some things, I feel like I've gotten to a point where what I could share could be potentially useful". So I started writing blog posts, and I think one of the earlier blog posts I wrote was, I want to say 2017, maybe it was 2018, early 2018, but was a post about serverless security, and what was great about that post was that actually got me connected with Ory Segal, who had started PureSec, and he and I became friends and that was the other great thing too, is just becoming part of this community was amazing.

So many awesome people that I've met, but so I saw all this stuff people were writing and these things people were doing, and I got to maybe August of 2018, and I said to myself, I'm like, "Okay, I don't know if people are interested in what I'm writing". I wasn't writing a lot, but I was writing a little bit, but I wasn't sure people were overly interested in what I was writing, and again, that idea of the imposter syndrome, certainly everything was very early, so I felt a little bit more comfortable. I always felt like, well, maybe nobody knows what they're talking about here, so if I throw something into the fold it won't be too, too bad, but certainly, I was reading other things by other people that I was interested in, and I thought to myself, I'm like, "Okay, if I'm interested in this stuff, other people have to be interested in this stuff," but it wasn't easy to find, right.

I mean, there was sort of a serverless Twitter, if you want to use that terminology, where a lot of people tweet about it and so forth, obviously it's gotten very noisy now because of people slapped that term on way too many things, but I don't want to have that discussion, but so I'm reading all this great stuff and I'm like, "I really want to share it," and I'm like, "Well, I guess the best way to do that would just be a newsletter."

I had an email list for my own personal site that I had had a couple of hundred people on, and I'm like, "Well, let me just turn it into this thing, and I'll share these stories, and maybe people will find them interesting," and I know this is going to sound a little bit corny, but I have two teenage daughters, so I'm allowed to be sort of this dad-jokey type. I remember when I started writing the first version of this newsletter and I said to myself, I'm like, "I don't want this to be a newsletter." I was toying around with this idea of calling it an un-newsletter. I didn't want it to just be another list of links that you click on, and I know that's interesting to some people, but I felt like there was an opportunity to opine on it, to look at the individual links, and maybe even tell a story as part of all of the links that were shared that week, and I thought that that would be more interesting than just getting a list of links.

And I'm sure you've seen over the last 140 issues, or however many we're at now, that there's been changes in the way that we formatted it, and we've tried new things, and things like that, but ultimately, and this goes back to the corny thing, I mean, one of the first things that I wanted to do was, I wanted to basically thank people for writing this stuff. I wanted to basically say, "Look, this is not just about you writing some content". This is big, this is important, and I appreciate it. I appreciate you for writing that content, and I wanted to make it more of a celebration really of the community and the people that were early contributors to that space, and that's one of the reasons why I did the Serverless Star thing.

I thought, if somebody writes a really good article some week, and it's just, it really hits me, or somebody else says, "Hey, this person wrote a great article," or whatever. I wanted to sort of celebrate that person and call them out because that's one of the things too is writing blog posts or posting things on social media without a good following, or without the dopamine hit of people liking it, or re-tweeting it, and things like that, it can be a pretty lonely place. I mean, I know I feel that way sometimes when you put something out there, and you think it's important, or you think people might want to see it, and just not enough people see it.

It's even worse, I mean, 240 characters, or whatever it is to write a tweet is one thing, or 280 characters, but if you're spending time putting together a tutorial or you put together a really good thought piece, or story, or use case, or something where you feel like this is worth sharing, because it could inspire somebody else, or it could help somebody else, could get them past a bump, it could make them think about something a different way, or get them over a hump, or whatever. I mean, that's just the kind of thing where I think people need that encouragement, and I think people deserve that encouragement for the work that they're doing, and that's what I wanted to do with Off-by-none, is make sure that I got that out there, and to just try to amplify those voices the best that I could. The other thing where it's sort of progressed, and I guess maybe I'm getting ahead of myself, but the other place where it's progressed and I thought was really interesting, was, finding people ...

There's the heavy hitters in the serverless space, right? The ones we all know, and you can name them all, and they are great, and they produce amazing content, and they do amazing things, but they have pretty good engines to get their content out, right? I mean, some people who write for the AWS blog, they're on the AWS blog, right, so they're doing pretty well in terms of getting their things out there, right, and they've got pretty good engines.

There's some good dev advocates too, that just have good Twitter followings and things like that. Then there's that guy who writes the story. I don't know, he's in India or he's in Poland or something like that. He writes this really good tutorial on how to do this odd edge-case for serverless. And you go and you look at their Medium and they've got two followers on Medium, five followers on Twitter or something like that. And that to me, just seems unfair, right? I mean, they've written a really good piece and it's worth sharing right? And it needs to get out there. I don't have a huge audience. I know that. I mean I've got a good following on Twitter. I feel like a lot of my Twitter followers, we can have good conversations, which is what you want on Twitter.

The newsletter has continued to grow. We've got a good listener base for this show here. So, I don't have a huge audience, but if I can share that audience with other people and get other people to the forefront, then that's important to me. And I love finding those people and those ideas that other people might not see because they're not looking for them. So, if I can be part of that and help share that, that to me, it's not only a responsibility, it's just it's incredibly rewarding. So ...

Rebecca: Yeah, I have to ... I mean, it is your 100th episode, so hopefully I can give you some kudos, but if celebrating others' work is one of your main tenets, you nail it every time. So ...

Jeremy: I appreciate that.

Rebecca: Just wanted you to know that. So, that's sort of the Genesis of course, of both of these, right?

Jeremy: Right.

Rebecca: That underpins the foundational how to share both works or how to share others' work through different channels. I'm wondering how it transformed, there's this newsletter and then of course it also has this other component, which is Serverless Chats. And that moment when you were like, "All right, this newsletter, this narrative that I'm telling behind serverless, highlighting all of these different authors from all these different global spaces, I'm going to start ... You know what else I want to do? I don't have enough to do, I'm going to start a podcast." How did we get here?

Jeremy: Well, so the funny thing is now that I think about it, I think it just goes back to this tenet of fairness, this idea where I was fortunate, and I was able to go down to New York City and go to Serverless Days New York in late 2018. I was able to ... Tom McLaughlin actually got me connected with a bunch of great people in Boston. I live just outside of Boston. We got connected with a bunch of great people. And we started the Serverless Days Boston for 2019. And we were on that committee. I started traveling and I was going to conferences and I was meeting people. I went to re:Invent in 2018, which I know a lot of people just don't have the opportunity to do. And the interesting thing was, is that I was pulling aside brilliant people either in the hallway at a conference or more likely for a very long, deep discussion that we would have about something at a pub in Northern Ireland or something like that, right?

I mean, these were opportunities that I was getting that I was privileged enough to get. And I'm like, these are amazing conversations. Just things that, for me, I know changed the way I think. And one of the biggest things that I try to do is evolve my thinking. What I thought a year ago is probably not what I think now. Maybe call it flip-flopping, whatever you want to call it. But I think that evolving your thinking is the most progressive thing that you can do and starting to understand as you gain new perspectives. And I was talking to people that I never would have talked to if I was just sitting here in my home office or at the time, I mean, I was at another office, but still, I wasn't getting that context. I wasn't getting that experience. And I wasn't getting those stories that literally changed my mind and made me think about things differently.

And so, here I was in this privileged position, being able to talk to these amazing people and in some cases funny, because they're celebrities in their own right, right? I mean, these are the people where other people think of them and it's almost like they're a celebrity. And these people, I think they deserve fame. Don't get me wrong. But like as someone who has been on that side of it as well, it's ... I don't know, it's weird. It's weird to have fans in a sense. I love, again, you can be my friend, you don't have to be my fan. But that's how I felt about ...

Rebecca: I'm a fan of my friends.

Jeremy: So, a fan and my friend. So, having talked to these other people and having these really deep conversations on serverless and go beyond serverless to me. Actually I had quite a few conversations with some people that have nothing to do with serverless. Actually, Peter Sbarski and I, every time we get together, we only talk about the value of going to college for some reason. I don't know why. It has usually nothing to do with serverless. So, I'm having these great conversations with these people and I'm like, "Wow, I wish I could share these. I wish other people could have this experience," because I can tell you right now, there's people who can't travel, especially a lot of people outside of the United States. They ... it's hard to travel to the United States sometimes.

So, these conversations are going on and I thought to myself, I'm like, "Wouldn't it be great if we could just have these conversations and let other people hear them, hopefully without bar glasses clinking in the background. And so I said, "You know what? Let's just try it. Let's see what happens. I'll do a couple of episodes. If it works, it works. If it doesn't, it doesn't. If people are interested, they're interested." But that was the genesis of that, I mean, it just goes back to this idea where I felt a little selfish having conversations and not being able to share them with other people.

Rebecca: It's the very Jeremy Daly tenet slogan, right? You got to share it. You got to share it ...

Jeremy: Got to share it, right?

Rebecca: The more he shares it, it celebrates it. I love that. I think you do ... Yeah, you do a great job giving a megaphone so that more people can hear. So, in case you need a reminder, actually, I'll ask you, I know what the answer is to this, but do you know the answer? What was your very first episode of Serverless Chats? What was the name, and how long did it last?

Jeremy: What was the name?

Rebecca: Oh yeah. Oh yeah.

Jeremy: Oh, well I know ... Oh, I remember now. Well, I know it was Alex DeBrie. I absolutely know that it was Alex DeBrie because ...

Rebecca: Correct on that.

Jeremy: If nobody, if you do not know Alex DeBrie, not only is he an AWS data hero, as well as the author of The DynamoDB Book, but he's also like the most likable person on the planet too. It is really hard if you've ever met Alex, that you wouldn't remember him. Alex and I started communicating, again, we met through the serverless space. I think actually he was working at Serverless Inc. at the time when we first met. And I think I met him in person, finally met him in person at re:Invent 2018. But he and I have collaborated on a number of things and so forth. So, let me think what the name of it was. "Serverless Purity Versus Practicality" or something like that. Is that close?

Rebecca: That's exactly what it was.

Jeremy: Oh, all right. I nailed it. Nailed it. Yes!

Rebecca: Wow. Well, it's a great title. And I think ...

Jeremy: Don't ask me what episode number 27 was though, because no way I could tell you that.

Rebecca: And just for fun, it was 34 minutes long and you released it on June 17th, 2019. So, you've come a long way in a year and a half. That's some kind of wildness. So it makes sense, like, "THE," capital, all caps, bold, italic, author for databases, Alex DeBrie. Makes sense why you selected him as your guest. I'm wondering if you remember any of the ... What do you remember most about that episode? What was it like planning it? What was the reception of it? Anything funny happened recording it or releasing it?

Jeremy: Yeah, well, I mean, so the funny thing is that I was incredibly nervous. I still am, actually a lot of guests that I have, I'm still incredibly nervous when I'm about to do the actual interview. And I think it's partially because I want to do justice to the content that they're presenting and to their expertise. And I feel like there's a responsibility to them, but I also feel like the guests that I've had on, some of them are just so smart, and the things they say, just I'm in awe of some of the things that come out of these people's mouths. And I'm like, "This is amazing and people need to hear this." And so, I feel like we've had really good episodes and we've had some okay episodes, but I feel like I want to try to keep that level up so that they owe that to my listener to make sure that there is high quality episode that, high quality information that they're going to get out of that.

But going back to the planning of the initial episodes, so I actually had six episodes recorded before I even released the first one. And the reason why I did that was because I said, "All right, there's no way that I can record an episode and then wait a week and then record another episode and wait a week." And I thought batching them would be a good idea. And so, very early on, I had Alex and I had Nitzan Shapira and I had Ran Ribenzaft and I had Marcia Villalba and I had Erik Peterson from Cloud Zero. And so, I had a whole bunch of these episodes and I reached out to I think, eight or nine people. And I said, "I'm doing this thing, would you be interested in it?" Whatever, and we did planning sessions, still a thing that I do today, it's still part of the process.

So, whenever I have a guest on, if you are listening to an episode and you're like, "Wow, how did they just like keep the thing going ..." It's not scripted. I don't want people to think it's scripted, but it is, we do review the outline and we go through some talking points to make sure that again, the high-quality episode and that the guest says all the things that the guest wants to say. A lot of it is spontaneous, right? I mean, the language is spontaneous, but we do, we do try to plan these episodes ahead of time so that we make sure that again, we get the content out and we talk about all the things we want to talk about. But with Alex, it was funny.

He was actually the first of the six episodes that I recorded, though. And I wasn't sure who I was going to do first, but I hadn't quite picked it yet, but I recorded with Alex first. And it was an easy, easy conversation. And the reason why it was an easy conversation was because we had talked a number of times, right? It was that in a pub, talking or whatever, and having that friendly chat. So, that was a pretty easy conversation. And I remember the first several conversations I had, I knew Nitzan very well. I knew Ran very well. I knew Erik very well. Erik helped plan Serverless Days Boston with me. And I had known Marcia very well. Marcia actually had interviewed me when we were in Vegas for re:Invent 2018.

So, those were very comfortable conversations. And so, it actually was a lot easier to do, which probably gave me a false sense of security. I was like, "Wow, this was ... These came out pretty well." The conversations worked pretty well. And also it was super easy because I was just doing audio. And once you add the video component into it, it gets a little bit more complex. But yeah, I mean, I don't know if there's anything funny that happened during it, other than the fact that I mean, I was incredibly nervous when we recorded those, because I just didn't know what to expect. If anybody wants to know, "Hey, how do you just jump right into podcasting?" I didn't. I actually was planning on how can I record my voice? How can I get comfortable behind a microphone? And so, one of the things that I did was I started creating audio versions of my blog posts and posting them on SoundCloud.

So, I did that for a couple of ... I'm sorry, a couple of blog posts that I did. And that just helped make me feel a bit more comfortable about being able to record and getting a little bit more comfortable, even though I still can't stand the sound of my own voice, but hopefully that doesn't bother other people.

Rebecca: That is an amazing ... I think we so often talk about ideas around you know where you want to go and you have this vision and that's your goal. And it's a constant reminder to be like, "How do I make incremental steps to actually get to that goal?" And I love that as a life hack, like, "Hey, start with something you already know that you wrote and feel comfortable in and say it out loud and say it out loud again and say it out loud again." And you may never love your voice, but you will at least feel comfortable saying things out loud on a podcast.

Jeremy: Right, right, right. I'm still working on the, "Ums" and, "Ahs." I still do that. And I don't edit those out. That's another thing too, actually, that one of the things I do want people to know about this podcast is these are authentic conversations, right? I am probably like ... I feel like I'm, I mean, the most authentic person that I know. I just want authenticity. I want that out of the guests. The idea of putting together an outline is just so that we can put together a high quality episode, but everything is authentic. And that's what I want out of people. I just want that authenticity, and one of the things that I felt kept that, was leaving in, "Ums" and, "Ahs," you know what I mean? It's just, it's one of those things where I know a lot of podcasts will edit those out and it sounds really polished and finished.

Again, I mean, I figured if we can get the clinking glasses out from the background of a bar and just at least have the conversation that that's what I'm trying to achieve. And we do very little editing. We do cut things out here and there, especially if somebody makes a mistake or they want to start something over again, we will cut that out because we want, again, high quality episodes. But yeah, but authenticity is deeply important to me.

Rebecca: Yeah, I think it probably certainly helps that neither of us are robots because robots wouldn't say, "Um" so many times. As I say, "Uh." So, let's talk about, Alex DeBrie was your first guest, but there's been a hundred episodes, right? So, from, I might say the best guest, as a hundredth episode guests, which is our very own Jeremy Daly, but let's go back to ...

Jeremy: I appreciate that.

Rebecca: Your guests, one to 99. And I mean, you've chatted with some of the most thoughtful, talented, Serverless builders and architects in the industry, and across coincident spaces like ML and Voice Technology, Chaos Engineering, databases. So, you started with Alex DeBrie and databases, and then I'm going to list off some names here, but there's so many more, right? But there's the Gunnar Grosches, and the Alexandria Abbasses, and Ajay Nair, and Angela Timofte, James Beswick, Chris Munns, Forrest Brazeal, Aleksandar Simovic, and Slobodan Stojanovic. Like there are just so many more. And I'm wondering if across those hundred conversations, or 99 plus your own today, if you had to distill those into two or three lessons, what have you learned that sticks with you? If there are emerging patterns or themes across these very divergent and convergent thinkers in the serverless space?

Jeremy: Oh, that's a tough question.

Rebecca: You're welcome.

Jeremy: So, yeah, put me on the spot here. So, yeah, I mean, I think one of the things that I've, I've seen, no matter what it's been, whether it's ML or it's Chaos Engineering, or it's any of those other observability and things like that. I think the common thing that threads all of it is trying to solve problems and make people's lives easier. That every one of those solutions is like, and we always talk about abstractions and, and higher-level abstractions, and we no longer have to write ones and zeros on punch cards or whatever. We can write languages that either compile or interpret it or whatever. And then the cloud comes along and there's things we don't have to do anymore, that just get taken care of for us.

And you keep building these higher level of abstractions. And I think that's a lot of what ... You've got this underlying concept of letting somebody else handle things for you. And then you've got this whole group of people that are coming at it from a number of different angles and saying, "Well, how will that apply to my use case?" And I think a lot of those, a lot of those things are very, very specific. I think things like the voice technology where it's like the fact that serverless powers voice technology is only interesting in the fact as to say that, the voice technology is probably the more interesting part, the fact that serverless powers it is just the fact that it's a really simple vehicle to do that. And basically removes this whole idea of saying I'm building voice technology, or I'm building a voice app, why do I need to worry about setting up servers and all this kind of stuff?

It just takes that away. It takes that out of the equation. And I think that's the perfect idea of saying, "How can you take your use case, fit serverless in there and apply it in a way that gets rid of all that extra overhead that you shouldn't have to worry about." And the same thing is true of machine learning. And I mean, and SageMaker, and things like that. Yeah, you're still running instances of it, or you still have to do some of these things, but now there's like SageMaker endpoints and some other things that are happening. So, it's moving in that direction as well. But then you have those really high level services like NLU API from IBM, which is the Watson Natural Language Processing.

You've got AP recognition, you've got the vision API, you've got sentiment analysis through all these different things. So, you've got a lot of different services that are very specific to machine learning and solving a discrete problem there. But then basically relying on serverless or at least presenting it in a way that's serverless, where you don't have to worry about it, right? You don't have to run all of these Jupiter notebooks and things like that, to do machine learning for a lot of cases. This is one of the things I talk about with Alexandra Abbas, was that these higher level APIs are just taking a lot of that responsibility or a lot of that heavy lifting off of your plate and allowing you to really come down and focus on the things that you're doing.

So, going back to that, I do think that serverless, that the common theme that I see is that this idea of worrying about servers and worrying about patching things and worrying about networking, all that stuff. For so many people now, that's just not even a concern. They didn't even think about it. And that's amazing to think of, compute ... Or data, or networking as a utility that is now just available to us, right? And I mean, again, going back to my roots, taking it for granted is something that I think a lot of people do, but I think that's also maybe a good thing, right? Just don't think about it. I mean, there are people who, they're still going to be engineers and people who are sitting in the data center somewhere and racking servers and doing it, that's going to be forever, right?

But for the things that you're trying to build, that's unimportant to you. That is the furthest from your concern. You want to focus on the problem that you're trying to solve. And so I think that, that's a lot of what I've seen from talking to people is that they are literally trying to figure out, "Okay, how do I take what I'm doing, my use case, my problem, how do I take that to the next level, by being able to spend my cycles thinking about that as opposed to how I'm going to serve it up to people?"

Rebecca: Yeah, I think it's the mantra, right, of simplify, simplify, simplify, or maybe even to credit Bruce Lee, be like water. You're like, "How do I be like water in this instance?" Well, it's not to be setting up servers, it's to be doing what I like to be doing. So, you've interviewed these incredible folks. Is there anyone left on your list? I'm sure there ... I mean, I know that you have a large list. Is there a few key folks where you're like, "If this is the moment I'm going to ask them, I'm going to say on the hundredth episode, 'Dear so-and-so, I would love to interview you for Serverless Chats.'" Who are you asking?

Jeremy: So, this is something that, again, we have a stretch list of guests that we attempt to reach out to every once in a while just to say, "Hey, if we get them, we get them." But so, I have a long list of people that I would absolutely love to talk to. I think number one on my list is certainly Werner Vogels. I mean, I would love to talk to Dr. Vogels about a number of things, and maybe even beyond serverless, I'm just really interested. More so from a curiosity standpoint of like, "Just how do you keep that in your head?" That vision of where it's going. And I'd love to drill down more into the vision because I do feel like there's a marketing aspect of it, that's pushing on him of like, "Here's what we have to focus on because of market adoption and so forth. And even though the technology, you want to move into a certain way," I'd be really interesting to talk to him about that.

And I'd love to talk to him more too about developer experience and so forth, because one of the things that I love about AWS is that it gives you so many primitives, but at the same time, the thing I hate about AWS is it gives you so many primitives. So, you have to think about 800 services, I know it's not that many, but like, what is it? 200 services, something like that, that all need to kind of connect together. And I love that there's that diversity in those capabilities, it's just from a developer standpoint, it's really hard to choose which ones you're supposed to use, especially when several services overlap. So, I'm just curious. I mean, I'd love to talk to him about that and see what the vision is in terms of, is that the idea, just to be a salad bar, to be the Golden Corral of cloud services, I guess, right?

Where you can choose whatever you want and probably take too much and then not use a lot of it. But I don't know if that's part of the strategy, but I think there's some interesting questions, could dig in there. Another person from AWS that I actually want to talk to, and I haven't reached out to her yet just because, I don't know, I just haven't reached out to her yet, but is Brigid Johnson. She is like an IAM expert. And I saw her speak at re:Inforce 2019, it must have been 2019 in Boston. And it was like she was speaking a different language, but she knew IAM so well, and I am not a fan of IAM. I mean, I'm a fan of it in the sense that it's necessary and it's great, but I can't wrap my head around so many different things about it. It's such a ...

It's an ongoing learning process and when it comes to things like being able to use tags to elevate permissions. Just crazy things like that. Anyways, I would love to have a conversation with her because I'd really like to dig down into sort of, what is the essence of IAM? What are the things that you really have to think about with least permission? Especially applying it to serverless services and so forth. And maybe have her help me figure out how to do some of the cross role IAM things that I'm trying to do. Certainly would love to speak to Jeff Barr. I did meet Jeff briefly. We talked for a minute, but I would love to chat with him.

I think he sets a shining example of what a developer advocate is. Just the way that ... First of all, he's probably the only person alive who knows every service at AWS and has actually tried it because he writes all those blog posts about it. So that would just be great to pick his brain on that stuff. Also, Adrian Cockcroft would be another great person to talk to. Just this idea of what he's done with microservices and thinking about the role, his role with Netflix and some of those other things and how all that kind of came together, I think would be a really interesting conversation. I know I've seen this in so many of his presentations where he's talked about the objections, what were the objections of Lambda and how have you solved those objections? And here's the things that we've done.

And again, the methodology of that would be really interesting to know. There's a couple of other people too. Oh, Sam Newman who wrote Building Microservices, that was my Bible for quite some time. I had it on my iPad and had a whole bunch of bookmarks and things like that. And if anybody wants to know, one of my most popular posts that I've ever written was the ... I think it was ... What is it? 16, 17 architectural patterns for serverless or serverless microservice patterns on AWS. Can't even remember the name of my own posts. But that post was very, very popular. And that even was ... I know Matt Coulter who did the CDK. He's done the whole CDK ... What the heck was that? The CDKpatterns.com. That was one of the things where he said that that was instrumental for him in seeing those patterns and being able to use those patterns and so forth.

If anybody wants to know, a lot of those patterns and those ideas and those ... The sort of the confidence that I had with presenting those patterns, a lot of that came from Sam Newman's work in his Building Microservices book. So again, credit where credit is due. And I think that that would be a really fascinating conversation. And then Simon Wardley, I would love to talk to. I'd actually love to ... I actually talked to ... I met Lin Clark in Vegas as well. She was instrumental with the WebAssembly stuff, and I'd love to talk to her. Merritt Baer. There's just so many people. I'm probably just naming too many people now. But there are a lot of people that I would love to have a chat with and just pick their brain.

And also, one of the things that I've been thinking about a lot on the show as well, is the term "serverless." Good or bad for some people. Some of the conversations we have go outside of serverless a little bit, right? There's sort of peripheral to it. I think that a lot of things are peripheral to serverless now. And there are a lot of conversations to be had. People who were building with serverless. Actually real-world examples.

One of the things I love hearing was Yan Cui's "Real World Serverless" podcast where he actually talks to people who are building serverless things and building them in their organizations. That is super interesting to me. And I would actually love to have some of those conversations here as well. So if anyone's listening and you have a really interesting story to tell about serverless or something peripheral to serverless please reach out and send me a message and I'd be happy to talk to you.

Rebecca: Well, good news is, it sounds like A, we have at least ... You've got at least another a hundred episodes planned out already.

Jeremy: Most likely. Yeah.

Rebecca: And B, what a testament to Sam Newman. That's pretty great when your work is referred to as the Bible by someone. As far as in terms of a tome, a treasure trove of perhaps learnings or parables or teachings. I ... And wow, what a list of other folks, especially AWS power ... Actually, not AWS powerhouses. Powerhouses who happened to work at AWS. And I think have paved the way for a ton of ways of thinking and even communicating. Right? So I think Jeff Barr, as far as setting the bar, raising the bar if you will. For how to teach others and not be so high-level, or high-level enough where you can follow along with him, right? Not so high-level where it feels like you can't achieve what he's showing other people how to do.

Jeremy: Right. And I just want to comment on the Jeff Barr thing. Yeah.

Rebecca: Of course.

Jeremy: Because again, I actually ... That's my point. That's one of the reasons why I love what he does and he's so perfect for that position because he's relatable and he presents things in a way that isn't like, "Oh, well, yeah, of course, this is how you do this." I mean, it's not that way. It's always presented in a way to make it accessible. And even for services that I'm not interested in, that I know that I probably will never use, I generally will read Jeff's post because I feel it gives me a good overview, right?

Rebecca: Right.

Jeremy: It just gives me a good overview to understand whether or not that service is even worth looking at. And that's certainly something I don't get from reading the documentation.

Rebecca: Right. He's inviting you to come with him and understanding this, which is so neat. So I think ... I bet we should ... I know that we can find all these twitter handles for these folks and put them in the show notes. And I'm especially ... I'm just going to say here that Werner Vogels's twitter handle is @Werner. So maybe for your hundredth, all the listeners, everyone listening to this, we can say, "Hey, @Werner, I heard that you're the number one guest that Jeremy Daly would like to interview." And I think if we get enough folks saying that to @Werner ... Did I say that @Werner, just @Werner?

Jeremy: I think you did.

Rebecca: Anyone if you can hear it.

Jeremy: Now listen, he did retweet my serverless musical that I did. So ...

Rebecca: That's right.

Jeremy: I'm sort of on his radar maybe.

Rebecca: Yeah. And honestly, he loves serverless, especially with the number of customers and the types of customers and ... that are doing incredible things with it. So I think we've got a chance, Jeremy. I really do. That's what I'm trying to say.

Jeremy: That's good to know. You're welcome anytime. He's welcome anytime.

Rebecca: Do we say that @Werner, you are welcome anytime. Right. So let's go back to the genesis, not necessarily the genesis of the concept, right? But the genesis of the technology that spurred all of these other technologies, which is AWS Lambda. And so what ... I don't think we'd be having these conversations, right, if AWS Lambda was not released in late 2014, and then when GA I believe in 2015.

Jeremy: Right.

Rebecca: And so subsequently the serverless paradigm was thrust into the spotlight. And that seems like eons ago, but also three minutes ago.

Jeremy: Right.

Rebecca: And so I'm wondering ... Let's talk about its evolution a bit and a bit of how if you've been following it for this long and building it for this long, you've covered topics from serverless CI/CD pipelines, observability. We already talked about how it's impacted voice technologies or how it's made it easy. You can build voice technology without having to care about what that technology is running on.

Jeremy: Right.

Rebecca: You've even talked about things like the future and climate change and how it relates to serverless. So some of those sort of related conversations that you were just talking about wanting to have or having had with previous guests. So as a host who thinks about these topics every day, I'm wondering if there's a topic that serverless hasn't touched yet or one that you hope it will soon. Those types of themes, those threads that you want to pull in the next 100 episodes.

Jeremy: That's another tough question. Wow. You got good questions.

Rebecca: That's what I said. Heavy hitters. I told you I'd be bringing it.

Jeremy: All right. Well, I appreciate that. So that's actually a really good question. I think the evolution of serverless has seen its ups and downs. I think one of the nice things is you look at something like serverless that was so constrained when it first started. And it still has constraints, which are good. But it ... Those constraints get lifted. We just talked about Adrian's talks about how it's like, "Well, I can't do this, or I can't do that." And then like, "Okay, we'll add some feature that you can do that and you can do that." And I think that for the most part, and I won't call it anything specific, but I think for the most part that the evolution of serverless and the evolution of Lambda and what it can do has been thoughtful. And by that I mean that it was sort of like, how do we evolve this into a way that doesn't create too much complexity and still sort of holds true to the serverless ethos of sort of being fairly easy or just writing code.

And then, but still evolve it to open up these other use cases and edge cases. And I think that for the most part, that it has held true to that, that it has been mostly, I guess, a smooth ride. There are several examples though, where it didn't. And I said I wasn't going to call anything out, but I'm going to call this out. I think RDS proxy wasn't great. I think it works really well, but I don't think that's the solution to the problem. And it's a band-aid. And it works really well, and congrats to the engineers who did it. I think there's a story about how two different teams were trying to build it at the same time actually. But either way, I look at that and I say, "That's a good solution to the problem, but it's not the solution to the problem."

And so I think serverless has stumbled in a number of ways to do that. I also feel EFS integration is super helpful, but I'm not sure that's the ultimate goal to share ... The best way to share state. But regardless, there are a whole bunch of things that we still need to do with serverless. And a whole bunch of things that we still need to add and we need to build, and we need to figure out better ways to do maybe. But I think in terms of something that doesn't get talked about a lot, is the developer experience of serverless. And that is, again I'm not trying to pitch anything here. But that's literally what I'm trying to work on right now in my current role, is just that that developer experience of serverless, even though there was this thoughtful approach to adding things, to try to check those things off the list, to say that it can't do this, so we're going to make it be able to do that by adding X, Y, and Z.

As amazing as that has been, that has added layers and layers of complexity. And I'll go back way, way back to 1997 in my dorm room. CGI-bins, if people are not familiar with those, essentially just running on a Linux server, it was a way that it would essentially run a Perl script or other types of scripts. And it was essentially like you're running PHP or you're running Node, or you're running Ruby or whatever it was. So it would run a programming language for you, run a script and then serve that information back. And of course, you had to actually know ins and outs, inputs and outputs. It was more complex than it is now.

But anyways, the point is that back then though, once you had the script written. All you had to do is ... There's a thing called FTP, which I'm sure some people don't even know what that is anymore. File transfer protocol, where you would basically say, take this file from my local machine and put it on this server, which is a remote machine. And you would do that. And the second you did that, magically it was updated and you had this thing happening. And I remember there were a lot of jokes way back in the early, probably 2017, 2018, that serverless was like the new CGI-bin or something like that. But more as a criticism of it, right? Or it's just CGI-bins reborn, whatever. And I actually liked that comparison. I felt, you know what? I remember the days where I just wrote code and I just put it to some other server where somebody was dealing with it, and I didn't even have to think about that stuff.

We're a long way from that now. But that's how serverless felt to me, one of the first times that I started interacting with it. And I felt there was something there, that was something special about it. And I also felt the constraints of serverless, especially the idea of not having state. People rely on things because they're there. But when you don't have something and you're forced to think differently and to make a change or find a way to work around it. Sometimes workarounds, turn into best practices. And that's one of the things that I saw with serverless. Where people were figuring out pretty quickly, how to build applications without state. And then I think the problem is that you had a lot of people who came along, who were maybe big customers of AWS. I don't know.

I'm not going to say that you might be influenced by large customers. I know lots of places are. That said, "We need this." And maybe your ... The will gets bent, right. Because you just... you can only fight gravity for so long. And so those are the kinds of things where I feel some of the stuff has been patchwork and those patchwork things haven't ruined serverless. It's still amazing. It's still awesome what you can do within the course. We're still really just focusing on fast here, with everything else that's built. With all the APIs and so forth and everything else that's serverless in the full-service ecosystem. There's still a lot of amazing things there. But I do feel we've become so complex with building serverless applications, that you can't ... the Hello World is super easy, but if you're trying to build an actual application, it's a whole new mindset.

You've got to learn a whole bunch of new things. And not only that, but you have to learn the cloud. You have to learn all the details of the cloud, right? You need to know all these different things. You need to know cloud formation or serverless framework or SAM or something like that, in order to get the stuff into the cloud. You need to understand the infrastructure that you're working with. You may not need to manage it, but you still have to understand it. You need to know what its limitations are. You need to know how it connects. You need to know what the failover states are like.

There's so many things that you need to know. And to me, that's a burden. And that's adding new types of undifferentiated heavy-lifting that shouldn't be there. And that's the conversation that I would like to have continuing to move forward is, how do you go back to a developer experience where you're saying you're taking away all this stuff. And again, to call out Werner again, he constantly says serverless is about writing code, but ask anybody who builds serverless applications. You're doing a lot more than writing code right now. And I would love to see us bring the conversation back to how do we get back there?

Rebecca: Yeah. I think it kind of goes back to ... You and I have talked about this notion of an ode to simplicity. And it's sort of what you want to write into your ode, right? If we're going to have an ode to simplicity, how do we make sure that we keep the simplicity inside of the ode?

Jeremy: Right.

Rebecca:
So I've got ... I don't know if you've seen these.

Jeremy: I don't know.

Rebecca: But before I get to some wrap-up questions more from the brainwaves of Jeremy Daly, I don't want to forget to call out some long-time listener questions. And they wrote in a via Twitter and they wanted to perhaps pick your brain on a few things.

Jeremy: Okay.

Rebecca: So I don't know if you're ready for this.

Jeremy: A-M-A. A-M-A.

Rebecca: I don't know if you've seen these. Yeah, these are going to put you in the ...

Jeremy: A-M-A-M. Wait, A-M-A-A? Asked me almost anything? No, go ahead. Ask me anything.

Rebecca: A-M-A-A. A-M-J. No. Anyway, we got it. Ask Jeremy almost anything.

Jeremy: There you go.

Rebecca: So there's just three to tackle for today's episode that I'm going to lob at you. One is from Ken Collins. "What will it take to get you back to a relational database of Lambda?"

Jeremy: Ooh, I'm going to tell you right now. And without a doubt, Aurora Serverless v2. I played around with that right after re:Invent 2000. What was it? 20. Yeah. Just came out, right? I'm trying to remember what year it is at this point.

Rebecca: Yes. Indeed.

Jeremy: When that just ... Right when that came out. And I had spent a lot of time with Aurora Serverless v1, I guess if you want to call it that. I spent a lot of time with it. I used it on a couple of different projects. I had a lot of really good success with it. I had the same pains as everybody else did when it came to scaling and just the slowness of the scaling and then ... And some of the step-downs and some of those things. There were certainly problems with it. But v2 just the early, early preview version of v2 was ... It was just a marvel of engineering. And the way that it worked was just ... It was absolutely fascinating.

And I know it's getting ready or it's getting close, I think, to being GA. And when that becomes GA, I think I will have a new outlook on whether or not I can fit RDS into my applications. I will say though. Okay. I will say, I don't think that transactional applications should be using relational databases though. One of the things that was sort of a nice thing about moving to serverless, speaking of constraints. Was this idea that MySQL or Postgres or whatever, really didn't have the scale or without, again, engineering a whole cluster and failover and sharding and all kinds of crazy things like that to make sure that you had the scale. Relational databases were just not the best choice when you were building things with serverless.

And so when I quickly realized that, I tried to find a solution. So I built something called Serverless MySQL, which sort of is a ... And again, I don't want the RDS proxy people to think that because RDS proxy sort of was trying to solve the same problem that Serverless MySQL was, that I have any problem with that. I'm actually glad. The fact that I had to use my Serverless MySQL was only because there wasn't a better solution for it. But I built that because I wanted to continue to use it. And even though I built that and it worked, there was just so many limitations. And it was one of those things where using NoSQL or no SQL just made so much more sense. And I forced myself into thinking that way because of the constraint. And that was huge, that changed my mind on how NoSQL works.

And I absolutely have to call out Rick Houlihan as well as Alex DeBrie. But Rick Houlihan, speaking about another sort of person who influenced so many of my thought processes and changed my mind so dramatically. When I saw Rick's 2018 talk at re:Invent about single table design. And I know that they're calling it something different now, but essentially single table design. This idea of ... I went back and watched 2017. And that was like, Okay, now my mind's moving around. And then watching 2017, watching 2018, then watching 2019. 2019, I was in his session watching it. And I could see his evolution of thinking. Of how he changed the way that he was approaching different problems and the patterns that he was using. And that clicked so much for me, that now I think about ... I feel like, this is going to sound strange, but if you've seen the movie The Matrix. You've probably seen the movie The Matrix.

Rebecca: Oh, yeah.

Jeremy: Oh, of course. Okay. When one of the guys is watching the green character scroll down the screen and he's like, "I don't even see the code anymore. I just see there's a blonde, there's whatever." That's how I feel looking at DynamoDB now. It just makes sense to me. It clicked. And I wish everybody could feel that way. I don't feel superior or anything like that, but it just works. It just works in my brain now. And that's one of the reasons why I built DynamoDB toolbox too, was I was trying to say, "How can I translate how I see this into a way that might be more relatable to other people and hopefully get them to sort of click." And now actually at Serverless Inc. one of the things with serverless clouds, we're building something called Serverless Data, which is a similar key-value store type thing.

Which again is me ... Is my manifestation of how I envision sort of the interface into these things and hopefully will make sense to people. So, but yeah. So to answer Ken's question. Serverless Aurora or Aurora Serverless v2, will definitely get me using it for anything that's got to be analytic or analytical processing or analytics process processing. And also probably using it as I sort of do now, as sort of a secondary, a separate secondary data store so that I can run queries on data, even though I want it to be more highly available on the front end through something like DynamoDB.

Rebecca: Oh my gosh. That moment where it clicks, I just have this mental image of two brain synapses extending their hands toward each other and finally touching. Yeah. Finally touching index fingers, being like, "Hey, we did it." All right. So from Matt Colter.

Jeremy: Oh.

Rebecca: Comes another one.

Jeremy: Love Matt too.

Rebecca: Right? There you got some fans and some friends. Some friends that you're fans of, or that are fans of you.

Jeremy: Speaking of Northern Ireland. Nor, Nor, Nor, Noren Ire ... what do they say? Noren Iron? Noren Iron.

Rebecca: I would... It would be trouble if I tried to pronounce it the way they say it. "So with the terms serverless-first," or Matt asks, "With the term serverless-first and cloud-native causing confusion as to what we know it means (code as a liability), do you have a less confusing name we could use?"

Jeremy: Ooh. So it's funny. I had this conversation with Jay Nair over breakfast one time where we were, I think we were at the serverless breakfast. Where were we? It must've been re:Invent I guess. But we were having this conversation and he was, he asked me a very similar question. And I said, "Look, it's as simple. Serverless is just the way." Right. So when somebody says, "So what's the term for serverless-first or for cloud-native or whatever." When you're building an application, it's just the way. That, it blows my mind. Now look, containers are great, by the way. I love containers. I know I don't talk about them very much. I'm not a fan of Kubernetes because I think it's overly complex for what it needs to do, but it works really well too. So I mean that if you know how to manage it, which not very many people do, that's why all the cloud providers are doing it now that, using containers it can be a very, very good way and a smart way to build your applications. You get portability around them. There're all kinds of reasons to do it. I love the fact that ... My skin was crawling a little bit when they announced that Lambda would support containers. Then when I realized it was just a packaging format, I was like, "Okay, that's much better. That I can deal with". But I think that's one of the things where it introduces a level of comfortability.

And if you put your, or if I should say, if I put my product manager hat on and I'm looking at that, I need to find familiarity, right? When I'm building a product, I need something that's familiar to people and not necessarily revolutionary, maybe evolutionary. I think serverless is revolutionary, which is part of the problem why it's not being adopted. I think as quickly as it could be because it's not quite as evolutionary as something like containers were. Containers are like the next step in VMs. Or it's this idea where you can now split things up into little, smaller chunks, and smaller chunks, and so forth, and then came orchestration and you had all the problems around that.

So I think that no matter how you're building your applications, whether you're building them in containers as a packaging format, as a runtime, whatever, how you serve those containers up, whether those are again, serverless, running in Lambda and Firecracker, or you're running them on IBM, or you're running them on Google Cloud ... Google Cloud Run, I think is a fascinating technology. No matter how you're doing it, I think the key here is to focus on the fact that you should be building your applications in a way that is going to be able to run on one of these modern types of infrastructures.

So that's the only thing I would say, if you're trying to write code to run directly on an EC2 instance, 1997 called, they want their ... I don't know their Pearl Jam shirt back, I don't know anyways. So ...

Rebecca: They want their HotDog shirt back.

Jeremy: They want their HotDog shirt back, right. I would say they want their Green Day shirt back, but I love Green Day. I was just listening to them the other day, anyways. So again, I don't think I have a better term for you, Matt, unfortunately, other than just to say, I don't think serverless is a very good term. I've never been a fan of the term. I've tried to defend it. And then I feel like what's the saying, if you argue with an idiot in public, people don't know that anyways. I don't know what the saying is. I was really ...

Rebecca: Who is the idiot?

Jeremy: Who's the idiot, right? Exactly. So it's one of those things. So the problem is, is that that term is not great. And things like serverless first, I liked that idea that a PR I mean, I love the sentiment of it, right? Like this idea of saying like, we're going to try to build everything serverless first, and then we're going to fall back to containers on the things we can't. And then maybe the things that we can't do, then we're going to fall back to VMs. And then in the worst-case scenario, you've got to build stuff on bare metal.

But so I love that sentiment. And I think that sentiment is always going to be the way, but I think there's just this idea of like, this is just modern app development. Like, this is just how you build apps now. And if you're building apps starting on the bottom up, unless you have a really compelling reason to do that, you are really handicapping yourself. And you're going to struggle because this is just the way the world's moving. So again, I just say, it's the way, it's the way to the way to build applications now.

Rebecca: Yeah. And as someone who had a large part in writing so many of those serverless messaging, serverless narratives, Lambda as packaged as containers, I'm sorry for making your skin crawl and to any listeners that I made crawl, I am @beccaodelay if you want to hit me up on Twitter about that, and I can apologize to you publicly. So lastly from Rob Sutter and, and maybe my personal favorite, because I can hear Rob's brand of humor in this question, since I have the great honor of knowing him personally as well, but he asks, "Do you ever go back and stand up instances just to remind yourself of everything you don't have to deal with anymore?"

Jeremy: Well, I just had Rob on episode 99, talking about FaunaDB, which is also a fascinating thing. So super exciting stuff that they're doing over there. So every once in a while, and I'm going to admit to this and hopefully people won't flood my website to crash it, but I have been so busy doing these other things that my personal website, jeremydaly.com is still a load-balanced WordPress site running on EC2 with an ELB in front of it, or maybe an ALB, whatever it is. And, and that is still out there running on multiple instances. And I have backup instances. I was hit on a Hacker News article one time that they shut my site down. So I had to spin up some additional instances, but that is still running there. So I am so afraid of going to touch that thing, that, because I just haven't done it in so long that I actually avoid it and I haven't done it yet.

So Off-by-none and Serverless Chat sites those are all static Jamstack sites. But yeah ... but so I don't do it often, but every once in a while, I do have to type in SSH and get into an old school server. The last startup that I was just at, we were running, we had actually inherited a Symphony app that was running on PHP.

So I did have to actually manage, manage a few clusters of servers, and have all the load balancing and all of the scale, the scale and groups and auto-scaling and things like that. And so I am not unfamiliar with all of that stuff, but if I do it for my own personal amusement, or I guess from my own personal suffering, I would not do that on purpose anymore. And, and that would be my advice to anybody is you maybe want to learn that stuff. And you probably do, if you want to get, you know, some of your AWS certs, but, but from a practical standpoint, I would not, I would not do that myself if, unless the absolute need arise or arose, I guess.

Rebecca: Yeah. I want to say I'm like, that sounds like fun dot, dot, dot. All right. So those are the listener questions. And I, I want to get back to a few of my own because this is me interviewing you. Right. But it's a time to reflect. Right. And so I just, I'm curious in the spirit of reflection in this 100th episode, if you were just starting Serverless Chats today, or just starting your newsletter or your blog or your conference talks, what advice would you offer to your own self?

Jeremy: Oh, well, I, one thing I have to absolutely call out because I don't, I certainly don't want people to think that these things just magically happen. I have a team that helps me with these now, when I first started, it was just me. I was writing the newsletter. I was reading the newsletter, I was copy editing. I was doing all of that stuff myself, but now I have two absolutely amazing people that help me out. Angela Milinazzo basically does a lot of social media stuff. She runs the newsletter for Serverless Chats Insiders, and she does all the guests reach out and are reaching out to the guests and coordination with the guests and so forth.

She does a lot of the marketing stuff and, and just so many things that can get taken off of my plate so that I can focus more on again, having the conversations and, and doing some of the more, hopefully important, the undifferentiated heavy-lifting stuff, I guess, that I don't have to do with, with some of those, some of the things that Angela does for me, which is amazing.

So thank you. And I've actually, I've been working with Angela for, I want to say like maybe eight or nine years, eight years now, something like that. And she worked at the same startup together. And then, and then we went separate ways is that we left that startup, but then we came back together to do this. So that was super exciting. And then also Melissa De orenzo, who was a time friend of mine, but all, she actually worked at my web development company with me, but she does copy editing for me, writes, helps with the research for the Serverless Stars and, and just copy edits the newsletter. And does all these other things, she does my accounting for me for all the stuff that we do. So I would not be able to do this stuff without having a really amazing team behind me.

And I think that is one of the biggest pieces of advice I would give anybody is teamwork. Like there is just ... I mean, I've been doing this if we want to, if we want to consider 1997 the sort of the start date of my career around this stuff, that's 24 years or so that I've been doing this. And I think any person is the sum of their experience. Like you just ... some things you remember, some things you forget, but whatever you experienced you're that's going to shape who you are. It's going to shape the way that you think. But you cannot ... there're just experiences that I will never have.

There are, there are backgrounds or situations that I will never experience. There are thoughts that I will never have because of who I am because of where I grew up, because of how, where I went to school, because of the experiences that I've had or whatever, and without having diverse teammates to sort of help you see things from a different angle, not only to help you, but I mean, not like help you, actually help you to work and accomplish things, but without having people around you that differ in ... whether it's in the slightest way or in a massive way ... without that different level of perspective you can't grow.

And so, I mean, that is one of the greatest things that I have ... I think the greatest thing for me, having gotten the chance to not only interview all these people for Serverless Chats, not only to read all of the posts that I've shared on Off-by-none and all of the articles there but to get to go to the conferences, to get, to give these conference talks, to have people question things that I've written in my blog posts. I should call out something really important here, and thank him for it. I wrote a blog post about serverless security, one of the, not my main post, but another one that was about like a SQL injection thing. And, and I used some language in there that was sort of general and sort of speculative, right. And Chris Munns actually called me out on that because he, and he actually kind of had to do a little tweetstorm.

I think he got some word from up above that he had to sort of call out, and, and make sure that he corrected the record on these things. And, and while I wasn't being critical of it, I was just being, I think I used some language and some general generalities that, that weren't accurate or did that maybe were misplaced in a way. And I don't think I did anything wrong other than the fact that I was too general and I wasn't clear enough. And when I got that feedback from him, I wasn't offended by it. Right. And that's another important thing. Like you've got to learn to take criticism, like absolutely, whether it's constructive or not, you need to learn to take it. But I remember getting that criticism from him and thinking to myself, I'm like, no, he's absolutely right.

Like, I can see how people could misinterpret what I said. And again, once you get a voice and once people start reading what you're writing, you have a responsibility and you absolutely have to just make sure. And that's one of the things that I did. I mean, sort of from that point forward, every post that I've ever written is highly researched. Right. And if I don't know something, I usually will say, I'm not a hundred percent sure about this. You know, I could be wrong about this or whatever. So I will try to call those things out if I'm not a hundred percent sure, but you can make, you can make a lot of assumptions when you're writing blog posts, because sometimes it's just easier to fill in a sentence here and there by adding some bit of flair to it or whatever, that will make an assumption.

And while it might seem right at the time those words can have an effect on somebody. And that's why I spend so much time now when I do write blog posts to try to heavily research those and make sure that the things I say are accurate and that I, again, I'm not using terms like "simple" and "easy" and things like that. 'Cause that's another thing what is simple to me or what is easy to me or what seems easy to me, or what seems easy to you or whatever could be wildly different from somebody else's perception. And that's another thing is just, I guess if we're moving on with the advice here is, know your audience again, going back to Jeff Barr, he just has this way to explain things that bring it down to a level that don't make you feel dumb, right.

That you're like, or that your eyes don't gloss over because you have no idea what he's talking about, but at the same time, doesn't feel like he's talking down to you either. And that's a hard thing to learn. I don't think ... I don't read a lot of blog posts that don't do that. And that's a hard thing to learn. So if you can find that level of humility where you say, I may know something, and I may know something really, really well, how can I communicate that to people in a way that doesn't talk down to them, but at the same time is accessible. Right? 'Cause accessibility is, is a huge thing as well.

Yeah. What else? I mean, going back again, I think the diversity thing, I don't want to harp on it too much, but that is those one of those things where me as a person personally, from 2018, when I first started writing these blog posts to the person that I am now, and the way that I think about things, politically as well as intellectually, the way I think about technology, all these different things.

I am a different person and I think differently now I have evolved my thinking dramatically because I was able just for a moment, just for a few minutes for 45 minutes, for 30 minutes on a conversation, or for five minutes in the hallway at a conference I was able to, sort of feel or be empathetic to somebody else's predicament or their perspective or there, sort of their ... and get a tiny taste into that background, that insight and so forth. And that has dramatically changed who I am. And I mean, I'm pretty happy with where I am now. I still think I've got a lot of work to do on myself in terms of continuing to open my mind, but I've met more people than I can ...

I don't remember all their names, unfortunately, but I have met so many people. And that is just, that is one of those things where I guess ... so my advice here is whatever you do if you're speaking at conferences or you're writing blog posts, or you're doing open source projects, or you're doing a podcast or whatever, open your channels up for feedback and talk to people. And, and if somebody has a problem with something, you say like, again, there are trolls, and then there are legitimate people who have concerns, or you know, who want to talk to you about something. And if you can take that criticism and you can open yourself up to that stuff, then I think, you just make yourself a better person. And yeah. And then the other thing, I guess I'll just say is, it's fine to make assumptions about products and find, to make assumptions about building things and software and whatever, never make assumptions about people.

Just the thing is, is that, you might read something somebody wrote and it might be wildly inaccurate. It might be way off base from your own personal thinking. And my biggest, I guess my, the advice that I give to a lot of people, especially younger people, is over the course of your career, you will hear a lot of good ideas and you'll hear a lot of bad ideas and you will not know the difference. It takes a long time to start understanding.

Most times when you hear something, you have no context, you don't have the context. You need to understand whether that's good or it's bad. Sometimes you do, but most times you don't. So just take everything with a grain of salt and know that the best thing you can do is continue to learn and keep an open mind and get as much context as you can. And hopefully, that turns into a better person and a better member of the community.

Rebecca: So I asked you for some serverless advice, but I think that's just really some great life advice. Most of those can be applied to a broader ...

Jeremy: Did I go off there?

Rebecca: No, I mean, thank you. I think let's, yeah, it's more than serverless, right? It's like the power of building a great team, the power of being able to receive critiques, and then in such a way where you want to improve your work and the way that you want to help others share it the way that you want to remain open, to understanding where your own blind spots are. Yeah. I'm a little floored, but yeah.

Thank you for sharing that with me. I think a huge, thank you, of course, to Angela and Melissa and your team, a huge thank you to Rob and Matt and Ken who submitted their questions that we asked on the air, and then a huge thank you to all of your listeners and to the serverless community. And so on this day, this very special day of your hundredth Serverless Chats episode. What do you hope remains with them, with your team, with your listeners, with the serverless community? What do you hope with them in their mind's ear as they drift off to sleep this evening after hearing you as your guest on Serverless Chats?

Jeremy: Oh man. Well, I mean, again, I think it's just one of those things where I'm wired in a way where I do what I do, I think, because I like to help people. And I think there are a lot of people who you just don't, you just don't know like, that's why I say don't make assumptions about people because you don't, you don't know, you have no idea what that person has gone through or what they're going through, or what's behind a smile or a frown, or whatever. You just, you don't know. And, and there's so much that, you know, human potential is amazing. And if you limit the possibility of human potential because you judge too soon, then I think that you do everything, everyone that disservice, including yourself and including, I guess, the evolution of mankind, which is something that is sort of passionate, that I'm passionate about.

So I guess the advice that I would leave is just look, don't make assumptions, be good to people, right? Like just, we're all in this together. So sort of like, I don't know, just go forth, be good, treat people, treat people well and build with serverless because that is definitely the future.

Rebecca: All right. I promise you as I drift off to sleep tonight, I will definitely think, be good to people, treat others well, build with serverless. Yeah. I love it. That's, it's three easy sentences. Good to remember, Jeremy, thank you so much for being our guest, but really your guest on Serverless Chats. And thank you for the honor of letting me be the asker. I can't wait to see you at episode 101. And I can't wait to see, did we, did I hear @vernor is going to be episode 101?

Jeremy: I don't know about 101, but I mean, there's plenty of episodes between now and 200, so.

Rebecca: Well, I can't wait. Is there anything else you want to leave us with?

Jeremy: No, I just, I want to thank you, Rebecca. I mean, you have been, you've been, I think another sort of what's the right word for it. Like you've been instrumental in me being able to do this, right. I mean, one of the things I had said earlier was, validation is extremely important. It's just what humans crave: validation. And it's not so much the notoriety or the popularity or any of those things that matter to me, what matters to me is that, that I help people. And when you put a lot of time and energy into something to try to help somebody, or you're thinking you try to help somebody, and it just doesn't get amplified. It is, it can be really frustrating. And, and again, like I said, there are so many ideas out there.

There's so many ideas out there that you do not know, that I do not know, that I've never heard before, they're perspectives that I've never heard before. And if you can't get to those, because you know, that person has five followers on Twitter, that's a shame, that's a horrible shame. And so I guess the ... what I want to say is that like you and the Heroes Program at AWS and, and the help that you gave me, I mean, just with, with dealing with like trying to do sponsorships and these other things that you, I mean, you helped coordinate some guests for me and like reach out to some people like that.

That's the kind of help, that's the type of thing where that, that feedback from you, that validation from you, the validation from AWS, that recognition that what I was doing was, was helping people and, and hopefully moving that needle, those are the kinds of things that people need. That was something that I needed. And I don't think I would, I don't think I'd be able to be doing what I'm doing now if I didn't have that encouragement and that support from you and other members of the community.

Rebecca: Well, I have no doubt that you would have achieved it regardless, but I am happy that I got to be the person to help you do so. And I think we share that ethos around and enthusiasm around the power of bringing community members together and being able to share their ideas and perspectives excitedly. So on the same plane here, I love it. Yeah.

Jeremy: Awesome. Awesome. Well, thank you, Rebecca. I appreciate it.

Rebecca: Yeah. Can't wait to see episode 100, happy episode 100 and, or, you know, hear it, I should say, 'cause I've seen it now this whole time, and then can't wait to, can't wait to see the next 100 episodes, really looking forward to it.

Jeremy: Awesome.