Episode #113: Serverless for Startups with Chris Munns

October 4, 2021 • 58 minutes

On this episode, Jeremy and Rebecca chat with Chris Munns about the evolution of serverless over the last few years, how the learning curve affects adoption, what goes into building an effective developer advocacy team, and advice for startups looking to get started with the cloud.

Chris Munns is a Tech Lead/Advisor for Startup Solution Architects at Amazon Web Services based in New York City. Chris spent the last 4.5 years working with AWS's developer customers to understand how serverless technologies can drastically change the way they think about building and running applications at potentially massive scale with minimal administration overhead. Before this, Chris a global Business Development Manager for DevOps at AWS, he spent a few years as a Solutions Architect at AWS, and has held senior operations engineering posts at Etsy, Meetup, and other NYC based startups. Chris has a Bachelor of Science in Applied Networking and System Administration from the Rochester Institute of Technology.


Jeremy: Hi everybody. I'm Jeremy Daley.

Rebecca: And I'm Rebecca Marshburn.

Jeremy: And this is Serverless Chats. Hey Rebecca, how you doing?

Rebecca: Hey, I'm good. Yep, that's where you're listening to Serverless Chats. I just, usually we have some banter, but I'm so excited for our guest today.

Jeremy: I am too but-

Rebecca: That's my only banter.

Jeremy: ... I'm also excited because my oldest daughter just left a few minutes ago. She's going to a Jonas Brothers concert tonight. And I-

Rebecca: What?

Jeremy: ... told her and her friend, I said, "Listen, no dancing on top of cars or stumbling out of bars tonight." That's the only Jonas Brothers song I know. So there was a terrible dad joke, but speaking of dads, I think our next guest or our guest this week, probably a single handedly keeps Lego in business with all of these-

Chris: [crosstalk 00:00:47].

Jeremy: ... sets that he buys for his kids because I constantly see it-

Chris: [crosstalk 00:00:50].

Jeremy: ... and basically I was in a mall the other day, for some back to school shopping for my kids, I saw a Lego store and the first thing I thought of was this person. So, this guest-

Chris: Thank you.

Jeremy: ... amazing guest, so happy to have him on today. He is currently the tech leads or a Tech Lead/Advisor for Startup Solution Architects at Amazon Web Services but most of you probably know him because he spent the last four and a half years as the leader or leading the Developer Advocate Team for serverless at AWS. So Mr. Chris Munns is with us, Chris, thank you so much for joining us.

Chris: Thank you. Thank you for having me both. I'm excited to be here and thank you for getting all of the words of my new job title out. I myself am stumbling over them most days now when I'm introducing myself, but yes. So Tech Lead/Advisor to the Startup Solution Architects at AWS.

Rebecca: So you do say the slash out loud? This was actually the first question I had for you is like, is it a spoken slash or do you say slash dash?

Chris: Yeah, I don't know if it should be tech lead and advisor or something. It's a mix. So the role which we can talk about here is, ambiguous, let's say in terms of certain bounds and functions and where it's going to end up. And so, there wasn't really necessarily a good title to base it off of, it sits somewhere between these two.

Rebecca: I guess it's a little shorter than tech lead [ampers and 00:02:14] startup solution advisor.

Chris: Yeah. I wish there was a better, just single word or two words that can be put together for it. But, no, I'm excited and it's just been, this is the end of my first two weeks in role and real quick on Jonas Brothers, so my only tie to the Jonas Brothers is that I actually grew up in the same area as them. And that was one of things where they went, I think, to the high school in the neighboring town or something like that.

Chris: And as they got more and more famous you used to hear people that would be like, "Oh, well the Jonas brothers, their family comes in and eats at my uncle's pizzeria," or something like that. And it was like, oh okay, that's cool. But yeah, they are North Jersey natives as am I and so that's all I got in Jonas Brothers, unfortunately.

Jeremy: Well, that's probably enough. At least enough for me anyways. Well, so you've been at AWS for what? Eight years now, something like that? It's been a very long time.

Chris: Yeah. I'm like nine years four months or something like that.

Jeremy: Oh, wow.

Chris: If you put it all together, I am technically a boomerang. Well, so I started November of 2011, I left in December of 2014 for a few months to run infrastructure for a startup and then I came back about six months later. So, had I not left, I would've hit 10 years here in a couple weeks, but instead I'm about, six or so months shy of that.

Jeremy: Wow. So you have this new role now, and it's like you said, it's not quite fully defined, it's still forming. Which I think is awesome by the way, because that is amazing when you get to that point where you've been in this business for so long now, you've had all this experience, you've seen all these different things from a number of different angles, and now you're coming in and you're really trying to use that experience and really help AWS focus on startups. So tell us a little bit about what you think this role was going to be.

Chris: I would say my career at AWS has been a bit different than what I would say the standard is, but I don't know if there's a standard at this point for AWS. I came in pretty early when the field was very small and new, back when we used to meet with customers and the receptionist at an enterprise would be like, "There's folks here from Amazon and I don't know what the bookstore people are doing here," type of comments.

