❗️ By the end of today, you will learn the easiest way to deploy a Lambda function to API Gateway and how to ELIMINATE cold starts. I got the idea for this video when I watched Ben Awad’s “Serverless Doesn’t Make Sense” video and realized that his problems with serverless are very common.
Hey, Ben, you made a video about why you're not making the switch to Cervalis and you stated your pain points, so I took five minutes poring over my code and then the next 10 weeks configuring API Gateway. And you're provisioning functions to make sure they're warm, that you're kind of just missing the whole point behind Serverless. I'm over here thinking on a whole nother level. You know what I want? I'll tell you what I want. This is this is big brain time, OK? I want my serverless functions to never cold start, not even once. I feel like dismissing Serverless is like getting mad at a Tesla for not being able to open the door. Cervalis can be difficult to get it first, but just give me ten minutes and I'll open the door for you. I'll just ask one thing. If this video helps Serverless make more sense for you when you share with your community so it can make more sense for them to bend. You made some great points. And as someone who works with Serverless in my career, I'm going to show you some industry standard solutions to the pain points that you and many others feel. So I took five minutes poring over my code and then the next ten weeks configuring API, Gateway, Dash Space, HTP, Colen and Tab Path Hello Path Method. And it's going to be a method Cervalis deploy and then it's that easy provisioning functions to make sure they're warm, that you're kind of just missing. The whole point behind Serverless is going to cost us one hundred thirty nine bucks with the provision concurrency. You can see this is going to come in at a whopping 69 cents and you can just see where that cost saving is because now you're not worried about well, do I provision one hundred or one hundred twenty five, you can just go ahead and provision really as much as you want, because the cost of calling a lambda is just so darn cheap. I'm over here thinking on a whole nother level. You know what I want. I'll tell you what I want. This is this is big brain time, OK? I want my services functions to never cold start, not even once. For the vast majority of use cases, you won't have to worry about a cold staff, not even one. I should introduce myself. I'm doing a cloud engineer living in Oregon. I work every day with companies large and small to address their computing needs, and many times Serverless is the best option. If you say no to Serverless, you're going to spend a lot of time managing your infrastructure and many times you're going to pay a lot more for little to no performance gains. In just a second, I'll show you how to use Serverless framework to make a lambda function connected to API Gateway with a callable endpoint and not ten weeks, but in a couple of minutes and I'll show you how to get rid of cold starts using a plugin from the Serverless framework. No more crystalized honey for you. For those new to the concept of cold starts, lambda functions run inside of a container and it takes some time for that container to get up and running before your code can run. Cold starts are the extra time it takes to get the container up and running before the actual function code executes. The container will terminate after roughly 45 to 60 minutes of remaining idle, according to a study done by a cloud guru. And so the theory is, as long as that container is running, you're going to have much quicker response times. Let's address that first pain point of getting Lambda connected to API Gateway without any outside tools. There's a lot to take into account. However, Serverless framework makes this a breeze. Instead of spinning your head in the US can so you can use the Serverless yaml file to declare your RWC infrastructure in just a few lines of code. Let me show you. Here I am in a new LVS code project and what we are going to do is use the Serverless framework to build our lambda function and API endpoint. So what you're going to do if you've never used the serverless framework. Plus don't forget the AI, we're going to type in NPM. If you've never used a Serverless framework, you're going to type in NPM, install SERVERLESS and then throw a dash on there if you have never done this before. I've already installed this, so I'm already done here. So I'm just going to skip the step. And then what we're going to do to make a new project is we're going to do serverless, create, dash, dash, template, A.W., Node, JSW. And this is going to do is scaffolded out a premade project for us. And you can see in this top left we have three files get ignore a Handler Digest's, which is where our function code is going to go. And then below it we have our list on YAML code and this is what's referred to as infrastructure is code, where in just a couple lines we're going to declare an API gateway and at an end point to it. Let me show you how that works. You can see it here, some options of what you can do. And down here we have our functions. It's called the Hello function and its handler. Hello. If we go over here, you'll you'll notice in our handler file, this is the helo function. So we're just going to keep it at that. You can rename it if you want. And what we're going to do below this is we're going to add in API gateway endpoint to this so we can call it. So what we're going to do is we're going to say events call tab HTP weps, you need a dash space, HTP Colen and Tab path. And we're going to call this the hello path. And under that, we're going to call it the method and it's going to be a get method. And that C, we're going to need to also throw a slash on that. And one thing you'll notice is the YAML can be a little fussy with spacing. So if you're getting errors, that's probably the reason you actually need to have a tab. Under this HTP, we can go back and do anything we want to this lambda function, we can put any code, but we're just going to put Dillons out lambed for then woohoo! Awesome. And you know, you said ten years. It's such a headache and I agree with you before something like this is would have taken, you know, upwards of ten minutes, if not an hour. If it's the first couple of times you're doing this. Let me tell you what we're about to serverless deploy and then it's that easy. That easy, really. OK, we can see that now. In fact, we do have this endpoint and this is a live end point. I'm going to click on it. I'm going to open it, and I'm going to drop this screen and bring this bad boy over Dillons Lamda for Ben. We're going to rerun that. Great. And you rightly mentioned that provision. Concurrency defeats the idea of Serverless. If you're new to the idea provision, concurrency means you have a certain number of lambda functions warmed up and ready to call at any time. And I agree that provision concurrency defeats the idea of serverless, mainly because it's expensive and you're still left guessing your traffic load. You don't want to provision more than you have to, so you'll still likely get cold starts in the event of a traffic spike. This is where the plug in I was talking about comes in. It'll keep functions warmed up for a substantially lower price and lambdas built in provision concurrency. This allows you to give yourself many more provision functions than you actually need, which will allow you to not have to guess and still be able to handle the vast majority of large traffic spikes. If you have a workload that's too large for what I'm about to show you, that sweet koronakis cluster that you mentioned in your video is going to be your best bet anyways, but it's going to cost you a lot. All right. So let's just break down some pricing here. So what we're going to do is we're not going to include the free tier just to give us a very transparent picture of prices. So originally with provision concurrency, then this is where I think you had a great point in that you're left guessing how much traffic is going to be on your website because you want to know how many lambda functions to have warm. And so let's say you want to guess one hundred time for which it is enabled, how many hours, let's say, oh, let's see how many hours are in a month. Let's say twenty four times thirty one. That's seven hundred forty four. So let's say we want to do a whole month of provision concurrency number of requests for provision concurrency. That's put it at five hundred thousand for you know, a load with one hundred provision concurrency. That's very reasonable duration for each request. That's put it at one hundred amount of memory. We're going to just say this is a simple function at 128 and we're going to see this is going to cost us one hundred thirty nine bucks with the provision concurrency. And now we're going to compare that to the price of the server. This plug in, which is not using HWC, is built in concurrency, but what it is, is just using normal function calls. But by the act of calling them all at once, it's warming up all those containers. And so how we're going to calculate this is the serverless plug in cause once every five minutes. And so let's say we want to do the same thing. We want to have 100 concurrency every five minutes. And so if we go over here, I'll bring the calculator and pitcher, if we clear this, we say, OK, five minutes times 100 concurrency, five times twelve is sixty. So that means this is going to happen 12 times in an hour, is going to happen 24 times in a day and then 31 times in a month. So that's going to be four hundred forty six thousand calls. So we're going to copy that normal number of requests. It is going to be this many. The duration is going to be one hundred, not a memory one twenty eight. And we're going to show calculations. And you can see this is going to come in at a whopping 69 cents. And you can just see where that cost saving is because now you're not worried about well, do I provision one hundred or one hundred twenty five. You can just go ahead and prevision really as much as you want, because the cost of calling a lambda is just so darn cheap. So and then if we want to go and compare that to the Cuban êtes cluster you were talking about, we can go over and check that out. OK, so here we are. We're going to go to our Cuber Nettie's. Cluster. So I'm going to configure it, I'm just going to say one cluster and this is going to be for the month just to do a cluster. It's going to cost you seventy three dollars. And keep in mind, this is not even including the two instances, because I think there's so much variation in the two pricing. I'm not even going to try, but just know that you haven't even started to pay for compute yet. And so when you start to consider pricing options for so many use cases, this serverless plug in, warm up with the lambdas is going to be the best solution. Now, to take care of cold starts, we're going to do is we're going to add the serverless, plug in, warm up, plug in, and we're going to add 10 concurrent lambda functions warm and ready to go to handle any requests coming in. So what we need to do is install NPM, install server lists like in warm up. And this is going to install the plug in. And once we do that, the next step is to just fill out our YAML file so it configures our infrastructure properly. So what we're going to have to do is we're going to have to start by adding in AYAM statement and this is going to allow Serverless plug in to operate on our HWC account. So now that we have that, we need to let it know that we are using a plug in. So we'll add that in. If you're following along and you're getting the errors, just make sure to double check any, any spaces you're using. That's almost always going to be the issue. OK, so now what we need to do is add a is declare our warmup function. So we're going to set custom and this is on the documentation for the plug in. If you're wondering where this is coming from, great. OK, and now our last step is to add the warm up to our function. So under events, we're going to say warm up, we're going to go the default enabled. True. And we're going to say concurrency. And this is the important part we're going to put to ten. And this is saying how many functions we want to have warm at any given time. And after we've done all of that, we are going to deploy it. So we're going to say server the ploy and away we go will be right back once it deploys. Cool. OK, so we are deployed now. Let's go check out the ABC console to see what we have. And we're going to see there that we had ten concurrent executions. We see right there. We had ten avocations. And so that's a good sign that's showing that, you know, there is, in fact, ten different functions being warmed up. And there you have it. Sure, it may not be best for the twenty five thousand users at once production workload, but for the vast majority of use cases, you won't have to worry about a cold staff, not even one drop any questions in the comments. And I'll do my best to quickly get back to you. If you want to learn more about technology that enables business, start right now by subscribing and clicking the bell so we can learn together. Have a great day and we'll see you next time.