Screaming in the Cloud - The Current State of Serverless with Kristi Perreault

Episode Date: March 27, 2024

On this week’s episode of Screaming in the Cloud, Corey is joined by Kristi Perreault. Given Kristi’s title of AWS Serverless Hero, Corey and Kristi discuss the origins and current state of the serverless world, the similarities between AI and serverless as the tech world moves into this next era, and why she emphasizes that serverless is not always the right solution for every issue. Kristi also opens up about her role as Principal Software Engineer at Liberty Mutual, and what she enjoys most about jet setting around the globe giving speeches.Highlights:(00:00) - Introducing Kristi Perreault(00:39) - The Unconventional Path to Becoming an AWS Serverless Hero(05:05) - Exploring the Boundaries of Cloud Education(10:53) - The Challenges of Keeping Up with Rapid Tech Changes(11:51) - Redefining Serverless: Beyond the Hype(13:12) - The Evolution of Serverless and Its Impact(21:55) - Staying Grounded Amidst Technological Zealotry(27:18) - Python Development in the Cloud(29:31) - Upcoming Talks and Where to Connect with KristiAbout KristiKristi Perreault is an AWS Serverless Hero and a Principal Software Engineer at Liberty Mutual Insurance, where her focus is serverless-first cloud enablement. She has over 5 years of industry experience, holds an M.S. in Electrical & Computer Engineering, and is very passionate about promoting women in technology. She is an established speaker, appearing in over 35 conferences, podcasts, panels, and more. Kristi founded the Serverless Denver meetup, and currently co-organizes the Portsmouth, NH AWS User Group and CDK Day. Outside of work and the serverless tech space, Kristi can be found reading a good book in her tiny home, enjoying a good poke bowl, or jet setting all over the world.Links:Linkedin: https://www.linkedin.com/in/kristi-perreault/Twitter: @kperreault95AWS Portsmouth User Group: https://www.meetup.com/aws-portsmouth-user-group/AWS Usergroup Belfast: https://www.meetup.com/aws-usergroup-belfast/

People are talking a lot about this post-serverless world. It's interesting because I picked it up pretty quickly, but also it was early on in my career, so I didn't have much to compare it to, right? Like I wasn't used to the frustrations of what came before it. So to me, I have a different perspective because I came in and just was taught that this is the way we do things. Welcome to Screaming in the Cloud. I'm Corey Quinn.

My guest today joins us from a very far away land, though it often doesn't feel that way due to the magic of the internet. Christy Peralt is a principal software engineer at Liberty Mutual Insurance. Christy, thank you for joining me. Thanks for having me, Corey. Super excited to be here. Finally get the chance to chat on the podcast. This episode is sponsored in part by my day job,

the Duck Bill Group. Do you have a horrifying AWS bill? That can mean a lot of things. Predicting what it's going to be, determining what it should be, negotiating your next long-term contract with AWS, or just figuring out why it increasingly resembles a phone number, but nobody seems to quite know why that is.

To learn more, visit duckbillgroup.com. Remember, you can't duck the duck bill bill. And my CEO informs me that is absolutely not our slogan. It's fine. You're one of those people where the job title doesn't tell the full story. Not that it ever does for anyone, but it feels particularly pronounced in your world. You've done a lot of work with organizing user groups. You're big into the cloud education space. You're an AWS serverless hero, which I'm old enough to remember when there was just one kind

of hero and it was the sort of where everyone clapped on the curb as they all went by. Where do you start? Where do you stop? It feels like it's been pretty nonstop since I've kind of joined the AWS cloud space for sure, which feels like it was a long time ago, but it's actually only been a couple years. I really broke into the space just attending reInvent like three years ago on one of the, actually one of the scholarships that they have for DE&I and people that are early on in their field. So at the time I was breaking into the serverless world and the cloud world at my job. And I just really wanted to go. I wanted to attend,

see what it was like. And I found my way there and it kind of just blew up from there. So it was super exciting. I met tons of people, took advantage of so much stuff and just came back rejuvenated and energized to really get involved in the community. And it happened pretty quickly after that. There was a podcast and conference talks and attending different events and just traveling a ton. And I've really enjoyed every minute of it and doing things like these podcasts and just being able to connect with and communicate with tons of different people in the tech world and really dove into serverless groups and user groups and then started having opportunities to organize those things. It's been incredible. I definitely had to take a step back last year. I was fully burned out from doing a ton of work, but I'm definitely excited to kind of jump back in and to keep going this year.

