AWS Lambdas Q&A

[00:00:00]
>> Scott Moss: I had a few questions on the chat if anybody are interested in hearing. One of them were, it's considered a best practice to trigger lambdas at regular intervals to keep them out of the cold state. I wouldn't say it's a best practice, but it is a practice, I do it, so yeah, and there's a couple of ways you can do that.

[00:00:16]
You can have one lambda calling another lambda all the time or you can use Cloud, is it CloudWatch? CloudWatch events, you can register intervals, that's actually a type of event that you can register to, actually. If you click on Events here.
>> Speaker 2: Yeah, but you mentioned if you don't know how much time.

[00:00:40]
>> Scott Moss: Yeah, you're still playing a guessing game but at least you might get it, but even then, they still recycle. Even if you keep them warm, they've still got to get rid of them because that's how they save the money, right? That's how they are able to give you that per usage billing.

[00:00:53]
Which by the way, the minimum they'll charge you for is 100 milliseconds. Doesn't matter how fast your lambda is, you'll always get charged for 100 milliseconds, so there are some things there. But yeah, you can use Events for that, we use it all the time, or when we redeploy with one of our lambdas.

[00:01:06]
And then there's another lambda that's calling all the other lambdas, so it's kinda crazy. Is every function you define an independent lambda when you deploy to AWS? Yes, every function you define is definitely an independent lambda, when deployed to AWS. They have nothing to do with each other, other than the fact that they were in the same repo that you created on your machine.

[00:01:25]
But once they get on AWS, they don't know about each other, they don't do anything. They have nothing in common, other than they were in the same repo, that's it. Even if you share dependencies between the two, depending on how you package when we get to deployment, how you package it.

[00:01:42]
They still wouldn't have anything in common. They would create their own versions of those dependencies because at the end of the day, and this is getting really deep. But if you go look at Amazon and you go to s3, how does Amazon know what your lambda is, where is it at?

[00:02:00]
But it's actually saving it in a s3 bucket, in a zip file.
>> Scott Moss: Here, so every time you deploy a lambda, it's saving as a zip file. So if you have lambda functions that are sharing dependencies. Like node modules in the same repo where there's several lambda functions.

[00:02:19]
When you deploy it, depending on how you deploy it, a copy of all those dependencies will get zipped in the appropriate functions file. So, yeah, they really don't depend on each other at all, they just make their own copy. For you putting them in one repo, that's just easy for you to deploy things like different services together.

[00:02:35]
Like, these are all common lambdas, I'm going to deploy them together. But when they go to AWS, they don't know about each other.