Episode #137: The Best of Serverless Chats (Part 1)

May 16, 2022 • 54 minutes

In this two part episode, Jeremy and Rebecca discuss some of their favorite moments from the last 30 episodes cohosting the show together.

Episodes mentioned:

• Episode #132: The Evolution of Serverless at AWS with Dr. Werner Vogels
• Episode #112: Abstracting Stateful Serverless with Jonas Bonér
• Episode #110: Mapping the Inevitability of Serverless with Simon Wardley
• Episode #128: Serverless-First Engineers and the Flywheel Effect with David Anderson
• Episode #129: What To Do When the Servers Go Away with Tom McLaughlin
• Episode #135: Serverless for Frontend Engineers with Swizec Teller
• Episode #131: Security in the Cloud with Merritt Baer and Megan O'Neil

Transcript

Jeremy: Hi everyone! I'm Jeremy Daly.

Rebecca: And I'm Rebecca Marshburn.

Jeremy: And this is Serverless Chats. Hey, Rebecca! How're you doing?

Rebecca: Jeremy, I'm doing really well. And you know, it's been- there's been some ups and downs. And I'm just really excited for this episode today. Like, should I say what it is? No, let's banter first. Do you wanna banter?

No, I think we have to keep people on the edge of their seat. So well, so these ups and downs. I mean, so the listeners should know we took a couple of weeks off from recording. We've recorded a whole bunch of episodes. We've got a bunch of really great episodes coming up as well. But we kind of, you know, I went on vacation. I think you had some interesting stuff happen to you. So I mean maybe let's start there. What is the most interesting thing that happened to you in the last couple of weeks?

Yeah. So I think there are two things. One, my car was stolen.

Jeremy: Well, that's not good.

Rebecca: It still has not been returned. But so like, you know, I guess I wouldn't even say it was stressful. There's like nothing I could do to control it other than, you know, file the police report and exactly what one might do. But there was a levatus moment where the police were like, 'Hey we'll probably get your car back. When people steal a car in Seattle, it's usually just so they can do crimes.' And I was like, 'Oh no! You think she's out doing crimes?' And they were like, 'oh yeah yeah. She's doing crimes.' And just the phrase 'doing crimes' and like, imagining my car turning to this other side just on a hard knock life, doing crimes.

I mean, that's the thing. You love them, you know, you try to keep them safe and then they just they grow up and they go out and they start doing crimes. It's crazy.

Doing crimes. So, that was, you know, an unexpected maybe 'low light', if you will. And I appreciated this car very much. Highlight is that Common Room, where I'm the head of community, won startup of the year last night at the Geek Wire Awards.

Jeremy: That's amazing. Congratulations.

Rebecca: And I really will say we were not expecting it. It is a really big honor. And it was really, it was a big highlight. So anyway enough about me. You went to Hawaii and you met a celebrity.

Jeremy: We did, yeah. I took my family to Hawaii. We've been planning this trip for 25 years, I think. I can't remember It's been a while that we've been wanting to go. So we finally got out there and it was my daughter's 16th birthday and we were on Oahu. And we were at, I forget the name of it now, but some blow hole thing where like, you know, the water comes up and splashes and there's this little

Rebecca: Blowhole?

Jeremy: Yeah, that's what they call it. A blow hole. At some whatever it is. But there's this little secret cove, which isn't very secret because you can see it from the road, but they call it a secret cove. You can go down there and you can swim and there's a couple of rocks you can jump off of and whatever So we go down.

And we're walking around and we see this giant man, I mean giant, just start like, you know, come out of the water and he puts Crocs on, you know, that are about the size of a canoe- giant, whatever. And my oldest daughter says, 'I think that's Rob Gronkowski.' And I'm thinking 'That is Rob Gronkowski.' So me, I just like run over to him. I was cool about it though. Like, I fist bumped him and I was like, 'Hey Gronk! What's going on?' And, you know, I tell him I'm from Boston and whatever. So we had a good conversation and then the funny thing was is that I took a selfie with him. And then I said, 'Well let's get a picture with the family. And his fiance who I still, I totally forgot her name, but she's a swimsuit model or a supermodel or whatever she is. I just casually asked her I said, 'Hey can you take a picture of my family with Rob Gronkowski?' And she did. So she was probably quite offended by that at the end. But, I mean, here's Rob Gronkowski six feet seven inches tall or something like that. I'm six feet and this guy's towering over me. So yeah, we just ignored her and just got this great photo with Rob Gronkowski.

Rebecca: Well I was really delighted to receive that photo when we had talked about how your travels were going. And honestly, if there's anything I believe or maybe believe the least it's that you were super cool about it. 'Don't worry I was super cool about it.' I'm like, 'I don't know if either of us are super cool about anything.' But we try our best.

