Deploying Lambdas on AWS

[00:00:01]
>> Scott Moss: In this next lesson, we're going to go ahead and deploy all of this stuff to AWS, and walk through what that actually means. What's different on AWS other than what we already talked about. And how to do things like environment variables, and looking at logs, and debugging.

[00:00:20]
And things like that and just kind of get a kind of sense of what a lambda function looks like and what it means. Before we start, are there any questions of the previous lessons, when we rushed off to lunch, that I might not have answered?
>> Scott Moss: All right, well, let's hop right into it.

[00:00:37]
So there's not another branch for this because you don't really have to change a lot of code for this one because we're mostly deploying. But I'm just going to deploy this and then we're going to walk through some stuff. So first things first is talking about a couple of ways you can deploy using the Serverless framework.

[00:00:54]
If we go look at the terminal here, just type in sls, and we go to help, you can also look at the docs for this, there's a few things to note.
>> Scott Moss: One is the deploy function and you can see right there it says deploy a Serverless service, so, what is a Serverless service?

[00:01:15]
Well, remember if you go back to our serverless.yml file, you will find a service is this. Basically, you can think of a service as pretty much every function that's going to be listed here, that's a service. You can have multiple services in one repo, you just put them in other folders.

[00:01:30]
And each one of those folders will have it's own serverless.yml file. So you can totally do that, I've tried that before, I don't think it works good, mostly just around like git. There's just issues with git and how that works. Because Serverless doesn't allow you to, if you want to run these serverless commands from your command line.

[00:01:48]
It's going to assume that you're in a directory that has a serverless.yml file. So if you have multiple folders with multiple serverless.yml files in them. You'll have to change directories into those folders from here just to be able to run the commands, and that gets annoying really fast.

[00:02:03]
So that's why I don't recommend doing that. So just group your functions together by a service, and then make another repo for another service it might be in. But you can put them all in the same repo with different folders, so back to deploy.
>> Scott Moss: If you just run service deploy, it's going to deploy that entire service, which means every function in that service.

[00:02:24]
But where does it deploy to, and how does it know to deploy? Well, let's talk about that. If you go back to provider, if you just get rid of these three things that I have here on mine. This will still deploy, that's because it has defaults, so I think I talked about this earlier.

[00:02:41]
But as far as the profile, it's just going to use the default profile in your AWS config which is on your computer. And if you don't have an AWS config, then you problably exported some variables, this is going to use those. It has a waterfall of fallbacks that it checks, but this is your chance to overwrite it.

[00:02:58]
And say, actually I want to you to use this AWS profile that I made, if you have one, mine is femasters. So if you don't have that, you probably need to comment that out or change it to whatever profile you did make if you made one at all.

[00:03:10]
If you just exported your variables in the Bash or whatever, you can just use that. You can also use environment variables inside this file using template language. I don't recommend doing that, it gets real sloppy, just don't do it, there's better systems for that. I don't think Serverless made a really good system for integrating environment variables into the yml file, so I try to avoid it.

[00:03:32]
The next thing is the region, by default, I believe Serverless defaults to US-EAST1, which is, what is that, is that Virginia, or is that US? Is that Virginia? Okay, yeah, so that defaults to Virginia, and then stage defaults to dev, and what is stage? Basically it allows you to stage your functions, so, just like if you had a server where you had staging, production.

[00:03:56]
And pull requests, whatever your stages are, you can add different stages to your functions too. So for each function, if I have one function and I have four different stages, then I would have four different functions on AWS. Four different, I don't want to say versions because you can actually do versions.

[00:04:12]
Four different stages for each one of those functions, if that makes sense? And they would have their own API gateways and everything, so that they're literally, copies of your functions. And then you can choose, depending on the name that you gave them, what you want to do with them.

[00:04:27]
And this stage variable is accessible inside that context object, inside your lambdas. So, inside your lambdas, you can determine what stage you're into and do different things. So there's a lot of interesting things you can do at that stage variable. Like, changing URLs, like we're in stage staging, so when I talk to this other API, I use the staging API URL instead.

[00:04:46]
So that's kind of where that comes in. It's really handy to be able to test your lambdas in production without having them override the production lambda. So that's what this is for, and by default it will default to dev, but again, you could override all of this, which is what I'm doing.

[00:05:04]
You can also override this on the command line too with flags, so once you've got those things, you can pretty much deploy this. So if you run deploy, it will deploy all of them, if you deploy a function, it will deploy just that one function. If you deploy a list, you can see right here, list-deployed version of your Serverless Service, just don't use this, [LAUGH].

[00:05:27]
And then a list of functions, lists all of the deployed functions and their versions. Basically what this is supposed to do, it's supposed to show you all the functions that are deployed in AWS. For some reason, this doesn't work for me, which is why I said I don't use it.