Chris: And then I've managed to find myself in three completely unique first time roles. So, before my time in the serverless space, I was the first ever Global Business Development Manager for the DevOps products at AWS. So all the development and management tools, and then through conversations with, Aja [inaudible 00:05:03] and Tim Wagner ended up in Lambda and those conversations were happening just about like five years ago now. And it took a couple months to get through process and join that org.

Chris: Pre-Amazon my career was in startups so I started as the very sexy title, these day of systems administrator which I don't think anyone admits that they are systems administrator these days, but that's where I started my career, working for startups like Etsy and Meetup, and a couple other smaller ones.

Chris: So to a small degree between the fact that when I first started at AWS, I did a lot of work with startups and then both my time in the middle between roles when I left for a little while, and then all my career before Amazon was at startups, two degree, this is something that I've really enjoyed doing is working really closely with small companies, out there exploring new problems, exploring new challenges.

Chris: So my current role is going to be a mix of one, really helping to support the inside part of this business, so helping our startup solution architects, which are a brilliant awesome group of people. Get even better at what they do and overcome challenges both organizationally. And Amazon's a big company these days, a lot bigger than it was back in 2011.

Chris: And I would say also our customers have a lot more demands on us than they used to. Again, now that we don't have to say that we're not the bookstore, now we have to say that we're the provider of 200 plus services across 20 plus different categories and all of the uniqueness or the challenges that come with that.

Chris: I would say the advisor side of my role is helping internally the business get better at how we work with our startup customers. The tech lead part, I think, is acknowledging something which I actually saw a lot of in my former role, which is that even though a lot of these new technology paradigms are out there, containers, serverless, all sorts of other advanced concepts.

Chris: I would say that a lot of startups are still building the way that they did eight, nine years ago and a lot of that lends itself to one, some of those things are still newer in the industry. I think two, from an educational standpoint, if you think of the cliche, startup founded in a dorm room type of a thing, there aren't a lot of college CS professors that are teaching serverless or containers or a lot of the modern architectures that are out there and academia lags a bit behind industry in that sense.

Chris: Another thing that I'm going to be focusing on is really how we message two startups. Like this is how you should be building, very much in a forthright out in their face way of saying, as you're getting started, you should start here, versus, know where you might think that you should start based on other background paradigms and so forth.

Chris: So within that, it's a lot of range. I'm excited to, again, get to do something new and different inside of AWS. And my manager and I keep talking about, we really don't know what like the next 60 to 90 days will bring, but then it's that 90 to 180 that I guess I really have to figure out why they keep paying me here.

Rebecca: I think, to say forthright indirect is something that is immediately indicative of the man's brand, if I can say that. I think that same Jersey candor that you grew up with that you bring to everything including to education. And so I want to touch on that because you're thinking about education and how to shift that paradigm into a tech lead type startup space/advisor, all the slashes that we can think of, but I would be [inaudible 00:08:54] to especially at Serverless Chats, right?

Chris: Mm-hmm (affirmative).

Rebecca: To not mention the outpouring of love and admiration for the work that you did specifically in the serverless space when you mentioned that you're not moving out of the community, but you're moving on to a different role, right?

Chris: Mm-hmm (affirmative).

Rebecca: And I think it's because of your extremely direct and candid approach to education, to developer advocacy, to really saying my favorite way that you described it once when we had an event is you said, "This is the paradigm we should be building with, fight me on this."

Rebecca: And so, you positioned these things in a really, really intense statement in such a way to engender those conversations around best practices, what is the best way to do something? And so that's a really long lead and say, I'm wondering if you can talk a bit about the very beginning when you discovered Lambda, right? Or when you moved to that team and then what it was like putting together advocacy team to give that candid forthright education?

Chris: First I'll have to say I was really very much humbled by the responses that I got from folks in social media and outreach that I got in the public sense and DMs and emails and things, both in my announcement that I was leaving the serverless org and then the announcement that I was wanting the startup org.

Chris: And it was interesting to see people obviously in the startup side being like, "Oh, we're so sorry you're leaving." And then the folks in the sorry, the service org saying that, but then the folks in the startup work being like, "Oh my God. Yes, that's awesome." That to me was really special and I really appreciated that. And it felt good that people said things like, "Hey, you've had an impact on my career."

Chris: And to me in my time at AWS, one of the biggest things for me is that concept that I've had the ability to impact people. Maybe going all the way back to college I was, like IT lab manager person and then I also help professors with courses and with teaching like a TA, I guess, and, knowing that you help someone better themselves, I think is one of the most noble things that we can do as humans is that aspect of helping people.

Chris: So that's one thing that drives me a lot, it's one thing in this role that I'll get to do out of mentorship, not as a people manager, but as an experienced individual inside of the business so that's that side of things. For me and I would say again, going back to the early days of AWS, I realized pretty early on that the one on one customer engagement model was not how the business was seeing success, right? It was that content, it was one to many, it was technical outreach in that sense. And I was really inspired by a lot of the, I would say early technical blogs that were out there.

Chris: I used to work at, meetup.com, many moons ago now and I remember being really influenced back in the day by the tech blogs from companies like Flickr, pre Yahoo acquisition, pre a whole of the world of tech ecosystem. There were companies out there talking in depth about this is what we're building and why we're building it and how we're building it.