You might be the first person I've ever spoken to who has talked about going to reInvent and then coming back rejuvenated and ready to dive on in. I want to crawl into a plastic bag and die at the end of reInvent. It takes me until early January to wind up getting my soul back, just because it is so much all at once once and there's no chance to rest. There's no chance. The time is so valuable there to catch up with people from far away places that it's just, at least from my perspective, it's always been just sort of the Superbowl of the, of the entire cloud world. I envy your ability to basically find that stuff empowering rather than exhausting. Well, I mean, to be fair, I was only like in my mid-20s when I went.

Yeah, step one, be younger. That does help. Yeah, exactly. Be younger. Yeah, show up younger for sure. I think it helps me have no expectations though. Like I didn't go into it like having to fill my calendar or, you know, trying to like meet tons of people.

I was kind of clueless, which was almost great in a way. I just kind of went with it. I knew some people at my company that had gone or were going that I knew I wanted to see. But that was pretty much it. I was like, we'll see what's on the schedule. We'll see what I can get into. We'll see where the days take me. And it was definitely way more relaxing.

I think once you get into the community and you go back in previous years, it turns into that. You just run into people all the time or there's people you want to see and there's definitely things you want to do while you have the opportunity. So it's almost better to go in clueless in a way. Has it started happening to you where people will swear that you've been around longer

than you actually have in the space? I'll wind up people talking, oh, and we hung out at reInvent in 2015. Yeah, my first time at reInvent was 2018, but I will believe whatever narrative people want to say if it makes for a good story. Yeah, my first time at reInvent was 2018. But I will believe whatever narrative people want to say if it makes for a good story. Oh, that definitely happens to me all the time. I get told that quite a lot, especially even one of my co-organizers with the AWS Portsmouth user group. He says all the time, I always forget that you haven't been in

this as long as I think you have. He was the first podcast I was on. And he's like, I had no idea. I thought I was just giving you a chance to try out one of your new talks or something. I didn't think it was the first thing you had ever done. So it kind of shocked me to this day. So yeah, it definitely happens for sure. But tech moves so fast. It's hard to keep up. It's hard to know. So I definitely don't, don't blame people for thinking that. It's a great problem to have. One of the thing that took me an embarrassingly long time to learn in my career was that I always try to inflate my experience because I feel it would justify, in other words, bring me in a certain level. And in hindsight, it was the wrong approach because you know what you know, and it's more impressive if it didn't

take you 15 years to learn it. And instead you did it in three. It's a, oh, okay. Yeah. But this person can pick things up quickly, which is one of the big signals any hiring manager worth their salt is going to be looking for. You've been focusing a lot on cloud education, which means an awful lot of things depending on who you are and what your perspective is.

I would argue I'm focusing on cloud education. I'm teaching the clouds to step lightly when it comes to certain billing structures. Where do your educational efforts start and stop? Yeah, I think that that's such a tough question to answer because I feel like, you know, you're educating people even just sharing like what you're learning as you're going, right? Like I'd argue all the speaking and user group stuff, like that's definitely, you know, education, even though it's not sitting down and taking a class or going through a course, like that

still counts. Like you're still sharing your knowledge and what you've learned you're still adding to the dialogue and sharing knowledge with with other experts or people that are next oh the best way to learn anything is to teach it you don't know it until you've been asked a really silly question and realize you don't know the answer to that so we're all going to learn together yeah exactly and i think you know andrew brown really tested me with this last year when he asked me to be a guest instructor for his bootcamp. And I love that guy. He's, I got to obviously teach the serverless section to a whole bunch of people and it was so like free form. He's like, whatever you want to teach it, like we can go through CDK stuff. We can, you know, you can screen share, I can screen share, we can do it together. Like, and it was just awesome.

And I had so much feedback at the end of that from students just being like, this was so much fun. Like, you know, thanks for coming on and like showing us how to do this. Like I've never even heard of like PDK or serverless. And like, this was a great introduction. I just want to learn more. So there's stuff like that. And then there's things like even been helping with certifications within the company as well. Like we've helped, we've got 35 people certified last year and we're running our cohort again this year. So there's tons of spaces for it and I'm just, I'm excited for more opportunities. I have tons of ideas that I might not be ready to talk about yet, but that we want to bring into the community to kind of move that, push that

