Build Go Apps That Scale on AWS

Understanding Lambdas



Build Go Apps That Scale on AWS

Check out a free preview of the full Build Go Apps That Scale on AWS course

The "Understanding Lambdas" Lesson is part of the full, Build Go Apps That Scale on AWS course featured in this preview video. Here's what you'd learn in this lesson:

Melkey introduces Lambdas, serverless functions that can execute code in the cloud and be invoked by events. An advantage of serverless Lambdas is scalability. When there's an increase in traffic to an application, the underlying infrastructure is already prepared to scale.


Transcript from the "Understanding Lambdas" Lesson

>> So with that being said, I'm gonna just remove all this cuz I think it looks kind of ugly. I'm gonna keep the nil, we're gonna just keep it as returning a nil, okay? Cool. And with all that being said, we are gonna do the majority of our development in this single function, in this new go CDK stack.

I'm gonna go ahead and uncomment this. I'm gonna keep it, not delete it, cuz we're gonna reference it when we first deploy our very first resource, which is gonna be a Lambda, okay? Now all that, I want us to go into our terminal and I want you to make a new directory called Lambda.

I want you to cd into Lambda, I'm gonna do a go mod in it. Go mod in it, and you can call this whatever you want, I'm gonna call mine Lambda dash func, okay? You can see here on your Lambda directory, this new go dot mod file. We already know what these are.

I'm gonna inside that Lambda directory we're gonna touch main.go. There you go. All right? And like we've already practiced package main, func main. Create a skeleton for us, right? So what is this? What is this directory? Well, this is basically our back end. This Lambda directory is where we're gonna house and define all the backend logic that we're going to need for our application, okay?

And this is gonna be then packaged and zipped and deployed to our Lambda function. All right, so let's see. What I would like to actually start with is, Let's go ahead and talk about what is a Lambda in the first place. So what is an AWS Lambda? I've said this maybe a few times now.

I haven't really given it the justice of explaining what it is, but an AWS Lambda is a serverless compute service that triggers two events, okay? It automatically manages a lot of things first, like computing, scaling, and all those kind of details. So when I say serverless, do I mean there's a new hidden technology concept that you can run code without on a server?

No, because it's still on a server that's own a AWS, but it goes even further than that. Serverless basically means it's abstracting a lot of the server management core principles that you would have to be responsible for in a server-based architecture. So talking to a few of you, we've had maybe like digital ocean droplets, we've had our own Linux kinda box that we've deployed code to, etc.

We have to manage a lot of the stuff there, right? Like scaling, Nginx, all this stuff we kind of have to manage when we have a server-based architecture, right? It's more than just deploy code, there's a little bit more granularity there. In serverless, you don't have to worry about that serverless scales for you.

And why that's important is like most of our applications, we have no users, all right? So it doesn't really matter. But let's say one day you have something deployed in a server-based architecture and it pops off. It goes from zero users to 1,000,10,000, where you did not facilitate your architecture to handle that traffic.

So what happens? Well, now you risk that your users are gonna have a poor experience. They might even hit your code. You might have panics, you might have stuff that just doesn't run. Serverless, you never have to kind of think of the concept of scaling, because the way serverless works and the way a Lambda works, it only runs when it's invoked, and it handles the scaling for us.

Server-based architecture, you basically have something running all the time. Unless by design, choose to run it down, or spin it back up. Typically, it's constantly running. It's a server deployed somewhere, that's doing some logic all the time, 24/7. Server list, that's not the case. Serverless architecture basically drops down to, it's just a function that's invoked.

That's all it is. And these invocations can come from S3 events, DynamoDB events, things called Kinesis, SNS events, or just users invoking the endpoint. And once that endpoint is invoked, that's when it starts to function, okay? So it speeds everything up in calls to function. That's all AWS Lambda is in a nutshell, okay?

And there's pros and cons to this. I'm not here to tell you server list based architecture is the way to go. Yes. Not having to worry about scaling and all these other things is very nice, but there comes at a cost, a literal cost. Lambda itself are very cheap.

You, me, all of us, we're gonna be doing this, we're not even, it's gonna be a fraction of a penny, okay? But again, if we use the example we scaled from one user to a 1,000, 10,000 invocations, our bill will also go up. So there's pros and cons to this to how you wanna develop and deploy your infrastructure.

Surveys have its pros and cons, serverless has their pros and cons, okay? And then our Lambda here after executing that function, has the capability of doing anything else in either AWS or wherever, right? It's just a function. So we can access different services in our example to access DynamoDB, right?

So we're gonna use our Lambda function, it's gonna be invoked, it's gonna do some logic, and it's gonna invoke our DynamoDB here. So the less deployments are a little more manageable in a sense. Again, if you use VS code, they use ad with Lambdas in their pipelines as well.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now