Chris: And I had then the honor to work actually alongside some of those people while at Etsy. And then Etsy had a really great technical blog that again also went in depth and there was a lot of conference speaking, things that other people did that I watched [inaudible 00:12:34]. Once upon a time, I actually used to attend conferences to learn not to have to speak and travel at them and represent AWS.

Chris: So I think, seeing that and realizing the value of it and then realizing once I got to AWS that, oh, wow, we could and should be doing a lot more of this in a technical bar that's high that gets people excited and adopting things. And so, early on, I started doing a lot of public speaking for AWS. I had a presentation that did call scaling on AWS for your first 10 million users that I first did at a VC event in 2013. And, it became, the Chris Munns show that your former friends, Rebecca in marketing used to fly me all over and have me speak to startups and enterprises and other stuff, this talk.

Chris: And it was a very straightforward story. Day one, you have one instance, how do you go from that forward and on? So that was my lending to the educational space and into content creation and delivery and seeing the impact of that. For me my experience with serverless actually starts pre-launch of Lambda when I was at AWS, so I was one of the people who got read in on the product.

Chris: And I don't remember if it was by Tim or Jay back then, I think Tim was on the call. And the original history and lineage of Lambda was it grew out of the S3 organization to help customers that had interesting S3 challenges and bring the compute to the storage in that sense. And I happened to have a couple of customers that were startups that were doing wild, crazy scale things with S3.

Chris: I remember learning about it being like, "Okay, this is pretty neat. This is pretty cool." And then it launched and the responses to it were interesting. I think a lot of people were still trying to figure it out. Fast forward, a bit later I left Amazon in December of that year rejoined in June of 2015, and I was at actually, I think it was my first week back at the job, I was at the New York City Summit when Werner announced API gateway.

Chris: And for me, I had a decent amount of knowledge of how internally we built products and APIs inside of Amazon and am familiar with some of the lineage that led to API gateway. And when I saw API gateway in Lambda, that for me was probably one of the biggest changes in how I thought about this technology space, because it became like, oh my God, people are building APIs like crazy right now. And it lends itself to the mobile and device space and microservices and all these things that we see.

Chris: And the fact that you could get the benefits of serverless of the high availability, the scale, the pay for what you use, all of those good things, the lack of servers as it were, right? Which to me, as a person that used to call himself a systems administrator, getting rid of those systems, sounds incredibly appealing.

Chris: So that was probably for me the really big aha moment where I thought I'm probably going to end up spending a lot of my day to day talking about this space and then I did and then it grew, and then it took forward from there. So that was the big aha thing, seeing customers doing interesting things with S3 and some of the other early event source models that were there, like Kinesis was really cool. And then, similarly, step functions, I'm a huge step functions fan. Really excited by yesterday's launch of the direct integration with APIs-

Rebecca: Heck yeah.

Chris: ... that's really cool stuff. And then, I was also in the org when we started talking about the plans for event bridge and what event bridge would be. And that to me helps fill in another major piece of the puzzle. And so I think those two they're in the general event-driven model, which it took me a little while to rock all the pictures of all of that. That to me is still the future of application development.

Jeremy: It's funny that you mentioned rocking the event-driven aspect of these things because you also mentioned earlier these engineering blogs, which were not very common, right?

Chris: Mm-hmm (affirmative).

Jeremy: You could find them, but I remember when I first started building in the cloud, 2009, 2010 or so, it was like trying to find out how to do things when you were limited mostly to the documentation. And somebody would be like, "Oh, I did this thing and you could get a little bit of information from it." But the how was important, like how do you actually do these things?

Jeremy: But I think the why, was also really important. And like you said, this understanding of event-driven architecture, and again, Lambda honestly, was a very cool product, but then as soon as you could hook up an API to it, suddenly it became a whole new thing, event bridge, step functions, all these other things changed this paradigm.

Jeremy: I'm just curious, we started seeing content early, I mean, like serverless framework and these other and other people using it started putting out content early on in terms of the hows and the whys of these things. But I'm just curious, what your experience was and what was the drive internally to get people to normalize not only this way of thinking, but also this idea of just being really public about how you build these different types of applications.

Chris: Wow. I'm just trying to think of all the different things to unpack there.

Jeremy: Sorry. We ask really hard hitting questions on Serverless Chat.

Chris: Yeah. I think when we look at so S3, you look at the lineage of S3, it grew out of a need that amazon dot-com had for what they realized was object storage, not file volumes and NFS and all this stuff. So S3, comes out of the dot-com need grows internally, becomes something that gets used in ways that I think today if people even understood what the rest of Amazon does with products like S3, they'd be like, "Wow, that's actually really interesting that it's used that way." And maybe I should say abused in certain ways as well.

Chris: So we look at things like of Lambda, we see obviously the external customer need. I think we also see some of the internal need that was there. And even after Lambda launched, the interest internally at Amazon was really strong. I mean, Werner always talks about Lambda being this, the compression algorithm for experience type of a product.

