Hello, and welcome to this lecture, where I’ll be taking an introductory look at AWS Lambda. AWS Lambda is a serverless compute service that’s designed to allow you to run your application code without having to provision or manage your own EC2 instances.

So to really understand serverless compute, you must first understand servers. For example, consider all the work that goes into running an EC2 instance: you have to install software, patch the instance, manage scaling and high availability, configure storage, and only after all that is done can you then write your application code and deploy it to the instance.

Now imagine if that infrastructure maintenance and administration went away, enabling you to focus entirely on your code and business logic. That’s the idea behind serverless. Now of course, this maintenance and server administration still exists behind the scenes; however, it’s no longer your job to do it - instead, it becomes the service’s responsibility and is managed by AWS.

So understanding AWS Lambda is really the same as understanding almost any function in code. There are three major parts:

The first piece is the input,
The second piece is the function itself, and
The last piece is the output.

Let’s start with the function. Just as EC2 is made up of instances, Lambda is made up of functions. And these functions are the code that you write that represents your business logic. Within your function, you’ll also configure other important details, such as permissions, environment variables, and the amount of compute power your function needs. And the way you specify this compute power is by choosing how much memory you want to allocate to your function. Based on this amount, the Lambda service will provide proportional amounts of CPU, network, and disk I/O.

To upload your code to Lambda, you can either write your code directly within the service itself, or you can upload your code via a zip file or objects stored in Amazon S3. The programming language you use to write your code must match the runtime you select in the service.

AWS Lambda offers several different options for runtimes. You can choose to use a runtime that Lambda natively supports, such as Java, Go, PowerShell, Node.js, C#, Python, or Ruby. Or, if you need to use a language that isn’t in that list, you can add support for other languages by using the runtime API. So if you find yourself needing to run PHP or C in Lambda, then the custom runtime feature is definitely for you.

So once you’ve uploaded or written your code, how does it actually run? Well, it has to be invoked. And this is where the first piece of the equation–the input–comes into play. Now there are several options for your function to be invoked:

Your function could be invoked directly through the console, SDK, AWS toolkits, or through the CLI,
It could be invoked using a function URL, which is an HTTP endpoint you can enable for your Lambda function, or
It could be invoked automatically by a trigger, such as another AWS service or resource. These triggers will run your function in response to certain events or on a schedule that you specify. So if you need to run your function every day at 8 am, you can do that.

When you invoke your function, you can pass in events for the function to process. If a service invokes your function, it can also pass in events; however, the service will be responsible for structuring those events. For example, your code could run in response to a request from API Gateway or an S3 event, such as a PUT object API call. So once the PUT object API call is made, AWS Lambda will run your code, just as you’ve written it, using only the compute power you’ve defined.

Then you have the third and final piece, which is the output. Once your function is triggered and your code runs, it can then make calls to downstream resources. This means that you can make API calls to other services like DynamoDB, SQS, SNS, and more, all from within your code.

When your Lambda function is triggered, the service automatically monitors your function through logs and metrics. You can also choose to add custom logging statements within your code to help determine if your code is operating as expected. These log streams act as a recording of the sequence of events from your function. Lambda also sends common metrics from your functions to CloudWatch for monitoring and alerting.

In terms of cost, you’ll only pay for the resources you use. This is based on three things:

The number of requests that you send to your function,
The duration of time your code executes, which is measured from when your function is triggered to when it finishes, rounded to the nearest millisecond, and
The amount of compute power you’ve provisioned for your function. So if you provision the maximum amount of memory for your function, which is currently 10 gigabytes, you’ll be charged accordingly.

That brings me to the end of this lecture. I hope you’ve enjoyed this quick introduction to AWS Lambda. Thank you so much for your time, and best of luck with your continued learning.

AWS Lambda

About