Jeremy: What would have been great is if he was like, "Hey aren't you that serverless guy?" I mean that would have been cool. I mean, if there was like a mutual celebrity respect thing. I mean, you know, maybe. But anyways, so look we, you know, took a little bit of time off like I said. But I think one of the things that we've done over the last, you know, many, many, many weeks and months and so forth is we've talked to a lot of really interesting guests. And we were counting them up the other day and we're up to 30 episodes that we recorded together. And, of course, we've had a number of amazing guests. But I also, you know, I really enjoyed talking with you, as well. So I figured what if we did an episode where we just talked about some of the past guests that we had, have a little chat about it, maybe pick out some of our favorite moments and so forth. And I was thinking about, you know, 30 episodes and, you know, I sent you a message and you said, 'oh 30 episodes. That's it?' And that made me think very much so, like, it does seem like we've done more than that. But it's sort of like being married. Like I've been married for almost 19 years but have people ask me I'm like, 'I don't know like 50? I don't know' It's just everyday has been a blessing.' But so yeah, I think this will be fun.

Rebecca: Yeah I also think, so 30 episodes, but we have been podcasting together and recording for about a year, a little over a year, I believe. And so that's probably it right? Because we record a bunch of episodes and we take some time off for the holidays and for the summer and like let people catch up on episodes. So the numbers and the math does work out But I think because the time has been longer than that. But just so people know, I mean Jeremy and I, you know, selected some of our favorite moments. And when I say 'selected' we literally have over 19 pages of notes of our favorite moments. And so we're not going to go through necessarily all 19 pages and a lot of it's texts that we'll actually just listen to the audio. But it is hard to pick our favorite moments because we have interviewed so many incredible guests. So thank you for this, to all of our guests, for all 19 pages of all these moments that Jeremy and I truly feel grateful to have been able to record with you all. Without further ado, Jeremy do you want to kick us off on what we believe is our thesis favorite moment?

Jeremy: I would and I do want to say something about the length of this here. Like, this this podcast is six and a half hours long today. So, you know...

Rebecca: Buckle up!

Jeremy: Maybe take a bathroom break if you want to. No. We're going to keep it, we're going to try to keep it, a little bit short. So yeah, I think, you know, the the one that we should start with, and this is a guest that I had been wanting to get for a very, very long time. I just, I find it really interesting. The work that he's done and, sort of, you know, in terms of serverless, I mean this is sort of 'the guy' when you think about it, in terms of driving the innovation around that or at least driving the organization that is driving the innovation around that. And that's Dr Werner Vogels. And we were lucky enough to have him on the show. And we asked him a whole bunch of questions. And again, you know, you get some of his answers that are very 'PR related' and so forth. And I think that there was an interesting moment during the show where I asked him about are we at a point with serverless where, you know, we've sort of built all the tools that need to be built? Or are there some other, sort of, major tools that that need to be built? So let's listen to this, and then we can talk about it a little bit. But I loved his comment at the end.


Werner Vogels:
So I think what we've seen, if you go beyond them though, I think if you just look at the Lambda ecosystem itself, Layers, SAM, all these other tools, earlier tools. Actually all have helped to become more efficient, but I also think you have to look at the complete ecosystem around it. API gateway, Event Bridge, you know, and then take everything else. Take SQS, take DynamoDB take S3. I mean, all of them are serverless. And since the integration between them becomes, is always important, but also how easier can we make it to build solutions on top of this? Because in essence, you know, I mean, we can talk a lot about sort of this one function that you want to build. but in the end, our systems are slightly more complex than that one function.

Yeah. And so I think step functions have become a crucial tool in all of that. Because again, you see we build on this Lambda and it's fun because you thought, 'oh, you know, you did deliver this file or this message in this queue or whatever. And this one function gets triggered. Well, turns out it's never one function and it is, then too many customers had to start doing all the heavy lifting again. They had to figure out, 'oh, has this function failed? What are the steps that they need to do after this function has failed?' And so, building step functions, for example, has I think greatly improved, the composition model, for Lambda, but I can never see Lambda separate of all the other pieces that we have, because I think serverless is just as important for those areas.

I mean, when now RedShift serverless. Now, you not only have to figure out exactly how many of these pillars do we need, or, you know, Aurora, RDS. I mean, all of this take RDS. RDS is also one of these sort of old fashioned kind of things, where we started off with. Yeah. In essence, you know, we had object storage, had network and security and things like that. EC2. In the database because everybody needed a database. Now, but in the beginning, definitely ideas still meant that you had to manage your database and anything you wanted to do. Do you want to have it.. Do you want to scale up? Did you want to scale down? Things like that were impossible. Now, it was also software built by other people, of course, largely. Because it was MySQL or Postgres, but then moving those to a serverless architecture means sensibly, 'hey, you know, you take the very, again, heavy lifting around it.' And then it also gave us the opportunity to do this massive innovation under the covers that became Aurora. Because I think that the sort of low file layouts is a complete departure from how we used to build relational databases anyway.

No, but good. For me, it serverless still, you know.
I still get annoyed by every piece of AWS that is not serverless.

Jeremy: I still get annoyed by every piece of AWS that is not serverless.

Rebecca: That honestly, I mean, I know we haven't printed bumper stickers yet. And maybe they've gone out of style a little bit, but when he said that, I think both you and I were like: 'can we bring bumper stickers back?' I still get annoyed by every piece of AWS that is not serverless. And I think both you and I were like, 'Do we get to keep this in?' Is that something that, let's say I mean obviously, Dr. Werner Vogels is, you know, a huge messenger for Amazon and AWS as a whole, or Amazon has a whole/AWS. And so we were like, 'Now how many things do we get to, does he get to be super opinionated about? And how many things does it have to be a little bit more, let's say scrubbed.' And so we were like, 'Do we get to keep this?' And yeah that's his opinion and that's how he feels and we get to keep it. And you and I, I think love, just love, that line.