Chris: And in my mind represents foundationally how Amazon thinks about how it wants to build and manage stuff. You're going back to reinvent last year, back when Andy was just the lowly CEO of AWS, not now that the head cheese as it were. The date of point that we were really excited to share around the percent of compute workloads from Amazon that were Lambda driven, which ended up being like just shy of 50%.

Chris: And we didn't put up what the other 50% was, but it was a mix of containers in EC2 and the different offerings inside of those. Lambda was overwhelmingly the majority of that. That to me is fascinating, right? Amazon is tens of thousands of developers, the old Death Star diagram of all the different services and points that we would have is just so massive these days.

Chris: And the fact that so many teams are saying, "Lambda's the way that we're going to solve our compute need," I think to me is still one of the largest testaments to just what the opportunity is there. Now, what are some of the differences between what Amazon can do or other people do? Well, we have dedicated teams that made it really easy to build and deploy those things. We have people internally sharing patterns and best practices as quickly as they're being defined. And an internal trust model where people just eat that stuff up.

Chris: So I think, if I'm trying to stay on topic here with what some of the question is, I think that's where we see at least the excitement in the space continuing to grow. Now, the event-driven model, I think aligns itself as well internally in the business. If you look at, for example, Werner's blog, back when we, maybe it was last year, there was a Werner blog about why DynamoDB existed and how we looked at all of these workflows that we had and we said, "These aren't relational database needs, these are key value store needs."

Chris: And really when you think about key value store needs, you do end up being able to align yourself back to this event-driven concept, which then of course, lines itself to the functions as a service compute model really well, which leads to Lambda. And so, as we started identifying that, and then, technically the first services at AWS besides S3, SNS and SQS, those are also effectively event-driven services.

Chris: All the way back, almost 20 years ago we're effectively seeing this without realizing that, that's what was happening. And I think that, that's lend itself to, well, early on SNS and then, maybe one of the biggest misses we had going back to 2014 was not having SQS as a native integration for Lambda. I think how we launched it on stage with that people probably would've ... it would've been like, "Oh my God, that makes the most sense in the world. This completely aligns so directly." So I think-

Jeremy: That's four more years before that, it was 2018 I think that that was integrated, right?

Chris: Yeah, it did. It took a couple more years. Various reasons for that, obviously but it is today an incredibly popular invo source for Lambda functions-

Jeremy: And just recently now you can invoke Lambda functions from an SQS in another account-

Chris: Yes. I saw-

Jeremy: ... which is exciting for me.

Chris: .... your thread on that, I applaud it, that there's a lot of good logic there. And I think we're at the point now where you can invoke a Lambda function from all of the main messaging services at AWS. You can do a lot of this stuff cross account which lends itself to the best practices that we have inside of the cloud. And again, you're doing this in a very simplified way without managing polars and managing all these other things across account, which would be a lot more complex.

Rebecca: So it sounds like you're talking about learning curves both internally and externally, right? Things that we noticed over time and as a short aside, when we launched SQS as a native integration into Lambda, I was the head PMM on that, and I was so elated to see how elated it made people. And I was still just getting into the serverless space. I've been around, I mean, six months I guess it's like 11 years in Amazon time or something but I-

Chris: My hair was jet black jet black.

Rebecca: Jet black, yeah.

Chris: Jet black in 2018. No, just kidding.

Rebecca: So I want to talk a little bit more though about those curves, like a learning curve, and then there's an adoption curve, right? And so I'm wondering what you've seen regarding customers at different stages. And then now, when you look at that adoption curve, specifically in your role for startups, how do you see serverless mixing into workloads? Obviously, Amazon is a huge customer and so do we take specific things and learnings from Amazon as a giant customer?

Rebecca: Do they live in their own realm because they're their own beast? And then there are other customers that have very direct and adoption models and curves that you see and how you approach them based on where they are in their company journey.

Chris: I think there's a lot to Lambda that mirrors the overall general experience that I think we've seen with AWS as a whole. And the companies that are most successful with AWS as a whole, are those that really look to adopt the fullness of what the platform has to offer. And there's someone out there who's going to say like, well, of course the guy who sells the cloud is going to say, "You should buy more of the cloud to be happy with it."

Rebecca: I was almost going to say that.

Chris: But it's the reality, right? We build these various Lego pieces as I'm sitting here fumbling with a Lego in my hand, we build these various Lego pieces with specific nubs on them to plug into the other components. And as you combine them, you get great power that comes out the other side of it.

Chris: There's a couple different challenges that I think within the serverless space that lend itself to being maybe more complicated than some other parts of the cloud that we have at AWS today is that you often do have more components or different components and the way that you plug those components together is a bit different than how people would've done it in other places.

Chris: Again, I think you look at the going back to the academic model of things, a college professor is going to start explaining things at the level of the TCP stack and CPU processors and important sockets and things like that because that's a core foundational concept and it makes sense that you teach people that to get to the point where you would advance up to an invo source and a compute behind an API paradigm.

Chris: And a function as a service is really elevating far, far, far beyond, that initial core concept of binary and machine languages and other stuff that you see in that sense. And so a big part of, I think the challenge for the serverless space is still getting people up over that hump effectively getting them to mind shift and understand what is different versus what also is the same.