needle forward, especially in the AWS space with how much stuff is out there all the time and then continually to come out. It's very confusing. It's overwhelming. It's difficult. I mean, even in my day job, going back and forth between languages and learning different services that are out there, there's so many gaps that you can still see that I would love to fill and to share. Andrew Brown has always been extremely kind to me, even when I may have given him reason not to be. He's one of the nicest people I think I've encountered in the cloud space. But his boot camps, at least to my understanding from what I've seen of them, tend to, like many boot camps do, tend to focus to all comers where they are talking to folks who are independent

learners in many cases who, well, all right, I'm going to learn this in my spare time. You have a day job at an absolutely massive enterprise. That is the nature of big companies. How do you wind up, I guess, finding that there's a difference between the way you learn things in a large enterprise style environment versus the I'm doing this with my own time, effort and money. And it just feels like there's a very different means to approach this or perhaps not. And I'm misunderstanding.

It's been so long since I worked at a big company. No, there definitely is a different approach. It's interesting and unique to kind of be able to see both of those and work in both of those spaces. I think, you know, the individual, like they are definitely looking for stuff that they're almost more like passionate because it's like, well, I, you know, don't have that job yet, or I'm willing to upskill on my own time. Whereas like the approach you kind of almost have to take in that corporate world is showing the angle of where it's going to help them in their job, or when it's going to help them build their resume, or, you know, it's got to be something that's more immediate benefit, I think, and trade off. But I also think that there's a lot there that is just so different within the ecosystem, right? Like there's so many different ways to do things,

but it's hard to find that information like for the Liberty system, right? So trying to learn within those guardrails of like, hey, I can Google it and AWS gives me this great article, but that doesn't help me with all the tools and things that we have to use here or the certain guardrails we have with security

or the certain processes that we have to interact with. It's not as easy as copy pasting from Stack Overflow or for going through a lab or a bootcamp or something. You can definitely use those skills and apply them, but there's no golden path for that, for learning that in a corporate environment. It's tough to fill in those gaps of like, okay, this is how you do it externally. But like, now we have to bring it into your corporate ecosystem and show you how we do it here. And they're not always a one-to-one map. No. And I would argue to take it even further where you're at a big company having that experience, it is almost certainly radically different than the experience at any of the other big companies. It's not a big versus small. It is big at this particular company versus small. Oh, completely. And then, you know, there's certain things too,

where people really need the information more immediate sometimes in the corporate environment, right? Like they want to know something because they're like, oh, I have to set this database up like tomorrow. Like I need something that's maybe more easily consumable or like a quick article or like something that I can find or a video walkthrough. Like you don't have two months to ramp up on something or to dedicate extra time to like, it's kind of more of, I need solutions and I need them really quickly and I need them to be able to find them really easily. So in some cases you can take the time and be like, sure, I want to, you know, maybe learn Python and take three days and sign up with the tech learning department to learn that. Or sure, I want to maybe get certified or something, but it's definitely a different

educational experience for sure. I don't envy you the challenges of building out actual formal curricula. It feels like every time you do a video course or even a blog post with screenshots or something, there's one feature change to the service or we got bored this week, decided we completely redesigned the console and then suddenly, oh, great. I have to replace all my screenshots, if nothing else. But I also, in some cases, would have to rerecord so much of it just because it doesn't align with what the learner is seeing. Yeah, that's a huge challenge. I mean, to be discoverable, I think think is definitely up there. It's hard to get your right audience, get in front of the right audience sometimes, whether you're in a big company

or whether you're in the community. But yeah, I think that that's, you know, problem number two is that stuff just moves so quickly. And it's so hard to stay up to date. So you have to dedicate kind of that time to go back and do that. Or you're adding disclaimers all over the place, right? Like, hey, you might see this button here, but, you know, they could have changed it by now. And then the buttons on the other side of the screen or they renamed it or something like that. So definitely a hard challenge to stay on top of. You can drive yourself crazy going through all of it. Here at the Duckbill Group, one of the things we do with, you know, my day job is we help negotiate AWS contracts.

We just recently crossed $5 billion of contract value negotiated. It solves for fun problems such as how do you know that your contract that you have with AWS is the best deal you can get? How do you know you're not leaving money on the table? How do you know that you're not doing what I do on this podcast and on Twitter constantly and sticking your foot in your mouth. To learn more, come chat at duckbillgroup.com. Optionally, I will also do podcast voice when we talk about it. Again, that's duckbillgroup.com. I'm curious to get your take as someone who's been around for a little while now. You are a serverless hero. I was very excited about serverless when it first came out. It scratched a number of itches that I