Yeah, I think there was a I think there was a moment there that it was a little bit unscripted, right? And the other thing that was interesting, too, is he talked about all these services before Lambda that are considered serverless. Now I just did a talk about this, too. To basically say, you know, for quite a lot of time from 2006 to 2014, they're developing all these different services that are essentially serverless, but it wasn't until Lambda came along and there was a little bit more sort of, you know, of an ecosystem built around it or that connection, that it became, sort of, this idea that these servers or services were serverLESS. So, it is encouraging too, to think that this is the direction that AWS wants to go. Or certainly the direction, I think, that Werner wants to go. So, it is interesting but it's also interesting to think about where we are now, where, sort of , where we were going. Around the time that Lambda was released and maybe some people who might've been thinking about that beforehand.

Yeah absolutely. Thank you for this wonderful set up, Jeremy. It's like we talked about this. But one of the moments that I was really excited to highlight that you and I talked about with Jonas Bonér. And it's this idea of, I guess I let the cat out of the bag. Maybe I was supposed to introduce it without saying who it was first. But, what was so interesting about talking with him is that he had written The Reactive Manifesto, which has, you know, almost 32,000 signatures on it. And he had written about how the idea that reactive systems are responsive, they're resilient, they're elastic, and they're message driven. And I think he had done that in like 2004 or something like that. And so, what was that? 10, 11, 12 years before the release of Lambda? But it was, sort of, this idea of, 'okay how were people thinking about this a decade before and then how did that evolve into something that ended up being something like AWS Lambda in the serverless ecosystem?' So, let's listen to a bit of our conversation with Jonas...

Jonas Bonér:
I wish I could say yes, I saw serverless coming, but then I probably would've invented it like you said while writing that document. It's not that simple, it's always easy to put one and one together when you look back, harder to predict the future, but sure, halfway, yes, as well. Because I knew where I wanted the industry to go when it comes to tackling these new challenges when building things for the upcoming cloud, building things for the great infrastructure, Amazon storage and provide, and others as well.

And the reason for writing it was that, when I was out talking to a lot of people, Akka's been around for about five years back then, people didn't really understand why and how they should conceptualize about these new types of systems. So what I tried to do is distill it down to some core principles and make it easier to grasp the gist of it. It's of course, very superficial in a way and that's the reason why I added this document about reactive principles, it goes a little bit more into depth trying to explain what reactive systems is all about.

But anyway, really trying to give a common vocabulary, having one way of looking at it so people communicate and talk about the systems in the same way. And also, a little bit like call for arms. This is what we have to do as an industry, this is where we're going, we better get prepared and join forces in trying to invent this future, like Alan Kay would say. So that's really what it was all about out. And I wish I would have come up with the Lambda serverless experience, I didn't, but that sort of followed these ideas, I suppose. While the reactive systems is more like the groundwork and how the system should work and how we should design these type of systems.

Jeremy: Well, I'm going to give you more credit than you give yourself because I do think that it was very forward-looking and I would be surprised if that document wasn't brought up in some of those early planning meetings.

Rebecca: And you're actually going to get a second chance right now because it is certainly hard to predict the future, but we often ask a lot of our guests to say like, "Hey, where do you see serverless in five years?" But we don't usually have guests that are actively trying to shape that future of serverless. And so, if we were going to predict the future and perhaps you're going to write another manifesto about what's coming, two questions, where do you think serverless is going? And where do you want it to go? Are they aligned?

Jonas:
Yeah, I have two passions, and I think they are aligned. I think we're going there and I think we have to go there. And the first one is around the user experience. Even though serverless was really groundbreaking when it comes to that, of course, more has to be done around the user experience and the whole toolchain, from developer tools, through the CI tools, staging, all the way up, and also around the programming malls, that's also part of the user experience, and how we actually resonate, reason about these type of systems. A lot of interesting work is being done there, but I think more work need to be done. And that's a place where we are really trying to think hard what it would mean.

I think that's will sort of make it or break it for serverless, unless we make it super accessible. It already is, but I think we can do even better. And then everyone will now start using it, which I think it deserves. So there's, of course, more to say, but off to the next one that I think is equally important for me, at least. And it might be a little bit more early days, but that is the move to the edge, and how the new type of infrastructure we're getting, things like 5G, for example, with the vision of having hundreds or millions of points of presences, even now, essentially in your backyard, where you can have local groups communicating a little bit more offline and having all this super optimization that can be done with 5G. Being able to push serverless up in that realm and having hybrid solutions, because it won't just happen overnight. We'll still have old cloud infrastructure, old in quotes, but traditional cloud infrastructure that want to communicate with these edge clusters, and do it efficiently. And how do you program for that?

Jeremy: I really love that conversation with Jonas because I think it was sort of, you know, it's the same sort of thing I've been thinking about for quite some time. This idea where, like, you've got to make service more accessible for people, right? And you have to get them out of their own their old mindsets.