Chris: And there is still a lot that's the same. So, realistically, a lot of the code that you write in a Lambda function or really any fast offering today, functions a service offering is the same code you would run somewhere else. You're talking to databases, you're talking to other API endpoint, you're potentially talking to other managed services, how that code runs, where it runs from becomes the biggest thing that changes.

Chris: So I still think our biggest challenges today are educational, just flat out. It's getting people to understand that little bit of difference that. You don't have important socket, you have an event source and it's going to send some event structure down to you and then you're going to have to work within that.

Chris: And again, I think the company isn't ... I remain unbelievably blown away by the work that for example, Lego has done. Sitting here talking about Lego team and some of the other Austin people there at Lego and their great heavy adoption of serverless product portfolio really shows that they're saying, "Yeah, if we push ourselves to understand the various ways that this works and the various ways that these two nubs plugged together in certain forms and fashions, we're seeing dramatic benefits."

Chris: I mean, I remember at serverless days London, 2019, I spoke actually right after Sheen, and I announced event bridge on stage there. But before that, Sheen was talking about some of their early explorations and iterations into serverless and how they were doing big things with very small teams inside of a big company that was used to doing things with much bigger teams.

Chris: And they had to do some due diligence, they had to do some homework, they had to explore a bit, but now you come out two years later and they are effectively what we call a serverless first organization. They're going to explore serverless technologies as the number one offering or the default offering and then they will back onto other more traditional computer offerings if they absolutely need to.

Chris: So I think, again, that's a great poster child example of, we put in the effort to understand that we had to use these other bits of the cloud to get this benefit. But then the long term outcome that we're seeing is, I'm sure reflective in the bottom line of the business somewhere.

Rebecca: For those who don't know, and Chris Munns is calling out Sheen Brisals who as an AWS hero has worked at Lego for a super long time, really push the envelope on it and you can follow him and learn a ton on Twitter @sheenbrisals as S-H-E-E-N B-R-I-S-A-L-S. And he does create really, really excellent, helpful content and so I just want to put that out there since Chris has been talking about him.

Jeremy: And Nicole Yip internally, is running the team that standardizes all of the serverless practices. So, amazing things there. So I'm going to continue to extend this Lego, I don't know analogy as far as we can take it. But one of the things that you mentioned in there was, different ways to connect things different nubs on the Lego that connect in.

Jeremy: And I was looking at it as like, when it first started a service comes out and it's like a Lego, just a single Lego block that you use, like for a castle turt or something, you get one nub on there, right? And that nub is maybe I connect through the SDK. And then all of a sudden you add another nub and you're like, "Oh, I can also plug this into Lambda," but then we start adding more and more nubs because other things can fit in different ways. And if you think about Lambda, the initial paradigm was I can make an API gateway request, API gateway integrates with Lambda, Lambda then calls the SDK and write something to DynamoDB or pull something from DynamoDB.

Jeremy: And that was a very standard practice. It was that you have a service Lambda is the glue another service on the other side of it. Then suddenly you come up with service integration, it's like, "Well, I can have an API gateway call DynamoDB directly and I can have API gateway write something to SQS directly or read something." And then you start building those integrations, then event bridge gets involved. Now you've got transformations that you can do, and you can actually make changes to data and shift things around.

Jeremy: You've got step functions that can do that and now with the new release of step functions, there's just so much Lambda function code that you can cut out completely. I would love to just go back for a second and maybe if you could give us some insight, I don't know, who's thinking this was, but it is really interesting and Gene Brisals mentions functionless all the time.

Jeremy: This idea of going from using Lambda as a glue, to getting more and more configurations into the service connections themselves, and then even eliminating some of this custom code that we have to write and using these service connections to do that. What was I guess the evolution of that and how we did it have to be evolutionary because the services weren't there yet but I don't know, just maybe expand on that a little bit because I find that fascinating where this is heading.

Chris: I think this is literally a straight line from the start, right? This is that we internally at Amazon are going to build services to enable our developers and operations people to not have to build and run stuff themselves. So you all the way back to S3 and EC2 in some of these earlier things of remove burden, remove burden, remove operational toil or remove low hanging work.

Chris: And then that extends itself up through, hey, people want an easier way to get compute to S3 data or process Kinesis streams. And then you move up through, hey, people want an easier way to build APIs and process the backend on that. And then, where you keep getting to is this point of people are like, "Well, I just want to call an API. I just want to call an AWS API. And I want to take that code and I want to say, if it passed through this, if it failed, do this other thing."

Chris: And really this is just that continued evolution of us saying, how can we simplify this? How can we make this better for certain workloads in certain places? I think really that's at the end of the day, the core of it is we're looking every day at, what are people doing with the service and is that really viable to their business? And in that sense, I think the continued integration points and plugins where you can remove a lot of that code because you can say, "This fits the majority of what people are doing with the data from this thing."

Chris: Are people going to completely take complex processing of events from or query response from certain APIs and completely disentangled it into a step functions when it could be maybe just like 20 lines of Lambda that some rejects in the middle of it? Probably not. But there's a lot of places where I think it does make sense and it can be really helpful.