thought were great. And I still like the core of what was announced back in those days. But it also increasingly feels to me like there's been a retconning of what serverless actually means. And for a while, I thought I was losing my mind because when I was talking, I was talking with a number of heroes about this in the early days. Serverless scales to zero. That's a definition. That's a characteristic property of the technology. And then AWS said, oh, no, no, no, no. That has never been a requirement for serverless. And I thought I was losing my mind for about two days before I went into the Wayback Machine on archive.org. And sure enough, when it was announced, it scales to zero, was absolutely prominently on the AWS serverless marketing pages. Now, most things that they announce with a serverless label will scale down to one unit

or whatnot, which is still in many cases going to be $40 or $70 a month just for this thing to exist. And that always sort of rubbed me the wrong way from a serverless purism perspective. Do you have an opinion on that side of the world? I'm not trying to get you to wind up calling people out or anything like that, because I know this can be controversial, but it's something that I've been frustrated by. And I'm wondering if that's just because I'm persnickety. No, I'm glad you brought it up, I think. And, you know, you've seen this quite a bit, or you're seeing this quite a bit if you're in the serverless community right now, is that people are talking a lot about post-serverless world, right?

And when I first joined, it's interesting because I picked it up pretty quickly, but also it was early on in my career. So I didn't have much to compare it to, right? Like I wasn't used to the frustrations of what came before it. So to me, I have a different perspective because I came in and just was taught that this is the way we do things. Like that's how we work. And I kind of stepped right into a team

that was really focused on serverless enablement at an enterprise scale and serverless first, which I still do very much believe. I still think that, you know, a lot of the core of what we do is serverless and building serverless. You know, everything I've done has been pretty heavy in the Lambda, the S3, the Dynamo sort of world.

And I really enjoy it. But I do think that we have to step back a little bit. And they're definitely overusing the word, I think, and tacking it on to a lot of services right now that maybe don't necessarily fit that traditional version of what we've been told or have believed that serverless is for so long. And I think that that's getting a little bit out of hand. But I do think that the core values are still there, right? It was the pay-as-you-go model. It's that event-driven architecture. I think that those are still core and still key. But I do think that there was this big wave of excitement of this is the new thing. And I think over the last year or so, we've kind of stepped back a bit. And especially seeing it firsthand,

there's all this day two that we have to worry about now as well. I mean, CDK, every time I blink, there's a different version. And there's no LTS of it either. There's nothing I can build on it that's like, okay, in six months when I come back and touch this thing,

I don't want step one to be half a day where I've got to go and get everything modernized and do all the version updates just to make the small change I was here to make in the first place. Right, I mean, like you're starting to get to the point where the serverless has tech debt too. You know, that's what we're starting to see. And it's like, well, how do we manage it? Is it better than our previous tech debt has been? I don't know yet. Like, I think we're still early on in that. I have some conference talk ideas kind of stewing about,

you know, the post-serverless world and how we want to handle that and what that looks like going forward. But I still fall back on the, let's use the right tool for the right job, right? I think that we can't say that serverless is going to be the magic fit for everything. And I think that there's elements to it that we can definitely take advantage of and use. But, you know, at some point, skill set comes into it, you know, the rest of your ecosystem. I mean, we acquire companies all the time and have different ecosystems that come into that don't necessarily fit that model, or we don't have time to fix. I'm kind of more relying on if it's not costing us a ton of money, if it's not broken right now, like, let's kind of keep going with it. And if we can modernize, we'll modernize. But if it's not causing any major issues, let's take some more time to

look at what the right fit is for that. Yeah, security patches are one thing but we're going to modernize the latest version just because it's a best practice somewhere. That requires more context. I want to be clear on my objection to what serverless has become is because for a shining moment,

I had this beautiful vision of what could be possible where not just every branch would have its own deployed instance of the application, but every feature branch could do that. If you're running on top of Lambda and DynamoDB set to on-demand, you still can. Your costs for that, each environment, round up to a penny. But when you start having to do this, you're either, okay, it's time to start sharing resources like databases and whatnot, which is a terrible plan, or you're driving up costs and not meaning it. I think that that's less of a concern