Rebecca: Indeed. And I think we've had some amazing conversations with some amazing guests. And, a couple of whom, one in particular, really helps us and others conceptualize what it means to get out of a mindset and what it means to see things from a new way.

Jeremy: Right. And I think if there's anybody who can talk ,about sort of, planning for the future, or maybe mapping for the future, Simon Wardley. We had him on episode 110 and you actually asked him this exact question about 'how do you, sort of, get people to, sort of ,shift that mindset and start looking forward to serverless?' And, of course, we named the episode The Inevitability of Serverless because I think it's quite clear from this conversation here that it's happening whether you want it to or not.

Simon Wardley:
Okay. I've been blunt enough anyway, I'll be brutally honest. Most inertia I don't find in people, in engineers, people doing the actual work. Most inertia I actually find in the management layer, in the executive layer. So where inertia occurs. For example, one government department very much resisting the shift to cloud mainly because the systems admin people within there and their managers were like, "Oh, we can't do that." Because the vendors were in there saying, "Well if it all goes to cloud, you're all going to be out of a job." And all that sort of stuff. So it was quite simple, it was to say well look, we don't want to shift to cloud actually. Totally agree because the runtime shifting. And so what we want to do is build up where which of course means that all the people will have to retrain up there and of course that creates a problem because those people will suddenly become incredibly valuable because this was 2016, 2017. They will become valuable over time. And all of a sudden, all these arguments because you gave people a path to go.

So one of the things I use with maps is I use the maps, I apply economic patterns to it and I look at points of inertia then you can directly counter those strategies for all different 16 forms of inertia that you can counter but the most important thing when it comes to people is give them a path. I hate this when people talk about people as resources or things like that as disposable assets. It's just a horrible way of thinking about things and I generally find that people are resistant to change. What they're resistant to is having a bunch of management consultants coming in and telling them they're fired while they're employing somebody else to do it. So not being given the chance, that's what I generally find.

So in terms of when it comes to adopting serverless, you've got several problems. One, executives like to talk about we have a strategy and it failed because execution wasn't right which is just a way of blaming other people for the fact that strategy was wrong in the first place. And so you've got to be mindful of the fact that you're going to have inertia within the executive areas, particularly talking about loss of manpower. You're going to have inertia within the people doing the actual work if no one has given them a path forward. Those things are fairly normal. So it's a good idea to map it out and find people a path and tell people where we're going to attack and how we're going to attack it as well.

You're going to have inertia coming from the vendors, the vendors will always tell you that you can have the future just like the past. So your capital investment, we can make sense of that. We can turn your grody data center into a private cloud, it can out compete Amazon. They're going to tell you all that stuff as long as it sells them servers. So you've got to be mindful of those sorts of things. One of the other big problems is of course once you get into serverless, you're really tying value down to where you're spending money. So this is like capital flowing applications.

Unfortunately, most organizations are very poor in understanding the landscape, very poor at understanding of the value that things create. If they actually mapped it, then it becomes a lot easier to do this sort of stuff. This is why you should definitely talk to David Anderson from Liberty Mutual, that's a great example or Drew Furlong is at Capital One, another great one. If you're going to have an honest discussion and for that, I use a map and we talk about what's changing, where are we going to have inertia and we talk about the inertia that we have and how we're going to tackle these issues, how we're going to give people a path forward because we're going to need them, we;re going to need them just working in a different area. I always find it relatively easy to overcome as long as you do the thinking beforehand. Right, okay?

Jeremy: Do enough people do that?

Simon: If you've just announced we're doing this great, big change program, it's all going serverless and the vendors are coming in saying, "You're all going to lose your jobs." Then you're going to have problems. So I generally find in it's in the executive layer."

Rebecca: A little insight for our guests who can't see us seeing each other. Actually when we were listening back to this clip you heard a certain sentence and you're like, 'Man I love that line.' And so maybe highlight that for folks because I also love that line. I love that it still gets you, even listening it back, and this has been probably the 30th time you've heard this back.

Yeah, and this is, again, Simon has so many great quotes that are in there but the line that I'd love to highlight is where he says, you know: Executives like to talk about, you know, we have a strategy. And it failed because the execution wasn't right. Which is just a way of blaming other people for the fact that the strategy was wrong in the first place.

Palpable, powerful and something where you're always like, 'Oh my gosh! The strategy being wrong! How do I ensure it from first principles, that even that foundation is correct?

I think I see a lead-in to the next piece that I want that we want to talk about. But before I go there, is there anything else that you want to leave us with in terms of takeaways from this conversation with Simon?

Jeremy: Yeah, well, I mean I think what he's talking about there, certainly there being a lot of resistance at a strategic level, right? And again, it's one of those things where I always find a lot of companies, especially when you get to larger companies, they they tend to lead from behind, right? So there's not a lot of innovation there. And I think you see this even happening with AWS at this point now, where it's like, you've got so many services and they're starting to tweak these things but you're not seeing the level of innovation that you're seeing from like CloudFlare, for example, because they're more nimble they can move a little bit faster and they can kind of do that. So this idea of, you know ,not thinking through strategy and just assuming that, you know, if your strategy is outdated or it's not forward-looking, then you're going to go ahead and blame the execution when in reality it's just, you weren't looking far enough ahead. And the predictability of some of this stuff, it's kind of crazy because, you know, if you look back at how predictable cloud was and cloud adoption and some of these other things, you know, if Simon was right about that, you know, I think he's going to be right about the serverless thing as thing as well.

