- Now let's take a look at a demo
of writing a Hello World in AWS Lambda.
From the AWS management console dashboard,
we can go to Lambda, of course, by searching here.
We'll go ahead and take a look at the Lambda dashboard.
You can see, if we go to the dashboard,
it gives us a summary of what's happening within Lambda,
in this particular account, in this region.
So currently in my account, I only have one function so far.
We can also see account level metrics
across all Lambda functions in that particular region,
you know, errors, invocations, total duration,
concurrent executions, all of those kinds of things.
And then of course,
we have access to all of our functions here.
You can see I only have one and we can go ahead
and from here we can create a function.
We could also create a function from the dashboard as well.
So if we create a function here in the management console,
then we're kind of limited, because if we're authoring
from scratch right here in the console,
then we're essentially going to be typing code
in the console, which means that we won't really be able to
include any dependencies.
So if we need dependencies, other libraries,
so for example, if you're writing in Node.js
and you wanted to include npm modules,
then you would have to do all of that locally,
wrap all of that up in a zip file,
and then upload the zip file.
So here we're just going to keep it simple
and write a very simple Hello World.
We'll call that.
And I'm going to use the Python 2.7,
and of course you can see that it supports
quite a few different languages, .Net, Go, Java,
different run times of Node.js,
different run times of Python, Ruby, and so on.
You can also use a custom runtime.
So we'll go ahead and choose Python, and then of course,
now that we have the runtimes selected,
we also need the role to be selected.
So we're going to choose an existing role.
We could also create a new role from a template
or create a custom role, but I already have one.
And I have one here called hello World Lambda.
So let me show you that real quick.
Before we actually get to the function,
let me show you that role because it is really important
to understand that what this says here is that
Lambda must be able to assume this role,
and the role must have Amazon CloudWatch Logs permissions.
So we are using roles to delegate permissions
to the Lambda service, so that this function
is capable of communicating with other AWS resources,
essentially on our behalf.
So I'm going to open IAM here in a new tab,
and I'll go to roles,
I just want to show you this real quick,
it's already created.
Let me search for my hello World role, there it is,
and you'll just see here that I've attached,
I have this role which is specifically for Lambda.
If we look at what we call the trust relationship,
you'll see that this one is for the Lambda service.
So we're saying that the Lambda service
is able to assume this role, not any other service,
not any other account, but specifically the Lambda service.
And so, the permissions that we've granted would be,
one we have a policy called AWSLambdaS3
where we're essentially allowing this particular Lambda
function to, essentially, download anything from S3.
Now you'll notice that what's lacking here
is the ability to list objects in the bucket.
So the function would not be able to explore S3
and just go and find things to download,
the function would have to know the URL to begin with.
And then, down here, we have the Lambda basic execution.
LambdaBasicExecutionRole essentially allows this function
to create a log group within CloudWatch Logs,
CreateLogStreams, and then PutLogEvents,
and you can see here it's specifically for
this particular function, hello World.
So now that we have the role chosen,
and that particular role has the right permissions,
now we can go ahead and create the function.
And we're going to skip over the designer for now.
Let's go down to function code.
And again, right here it's saying edit code inline,
and again the runtime is Python 2.7,
and now before we actually make any changes to this,
let's just first take a look at what they've given us.
You can see that they've already given us
a bit of a hello World, but let's just take a minute
to understand what's going on here.
You'll see that, whether or not you know Python,
that's pretty easy to see
that we are essentially defining a function here.
So all Lambda functions,
regardless of the language that you write it in,
have to have a handler, and you'll see here
that we are calling this one Lambda_function.lambda_handler.
So this right here, Lambda_function.py,
you'll notice that this is essentially the name of the file,
so it's essentially name of the file dot Lambda handler,
and you'll see up here
Lambda handler is the name of this function, right?
So we're telling the Python, excuse me,
we're informing the Lambda service
that when our function is to be executed,
it is to execute this particular function.
Now we could, if we wanted to,
we could define other functions up here, right?
That would essentially be private.
We could define my function here,
and some other function down below,
and all of those would be essentially including in here,
but we're saying out of all the functions,
that might be defined,
this is the one that needs to be executed
when our Lambda function is invoked.
And then of course, that particular handler
will always receive two objects, the event object,
and remember that Lambda can be triggered by events
from a number of different places, from API Gateway,
from S3 Dynamodb, Simple Queue Service, Canesis.
So for example, if you were to leverage
S3 event notifications and you upload a file to S3,
once that object is written and that upload has finished,
then S3 will send an event notification to Lamdba.
And all of the information about that event,
where it came from, any other pertinent meta data,
will be included in that event object.
And then the context object is essentially used,
it can be used to indicate a success or a failure.
You can see here that we don't necessarily have to do that.
We can just return, but you can gain more control
over the execution of this function
by leveraging the context object.
So before we actually run this,
I just want to make one small change.
I'm going to add.
I'm going to import one more thing, the print function,
and here, we're going to say print loading,
so that we can see these things in the logs.
So remember that Lambda will always write logs
to CloudWatch Logs and anything that we print,
to standard out or to the console,
will be captured by CloudWatch Logs.
So we can leave ourselves some debugging information
by essentially printing here.
All of that will be captured by CloudWatch Logs.
We could echo this particular event here, right?
We could do something like this.
We could say receive that event,
and then essentially, use the Json library
to dump that out so that we can see
the contents of that event object in our logs, right?
And so we'll go ahead, down here
we can also assign environment variables
and then of course, just like most resources,
we can set tags for that,
and then if we needed to change the role,
we could, down here,
if we wanted to update the role to something else,
then we could do that there.
We can also define how much memory this needs.
So, also it's worth noting, that your function
is allocated CPU proportional to the memory.
So if your function needs more CPU,
then you have to give it more memory.
The two of them are not separated.
There is an intrinsic relationship
between the amount of memory you use
and the CPU that you get, right?
So remember that the more memory you use,
and the more time you use, the more you pay.
So it's important, not every function needs
3 gigs worth of memory, and not every function needs
five minutes worth of a time out.
So if you just end up doing those kinds of things,
by default, you could very significantly
end up artificially inflating your bill,
and I've seen that happen with clients I've worked with
who had kind of a, they just didn't realize
what was going on and they had a habit of
just always setting the time out to five minutes,
but then not forcing their function to exit
when it could earlier, so it meant that their functions
were just always running for five minutes,
even though the processing may have completed in 1 second.
And so by doing that, they were spending
a lot more money than they needed to.
So really take time to understand,
we may not need five minutes worth of execution,
we may only need three seconds or maybe we need ten, right?
Now it doesn't mean that you're going
to be charged for ten seconds,
you are charged for what actually runs.
So it's important that our function,
right if we go back up to our function,
it's important that our function
either return or call the context fail, as soon as it can.
And so here, hello World certainly doesn't need 3 gigs
worth of memory, we'll go all the way down.
So 128 megs is still more than enough,
but it's the lowest limit.
We could give Lambda functions access to our VPC.
If we wanted Lambda to communicate with EC2 Instances
in our VPC, we could do that as well,
and we could choose a subnet
such as our application servers.
We could do that if we wanted to
and we could give it a security group.
Well I'll just go ahead and close all of that for now.
So that can be really helpful when you want Lambda
to communicate with something, perhaps an application server
or a load balancer, or a relational database
from the RDS service.
And then of course, we could also say we want to reserve
a certain amount of concurrency for this function.
So remember that right here, what this is showing,
is that I have an account limit
of 1000 concurrent executions of functions,
and that's across all functions.
And so if I felt like this particular function
needed more concurrency than other functions,
then I could reserve that and say well I want
to reserve a certain amount of concurrency, right?
And then you can always lift, this is a soft limit,
you can lift this number by submitting a ticket
to Amazon support.
So if you have a very busy application,
you may very well need 2000
or maybe even 10000 concurrent executions.
Amazon does this, these kind of soft limits,
to limit resource consumption.
So let's go ahead and save that,
and then now that it's saved,
we can actually go ahead and test that,
and we can select a test event.
So remember that the event will come
from whatever is triggering this function.
So when you're testing, you need a test event.
So I can go ahead and configure one.
And I'm just going to go ahead here
and get rid of all of these things and say message Hello.
And I'll call that one Hello.
So we've created this new test event
and we can use this to mock other events,
so if we wanted to test against like an S3 notification,
or a Dynamodb notification, then we can take
one of those notifications, we can generate one,
and then take that data and put it in here
as something to continually test against.
So I'll go ahead and create that.
And now, we have, if we go back up here to test,
we can use the hello test event to say test,
and of course it failed, so let's see.
This happens. This is, we're not always perfect.
So again, it's saying it has a syntax error,
and then now we get access to the log output.
Syntax error on line two, so let's come back down here.
I think I might need to put this up here.
Let me try that.
All right, so we can save that again,
very quickly and easily we can make a change
to our function, we can save it, and we could also,
you'll notice here that it's giving us a link to the logs.
We could also go to CloudWatch Logs.
We'll come back to that.
So let's go ahead and we'll close this and try that again.
And there we go, it said result succeeded.
So it was just a matter of,
I ended up putting that from in the wrong place.
And again, that happens,
you just learn from the error and move on.
So this is what was returned, and then down here,
you can see here's where we printed our loading
and here's where we said received event message hello.
So this is our test event.
And then it also tells us, in the logs,
how long the function actually ran for.
So it only ran for 0.52 milliseconds, but we were billed,
right it says here we were billed for 100 milliseconds
using 128 megs worth of memory.
So again, the greater these two numbers combined,
the more we pay.
So if we wanted to take a look at the logs,
we could click here, and that would take us directly
to CloudWatch Logs, and then you can see
this is the streams for hello World.
And you'll see it's ordered here by last event time.
So if we were to take a look,
let's go back to this one here, I think we'll see the error.
Nope, nothing in that one, let's go back.
Maybe it was this one here? That was something else.
Let's take a look here. There we go.
So here is the same information that we saw earlier
where it's saying loading, received event, and so on.
So we'll go back to Lambda and we can close that.
And then of course, we could say,
let's go back to our functions and there we go,
in just a few minutes we've created a hello World
and we created a, by choosing our runtime being Python 2.7,
we specified memory and a time out.
We added some code and we created a test object,
a test event, and then we tested the code
and verified that the code was working
through the logs that the Lambda service gave us.
So that's how we can write functions in AWS Lambda.