for large companies than it is for someone in their spare time using their ramen budget to figure this stuff out as they go. I say this as someone who experiments on his own ramen budget. Yeah, yeah, definitely. And I think that there's still, there's still gotchas there, right? Like, I think that people kind of come into it thinking that it's going to solve all their problems. But,

you know, like perfect example, I've been working a lot with Python and, you know, we had a package that was way too big and it was even too big for layers in Lambda. So it was like, we ended up having to containerize it, which was a bunch of extra steps. And then you have longer build and deploy times, but people don't, you don't which was a bunch of extra steps. And then you have longer build and deploy times. But people don't, you don't put those things together all the time. And you don't say like, hey, Lambda is still a really good fit for this. But there's a couple extra steps in here involved in that. And I think that that's some of where that education thread weaves through.

We need to be better at communicating when to use these things, when to use these services and these tools, when they might not work out of the box for you. Because I think that that's the hugest part is that it's so easy to find those hello world examples or those small little snippets of stuff. But it's when you start getting into the complicated things and stuff starts getting too big or too intertwined and you've got a thousand different services that you're kind of chaining together here in an event-driven architecture, it's really hard to trace some of those issues and to explain when you're going to use SNF and when you're going to use event bridge and when you're going to use step functions versus a series of Lambda functions. You're getting into those convoluted points. So it's not a magic solution for everything, but it's a really good tool to add to your toolkit. The answer is always, it depends once you go deep enough into anything.

And nothing's perfect. I mean, you look at the AWS advice on how to build these things as reference architectures, you've got to be careful to make sure this didn't just bankrupt you for funsies. Conversely, when I see a lot of these tutorials, when I'm gathering content for the newsletter every week, where people will start off talking about things and then they'll either talk, they'll either make an observation that is completely incorrect. Sometimes just trivia. Other times like,

no, this could actually cause some harm. And the problem is both is twofold, both in that, okay, this person seemed to really understand what they're doing. Like I want the idea of a golden path of do it this way, but I want to also have it explained what the trade-offs are for that.

And then of course, the other problem is, is so much of these things that are put out there, this is how to do it with version strings and the rest. You read these blog posts, it's like, this thing is going to age like milk. It's awful. It's going to become this, the cautionary tale of never do this ever. And I say this not to be unkind, but as someone who's written those exact things, where I look periodically through the web analytics for my site, the old things I've written, it's, oh God, people are still visiting this one tutorial. It's terrible. Like I wanted, I've edited some of them, put warnings at the beginning of, yeah, this was a product of its times. Don't do that. However,

the problem now is becoming even worse because you or I reading that would generally either understand that this is more of a historical artifact and there are better approaches, or we're in for a real fun learning experience. But the large language models that people are training on the crawl on the internet for these things are not going to pick up that nuance. And here's how you open an S3 bucket. What else can I help you with? Paying for it, maybe? It's so true. I mean, like the AI stuff, it's, I'm definitely in still in that, that skeptic camp a little bit, right? Is that there's so much stuff out there and not all of it's going to be true and not all of it has that stamp of approval or you know i almost think the date needs to be bigger than the title

of your podcast or your article so that people know because that's the first thing i look at i'm like is this from 2023 or is this from like 2020 and some of the seo jerks have figured this out and they'll start updating things like periodically on their website so it shows up in search engines is oh updated three days ago and I'm clicking through this thing, like how to build a static website with S3 and CloudFront. It's, I'm betting it was not in fact, but okay. You have to apply a critical mind on this, but the reason you wouldn't know, you know this, and I know this is because we, there've been times where we very clearly haven't and wound up regretting it.

So it's, yeah, you have to get your lumps before you understand how this stuff works. That feels like it's not serving future generations very well. Yeah. And I think that that's true in that AI space. This is why I'm so skeptical of it too, is that I think it's going to be a great tool. Again, it's like serverless, right? You're just going to add that tool to your toolkit and And it's something that you can pull out and use. And there's a time and a place for those sorts of things. But it does scare me the amount of people that are going to completely rely on those things. You know, you and I are going to look at that and take it with a grain of salt and maybe be like, I'll check three or four other sources or I'll ask somebody else or I'll look at the other industry experts. But there's some people that are just starting out or that are going to take that and