Rebecca: Yeah, and I think this sort of dovetails into this idea that a lot of times, let's say, and this is a broad statement I know this, but a lot of times enterprises are seen as people that are companies, organizations that are a bit entrenched. They get entrenched in this one way of thinking and it was really successful for whatever time it was in. And then what Simon does with mapping, right, is he's basically, like, 'So where is it going next?' And you can actually start to see where it will be going next so that you can make that strategy, so you can make your strategy work. And it's not blaming the execution, but the strategy itself, by understanding where the market is going or where an organization needs to grow and where it should go next

However, he also mentions a few different folks at the end of that clip we just listened to .And it dovetails really nicely with the fact that one of them works at, or worked actually rather now, at Liberty Mutual. And it's one of those enterprises that does understand where serverless and the cloud, where the cloud and then therefore then serverless was going, and adopted a 'serverless first' approach. And so let's listen to a clip with David Anderson from our episode: Serverless First Engineers and the Flywheel Effect.

Dave Anderson:
Well, from a few different efforts of change, you realize that sometimes if you're extremely detailed upfront, you turn people off. So we just started talking about serverless first and a different way of building. And we started to slowly define what that meant. So we started to say things like event driven, well-architected. We talked about the serverless first spectr you know, start with serverless and managed services and work your way back through, you know, containers and even back to like, you know, the likes of cloud foundry, et cetera. So really giving people that prioritized list to work backwards from. We talked with engineering excellence, it's that we will take great pride in how we build. We'll have umpire teams.

So we can, we grew it to be slightly bigger. We'd be driven by a KPI.

And not just, you know, not just writing a feature, but actually driving the business KPI. So this all led to teams that were more self-sufficient and more responsible. And again, there's a couple of really nice things for Liberty Mutual. One of the phrases was responsibility is our policy. We're like, yeah, we can work that into it. One of the phrases with auto was the fact that only pay for watch you need. For your auto insurance. So we thought, okay. That sounds like a serverless thing. Only pay for what you use. So we started folding in the corporate kind of directions, which are really solid and linking them back to what the engineers were doing.

The engineers loved this because it was all of a sudden tying us to the business. And then when we did sit and talk to the business, we were talking the same language. So I've not consistent language from the engineering teams to the business leaders. It's just, it's just was incredible. This idea of experimentation as well.

You could try things really quickly and see if it worked and then you'd have the scale there if needed. So it's just about tying those, tying those things together the whole time. So it was, it's just fascinating to see how it grew.

Jeremy: Yeah, and this is where you asked him if he could, sort of, define 'serverless first' and what it means to Liberty Mutual.

So I think this was really interesting. The evolution. It was, sort of, like a skunk works project almost inside of Liberty Mutual where they just started talking about this slowly, what's that movie? Inception, right? Where you're starting to plant things in people's brains and then slowly it becomes their idea, maybe. But I think it was really interesting how Liberty Mutual sort of did that. And I love this idea of common language. That is something where ,we talk about that even with the reason for getting an AWS certification, for example. So that when you talk to other team members that ,are working on similar projects or the same project, that you have that common language to fall back on.

Rebecca: Yeah, and I think Liberty Mutual is certainly an example, a model here right, of how an organization can embrace a common language, how people can grow within a mindset and then adopted across an organization. And I think they're also, sort of, still an outlier in a lot of ways. Or organizations are certainly moving in this direction, but they were an example for a reason. They headlined a lot of things that 'serverless first' for a reason. Because they're one of the largest and first to really adopt this, like, full scale. And grow it over time and speak that common language across across their org. So, this doesn't happen all of the time. And, in fact, I think it's almost more surprising right now when it does happen, rather when than when it doesn't. And so with that spirit in mind, Jeremy I'd love for you to talk about this next clip that we thought was quite interesting to juxtapose this with.

Jeremy: Well, yeah. I mean this was the interesting thing to me, is that you've got this enterprise that is now adopting this really new technology. And they're finding a ton of success with it. And of course, you know, Matt Coulter and Kristi Perrault and all these other people who are out there now talking about what Liberty Mutual is doing with serverless and the success in an enterprise is really interesting. And, for me, when we talked to Tom I was sort of, like, you know, 'who's the typical'- this is Tom McGlaughlin, by the way, who maybe worked at Liberty Mutual for awhile, I can't confirm or deny that- but when we talked to him I asked him 'who's the typical serverless developer or who is serverless typically for? And I was really surprised by this answer.

Tom McLaughlin:
I don't think there is a typical company. but one of the things I have noticed is, and this is something I think we discussed a few years ago that serverless, back in like 2017/2018, we thought serverless was gonna be all the rage among the startups. And it really wasn't. It ended up becoming more so at the top, the big enterprises. And it's kind of working its way down. So that's, and so those are a lot of the people, and again, I've worked with small companies, startups and, and the enterprise. So I've seen both ends. So, yeah, there is no typical company, but particularly the enterprise, you have folks that are in a large company. They have been doing things a certain way for, for quite a while.