Chris: And again, to my previous point again, it's one of these where if you're willing to take in that, the collective benefit of the services being put together, your direct outcome of that collective benefit should be that agility faster time to insanely reduced operational burden. I used to give a under NDA talk to customers in executive briefings and it was effectively called the culture of development at Amazon. And I would talk about the whole two pizza team paradigm where you are both the developer and operator of your service. And you can just think of a very basic scale where, the more operational burden you have, the less time you're spending on development, the less time you're spending delighting your customers and your leadership and all that good stuff.

Chris: But as you find ways to continue to reduce operational burden, right? More managed services, even less code you have to maintain and write, then you're immediately getting spent so much more of that time on the product side, on delighting your customers, on delighting your leadership and all of that, that it just becomes a no brainer.

Chris: Now, I mean, I think, again, this lends itself back to the Lambda adoption. I would love for us to see a couple of years down the line, we say, "Wow, you know what..." You could even say like 50% of compute workloads are step functions. There would have to be some other adoption metric that we can say of, allow internally at Amazon the adoption of the step functions API capability represents X amount of workloads. I think we'll get there because I think this is one of those things that benefits folks like that as well.

Jeremy: And I do wonder if that's also, it's like adds to the burden, know that, that mind shift burden where you start trying to drive people towards event-driven stuff, and then you start telling them, "Oh, by the way, as those events are passing through the system, you can actually manipulate them. You can do things like that." It's just another thing that I think makes the adoption a little bit harder, but I think you're right. If you're willing to go down that rabbit hole and start looking at what the system can do, they say not to drink the Kool-Aid, but the Kool-Aid tastes pretty good in this situation.

Chris: And again, I think there are a lot of customers' success stories in companies that are really technology forward and aggressive, the capital ones of the world, again, companies like Lego, a number of others where it's clear that the teams and the folks involved have put in the time to say, "We're going to learn this different model because we're obviously seeing the benefits of it," and then continuing to expand upon that. So I think with that announcement yesterday, that's going to be a really interesting one to see roll into more and more customer workloads here in the near future.

Jeremy: And I think it'll be great when we live in a world where we never put any of Eric Johnson's code into production.

Chris: Going back to the whole compute list paradigm actually, Eric wrote some really great content on this back in 2019 in API gateway direct to other backends and completely removing the Lambda layer. And so I think, some of this stuff isn't as new as it might seem, it's just not as widespread as our thought leaders like Eric Johnson are in the space.

Rebecca: I want to pull this thread a little bit more then in terms of how this starting point, right? And then as a tech lead, I'm going to try to get this right tech lead/adviser to serverless no, no startups solutions architects. I'm imagining that even though it feels like even in 2019, right? There's been great content around this and there's been content around and we feel like this should probably be a pervasive in the vernacular, but yet it isn't quite yet or maybe in some moments it's not.

Rebecca: So I'm wondering if you're seeing now as an advisor to these startups, what is the persistent question that they keep asking, like the hurdle that they need to get over or is there some pattern of a blocker where they're like, "Could we really adopt this? Do we really want to reach out and play with these Legos?" And if there's something like one core aspect where you're like, "Let's get past this, let's resolve it and then we can move forward."

Chris: I think it comes back to a large degree to education. So not just education extra of the education internally and that's where the advisor part of my role comes in, is helping to make sure, for example, like the startup field has a good grasp on what is the tip of the spear that we should be telling our customers? How should we be proactively guiding them towards these patterns that actually will align really well with what they're trying to accomplish.

Chris: And that once achieved will provide the benefits to a startup that they want to see. Startups struggle with two main things, time and money. You burn through one and you burn through the other. So how do we get them to be better about that? And I think, again, that's the true outcome that we see in these things is, the two pizza team model is a mini startup model inside of Amazon and it's the same thing, right? It's time and money.

Chris: So I think, part of it is that, that education internally and externally, part of it is obviously I think the noise of the industry, there's a lot that's going on in a lot of different places, there's a lot of exciting things in different places and making sure that we get this information in front of the "right crowds" is another challenge that's mine and it's marketing's and the product and all of that stuff.

Chris: In where and how maybe adoption isn't externally the same way as it is internally, again, I think it's a combination of all of these things. It's people who have been doing development for years that are comfortable with what they're doing and they maybe don't see the need to change a push for those benefits because that comfort is there.

Chris: There are people that have various decisions around tech stacks that they like, for various both personal reasons and other reasons that exist out there and I think that's something that's there too. I think in talking about how Amazon so heavily has dog food in Lambda, and this event-driven concept and functions as a service, that's not the same for our competitors yet. And they have their own paradigms and models and things that they champion and a lot of them don't have a technology capability like Lambda. I mean, at the end of the day-

Jeremy: Are you saying google doesn't run on Google cloud? That just sounds crazy, Chris.

Chris: I won't make any statements about-

Rebecca: No comment.

Chris: [crosstalk 00:40:37], I will focus on the needs of my customer. But I think that lends itself to part of it and that was part of the challenge and the developer advocacy team and role, and for our friends in product marketing, other parts of the business and the field teams and everything else is get everyone to understand just the sheer value that comes out of this.