be like, well, that's what they said is true. So it must be true. And that stuff kind of scares me. Like it's definitely not right. A hundred percent of the time, some days, not even like 50% of the time. Right. I have to ask, and again, please do not take this as an attack. This is a microcosm of a much larger problem that I'm starting to think I see. You are like back, back when I started playing around in this space, they just had see. You are, like, back when I started playing around in this space, they just had the AWS community heroes, of which I was never invited to become one of them, because if anything, I'm the community villain, but I'll also take anti-hero. But then they started breaking them apart into different focus areas. You are a serverless hero,

as an obvious example of this. But when I hear someone self-describe on some level or have a title that ties them to a particular technology or particular architecture, I get a little concerned just because I've seen this happen in previous generations. I used to work with a consultant who had a large monitoring package as his nickname. Like, it was like, like, I don't know, let's call it SolarWinds. It was not. SolarWinds Steve would have been his email signature.

And surprisingly, whenever he was asked to weigh in on a technical problem, the solution, wouldn't you know it, somehow involved SolarWinds. So I think the concern I'm getting at here is when people start identifying with a certain technology, it feels like the road to zealotry is fairly short.

How do you guard against that? And I know for a fact that you do, because I have seen you multiple times point out where serverless is clearly not the right answer for a given problem. How do you keep yourself honest? Yeah, I think that that's a great question. But first, I'll say you're welcome to be my AWS serverless sidekick if you'd like. I would be happy to give you that title. You can join me for sure. But I think that's a great question.

And I took a big step back last year and haven't done a ton of speaking events. And I did over 35 of them in 2022. And I just needed to take a step back. And part of that was some of that identity thing, right? There's a big AI boom. The tech industry has kind of been upended over the last year or so. And I kind of needed to take a step back and listen a lot more than I needed to speak and kind of understand where are we headed? Maybe not necessarily what's the next big thing, but what kind of makes sense in the next path? Like I've got a long career

ahead of me, I hope. So what is going to align me best? What is going to help me serve the community best? You know, as much as I might be skeptical in AI and stuff, it's still important to learn about those things and to understand them and to bring those opportunities to the user group or, you know, to speaking events, to events, to conferences. So I took some time with that too. And I still think that, you know,

serverless is definitely part of my identity and part of what I've been working. And even AWS, you can even take a step back from that too and say, you're tied to AWS as well. And I think that it's one piece of a whole bigger part of me and what I've been focused on and doing. So I think that part of that is branching out and trying new things and being known for those things. I'm speaking a little bit more on Python development, on stuff that's not necessarily AWS serverless. So I think that part of it is owning that part of your identity, that part of your history, that part of, you know,

you're going to take that and go forward with it. But it's also diversifying your portfolio, speaking out about more things. It's, you know, I'm talking more about cloud education as a whole, developer tooling, you know, looking towards kind of what's next. And I think that part of it's just staying up to date with things

and how you're presenting yourself. You know, like this talk wasn't all entirely on serverless, right? Like hopefully people come away thinking that there's more, you know, we're talking about education, we're talking about all these other facets. And I think that it's important to embrace it,

but also make sure that, you know, you're diversifying your portfolio more as well. Yeah, and I think there's also a, as we see increased specialization in the world, but also make sure that you're diversifying your portfolio more as well. Yeah. And I think there's also a, as we see increased specialization in the world, that we tend to assume less and less that someone who's very good at something has at least a working grasp of the rest of the basics and other

areas. In reality, it's, well, what do you do? Well, I do an awful lot of serverless compute work. Yeah.

I can probably safely assume you also know what a database is, as a hypothetical example. It's, most people are able to think about more than one thing at a time and are not completely unidirectional. What I think I'm seeing, too, is that as serverless tends to expand its footprint to mean more and more things, it also starts to feel like it is less of a distinguisher as time goes on. Do you get that sense? Or because again,

you're a lot closer to this than I am. I'm sitting here in the cheap seats. Yeah, I would agree. I think that it's, it's less and less about that. I think like using other terms is like, you know,

event driven and stuff. That's not, that's pretty tightly coupled with, with serverless when we talk about those things, but it's, it's switching our vocabulary. It's like I said, you know, using it as a tool

and not the end-all be-all, not the golden solution for everything. And I think like, you know, a huge part of this is to not being in the community about it is not having an ego about it either. Like I want people to tell me if I'm way off on something or politely, right? Like don't attack me.