And they're now being tasked with change. So it might not just be, you know, an architecture change. It's part of, say, digital transformation or service modernization. So, you know it's all tied together with these larger initiatives.

Rebecca: I wanna follow up on that. I mean, I was also working at AWS on the serverless team, right? And we had definitely sort of like messaging for enterprise and messaging for startups and everything in between. And I'm so curious since you have been in the business for a long time, if you have a why behind, I mean, it was sort of surprising, right?

As you said, you thought maybe startups would adopt at first and it would work its way up, but really it started, or you saw the most adoption or desire for adoption through digital transformation at the enterprise level, and then maybe some startups end up using it as well. Do you have a hypothesis? Or maybe you have like, you know, cold, hard facts where you're like, this is actually why it was more adopted at the enterprise level and here's the reasons why we were surprised, but it didn't actually catch fire, let's say, in the startup land.

Tom: I think in the startup world, let's start there. I think Kubernetes was just so attractive just because there was the mind share and, you know, you could like, you know, throw a wrench somewhere and hit some infrastructure person that could set up Kubernetes for you. I don't, you know, a lot of it's funny cuz there's a meme where this person has a toy car and it's on like a giant flatbed truck and they're like 'deployed my WordPress instance to serverless', and, yeah, I, I think there's just this in the startup world, it's like, oh, we do Kubernetes, cuz we're gonna be that big and we're gonna need all of that.

And we don't know what we're gonna need tomorrow. So we can't tie ourselves into AWS. We need this agnostic platform. So that, and, and I see that appeal. I disagree with it, but I think that's why it's really taken, you know, that's why I think it's still very common in the startup world. You know, finding the people with the skills is really easy.

You can find somebody that knows how to put some software in a container. You can find an infrastructure person that can set up and run Kubernetes for you. So. All right. Cool. Let's just go with that. On the enterprise side, the enterprise is really fun. I would tell. anybody, take some time in the enterprise, if you just want to study like organizational culture, like pretend you're an anthropologist. It's really cool. so let...

Jeremy:
I can't tell if you're being facetious or not.

Rebecca: I literally just read to Jeremy, I was like enterprise is really fun. I was like, this is likely the first time I've actually ever heard this.

Tom:
No, it's very, it's so interesting because you start talking, when you look at the enterprise, you're just kind of like, 'Well, why is that giant 5,000 person organization, or 50,000 person organization making this sort of decision?' And then you have to start kind of going through the org chart.

And you can actually trace sometimes the logic of certain decisions by looking at the org chart. So my favorite is go try and sit there and sell, you know, a IT exec on, 'Hey, well, you know, if you go serverless great, you can transfer headcounts and resources over into development. You know, the people that make money, take stuff out of the stuff that costs money to run.'

And it sounds like a compelling argument, right? You know, who doesn't wanna make more money and spend less money, you know, running all that stuff.? That's great until you realize that, yeah. the people that like, you know, do the development and the people that do the operations are two completely separate , you know, like VPs or something like that. And for each of them, it's amazing that like, for each of them, actually, that argument doesn't only not resonate. It actually doesn't make sense for them. So you, so the person that's running infrastructure, they don't want to give up, you know, their budget and like the head count and stuff like that.

So they're incentivized to, you know, let's have this and you go to an enterprise, you know, a development VP. And they're like, 'Well, I can also use Kubernetes because somebody else is already providing this.' And I, now I'm just now talking about why people would use Kubernetes instead of serverless, in an enterprise.

But that's actually one of, that was actually something I saw once before, because it was just the org going through the org chart and trying, and seeing that, like people had different motivations And people looked at the arguments that we give in just different terms than we're accustomed to.

Jeremy: So, I think 'enterprise anthropology' sounds like a really bad suit shop or something like that. but, so

Tom: I was just gonna say, yeah, it's I think, you know, it's the reason I say go into the org, go into the enterprise and it's just, once you start seeing like an org chart, you can understand how decisions get made. And it's fascinating, completely fascinating to understand all this stuff.

But why would certain, you know, why would a development team inside an enterprise go serverless? One of the reasons is you will have other IT executives who will disagree with that. You know, with that first executive's thinking that 'Sure, we can just have that other group run all our infrastructure.'

You'll have another team that says, no, we actually want to be more nimble. You know that infrastructure and IT group is serving a 5,000 person organization. And you're a small hundred to maybe 200 person development team. It's kind of like, 'well, wouldn't it be pretty cool if we could actually just have, you know, if we could respond more, more quickly to our own needs instead of having to filter everything through them.'

So that is again, so that's one reason why within an organization, yes, you can definitely, you will see, teams adopting, you know, serverless within the enterprise.

Rebecca: Just, I remember both of us were typing back and forth to each other as we do. That's how we take notes, in case our listeners don't know. We were, we both typed something at the same time, which was something like, 'Wow this is the first time I've ever heard this.' Or 'what a surprising statement.' Or, 'I've never heard the enterprise is super fun.' Nor this idea, which is not to say, I think we were both, like, in our heads we're like, 'Yeah serverless is nimble right? It allows you to really move quickly.' And so this idea that startups, it's like well-designed for startups. And it is. I think that we don't often hear that enterprise story a lot 'where it's like enterprises are the ones that want to be adopting this.' They're usually like that idea where it's like slower and harder to change. And I think this answer from Tom was memorable, not only because he's clearly been on all sides of the spectrum, working with different sizes of organizations, but also memorable for me because you and I both had similar "ha!" moments. And so that's why, I think, I really wanted for all of us to relisten back to this.

