Introduction To AWS Lambda For Dummies

There’s something really human about software. It grows not in the direction that is most efficient, in terms of resource utilization, but it seeks simplicity. AWS Lambda offers a completely different paradigm for you to design/run your apps. Before we delve deeper into the core of AWS Lambda let’s put, in simpler terms, what it will help us achieve.

Your application, or at least a certain part of it, involves doing a set of simple operations preceded by a real-world event. For example, there’s a request to view an html page and there’s a bit of Node.js code that executes in response to it. If that’s the case, then it is wasteful to have a web server like apache or nginx running 24/7 waiting for that event to occur and then perform an action in response to it.

This is illustrated rather well in this smbc comic.

AWS Lambda is a solution to reduce this wastage of resources. It essentially spins up the service in response to an event. That is to say, your code sits out there as just a file and AWS keeps a lookout for a trigger event, which you are interested in. When that event occurs, then the code is executed and the required operations are carried out by your code. You are billed only for the number of resources your program consumes, and for the time for which it runs.

The server doesn’t exist until the user goes out there to look for it! Which is termed as ‘serverless’ compute. A more proper term would be Function-as-a-Service (FaaS).

Needless to say, this is a really price-effective way of designing your application and as an added bonus you don’t have to think about scaling the infrastructure either. AWS manages all of that for you. When there’s a lot of requests the function automatically scales to accommodate the growing needs. Similarly, when the need dies down, the service scales down as well, to conserve resources.

Prerequisites

If you wish to closely follow the steps as they are described below, and get a hands-on experience with AWS Lambda, you would need to have only one thing in place – An AWS account with console access.

Anatomy of a Lambda function

The Lambda function in itself is not capable of storing persistent information, this is what we call statelessness. For example, if you define a variable as a counter and make your function increase the counter’s value, by one, every time it is invoked, that would not work. Because the variable is defined and initialized within the confines of your code and would be reinitialized again the next time the code is run.

This basic statelessness might be frustrating for the new users, but it actually serves an important purpose – Separating data from the software. Of course, Lambda has a very good integration for S3 bucket, DynamoDB and other services from Amazon which offers persistent storage when needed.

The function itself has the following important aspects associated with it:

  1. Trigger: A set of activities which invokes the function (runs the code you provide). The activity could be anything like a new object coming to your S3 bucket, a website or service going down, an API call, etc.
  2. The actual function: This is the run-time code that constitutes the function. AWS supports Python, Node.js, C#, Go and Java8 as runtime environment, at the time of this writing.
  3. Resources: Each function can be assigned certain Roles, which in AWS that grants the function certain privileges such as reading S3 bucket contents, writing results to a database and so on.

The triggers are shown to the left, and in this case, an API gateway trigger is active. The resources are shown on the right, which in this case, are CloudWatch Logs and DynamoDB.

Creating a simple Lambda function

Let’s create a very straight-forward Lambda function which gets invoked by an API call. In simpler terms, we generate a URL which when entered in the browser would invoke the function.

Our input would be passed into the function via this URL and the output would be returned and shown in the browser.

Step 1: Creating the function

In the Lambda console panel, click on create function. Give your function a name, in our case, it is DemoFunction. Also select the runtime as Python3, as we will be using that particular language for this example. Lastly, give your function’s role a name and, from Policy Templates, select Simple Microservice permissions.

Click on Create Function and you will be taken to the next screen where you can provide the actual code. We are authoring this API from scratch, but there are tons of templates from Amazon that you can explore.

The next page will have an inline text editor with a simple python function in there. Replace that with the following content:

import json
print('Loading function')

def lambda_handler(event, context):

    firstName = event['first']
    lastName = event['last']
    return 'Greetings, ' + firstName + ' ' + lastName +'!'

The first line is for parsing the JSON using the json library in python. The lambda_handler function gets event as one of its parameters. This event brings along a set of data with it. The first and second line inside the function extracts whatever data is labelled first and second and stores them into the respective variables.

The last line returns a message back and that’s what we will see in our browser.

We can add an API gateway trigger right here, but for the sake of clarity, let’s do it separately. For now, we can click on Save and move into the testing phase.

Step 2: Testing your function

To test your function, just click on the top right corner where it says ‘TestEvent’, then click on configure test event.

Here we will have our first encounter with a JSON payload. In the template TestEvent.

Replace the file’s content with the following lines:

{
  "first": "Jane",
  "last": "Doe"
}

Now that we have saved the test event. Click on Test in the previous menu. Upon successful execution you should see:

Step 3: Setting up a trigger

As mentioned before, our user would invoke the function by accessing a certain URL. To enable that go to the API Gateway Console under your AWS Services and click on Get Started or New API option.

Let’s create one from the scratch:

Our API is named dashbird-api. After clicking on Create API. You will get the resources that the API has access to (listed in the next menu):

Since there are no resources, we just get a forward-slash. But you can create a new resource by using the Actions drop-down and picking Create Resource option there.

And then in the resource list, you can select this new resource (named greetings), click on Actions and select Create Method. Our HTTP request method is going to be GET request since our aim is to get an appropriate response from invoking the function.

The method will have a Lambda integration option, select that and then enter the function name chosen by you in Step 2. Also from Step 2’s screenshot make note of the function’s ARN (top-right corner) it has the string eu-central-1 indicating the region it is at. Make sure that the same region is selected as Lambda region as shown above. It would then ask permission for invoking the function, grant that and now we are ready for the final modification.

The GET method execution is explained in this neat and diagram.

We still need to make sure that the input parameters are passed on correctly. For that, we need to modify the Integration Request stage from above. You can click on it to make modifications:

Leave everything as it is, except at the very bottom of the menu where you will find the Body Mapping Template here we get to describe our input template. The template is going to be of type application/json :

{
    "first": "$input.params('first')",
    "last": "$input.params('last')"
}

The dollar sign and the input.params() part act as a placeholder and helps us define the structure of a proper request. Now we can save our changes, and click on Actions and select Deploy API option. It would ask for a stage name; Give it a suitable name (in our case it is called prod). All is set! We can now run this function in real-time.

Running the function and monitoring it

The function can be invoked using a unique URL associated with it. In the API console, where we first selected Resources, select Stage submenu instead. Then drop down to greetings and then to GET option.

It would give you an invoke URL, you can click on the URL and it would run the function. However, on the first try, you might get an error message because you didn’t give any input. You can do so by modifying the URL like this:

https://………amazonaws.com/prod/greetings?first=John&last=Doe

Adding the last part to the URL would result in a successful execution of the function:

To monitor such a function, you can go to the Lambda console, select a particular function and then click on the monitoring tab:

That shows you not only the invocation rate, but the duration and the amount of memory used. There are more advanced options available with the Dashbird console which integrates with your AWS account and securely gathers metrics and error reports that your organization can use to debug the code, predict costs, dedicate and mitigate DDoS attacks and much more.

If you have followed this so far, we are ready to go more in-depth from here in the next posts…

Read our blog

ANNOUNCEMENT: new pricing and the end of free tier

Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.

4 Tips for AWS Lambda Performance Optimization

In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.

AWS Lambda Free Tier: Where Are The Limits?

In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.