Chris: AWS when it launched, launched without competition. So we could go out in a vacuum and talk about the awesomeness of AWS and you either could see it, or you couldn't, but there wasn't another option besides what you already were doing, right? The large companies that I worked with back in 2012, who were the, "Why is the bookstore people here?" Kind of folks, they had data centers and they had operations teams and they had all of this stuff they'd been doing for a long time.

Chris: And it was the startup space that I think really blew up the initial early parts of AWS and helped make AWS into what it is today. So, cloud is the default for startups, that's pretty much solved and done. Obviously, I think in the enterprise space, we always say we're in the early days of a really long journey, but we already see so many huge enterprises that are moving whole heart into the cloud.

Chris: They're moving into the cloud with existing stuff and new stuff and everything else and so the difference between greenfield and existing stacks and migrations and all this other stuff, it's all just part of the big part of the picture. But I want to get the industry to a point where when you're building a new compute workload, even in my space here in the startup work, you're evaluating serverless is to start up that stack. And I think that, that's still to me, one of the key things that I see is possible, especially as we see the capabilities of these products grow.

Chris: Again yeah, maybe next year that my old team, they're also folks that are on that team will be spending most of the time talking about step functions API integrations. That would be great. There would not be a downside to that, but, there will be some people who are like, "Hey, I'm still just trying to migrate this sequel server over from my data center that's under Bob's desk in the office." Again, it's a lot of a lot, the complexity is a shift, the education is multifaceted and now we're not doing this all in a vacuum, so there are other players and competitors and other technologies that are vying for people's attention.

Rebecca: I want to ask you a little bit more about the education piece or especially the developer advocacy piece. Especially because one, you grew a team and I think that there's seven developer avocados at some point and they're so invaluable in terms of getting education out there. I mean, they were doing Twitch streams, they were giving conferences, they were doing meetups, they were writing blog posts.

Rebecca: And when I talked to other customers now, especially in the developer relations space, right? People are like, "I can not hire enough developer advocates." Like there are not enough advocates in the world. I don't want to say it's an emerging space, but in a way it's a space where people are only now or in the last five years, I think really saying, "We value education and this is a way to help evangelize our products." So people actually know how to use and adopt them.

Rebecca: As a hiring manager who built a super excellent team, I'm wondering what you would look for when looking for a developer advocates, what types of content was super strong and what you saw resonate most? What could you perhaps ... Maybe someone is like, "Okay, I'm a programmer today, but I'm actually more interested in getting into the educational side of things." What should they know? What does that feel like when you're looking at that field and you're a hiring manager looking [crosstalk 00:44:38] advocates.

Chris: I don't know if I ever said this to you previously, but I've joked with peers over the years that am I or was I ever a developer advocate with not yet writing my own OPUS on what the role means and what the job is. And it seems like there are a lot of my peers in roles like that across industry that are like life of a developer advocate and how we think about it. And so, yeah I did it for four and a half years and one of the biggest beasts and helped define the role and then higher, then grow the team and I'm excited to say that I think the team will grow again next year beyond where I got it to.

Chris: And then I was a big part of helping other teams expand the developer advocacy. So I've probably done well over a hundred in person interviews, probably read a couple of 100 resumes and helped something like a dozen plus different product teams decide to invest in the same area. Why? I think for one, in again, going back to one of what we were talking about earlier, this self-help aspect of the cloud, the fact that a majority of people who use it end up using it without talking to anyone.

Chris: It's key for businesses in that sense where, you have a SAS offering where you again have that model where sales is not gatekeeping the sales of your product, then content is king and having a team or individuals that could produce that content in the tone and voice that your customers are looking for is critical to the business. Is critical as the product itself.

Chris: I have a number of strong opinions about developer advocacy, candidates and hires. For one, for me, it is not a role for someone who is necessarily super young or new to the industry. I think it does require a trust that can be earned and a credibility and an experience in some part of the industry that lends itself to, I can get on a stage and talk about previous experiences and how maybe they align.

Chris: I think it requires an incredible attention to detail in content creation and an ability to really empathize with where the customers are. As you might remember, so I still own the AWS compute blog, I will continue to brag publicly until it isn't that it is the number one topic blog at AWS. It gets a lot of eyeballs on it every month.

Chris: We had a very high bar for what content could be published on that blog. And I'm happy now that I have James Vesica on the team, who maliciously, maliciously reviews that content and keeps it at such a high bar, that people strongly dislike him for it. But I love him like a brother for the fact that he does that.

Chris: And I think that's really key. I think that's really key. When you read a crappy technical tutorial, that impacts your ability to do things. When something is surface level and either doesn't maybe link to other resources or go deeper on a topic that's going to effectively block a sale or blocking adoption. So I would really look at, okay, well, what's the content you've delivered? What is the value to that? I believe that there has to be a strategy for that and so far as how people write stuff.

Chris: So I would see people say, "Hey, I just like writing technical blogs." Why? What motivated you? How did you make sure that that was the right content for readers? What feedback have you taken or not that might adjust you in writing that or changing that in one way or different?