[00:05:40]
If anybody else can get it to work, that's fine, maybe I think I just have like a messed up version of Serverless, actually, yeah, I do. I forked Serverless and did some changes to it, so I'm far off from what, yeah, it might work for you. This doesn't work for me because I forked it and did some stuff because it was messed up, and I never went back.

[00:05:59]
But yeah, this just shows you all your, actually let's check, let me see if this works.
>> Scott Moss: Deploy.
>> Scott Moss: List.
>> Scott Moss: So this should show me the service that's deployed.
>> Scott Moss: Yeah, it looks like it's working now, okay, yeah, this wasn't working for me like a week ago, nice.

[00:06:20]
So this is so you're, like all the services that you deploy, this isn't really that helpful because, what does this mean to you? You didn't do a CloudFormation thing, you don't know what this is. So it's really not that useful but I would imagine list functions would be more useful.

[00:06:34]
Because it will actually show you the functions that you deploy, which for me, I don't have any functions deployed from this service. So that's why it's throwing me an error right now.
>> Scott Moss: All right, but the main one you will probably use is going to be deploy and sometimes deploy function.

[00:06:51]
And the difference is, again, deploy deploys everything, which is great if you just need to deploy everything. But if you only change one function, then don't go through trying to redeploy everything, just deploy that one function. And it is not that big of a deal right now because we don't have a build step with this repo.

[00:07:07]
But we use webpack for our lambda functions because we like to use the latest everything, and that has to build. And then webpack dedupes the node modules and bundles and optimizes, so it can take a long time. And then we have like ten functions plus and all we did was change one line and one function.

[00:07:22]
So, running sls deploy will do all of that again, zip it all up, and then just to really only override one function. So, yeah not really worth it, so, yeah you'll probably only use these two things, so, that's what I'm going to do now. I'm just going to go ahead and run sls deploy here, and the first time you deploy, it's going to take a long time.

[00:07:45]
And that's because it has to set up your CloudFormation stack. So whenever you do CloudFormation, which service is doing for you, it creates what's called a CloudFormation stack in AWS. Which is basically AWS taking that CloudFormation file and creating a text stack really of all the services that you need.

[00:08:05]
And it's going to create that stack for you, and it's going to keep it there on AWS. So the next time you deploy, it doesn't have to recreate all those resources. It just updates them based on the configuration that you gave it. It can detect changes, it does diffs and it knows what's different and what's not, but the first time it has to create all that from scratch.

[00:08:21]
So it can take a long time. So the things that Serverless is going to be telling CloudFormation to create are going to be things like log groups. ARNs for lambdas, IM users for execution, insider limbs, it's going to create a lot of things. We're using API gateway, so it's got to create that.

[00:08:40]
And really, depending on what you connected it to, it's going to create a lot of stuff, so it could take quite a while. So I'm just going to run this for now, and we're going to see what happens and how long this takes. I should have ran this before I talked so it'd be done by now.

[00:08:51]
>> Group: [LAUGH]
>> Scott Moss: [LAUGH] Because it could take a while, I mean, we only have two or three functions, so it's not so bad. But I've had deployments take ten minutes before, but basically you can see the process here. I didn't put verbose on it, you can do dash, dash, v, or dash, dash, verbose, or dash, v to see the verbose of what's happening.

[00:09:14]
The other thing you can do is, right here it's saying updating stack, checking stack progress. You can actually just go to AWS while all this is happening, and go to Services, go to CloudFormation. And you should be able to see this happening in real time as it's updating.

[00:09:29]
And you can see it right there, mine is, Update In Progress, so it's actually updating this right now. And then, yeah, I guess I already had a stack, so mine probably won't take that long. But if you click on this, you can see everything that's happening. So all this is in progress right now, it looks like it's creating a new TodoLambda, right there, creating a TodoLambda.

[00:09:52]
That's in progress, it's creating a new TodosLambda, it's creating an ApiGateway for a method called Get, for the Todo. So you can see it's literally doing everything that we described inside of our serverless.yml. Which, again, is just an abstraction around CloudFormation, which AWS already created. So sometimes this doesn't work all the time, sometimes it fails just for weird reasons.

[00:10:19]
You've just got to unplug it and plug it back in, honestly, [LAUGH], that's the best way to get past this sometimes. Usually around packaging and things with webpack, it kinda fails, but most of the time, it'll go. So, once it's done, you'll see something like this, you'll get this Service Information, listing your service, the stage.

[00:10:38]
And by the way, if you go back and look at this CloudFormation, the name of this CloudFormation is serverless-dev. So where did it get that name from? Well, that's the name of my service, dash, the name of the stage, that's where serverless-dev came from. So for every stage you create, for every service, you'll get a new CloudFormation stack.

[00:10:57]
So it's completely isolated from the other services, which is great for testing things. Here's the region, again, here's a stack name, I don't have any API keys. And because I created the HTTP events inside my serverless.yml, I got these nice URLs that I can hit.