Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Common Mistakes with Serverless
10 Plays1 year ago
In this episode of the Basement Programmer Podcast I interview Serverless Specialist Solutions Architect Adam Wagner about common mistakes that customers make when adopting serverless technologies.
Recommended
Transcript
Introduction and Podcast Overview
00:00:11
Speaker
Hello basement programmers and welcome. This is the basement programmer podcast. I'm your host, Tom Moore. The opinions expressed in the basement programmer podcast are those of myself and any guests that I may have and are not necessarily those of our employers or organizations we may be associated with.
00:00:28
Speaker
Feedback in the Basement Programmer podcast, including suggestions on things you'd like to hear about, can be emailed to me at tom at basementprogrammer.com. And I'm always on the lookout for people who would like to come on the podcast and talk about anything technology related. So drop me a line. And now for this episode.
Guest Introduction: Adam Wagner
00:00:46
Speaker
This month, I'm joined by my guest and one of my favorite Amazonians, Adam Wagner.
00:00:52
Speaker
Serverless Specialists for Amazon Web Services. We're going to talk about some of the common mistakes people make with Serverless technologies. Adam, welcome to the Basement Programmer podcast. Thanks, Tom. Glad to be here. So, Adam, let's start off with an easy question.
What is Serverless Technology?
00:01:10
Speaker
What is Serverless? Yeah.
00:01:14
Speaker
These days, it feels like it's a little bit of a changing definition, but basically, if you think about what you take in responsibility for managing your infrastructure in the cloud, and think about what AWS manages for you, and dial that knob so that AWS manages basically as much as they can, that's serverless.
00:01:40
Speaker
So if you think about a service like Lambda, which is a serverless compute, we're handling the scalability, right? So you call Lambda once, it runs once, call Lambda a thousand times, it runs a thousand times. We handle the availability, so you don't need to think about you're spreading your Lambda functions across multiple availability zones. We take care of that for you. You don't, the kind of,
00:02:10
Speaker
of what part of security that's managed by you is kind of higher up the stack. So if you think about things like operating system patches, things like that, again, that's AWS is responsibility, not yours. And then lastly, it's really paper value. So I think of it as services where, you know,
00:02:34
Speaker
we're really directly tying the cost to when you're actually using it. So for something like Lambda or API gateway, there's no idle costs associated with it. If you're not serving requests, you're not paying for it. So that's sort of like my definition of serverless.
00:02:53
Speaker
There are definitely some AWS services that have been launched more recently that stretch that a little bit. So there's some of the newer kind of serverless database services and things like that do have sort of like a minimum idle cost. And then that cost kind of scales with usage. So not everything that's labeled serverless is kind of like tightly fit in there, but that's the general idea. And there are still servers.
00:03:23
Speaker
holding up to serverless stuff, correct? There's definitely still servers, but the idea is that, you know, you don't have to think about them. So your job is to be a serverless specialist. What does that really mean?
Adam's Role and Responsibilities at AWS
00:03:38
Speaker
Yeah, so it's, I want you to see, great, it's the best job at AWS. I really kind of believe that. If you're kind of into serverless and you're a serverless nerd,
00:03:53
Speaker
It's just the best. It's great. But basically, what it means is that I spend my day trying to think about how to help as many customers as possible with our serverless services. And for me, that definition of what those services are, we're talking API gateway, lambda, step functions, event bridge, SNS, SQS,
00:04:23
Speaker
are kind of the main ones there. And so that can take a bunch of different forms. Sometimes I'm talking directly with customers, which I love to do. But there's kind of only one of me for the whole East Coast. And so I don't scale very well if all I do is talk one-on-one to customers.
00:04:48
Speaker
customer can't get to them all. Um, so then I also do things like, uh, things that we refer to as like thought leadership activities. So that's things like speaking at reinvent, doing webinars, helping to make our docs better, helping to write blog posts, write example code, things that people can consume and, you know, without having to talk directly to me that kind of really helps scale. Um, so that's another facet of it.
00:05:17
Speaker
Another facet is working directly with our service teams to help make our products better. So I'm out there talking with a lot of customers, a lot of kind of leading edge customers that are really kind of pushing our products. And so I'm taking that feedback back to our product teams, suggesting features, talking through, you know, use cases and how we can make things better.
00:05:44
Speaker
And also helping kind of with the launch of new features too, which is really, really fun. And then lastly, there's a whole lot of solution architects and other customer facing people within AWS. And so I'm also always trying to like just help raise the general knowledge level around serverless. So I'm doing a lot of kind of internal presentations and internal trainings to help
00:06:13
Speaker
like scale up our customer facing folks on all those serverless services. I love your answer. I love serverless, but I got to disagree with you on one part. Being a.NET developer advocate is the best job at AWS. It does sound pretty good as well, admittedly. I mean, for me as like a mostly Python nerd, it would be a very difficult job, but it does also sound fun.
Challenges and Best Practices in Serverless
00:06:44
Speaker
So how is the serverless programming different to traditional programming? Yeah. So I think the core business logic that you write is generally the same. You don't have to use a special programming language or a specific framework. You're well aware.
00:07:13
Speaker
.NET fully supported. So you can bring your .NET code, run it in Lambda, support for really all the popular languages, and then you can bring your own. But there's definitely some things that are different when you think about designing your application. One of them is that
00:07:35
Speaker
most of the serverless components are stateless. So things like a Lambda function has no state. And so if you need to persist state, you need to put that in some sort of an external store. The other interesting thing that comes up a lot is things like API gateway and Lambda scale really, really easily.
00:07:59
Speaker
But sometimes the system that you're talking to from Lambda can't scale to the same degree. And so it's easy to create these kind of new front ends with API Gateway and Lambda that if you have a big scaling event will overwhelm some legacy backend that just can't scale to that same degree. So that's another thing that you want to think about. I would say the other thing is very often
00:08:27
Speaker
as you learn more and more about the different serverless services, basically, you can just have less code. Even an application that someone might have written using Lambda four years ago, three years ago, even two years ago, there's now a lot of native integrations with other AWS services where you might be able to remove a whole bunch of that Lambda code.
00:08:57
Speaker
like step functions comes to mind here, your step functions, really cool serverless workflow orchestration. And in the past, if you wanted to talk to an AWS service, there were a few services that had built-in integrations with step functions.
00:09:15
Speaker
Other services, you'd call a Lambda from Step Functions, and that Lambda would call out to, maybe you want to do some machine learning on an image, like label all the things that are in there, call Amazon Recognition. In the past, you needed a Lambda function to do that. Now, Step Functions, you can call any of the AWS DKs directly from Step Functions. And so if you're not doing any real business logic, you're not doing any heavy transformation,
00:09:43
Speaker
You don't need that Lambda function anymore. You can do it directly from step functions. And so there's like that concept of retiring some of your code and just moving into configuration. And so I think that's kind of some of what makes it different. I think I've written some of those Lambda functions that do nothing other than just say, put this here. So basically, I shouldn't just take my ASP.NET web server and throw it into a Lambda.
00:10:13
Speaker
So this is a funny, this is like an interesting concept, sort of like the idea of sort of like lifting and shifting like an app kind of into Lambda. I think in the past, people would just say no, right? Like, no, definitely don't do that, right? That's not the way Lambda should be. Lambda should be like single purpose microservices, one per Lambda, and do it that way.
00:10:43
Speaker
And that way it works great, like build granular microservices with Lambda. It works really well. If you're going to rapidly iterate on your application, you anticipate different services being owned by different teams eventually, probably makes sense. But maybe that .NET web server, that .NET web app that you have, maybe it does just a few things. Maybe it's not going to change very much.
00:11:12
Speaker
And it doesn't, you know, you just want to kind of lift it and shift it. There is a way, there's a great project by Harold, one of my colleagues, another serverless specialist essay out of China that basically allows you to do just that. So you can take basically any framework that expects a web request, put it inside this Lambda web adapter, and then run it as a Lambda function, and it'll just work.
00:11:40
Speaker
And like I said, if you're looking to modernize that web application, break it up into more microservices, that might not be the way to go long-term, but it might be how you start. And so I've actually become much more okay with almost these monolith lambda functions. I think they have their place. And sometimes that's all you need.
00:12:06
Speaker
Yeah, but you might not have been the answer you expected, but I would say, sure, try it, lift it and shift it, why not? That's great. So what kind of things are best suited to serverless? Yeah, yeah, get this question a lot in terms of, you know, like, what's the sweet spot? Where does this fit, you know, really well? And I'm obviously biased, right? Like, I looked at any
00:12:34
Speaker
business problem and I'm like, yeah, you solved that with serverless. Let me grab my bag full of step functions and grab my other bag full of Lambda functions and we'll just get this done. But there's really like lots and lots of different things that work well in serverless. I think some of the areas that work really well are things that have sort of
00:13:02
Speaker
unpredictable load, right? Like things that sit idle for five minutes, 10 minutes, and then you need to spin up a whole bunch of requests. Then it goes back to being idle. Um, those sort of things work really, really well, uh, in serverless. And then, uh, you know, I mentioned step functions a few times, but like anything where you're trying to orchestrate other things that are happening in AWS and you don't already have
00:13:31
Speaker
a tool to handle the orchestration, reach for step functions. There's other AWS tools that are more specific. If you're doing ETL processing, very often you reach for Glue, and Glue is very specific to ETL processing, works really well. But you might have something where you're like, well, I need to make a few API calls,
00:14:00
Speaker
I need to do these few other things. And then I need to kick off that glue job. It's like, Oh, well, yeah, like wrap that step function. It'll work great. Uh, step functions are also really great. Anytime you have, uh, you know, I talk with folks a lot who are kind of like automating a business process and it's like really easy for them to get to like 90% automation.
00:14:23
Speaker
But there's this 10% where they need a human element. It might be like you're running machine learning on something to see whether or not your machine learning algorithm says this should be approved. And it has a confidence interval. And if the confidence isn't high enough, you want to have a human reviewer.
00:14:41
Speaker
that type of workflow, super easy to build up in step functions. And like, again, the serverless pay for value, like step functions, when you like put a call out, when I send an approval over to Tom to say, Tom, you know, decide whether to approve this loan or not, while it's waiting for you to send back that approval, you're not paying for anything. There's no idle cost and step functions while we're waiting for that response back. And you don't
00:15:10
Speaker
have to worry about the scaling, right? If there's like five of those loan applications going on, there's five of those stuff functions running. There's 500, there's 500, right? Like it just scales. And so those are just a few of the places where it works really well. One other one that I'll plug, because it's one of my favorites.
00:15:32
Speaker
Um, is, uh, serverless stream processing. So, um, you know, Kinesis and AWS is like a streaming data product. Um, you also have Kafka, right? Open source tool. You can run it in AWS and a managed version with MSK managed streaming for Kafka and also run it with our partners and confluent. And whether you're managing it yourself, running it on EC2.
00:15:57
Speaker
or you're running it in MSK or you're running it in Confluent, either way you can hook up a Lambda function to be triggered when there's new messages in that topic. And I think this is great because when you see Kafka in an enterprise today, very often it's in the past, like there would be an analytics group and you would have people who really knew streaming analytics, they're writing Flink jobs, they're doing,
00:16:25
Speaker
pretty, pretty fancy specific streaming things. Nowadays, often all the kind of enterprise events are living on Kafka. And so you have just, you know, kind of normal like me programmers that need to consume these events. They're not experts in streaming data. They don't want to go learn a new framework like Flink or Spark streaming or things like that. They just want to execute their business logic.
00:16:49
Speaker
when a certain event comes over the wire, and Lambda makes it super easy to do that. So I think that's another use case that I'm really excited about. I talk with a lot of customers about that one. It's a lot of fun. Fun fact, Adam actually introduced me to Kinesis about six and a half years ago, giving me my first crash course in the service back in Cambridge. Tom and I go back a little ways. Yeah, good times.
00:17:20
Speaker
So Adam, let's talk about the top kind of mistakes that people make when it comes to serverless. What are some of those? Yeah, yeah. You know, I think I don't want to make it like serverless is hard to use because I don't think it is. But there is a little bit of a learning curve and hopefully kind of talking about some mistakes that we see can kind of help people avoid them. I would say the first one
00:17:50
Speaker
is not sizing lambda functions correctly. So when you create a lambda function, one of the knobs available for you to turn is how much memory is assigned to that function. By default, it only has 128 megabytes assigned to it. And you can crank that knob all the way up to 10 gigabytes. When you increase the memory,
00:18:18
Speaker
you also increase the CPU performance and the networking performance. So often, folks will run their code, set up this Lambda function. They run it at that default value of 128. You get a little printout in the log line that says what the max amount of memory is that the function used. And they'll see like, oh, it only used 80 megabytes. I'm good. I don't need to adjust that Lambda function at all.
00:18:48
Speaker
Very often the best kind of price performance trade-off is at a higher amount of memory. And I say price performance because remember Lambda is pay per value. So you're paying basically by the gigabyte millisecond. And so if I have 128 megabyte Lambda function and it takes one second to run and I quadruple the amount of memory,
00:19:18
Speaker
And it runs in 100 milliseconds. Not only is it going to run faster or my user is going to be happier, but it's actually cheaper too. And so there's a great utility out there called AWS Lambda Power Tuning that basically you feed it your Lambda function and a test payload, and it will run your Lambda function for you at a whole bunch of different memory configurations.
00:19:45
Speaker
spit out a very nice graph that shows that price performance that I'm talking about. So that's one that I think a lot of people could benefit from basically tuning the amount of memory that you have assigned to your Lambda function.
00:20:03
Speaker
So Lambda, great, but it doesn't just magically fix that problem of trying to scale and everything else all by itself, right? Not yet. Hopefully someday. We'll see. There's also like AWS Compute Optimizer also kind of does this for you.
00:20:24
Speaker
Compute optimizer is like look back, right? So basically the Lambda function needs to run for a while and then compute optimizer will make suggestions for you. So AWS Lambda power tools is nice because you can kind of size it proactively, but the compute optimizer is another way to do it. So getting a little closer to setting these things up automatically. Great.
00:20:51
Speaker
Okay, so problem number one, or potentially issue number one, not sizing Lambda functions correctly. What's another issue that customers need to look at? Sure. Another gacha that I see is setting the Lambda timeout to a value that doesn't match
00:21:16
Speaker
the integration, the trigger, the way that you're running that Lambda function. Lambda doesn't have that many knobs for you to change, but another one of them is the timeout for the Lambda function. Lambda functions can run up to a maximum of 15 minutes for a single Lambda execution, but you can dial that down
00:21:41
Speaker
to whatever you want. So you can dial it down. By default, I think it's three seconds. And so you can dial that down to what you want it to be. But there's some Lambda integrations that have their own timeouts. And today, we don't do a great job of letting you know when you have a mismatch. So the classic example here is API gateway calling a Lambda function
00:22:09
Speaker
as the backend for an API call. API gateway has a 30 second timeout on backend responses. And so if you have your API gateway calling a Lambda function and that Lambda function has a minute long timeout, your API gateway is gonna return an error to the user that's calling that API gateway. Your Lambda function is just gonna keep running, right? Like it just keeps running and you look in your Lambda logs
00:22:38
Speaker
And Lambda is like, I'm doing great. I ran awesome. You know? Um, and so that like, that's a, that's one to look out for. Um, similarly with AWS step functions, step functions has two variants, standard workflows, which are good for like long running workflows and express workflows, which are good for like high volume, but short lived workflows.
00:23:03
Speaker
those express workflows have a max runtime of five minutes. So again, if you're calling a Lambda function from within that express workflow, you want to make sure that the timeout on the Lambda function is short enough that it's going to fit within that five minute window within your express workflow. That's great advice. And I've seen the
00:23:30
Speaker
Yeah, the timeout issue a couple of times, and customers think that because Lambda can run for 15 minutes, it should run for 15 minutes. Yeah, that's another good point, right? So sometimes in development, folks will just kind of crank up that timeout all the way to 15 minutes. And maybe what you're doing actually does potentially need all of that time.
00:23:59
Speaker
But maybe it doesn't. And so if there's a possibility of your Lambda function getting in some sort of loop or running away, it can be a good safeguard to have that time out much closer to what you actually think the runtime of the function should be. Another thing that I've seen customers do with that 15 minutes is they'll think, well, I'm going to implement retry logic and error handling.
00:24:28
Speaker
inside of my lambda function? And what do you think about that? Yeah, I mean, that really kind of depends on the use case, right? I think sometimes you do want to fail fast rather than doing that sort of timeout, that sort of retry and kind of doing more of those retries within lambda. Sometimes
00:24:55
Speaker
some retries in Lambda make a lot of sense. Um, you know, I just wouldn't go kind of too overboard with it. Um, and like, especially if you're starting to think about kind of like longer wait times and timeouts, you don't want to be, you don't want to be sleeping for two or three seconds in a Lambda function before calling something again. You're just, you're just kind of wasting money at that point, right? Like we don't, we don't want sleeps in our, our Lambda functions.
00:25:25
Speaker
So I often think about moving the kind of retry logic a little higher, right? So if a step function is calling that lambda function, put the retry logic in that state within the step function, not in the lambda function itself. Great advice.
00:25:44
Speaker
Let's see, do you have another pitfall for us? Yeah, I would say maybe my final one would be like Lambda functions calling other Lambda functions. Sometimes I see customers start to tackle a problem and they realize they have a few different things that all need to happen.
00:26:10
Speaker
maybe kind of in parallel and They create like one lambda function that calls three other lambda functions and it's like the Coordination between those and the problem there is that that first lambda function that's being that coordinator It means you sort of double pay while those other lambdas are running right so it's calling and
00:26:34
Speaker
Lambda function A, your coordinator, calls Lambda function B and calls Lambda function C and it's waiting for that response to come back. And so you're paying not just for Lambda function B and Lambda function C, but Lambda function A is sitting there running that whole time to, you know, waiting for those to finish. That type of use case is a
00:26:54
Speaker
perfect fit for step functions. And so kind of whenever I see that type of pattern where people have lambda functions, calling other lambda functions, kind of chaining them together, I often encourage people to take a look at step functions. Great advice. Let's see.
00:27:20
Speaker
So let's say you've got a customer who's gone down this road. They've made a whole bunch of these different, stumbled into a bunch of these different pitfalls. How do you help them to kind of unwind the string and get to a more optimal situation? Yeah. Yeah. I try not to be too, too like ideological about it, right? So, you know, like Lambda functions, calling other Lambda functions, there is this kind of better way to do it most of the time.
00:27:51
Speaker
But if I'm talking to a customer about that and cost isn't an issue and the maintenance of the current solution isn't a problem, then I'm not going to harp on it to go and change it if it's working well for them. So I really want to start with where their pain points are and help from there.
00:28:17
Speaker
If a customer has that type of architecture and the issue is that their costs are growing too high, then I absolutely want to look at that and see that as a way to fix it.
00:28:32
Speaker
And so in that case, if that customer, if cost was their main concern, I would look at kind of combining a couple of those things that I talked about. So I would both look at like, okay, let's replace that orchestration with a step function. And so now you're not kind of double paying for the Lambda.
00:28:52
Speaker
and then let's optimize your Lambda functions using AWS Lambda power tuning to make sure they're sized at the optimal size to get the best price performance that you can. Another tool in the toolbox in the price performance space is looking at running the Lambda function on Graviton processors instead of x86.
00:29:19
Speaker
So Graviton are the AWS ARM-based processors, and you have an option with Lambda to kind of toggle between x86 and ARM. If you're using an interpreted language like Python, very often you don't have to change anything, easy to kind of do it. If you're using a compiled language, a little more work to do, but there's actually a really great utility that just launched that's called the
00:29:48
Speaker
I think it's called the Graviton Porting Advisor. It's like a CLI tool that helps look at your code and make suggestions for porting from x86 to Graviton. But yeah, moving to the Graviton-based processors for most workloads gets you a price performance boost. So that's another thing you could look at there.
00:30:16
Speaker
So Adam, you've been interested in serverless. Well, as long as I've known you, thinking back over your time at AWS, what's the most fun you've had working on a serverless project? Oh, oh man. There's so many good ones to choose from. I like, I like high scale. And so
Adam's High-Scale Project Experiences and Interests
00:30:44
Speaker
I've gotten to talk with some car companies, some automobile manufacturers about like IOT use cases where you're getting data from hundreds of thousands of cars, maybe not that many, but yeah, tens of thousands of cars, lots and lots of data coming in into Kinesis data streams and then processing that with Lambda.
00:31:12
Speaker
And just talking through kind of the performance of that system, the scale of that system was, was super fun. So that's, that's one that was really cool. Let's see what other ones, what other good ones have I seen? That one's, that was one of my favorites, but yeah, lots, lots of great use cases. I had one that I really enjoyed.
00:31:39
Speaker
Um, that there's, there's actually kind of a public case study about is Liberty mutual, um, replaced their, uh, basically like document management system with a homegrown AWS document management system. And basically like they moved from a commercial product to this home built thing on AWS.
00:32:01
Speaker
their costs dropped just dramatically, you know, something like $30,000 a year to $2,000 a year or something like that. Um, and, uh, performance was great. And, uh, yeah, that was, that was a cool one just because that team, that team built it in a relatively short amount of time to.
00:32:23
Speaker
And yeah, just really impressive kind of impact for their business, making things easier for people to manage these documents, getting a system that is really customized to them all at a cheaper price. So that was cool. That was a great result. Yeah. So just for fun, if you weren't an AWS solutions architect, what would you be? Oh, man. It's a good question. I mean,
00:32:52
Speaker
You know, I think, uh, if, if I was going to walk away from computers forever, I think I'd probably, um, I'm still sort of like a builder at heart. So maybe I'd make furniture. Uh, I like, like building stuff out of wood. I'm not very good at it. So it'd be hard for me to do right now, but I think that'd be really fun. So not the professional bike racer. Uh, again, I mean, that sounds like it would be super fun. I'm just, I'm just not good enough.
00:33:24
Speaker
Someone wants you to take me to race bikes and finish last all the time. I'm all for it. I'll do it. All righty, Adam. It has been an absolute pleasure having you on the Basement Program or podcast. Hopefully I can have you back again sometime, maybe talking about new features or launches.
Conclusion and Listener Engagement
00:33:41
Speaker
Yeah, that'd be great.
00:33:43
Speaker
Thanks for listening to this episode of the Basement Programmer Podcast. I really appreciate you tuning in, and if you have any feedback or comments, of course, send me an email. Also, please consider subscribing. It lets me know that you're enjoying this production. I'm looking forward to you joining me for the next episode of the Basement Programmer Podcast. In the meantime, take care, stay safe, and keep learning.