Chris: I'm not necessarily a super passionate about one mechanism over another, there's a bunch of data that's out there that talks about, people like blogs, they like technical tutorials, they like new videos and podcasts and stuff like that. If you have a Twitch show or a podcast, are you bringing people back to code, to samples, to examples and things like that? I think that's key versus just talking. And so I think that's the stuff that separates the better developer advocates in the industry versus not.

Chris: I think there's also the awareness that at the end of the day, developer advocacy is a role that crosses various chasms. It is a marketing role. It is also a sales role. It is also a development role. It is also a customer support role. It is all of those things. I personally was not a fan of candidates who were looking for, I out of college spend a little bit of time at a hedge fund, pre 2008, which I'll say were the key models and bottles years of that industry in New York City.

Chris: Develop advocacy, I think is most poorly done by the folks who are like, "I want to be on a plane 24/7. I just want to fly around and shake hands and talk on stages," and things like that. I think that when you do that, you lose the ability to spend the time and focus necessary to really understand your product and its problems and your customers. And then create that valuable content that's going to lead them to being successful.

Jeremy: And definitely plus one for the content that James and Eric and Julian and the whole team are doing. It's top notch content. I mean, it's wonderful to read because it's tech technically accurate, it's always really engaging and there's always really, really good diving in just to the right level I think for a lot of what they do.

Jeremy: I do have a bit of advice for developer advocates. If you call yourself a developer avocado, you can charge a dollar extra. Sorry, I was just in this dad joke mode from the Jonas Brothers earlier today. But anyways, I guess one last question, because we're running out of time, but I want to get just go back to the startup thing for a second. You mentioned time and money, of course, time and money are always the constraints that a lot of these people have.

Jeremy: And I think that a lot of startups don't necessarily recognize, especially highly technical startups don't recognize that when you add those two things together, really we're talking about TCO, right? We're talking about total cost of ownership. And just I'd love it if you could just give ... What would your pitch be to a startup right now? If a startup came to you and said, "Why should I build with serverless?" What would that pitch be?

Chris: Well, it's what you just said, right? It's this understanding that, hey, you're looking to find a market fit and adoption and awareness, that involves you investing in your product and investing in sometimes the money to get the voice of your product out there and marketing and things like that. What you don't want to be doing is spending time on technology toil. In my mind, running instances, running container orchestration, running bespoke open source software, just because it's open and free, does not mean that the energy involved in running that is open and free.

Chris: And so anything that you can do to shove responsibility onto something that you don't have to manage is going to give you back that time and money to focus on those things that are critical and key to you. And so from a startup perspective, to me, any of the stuff that could be solved by a managed service or a SAS offering, I'm running to at full speed. And again, making sure that I am aware of the other side of that.

Chris: And so, people talk about the comparisons between say Lambda and EC2. Obviously those are a apples to onions comparison in terms of what's really there from a product perspective, but I think it's important to understand that your people time in all of the work that goes involved in managing some of these things, I've lived it and I wish that I could have been more useful to the businesses that I worked for by not having to spend time managing those things.

Chris: So I think it's very much a one plus one equals two, you're taking time away from doing toil, you're freed up to spend time on your business, on average that should lend itself out to a more successful outcome.

Jeremy: And I-

Rebecca: Can I add to that?

Jeremy: Oh, I was just going to say, I've worked for so many startups and wasted so many hours. I totally agree with you, just so many hours wasted.

Rebecca: I was going to say, I think there's or what I've heard right? For, in terms of like hands-on builders and practitioners is, it's not just the time, the exact time spend, but also the quality of life they feel from what they work on. So is this quality happiness or empowerment component that I think even goes beyond just time and toil, but also personal, aggravation that builds over time, which is a whole other dimension to consider.

Chris: Absolutely. I mean, I have stories of pre-Amazon days of ruined holidays, of ruined dates, of all sorts of things where, oh, oh, something happened in the data center and I had to get to that data center, or I had to get on a laptop and do a thing that, hey, if I had auto-scaling or obviously if I had things like Lambda, I would have never had to worry about a web server, oh, oh three going, boom, it wouldn't have been a problem.

Chris: And so again, I think there's just a lot, yes, to that overall condition of life and satisfaction and happiness that comes from spending your time and money on the things that are more valuable to you.

Jeremy: So serverless adds to your quality of life. I think we can end it on that.

Chris: [crosstalk 00:54:13].

Jeremy: Well, Chris, thank you so much. I know that you're busy, you've got a lot of tech leading and advising to do, but if people want to follow you on social media or find out more about what you're doing, maybe go to the compute blog, how do they do that?

Chris: I mean, for me right now, @chrismunns on Twitter is probably your best bet. I would encourage people who are interested in serverless, also check out serverlessland.com, which is a site that my team launched last year which has a ton of content on it. And then again, for me as an individual, Chris Munns on LinkedIn or on Twitter is the best way to reach out.

Jeremy: Awesome. All right. Well, we'll get that in the show notes we'll also put a link to the compute blog because again, amazing content there. Thanks again, Chris.

Rebecca: Thanks so much Chris.

Chris: Thanks for having me. It's great to talk to you about.

Rebecca: Good to see you.