That's a very important qualifier that people often miss. Yeah, and that's a piece that people often miss, yeah. But, you know, if you want to politely, constructively have a conversation about things or share your opinion or, you know, something that's different, like, I welcome that. And I think that you can't be afraid to change your mind on stuff and to change your, especially how quickly things are changing. And, you know, I think that it's healthy to go back and say, hey, what I said, you know, a year ago does not hold up today. You guys are all harping on that still. Or, you know, even last week, like, hey, I've learned more information.

And I think more people need to be willing to admit that or to amend that or to say those things. One last topic that I want to cover before we wind up calling it an episode is something near and dear to your heart, the idea of Python development, specifically in the cloud. The problem that I've run into whenever I'm doing what lately has looked like an increasing amount of Python development in the cloud has been that you wind up with analysis paralysis. There's so many choices to make just out of the gate. Do you use pip? Do you use pip? Do you use

pyad? Do you use poetry or one of the other various ways of handling virtual environments? How do you wind up normalizing versions? How do you wind up doing the packaging? How do you handle dependencies and so on and so on and so on? Do you have a golden path approach that you think works for most people in this space? Or is it always the big magic? It depends. And everyone has their own opinions. Everyone except mine is terrible, which is increasing.

That ladder is increasingly what I'm starting to believe is the case. Yeah, I definitely lean towards the ladder. I've done PIP. Most of my more recent work has been in poetry packaging. So I've liked that a lot. One thing I've been pushing a ton, people are telling me are talking about is

Lambda Power Tools is a huge one for me. I think that that's so great for looking at your tracing, for metrics, for logging. So that's kind of a non-negotiable tool for me that I've had in all my Lambda functions

and I've been pushing for sure. I do think some of that depends. Some of that, again, it's the corporate guardrails too, you know, what's available to you and what can you, because I'm not going to own everything forever, right? That's going to eventually go to another team, you know, what's going to future-proof it the most.

So like where you kind of tend towards where the skillset is in some respects. So that's what my team is comfortable with, you know, what we think the next teams will be when they eventually take this on or what's going to age the best. So I've definitely, I've been using Poetry. I kind of stick to the latest versions of Python that I can.

And then I also really like Talk for my testing tool. It's so easy to just get all your testing dependencies in one place and run one three-letter command to get all your unit infrastructure, integration tests running. So I love that as well. I am definitely excited to talk more about one of my upcoming talks as well. So hopefully I can enlighten some folks on my Lambda Python development practices. Do you have any talks coming up soon? Yes, I will be at Python Italia. So my talk is on the ups and downs of Lambda Python development. I'll share some of the good, the bad and the ugly, some of my favorite tools and how to

use them. And then I'm looking forward to attending some summits this year, hopefully re-invent this year as well. So I might try to squeeze that one in there too. If so, I know I'll run into you there. It's one of those, it's the giant central focal point of the entire industry, whether we want it to be or not. But I'm looking forward to seeing the slides of your talk and ideally picking some things up. People sometimes get worried when I'll go into a watch a talk or I'll ask them questions about like, oh God, are you about to take me for a drag in the internet? It's, well, you are not a named executive of a trillion dollar company. So no, I'm actually here to learn. Thank you for the assumption, but no, I'm not here to make people regret showing me something.

Well, you can come to mine. I won't be scared. You can live tweet it if you want. Excellent. There we go. If I make, if I find myself in Italy in a couple of months, I'll definitely do that. And if some people won't be, where else can they go to learn more about what you're up to? Where can they find you? Sure. I am on LinkedIn, just as my full name. I'm also pretty active on Twitter slash X these days too. Just Twitter. We're just calling it Twitter. I will, I'm not a believer in dead naming except when it comes to companies. I am on board with that. I've not changed the name of my bookmark on my phone. Yes, I am on Twitter at k4alt95. And I will hopefully be at some summits this year, some user groups for sure.

So I will be at our AWS Portsmouth user group, as well as helping out with the AWS user group in Belfast, Northern Ireland too. I travel quite a bit. So hopefully I'll be in a city near you. And we will, of course, put links to this in the show notes. Thank you so much for taking the time to speak with me. I appreciate it. Thanks so much for having me, Corey. Christy Peralt, Principal Software Engineer at Liberty Mutual Insurance. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you enjoyed this podcast, please leave a five-star review on your podcast platform of choice.

Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment, which will never make its way to me, because whoever built that platform knew everything about how to write podcast platforms, but had never heard of what a database was.