Jeremy: Right, and I actually think it was an interesting, sort of, as you said, this idea of like: you would normally flip it the other way. Like I would think when he says 'You know, you can throw a wrench and hit somebody that knows how to set up a server or do containers.' He's actually very right about that. I mean, that is something that lots of people know how to do. When you start talking about more specific things like serverless and so forth, it does get a little bit niche, right? And you have to find people that know how to use dynamo DB and people who know how to use, I mean, now start talking about the more niche services like AppSync and EventBridge. Like, these are things that require a fair amount of specialization in order for you to understand and then be able to use them correctly. And I almost got the sense from Tom that there was a little bit of frustration within enterprises, from the people who work on these teams, who are like 'why does it take six months to get an API end point provisioned, right? Like, we need to move faster than this and we need to be able to do these things quicker. So I can see the reasoning behind it. You know, and certainly from a corporate standpoint trying to, or from an enterprise level standpoint, trying to justify the savings that you're going to have and the productivity boost. And all this other stuff makes a lot of sense. But it is a big cultural shift. And then on the other side of it, though, I do think that, you know, there is something we need to sell with serverless that we're not selling. That is this idea of, you know, 'yeah there's maybe some complexity to it and so forth' and again we've got to make serverless easier. This is a question, you know, this is a topic we could go on for hours about. But the idea of being able to say something like 'if you're a small company- a one person, two person, three person startup- how you build something Is maybe a little bit, I guess, less important than whether or not you're building the right thing.' And I might've given away too much there, but I'd love to hear your thoughts on that.

Rebecca: Yeah, I don't think you gave away too much. I just think you set it up so well that I would love for people to go ahead and listen to this outtake with Swizec Teller, from the episode Serverless for Front End Engineers, talking about iterating quickly and building the right thing, and what that means for teams.

Swizec Teller:
One of the things with software that's really nice is that you can iterate fast, but then we're putting all of these roadblocks in our way that makes it hard to iterate fast. And it's only that fast iteration that really makes it possible to build something that people want. Because I feel like in most companies or in most environments, it's much more likely that you're going to build the wrong thing than it is that you're going to build the right thing wrong.

Because if it's the right thing, you can always fix it later. But if it's the wrong thing, it needs to die as soon as possible. You don't want to spend.

Jeremy: So, I mean, that was one of the best quotes I think we've had from 135 episodes. It's much more likely that you're going to build the wrong thing than it is that you're going to build the right thing wrong. This happens all the time. It's like, I tell startups all the time, or any company that I consult with- especially before serverless came around- I would always tell them don't worry about scale. If you get to a point where your systems are really stressed and you have to scale up, there are ways to do that, right? That may not be super great, but let's hope you have that problem, right? I mean, that's where you want to get to. And that very much so ties back to what, you know, I think what Tom was saying where again, yeah, great. Let's spin up a Kubernetes cluster and containers and do all this crazy infrastructure, just to get up a proof of concept. Well, guess what? If nobody likes that proof of concept you've wasted a lot of time engineering infrastructure that you could have completely abstracted away with serverless. And even if serverless didn't scale to where you needed it to scale to, which it most likely would, but even if it didn't or there was some whatever there- if you get to that point that's a great problem to have.

Rebecca: Yeah and I think this ties back, not only to Tom's, but all the way back to Simon Wardley, right? Where, it's like, it's the strategy at the very beginning. It's not the execution that you have to blame. It's also the strategy where 'what are you building If you're going to build wrong thing, that's a strategic decision at the beginning. Like, get to that knowledge point way faster, right? Understand that you're building the wrong thing before you go build it, essentially. It'd be much better to build the right thing wrong.

Jeremy: Yeah, totally agree. So, we're running out of time and I actually thought we were going to get through all of these things very, very fast.

Rebecca: Me, too. We're always so optimistic.

We are optimistic- things always take 12 times longer than we, or a hundred times longer than I think we think they're going to take. But anyways, I want to get through one more of these and then I think, what we'll do is, we'll take a break, we'll we'll come back, and we'll do we'll do another one of these next week. And follow up with some other ones. And then we'll have a few more guests before we take our summer break.

Jeremy: But, I do want to get to this because, you know, we talked a lot about enterprise. And we talked a lot about small businesses. And we talked about building things right or versus, you know, the wrong thing versus building the right thing, whatever. So there's a there's a lot of complexity in all of that. And Liberty Mutual is a gigantic organization. They've got tons of developers that they can use. I mean, I forget how many thousands of developers they have. And so they can go through all the motions, and they can worry about compliance, and they can worry about security, and they can worry about all these other things. If you're a small business, though, or you are a startup. I mean, there's a lot of risk in setting up Kubernetes or something like that because you might need someone to manage it. You have security concerns. You have all these other things you have to deal with. And we had the pleasure of talking with Merritt Baer and Megan O'Neil in episode number 131 and we were talking about security in the cloud. And you you asked her about a quote that she uses quite a bit, that 'hope is not a plan' and, sort of, asked her to discuss that, or tell us a little bit more about that. And I found her answer to be very, very interesting.

