- [Jon] In the previous lecture, you learned about the benefits of Lambda. Let's dive into the details. Before you can start creating the code of your Lambda function, you will need to pick a programming language. As of today, Lambda natively supports six programming languages: Node.js, Python, Java, C#, Ruby, and Go. Sometimes those native runtimes aren't enough because you may have a tool that you don't want to rewrite that's in C++, or maybe because your expertise isn't PHP. That's why it's possible to use your own runtime, but you will need to develop that piece as well. Now that we figured out the runtime, the next step required to create a Lambda function is to upload our code. That can be done in three different ways. You can use the inline code editor, upload your own ZIP file containing your code, or decide to store that ZIP file in S3 and point Lambda to that file. Depending on what your code does, you may require Lambda to access other AWS services. For that, you will need to specify an Identity and Access Management role that Bobbie will explain to you in the next lecture. That role is required to do logging as an example. That's right. You aren't getting away with no logging here, as you may need to troubleshoot the execution of your Lambda function. To do so, you can just output to the console in Node.js and Python. Anything that is sent there will automatically be sent to the CloudWatch Logs service, which is just a service to collect logs. That's why the permissions of your Lambda function are so important. At that point, the Lambda function will be created. However, a Lambda function on its own doesn't do much. It needs to be executed. We call that triggers. There are many AWS services that can trigger a Lambda function, some that we have already seen this week that can trigger a Lambda function - like Simple Storage Service, CloudFront, API Gateway - but there are many more. For example, a Lambda function can be triggered by S3 when a new object gets uploaded. So if you wanted to transform a picture that is uploaded to an S3 bucket and flip it upside down towards another S3 bucket. Let's take this example on a diagram. On the left side of this diagram, you can see an S3 input bucket with a triangle. And then on the right-hand side, I have my S3 output bucket, with that same triangle flipped. In the server world, you will have to poll the S3 bucket to know if a new image has been uploaded every once in a while. So adding my server here, I'll need to poll that S3 bucket constantly until the image is there. And then once I'm ready, I can then send that towards the other S3 bucket. While with Lambda, you can configure S3 to trigger the Lambda function as soon as that image is uploaded. S3 needs to be allowed to trigger your Lambda function. As by default, nothing can trigger it. To do so, you use a function policy referencing the S3 bucket - in this case, our input bucket. Luckily for us, if we use the AWS Management Console, that policy can be automatically created, as you will see in the next demonstration. When your Lambda function gets executed, Lambda - the service - needs to know what piece of your code it needs to execute. That is the entry point for your code. In the Lambda world, that's called a "handler." This tells Lambda in which file or class the function to execute is, as well as its name. Lambda will use that handler to execute your Lambda from the trigger it received, but your code probably needs to receive some more information about what just triggered it. That information is passed to the handler via what we call an "event payload." If we go back to our example of a picture uploaded to S3 to be transformed, that event payload will contain the bucket name and the object key of the blue triangle, which Lambda can now use to know which one of the objects from that input S3 bucket to transform. When a service like S3 invokes the Lambda function, there is no need for S3 to get return data from the function. It really doesn't care about what Lambda does. That is what we call an "asynchronous invocation." If we take another example where we will have API Gateway that sends a request to Lambda for a REST API call, API Gateway is really interested in the response from Lambda to be able to send it back towards the user. That is what we call a "synchronous invocation." Those are the two types of invocation of Lambda. While the function is running and transforming that image from S3, RAM and CPU are used. How are those allocated in Lambda? Well, you don't allocate CPU power, you only allocate RAM. However, the more RAM you provide, the more CPU power your Lambda function will also have. As of today, that RAM allocation can go from 128 MB to 3 GB. Why would you not always allocate the highest amount of RAM? Well, the reason is that you pay more money per 100 milliseconds when you allocate more RAM. So that's obviously more expensive. Let's not do that. But wait, if the Lambda function finishes in less time because it has more RAM and CPU power, then it means that it uses less 100 milliseconds, thus reducing the price of the length of our Lambda function. Let's take a look at a graphic here. What you can see here is Lambda compute cost by function execution time for 100,000 invocations. On the y-axis, you can see the cost of compute from $0 to $12 USD. It is not that expensive, but again, this is Lambda. On the x-axis, I can see the function execution time in milliseconds. So in orange, for example, at the 3-second mark, what I can see is that for a function that will have 2 GB of RAM, it will cost close to $10 for running that for 3 seconds for 100,000 invocations. For a 512 MB of RAM, it will cost a lot less, so about $2.50 or $3 here. Well, then you will always be using the lower amount of RAM. No, but let's think about this for a second. If it takes 3 seconds to execute our Lambda function with 512 MB of RAM, how much time will it take to execute that with way more horsepower here? Well, I don't know. It's not always the function of this, it's not division in here. So maybe it will arrive towards 400 milliseconds? So, if you look at the price difference - now we're at about, I don't know - about $1 here, versus executing that at the $2 to $3 mark that is here. So since this all depends on the complexity of your Lambda function code, you will need to execute some tests to figure out which amount of RAM is better here, which is the lower cost. Now a limitation of Lambda is that a single execution can only run for maximum of 15 minutes. After 15 minutes, we will yank the carpet under your code and you will now have no choice but to stop abruptly. If you do need to run for more than that, you are probably looking for another type of compute. Staying in the serverless world, you can take a look at AWS Fargate, or you could go to an architecture like the one Adam talked about with those servers. Since you paid per 100 milliseconds of your code running and Lambda has a maximum timeout of 15 minutes, what happens if your code was to go in an infinite loop? Will you be charged for all the way to those 15 minutes? The answer here is: Yes, you will. However, there's a timeout that is configurable for your Lambda function to prevent this kind of behavior. In the next lecture, I will do a demonstration of all of the topics we just covered using the Hello Name application we discussed with Adam earlier. Thanks for watching.