Merrit Baer:
I take very little credit for it. I think it's kind of an Amazonianism, cause I have also heard it from Eric Brandwein. and that's usually who I attribute it to. But it is, I think the idea is that good intentions are not enough that, you know, we believe that humans are, you know, as Anne Frank would say 'inherently good at heart' or something, you know. But that's not enough, right?

That ultimately there needs to be mechanisms to get the job done. And that mechanisms allow us to also scale and to be able to, because we can not only be able to hand over to the next person, sort of a playbook of what we've been working on, but also to allow us to automate away. Because if it's a mechanism that, so for example, our SIM system, initially every SIM gets answered by a human and then increasingly gets answered by a robot.

Because we realized that there are things we can automate away. And then meanwhile, we hire people who love automation. You know, security engineers who can code, which often means we hire devs to be security engineers. Which means that one of their goals is to never close a trouble ticket until you've scripted a remediation, if it can be scripted, you know?

So it becomes this whole, one of the big questions I get is like, how do I build a culture of innovation, a culture of security, a culture of... And it's like, you build a culture of what you repeatedly do. Culture is what you do on purpose over time. And I think, you know, if you want to do those behaviors, then you exhibit them. You know, like, and the way to exhibit them is to create mechanisms to encourage and foster and kind of, you know, grow those.

Jeremy: So culture is what you do on purpose over time.

Rebecca: I would follow it up but I think the silence allows it to land a little better.

Jeremy: Yeah I mean it just, the point, I think, of what she's saying here again, and of course she's got a lot of talks and writing, too, that you can go and check out, and I encourage you to follow Merritt and see what she's talking about. But some of the things that kind of hit me here, too, is that you know security is is super important, right? You can't just, you know, hope and pray that everyone's going to be a good soul and there aren't going to be any nefarious actors out there that are gonna do stuff. But what I also ,liked about this was this is very much so an evolution. You don't get it perfect first. She talks about every time they get a trouble ticket, the culture or the process is to then automate the remediation for that. So that it's, you see something new and you figure out how to deal with it, and then you automate that so that you continuously are lowering your burdens, but still getting better at what you do. And then just having that mindset is a really important part of any team's culture.

Rebecca: Yeah, and I think she and Megan exemplified this really well throughout the entire conversation. If you hadn't heard this episode before, highly recommend you going back to it. I feel like 'hope is not a plan' and 'culture is repeated actions' are just two of the many takeaways. Especially when applying it to security where ultimately it comes down to the, like, it's a foundational P0. And it maybe seems unsexy. And I think we talked about that in the episode, too. But really it's kind of the most exciting thing you could possibly solve in an ever-evolving cloud world.

Yeah, totally agree. All right. Well, so I think we've given our listeners a whole bunch of things to digest. If you have not listened to these episodes, they are great. Our guests are absolutely amazing. We are so lucky to have such amazing guests on this showand have the opportunity to talk to them. So, we will put in the show notes for this show, we will put all of the links to the shows that we mentioned here. And Rebecca you have something you'd like to say.

I do. You know doing ,this was sort of like a love letter, right? Like going through this retrospective. Looking at some of these moments. I'm glad we get to do a second episode to finish off the other ones that we haven't gotten to next week. But it's, sort of, it's a love letter to our guests, right, this episode is. It's a love letter to the great moments across the past 30 episodes and across the past one year. But also, Jeremy, I really want to say doing this exercise was also, sort of, a love letter to you, as the co-founder of serverless chats. And as a cohost, I really just wanted to take this moment and say, like, you are such a cool host to have these conversations with. You give credit where credit is due. You celebrate others' work. You share enthusiasm. You build up other people's ideas. You build on other people's ideas. And so while I was going through some of these episodes that we've done together while I thank our guests so much and I thank the fact that we got to share these really great moments, I really want to thank you, too. You have really set something up and I think brought a space where our guests can share a lot of their expertise and hopefully our listeners appreciate it, too.

Jeremy: Well, I appreciate that. And I, of course ,appreciate you. I won't tell my wife that you wrote me a love letter, but that's okay. No, I think it's, I thank you very much so for that. Because that is one of the things that I strive to do with this show right from the beginning. Is to say: I have this privilege where I get to talk to these amazing people. And it's just not fair that other people don't get to hear these conversations. Now, that maybe the bad part is that people have to listen to my side of the conversation and they can't just listen to the guests. But, so you do have to put up with me in order to get the good stuff from the guests, but yeah that is an important thing to me. And I just love what these people are doing. I love the community. I love the whole ecosystem and the innovation. I am just floored by the technology and where it's going. So yeah, so I appreciate what you said there. And I hope the guests appreciate it and I hope that the audience appreciates listening to them.

Rebecca: Yeah, if you do, or if you don't, let us know. You can find us on Twitter.

Jeremy: @serverlesschats. All right, well, we'll put all of the shows that we mentioned, all the episodes we mentioned, in the show notes. And we will be back again next week with another best of episode.