Search icon CANCEL
Subscription
0
Cart icon
Cart
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Mastering AWS Lambda
Mastering AWS Lambda

Mastering AWS Lambda: Learn how to build and deploy serverless applications

By Yohan Wadia , Udita Gupta
$39.99 $27.98
Book Aug 2017 300 pages 1st Edition
eBook
$39.99 $27.98
Print
$48.99
Subscription
$15.99 Monthly
eBook
$39.99 $27.98
Print
$48.99
Subscription
$15.99 Monthly

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now
Table of content icon View table of contents Preview book icon Preview Book

Mastering AWS Lambda

Introducing AWS Lambda

I still remember the days when there was a clear demarcation between IT developers and system administrators; so much so that, each time a developer wanted a simple software platform or environment to be set up on their workstations, they would have to log one or more change requests, then dubiously wait for an IT admin to come along, who would more often than not provide you with an incorrect version of the software that you requested. Basically, you would end up wasting a week's effort just to get some simple software like Java or Tomcat to be setup, right? Many of us have sometime or the other been through this so called vicious cycle in IT and some still do, even today. But what if I told you that there is some ray of light around the corner! What if you, as a developer had the flexibility to simply write your code and put it up for execution; without having to worry about the underlying software platform, the OS or the hardware on which your code will run? Sounds too good to be true? Well fret no more, because that is what this book is all about! How you, as a developer start leveraging certain cloud-based services to develop, test, and host applications without having to even manage anything! Welcome to the amazing world of serverless computing!

In this chapter, we are going to get an understanding of the following topics:

  • What serverless computing is, along with its pros and cons
  • Introduction of AWS Lambda as a service and how it works
  • Getting started with AWS Lambda using the AWS Management Console, as well as the CLI
  • Pricing and a few of Lambda's limitations

So, without further ado, let's get started!

What is serverless computing?

To understand what serverless computing is all about and how it came to be, we first need to travel back in time to the era of mainframes and traditional data centers! Sounds like a long-lost time, right? Don't worry, we are not going that far back. This is probably in the time when most IT organizations had massive in-house data centers for hosting almost all enterprise applications and services. First, these applications were hosted directly on physical servers, and then eventually migrated onto the virtualized environments that provided a better utilization of resources as well as helped to slash down the overall costs and time for deployments from months to days. With the advent of the virtualization era, we also started to develop and use more convenient deployment tools that helped to deploy our applications with more ease, but it still meant managing the application's underlying operating system, software platform, and so on:

With virtualization clearly not having all the answers, we started looking for a much simpler application deployment model and, in return, found Containers. Unlike their earlier counterparts, Virtual Machines, Containers don't require a lot of resources or overhead to run. They are far easier and quicker to deploy, hence, reduce the overall application deployment time from days to minutes! You could now easily roll out a new patch for your application, scale your application dynamically based on incoming requests, and even orchestrate various other functions using a vast variety of container management products. However, the question of managing the Containers still remains, and trust me, managing a fleet of thousands of Containers and their underlying physical servers is no easy task. A better, more efficient, deployment model was needed; something that provided us with the agility and flexibility of containers, but without all the hassle and trouble of managing them. Enter serverless computing!

Serverless computing is all about running your application code on small ingots of some CPU and memory without having to worry about the OS type, the software platform, or any of the underlying hardware either. Just take your code and run it! Yes! It's that simple! Serverless computing today is offered by most public cloud providers, such as Amazon Web Services, Google Cloud Platform, Microsoft Azure, and even by IBM as a managed service. This essentially means that all you need to do is write your code or functions that perform a very specific task, select the quantity of resources (in this case RAM) required to run your code and submit it to the serverless cloud computing service to execute on. The service makes sure that your code gets the required amount of memory and CPU cycles it needs to execute. Hence, the collective term Function as a Service (FaaS).

Pros and cons of serverless computing

Here is a quick look at some of the key benefits that you, as a developer, can attain with the help of serverless computing:

  • No ware to manage: Perhaps one of the biggest reasons for the hype about serverless computing is the fact there is absolutely no hardware or software to manage. The management of the serverless computing environment all the way from the underlying hardware to the OS, to even the application's platform layer, is managed by the cloud provider itself.
  • Faster execution time: Unlike your standard cloud instances, which generally take a good minute or two to boot up, functions, on the other hand, spin up very quickly, mostly in a matter of seconds. This could be due to the fact that the functions are made to run on top of a containerized platform.
  • Really low costs: Since there is virtually no opex involved with serverless computing, it is fairly cheap, even when compared to hosting and managing instances in the cloud. Also, the pricing model for serverless computing is a little different from that of your traditional cloud pricing model. Here, you are generally billed on the duration of your function's execution and the amount of memory it consumed during its execution period. The duration is calculated from the time your code begins executing until it returns or otherwise terminates and is rounded up to the nearest 100 ms.
  • Support of popular programming languages: Most cloud providers that provide serverless computing frameworks today, support a variety of programming languages, such as Java, Node.js, Python, and even C#. Azure functions allows the use of F#, PHP, Bash, Batch and PowerShell scripts in addition to the few mentioned.
  • Microservices compatible: Since serverless computing functions are small, independent chunks of code that are designed to perform a very specific set of roles or activities, they can be used as a delivery medium for microservices as well. This comes as a huge advantage as compared to hosting your monolithic applications on the cloud, which do not scale that effectively.
  • Event-driven applications: Serverless functions are an ideal choice for designing and running event-driven applications that react to certain events and take some action against them. For example, an image upload operation to a cloud storage triggers a function that creates associated thumbnail images for the same.

Feeling excited already about giving serverless computing a try? Hold on! There are a few cons to serverless computing as well that you should be aware of before we proceed further:

  • Execution duration: Serverless functions are designed to run for short durations of time, ideally somewhere under 300 seconds only. This is a hard limit set by most cloud providers, however, there are a few workarounds to this as well.
  • Stateless: Serverless functions are purely stateless, which means that once the function completes its execution or is terminated for some reason, it won't store any data locally on its disk.
  • Complexity: The smaller you make things, the more complex it's going to become. Although writing functions that perform very particular tasks is a good idea, it can cause complexity issues when you view your application as a whole system. A simple example can break one large application into some ten different functions such that each perform a specific task. Now you need to manage ten different entities rather than just one. Imagine if you had a thousand functions instead.
  • Lack of tools: Although serverless computing is all at its hype, it still doesn't provide a lot of out-of-the-box tools for management, deployment, and even monitoring. Most of your monitoring tools that you use today were designed for long-running, complex applications; not for simple functions that execute in a mere seconds.
  • Vendor lock-in: With each cloud provider providing its own unique tool sets and services around serverless computing, you often tend to get tied down to a particular vendor. This means that you cannot change your cloud provider without making some changes to your functions as well.

With these key points in mind, let us get to understanding and learning a bit more about the core serverless computing service that this book is all about--AWS Lambda.

Introducing AWS Lambda

So, here we are, finally to the fun part! In this section, we will learn what Lambda is actually all about, what some of its salient features are, how it works and some steps on getting started with your very first Lambda invocation.

AWS Lambda was first introduced way back in 2014, at the yearly AWS re:Invent conference in Las Vegas. The idea back then, and which pretty much holds true even today, is that Lambda is a simple compute service that runs your code in response to certain events. These events can be anything, from an upload operation of an object to an S3 bucket, a record insertion in a DynamoDB table, or even some form of event triggered from your mobile app. The idea here is simple--you simply provide your code to AWS Lambda. Lambda will internally take care of provisioning and managing the underlying infrastructure resources, making sure your code gets deployed successfully; even things like your code's scalability and high availability are taken care of by Lambda itself! Now, that's neat!

Source: https://aws.amazon.com/lambda/

Lambda was specially introduced by AWS to answer a very particular issue with EC2. Although EC2 still remains one of the most widely used core AWS services, it's still not designed to handle or respond to events; something that is required more often than not in today's applications. For example, a simple image upload activity to an S3 bucket triggers some form of operation, such as checking whether the object is actually a valid image, or whether it contains any viruses or unwanted malware. You can even have a requirement to create thumbnails of the uploaded image and put that up on your website. Now, imagine an EC2 instance doing all these activities for you. Firstly, you would have to program some mechanism for S3 to notify your EC2 instances to periodically perform checks on your S3 bucket, as EC2 has no way of telling when a new object has been uploaded.

Then again, you would have to manage the EC2 instance and handle all failovers, such as what happens if the EC2 instance fails to poll the S3 bucket, or what happens if the EC2 instance gets terminated for some reason. There's also the issue of scalability, right? Today you may be uploading just about 30-40 odd images, enough for a single EC2 instance to work on; but what happens when there is a large surge of upload operations? Will your EC2 instances scale effectively? And most important of all and by far the biggest issue for most enterprises--cost. Your EC2 instance will be running even on those days when there are no upload operations occurring in your S3 bucket. Sure there are many ways in which we can create workarounds for this, such as by creating a separate instance that polls continuously and by leveraging SQS or SNS as well, but isn't all that really overkill for something so simple? That's exactly the reason why Lambda is so popular and so widely used today. It just makes things simple!

How it works

Well, we do know for sure that Lambda powers your code on some form of container technology which explains how AWS is able to get it to spin up so quickly as compared to running your code on standard EC2 instances. These containers are spun up on underlying EC2 instances that are all created from a common image (Amazon Linux AMI: amzn-ami-hvm-2016.03.3.x86_64-gp2). Once again, we cannot control or see these containers or EC2 instances; they are managed by AWS itself.

There is a short latency between the time a Lambda function is invoked. This is primarily because AWS has to bootstrap the container that runs your code and provides the necessary resources for it to run as well. This latency is generally observed when the function is either invoked for the first time or when it is updated.

At the heart of the container is your code, which, as a rule of thumb, has to be written specifically to perform a single task or a few simple processes; similar to how you would write functions in your normal code. Each Lambda project that you deploy can thus be termed as a Lambda function, or just a function. At the time of writing this book, AWS supports Java, Python, Node.js, and even C# as programming languages for your functions. Each function can be invoked either on demand or invoked dynamically based on certain types of supported events. A few event examples are listed out as follows:

  • Amazon S3: Lambda functions can be triggered when an object is created, updated, or deleted in an S3 bucket
  • Amazon DynamoDB: Lambda functions are triggered when any updates are made to a particular DynamoDB table, such as row insertion, deletion, and so on
  • Amazon Simple Notification Service (SNS): Trigger a Lambda function when a message is published on a, SNS topic
  • Amazon CloudWatch Logs: Use Lambda functions to process CloudWatch Logs as feeds
  • Scheduled events: Run Lambda functions as scheduled events, just like a cron job
  • AWS CodeCommit: Execute Lambda functions whenever new code is pushed to an existing branch, and so on
For a complete list of the latest AWS services that are supported as Lambda invokers, refer to http://docs.aws.amazon.com/lambda/latest/dg/invoking-lambda-function.html.

When creating Lambda functions, you have to specify the amount of memory resource your function will require, as well as the approximate time it will take to execute before timing out. The memory can be set from 128 MB to 1.5 GB of RAM and the timeouts anywhere from one second to a max of 300 seconds. Both the memory and duration values are upper limits to your Lambda function, which means that if you have allocated 512 MB of RAM to your function, it doesn't mean the function will have to use all 512 MB, of it. It can work at any value up to 512 MB post which Lambda will simply throw you an error message stating that your function ran out of memory. The same applies for the duration of your function as well. You may set your function to timeout after 60 seconds and the function may only run for, say, 10 seconds. However, if your function fails to complete its processing by the 60th second, Lambda once again will time it out and pop you up an error message.

It is important to note, however, that varying the amount of memory for your function or the duration of the timeout also impacts the cost of your Lambda function. We will have a look at Lambda's pricing and limitations a bit later on in this chapter. For now, let us learn a bit more on how to actually get started with deploying Lambda functions using the AWS Management Console, as well as the AWS CLI.

Getting started with AWS Lambda

In this section, we will look at how easy and effortless it is to execute a simple Lambda function using both the AWS Management Console, as well as the AWS CLI, and in the process learn a few necessary components and configurable items along the way.

Using the AWS Management Console

The AWS Management Console is by far the simplest way to getting started with AWS Lambda. Now I'm going to assume that you already have a valid AWS account and some basic hands-on knowledge with the core AWS services and products such as EC2, IAM, S3, and so on. If not, then you can always create a new account with AWS and leverage the awesome one-year Free Tier scheme as well.

To read more about Free Tier usage, check out this link here https://aws.amazon.com/free/.

The following are the steps to create a new Lambda function:

  1. Log in to your AWS Management Console using your IAM credentials and from the AWS Services filter, type in Lambda to get started. You should see the AWS Lambda dashboard, as shown in the following screenshot.
  2. Click on the Get Started Now option to create a new Lambda function:

Creating a Lambda function is a straightforward four-step process and it begins with the selection of a function blueprint. Just the way we have AMIs for easy and fast deployments of EC2 instances, the same applies for a Lambda function as well. Blueprints are nothing more than sample code that you can use as starting points to writing your very own functions. AWS provides a cool 70-odd blueprints that you can select from, this can help you integrate S3, DynamoDB, and Kinesis with Lambda for to perform specific tasks. For this section, we are going to be using a very simple hello-world Lambda function blueprint from the catalog. We can do so by following the given steps:

  1. First, simply type in the keyword hello in the filter provided. You can optionally even select the runtime for your function as Node.js from the Select runtime drop-down list provided to narrow your search.
  2. Select the hello-world blueprint, as shown here:

The second stage of creating your own Lambda function involves the configuration of the function's trigger mechanism. This is an optional page, however, it's worth paying attention to. Here, you can select a particular service that will trigger the Lambda function's invocation by selecting the highlighted box adjoining the Lambda function icon, as shown. To select a particular service, you will be required to populate some necessary fields pertaining to that service.

For example, if you happen to select S3 as the service, then you will be prompted with fields where you will need to provide the particular bucket name, the event type (whether to trigger the function based on an object's creation or deletion), and so on:

  1. Select Next to continue with the wizard. The next page that shows up is the function's configuration page. Using this page, you can provide your function's basic configurable items, such as Name, Description, and Runtime.
  1. Provide a suitable Name for your Lambda function. The Description field is optional, however, it is always a good practice to provide one. The Runtime for this scenario is already auto populated to Node.js 4.3. At the time of writing this book, the following runtimes are supported:
    • Node.js 4.3
    • Edge Node.js 4.3
    • Java 8
    • Python 2.7
    • C# (.NET Core 1.0)
Edge Node.js is nothing but a new extension of the Lambda service called Lambda@Edge. This service basically allows you to run Lambda functions at various AWS Edge locations in response to CloudFront events. You can read more about it here at http://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html.
  1. Post the runtime. You will also notice your Lambda code prewritten and ready for execution, shown as follows:
        'use strict'; 
        console.log('Loading function'); 
        exports.handler = (event, context, callback) => { 
          //console.log('Received event:',JSON.stringify(event, null,
2)); console.log('value1 =', event.key1); console.log('value2 =', event.key2); console.log('value3 =', event.key3); callback(null, event.key1);
// Echo back the first key value //callback('Something went wrong'); };

The code itself can be broken up into three distinctive parts: the first is the invocation of the function. The function, in this case, is called handler, which gets exported from your Node.js code. This handler is then invoked by calling the function's file name (which in this case is index), followed by the function's name in this format: index.handler. The rest of the parameters go as follows: event is the variable where you get your function's event-related data; context is used to get some contextual information about your Lambda function, such as the function's name, how much memory it consumed, the duration it took to execute, and so on, callback is used to send back some value to your caller, such as an error or result parameter: callback(error,result).

Callbacks are optional however they are really useful when it comes to debugging errors in your function's code.

You can either edit your code inline using the code editor provided in the console or even upload a packaged code in the form of a ZIP file either from your local workstation or even from S3. We will be exploring these options later in the next chapter, for now let us continue moving forward.

The next section on the function configuration page is the Lambda function handler and role as shown in the following screenshot. Here you provide the Handler* for your code along with the necessary permissions it needs to run in the form of IAM roles. You have three options to select from the Role* drop-down list. The first in the list is, Choose an existing role that basically allows you to select an IAM role from a list of predefined one. For this scenario, I've gone ahead and selected the role lambda_basic_execution which as the name suggests, provides basic execution rights to your Lambda function:

The other two options are Create a custom role or Create a role from a template. You can use either of these options to create new roles based on your requirements.

Make sure your role has the necessary permissions to view CloudWatch Logs as that's where your function's execution logs are displayed.

The final section on the function configuration page is the Advanced settings section. Here you can configure your function's resource requirements along with a few necessary items as well. Let us have a quick look at each one:

    • Memory (MB): Select the appropriate amount of memory for your function to run. There is no provision for selecting the CPU resources for your function however the more RAM that you provide to your instance, the better CPU cycle it will get as well. For instance, a 256 MB function will generally have twice the CPU than that of a 128 MB function.
    • Timeout: The Timeout field is used to specify your function's maximum execution time. Once the timeout is breached, AWS will automatically terminate your function's execution. You can specify any value between 1 second and 300 seconds.
    • DLQ Resource: This feature is quite new, but a very useful feature when it comes to building fault tolerant asynchronous applications. By default, AWS automatically queues the various asynchronous events that the function has to invoke on. It can automatically retry the invocation twice before that particular event is discarded. If you do not wish the event to be discarded, you can now leverage either AWS SQS or SNS to push those stranded events to the dead letter queue. Selecting SNS prompts for a valid SNS Topic name and selecting SQS prompts you to enter a valid SQS Queue name:
    • VPC: By default, your Lambda functions are created and deployed in an AWS managed VPC. You can optionally toggle this setting and provide your own VPCs for the functions to run out of.
    • KMS key: Lambda provides you to develop functions by passing environment variables as well. By default, when you create environment variables, AWS encrypts them using the KMS service. You can use this default service key or even create your own custom key using the IAM console.
  1. With the Advanced settings out of the way, click Next to proceed. On the Review page, make sure you go through the items that you have configured during this section.
  2. Once done, click on Create function to launch your first Lambda function.
    You should see your Lambda function successfully deployed as shown in the following screenshot. You can use this dashboard to edit your function's code inline, as well as change a few necessary parameters and even test it. Let's take a quick look at the tabs for a better understanding:

The tabs in the screenshot above are explained as follows:

    • Code: Using this particular tab, you can edit the deployed code inline as well as upload a newer version of your code using either your local workstation or from S3. Once you have made changes to your code you will be prompted to Save and test the same.
    • Configuration: This tab provides you with the same configurable items as described earlier in this very section. You mostly will use this tab to reconfigure your function's resources or change its execution duration.
    • Triggers: Use this tab to configure your function's triggering mechanism. For this section, this would be blank anyways.
    • Monitoring: This tab will display the function's invocation count, its duration, and whether any errors or throttling events occurred.

For now, let us run a quick and simple test to verify whether our function is working or not:

    1. To do so, select the Test option. Here, you can select from a list of few a predefined test sample events using Sample event template, as shown in the following screenshot.
    2. Select the template Hello World:
    1. The function processes incoming events in the following format. Replace the value field with your own string values and click on Save and test to view the results of your function's execution:
                { 
                  "key3": "value3", 
                  "key2": "value2", 
                  "key1": "value1" 
                } 
    1. If the execution goes well, you should see the following displayed on your dashboard. The first thing you need to notice here is the result of your code's execution, followed by the Summary of your function's execution. The Summary section displays the Duration the function took to execute, Billed duration, along with other important details such as the function's Resources configured and Max memory used. You can always use these details to fine-tune the amount of resources you provide to your function to execute the next time:
AWS Lambda rounds the function's execution duration to the nearest 100 ms.

The second important part is Log output, which displays a part of the function's execution logs. You can use these logs to rectify code errors and make performance improvements as well.

Here's a handy tip! You may notice your function might have taken some 10 ms to execute on an average. That's not too, bad but still it is way too long for something as simple as this function, especially when there is no computation involved. So rerun the test again and verify the duration now. It should be significantly less, right? This is the same latency issue that we talked about earlier, and this is just a way to demonstrate the same.

So, with just a few simple clicks we were able to create, run, and test our first Lambda function, and all the while we did not bother about setting up the development platform nor managing the underlying infrastructure! That's exactly what serverless architecture is all about! There are still quite a few options available from the dashboard that we can use, however, we will keep them aside for the next chapter. For now, let us explore how the AWS CLI can be leveraged to spin up and manage Lambda functions as well.

Using the CLI

As you may be well aware of, AWS provides a rich and easy to use CLI as well for managing your cloud resources. In this section, we will be using the AWS CLI to create, package, and invoke a simple Lambda function:

  1. To begin with, make sure your AWS CLI is set up and ready for use. You can install the CLI on most major Linux OSes, as well as macOS, and Windows. You can go through the following guide for the installation, as well as the configuration steps: http://docs.aws.amazon.com/cli/latest/userguide/installing.html.
  2. Next, create a new folder (in this case, I created a folder named lambda) and copy the following contents into a new file:
        console.log('Loading function'); 
        exports.handler = function(event, context) { 
          var date = new Date().toDateString(); 
 
          context.succeed("Hello " + event.username + 
"! Today's date is " + date); };

The following screenshot shows the output of the preceding file:

  1. Name the file index.js and save it. This particular code is fairly straightforward. It logs the current date and prints a user-friendly message with the user's name passed as the event.
  2. Now, in order for the Lambda function to execute, we need to create a minimalistic IAM role that Lambda can assume for executing the function on our behalf. Create a file named policy.json and paste the following content into it:
        { 
          "Version": "2012-10-17", 
          "Statement": [ 
            { 
              "Effect": "Allow", 
              "Principal": { 
                "Service": "lambda.amazonaws.com" 
              }, 
              "Action": "sts:AssumeRole" 
            } 
          ] 
        } 
  1. To create an IAM Role, we need to make use of the create-role command, as shown:
        # aws iam create-role  
        --role-name basic-lambda-role  
        --assume-role-policy-document file://policy.json 

From the output of the preceding command, copy the ARN that and keep it handy. We will be requiring the same in the coming steps.

  1. With the role created, we can now go ahead and create our function. First, zip the index.js file using the following zip command. This is going to be our deployment package that will be uploaded to an S3 bucket and executed as a function by Lambda itself:
        # zip -r mySecondFunction.zip index.js
Make sure you only zip the file and the folder it was created in.
  1. Next, we use the create-function command to create our Lambda function. Type in the following command:
        # aws lambda create-function  
        --region us-west-2  
        --function-name mySecondFunction  
        --zip-file fileb://mySecondFunction.zip  
        --role arn:aws:iam::00123456789:role/basic-lambda-role  
        --handler index.handler  
        --runtime nodejs4.3  
        --memory-size 128 

Let us explore a few of the options that we just passed with the create-function command:

    • --function-name: The name of the function that you will be uploading. You can optionally even provide a description for you function by passing the --description option.
    • --zip-file: This is the path of the deployment package that we are uploading.
    • --role: The ARN of the IAM role that Lambda will assume when it has to execute the function.
    • --handler: The function name that Lambda will call to begin the execution of your code.
    • --runtime: You can provide the runtime environment for the code that you will be executing. There are a few pre-defined values here that you can use, namely: nodejs, nodejs4.3, nodejs4.3-edge, java8, python2.7, and dotnetcore1.0.
    • --memory-size: The amount of RAM you wish to allocate to your Lambda function. You can optionally set the timeout value as well by using the --timeout option.

The full list of options can be found here https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html.

By default, your functions will timeout after 3 seconds if no value is provided.

Once you have created the function, you should get a response similar to the one shown in the following screenshot. This means we are now ready to invoke our function:

  1. To invoke the function from the command line, we need to call the invoke command, as shown:
        # aws lambda invoke  
        --invocation-type RequestResponse  
        --function-name mySecondFunction  
        --region us-west-2  
        --log-type Tail  
        --payload '{"username":"YoYo"}'  
        output.txt 

Let us explore a few of the options from the invoke command:

    • --invocation-type: The type of invocation your Lambda will undertake. By default, the RequestResponse invocation is invoked. You can also choose between event meant for asynchronous executions or the dryrun invocation if you want to verify your function without running it.
    • --log-type: Used to display the log of your function's execution. Do note, however, that the Tail parameter only works when the --invocation-type is set to RequestResponse.
    • --payload: The data you wish to send to your Lambda function in JSON format.
    • output: The file where you want to log the output of your function's execution.

The full specification can be found here https://docs.aws.amazon.com/cli/latest/reference/lambda/invoke.html.

  1. Once you have successfully invoked the function, check the output of the execution in the output.txt file:

There you have it! You have now successfully created and launched a Lambda function using the AWS CLI. There are a few other important commands that you should also keep in mind when working with the CLI, here's a quick look at some of them:

    • list-functions: A simple command to list your published Lambda functions. You can invoke it by using the following command:
                    # aws lambda list-functions 

You can optionally use other parameters, such as --max-items, to return a mentioned number of functions at a time:

    • get-function and get-function-configuration: As the name suggests, both commands return the configuration information of the Lambda function that was created using the create-function command. The difference being that the get-function command also provides a unique URL to download your code's deployment package (ZIP file). The URL is pre-signed and is valid for up to 10 minutes from the time you issue the get-function command:
                    # aws lambda get-function <FUNCTION_NAME> 
                    (or) 
                    # aws lambda get-function-configuration 
<FUNCTION_NAME>

The following screenshot shows the output for the preceding command:

To get a complete list of the CLI supported commands, click here http://docs.aws.amazon.com/cli/latest/reference/lambda/.

Pricing and limitations

As discussed sometime earlier in this chapter, a Lambda function's cost depends on the amount of compute resources (RAM) supplied to it, as well as the duration of the function's execution. But that's not all! A Lambda function is even billed based on the total number of requests collectively across all your functions. The cost is calculated each time Lambda responds to a request generated either by an event or by a manual invocation. This also includes responses triggered during testing of your Lambda function using the Amazon Management Console. At the time of writing, AWS charges $0.20 per 1 million requests ($0.0000002 per request). The best part is that, each month, you get one million requests and 400,000 GB of compute time for free. This feature does not expire, even after your Free Tier validity is over.

Let's take a simple example to understand this better. Consider your Lambda function has been allocated the minimal 128 MB of RAM and it will execute a good 5 million times in one month for one second each. In that case, the cost is calculated as follows:

  1. First, we calculate the monthly compute charge. The monthly compute price is $0.00001667 per GB and the Free Tier provides 400,000 GB for free each month:
  1. Similarly, we now calculate the monthly request charge. The monthly request price is $0.20 per 1 million requests and the Free Tier provides 1 million requests per month:
  1. So, your total cost for running a Lambda function with 128 MB of RAM for a duration of 1 second a million times is >> Monthly Compute Charges (a) + Monthly Request Charge (b) = $3.75 + $0.8 = $4.55.
  2. Not impressed? Let's take a look at how a Lambda function fares with an EC2 instance when it comes to pricing with a simple example.
  3. Consider a really simple Lambda function that will execute roughly 300,000 requests in one month with 3 seconds for each. We will give our function a good 512 MB of RAM for execution. The monthly compute charge is calculated as follows:
  1. Similarly, we calculate the monthly request charge as follows:
    • The monthly request price is $0.20 per 1 million requests and the Free Tier provides 1 million requests per month:
    • Since the number of requests is less than that given in Free Tier, the monthly request charge (b) evaluates to $0:

Compare that with an EC2 t2.nano (512 MB) instance, running 24/7 for a full month, amounts to $4.32! Now that's really cheap!

Let's also check out some common Lambda limitations as well. For starters, Lambda is not designed for applications that have a long execution time. The maximum execution time supported for a Lambda function is 300 seconds. There are also some hard limits on the amount of RAM you can assign to your Lambda functions. The minimum is 128 MB and it goes all the way up to 1536 MB in increments of 128. Each Lambda function also receives 500 MB of non-persistent scratch space that is generally mounted to /tmp.

If you are looking for persistent storage options, you may want to leverage S3, RDS, or DynamoDB for the same.

There are also some limitations set on the size of the code that you can upload to Lambda. Each Lambda function supports a max upload of 50 MB of code, bundled either as a .zip or .jar file. You can read more about the various limits set on Lambda code deployments, as well as executions here: http://docs.aws.amazon.com/lambda/latest/dg/limits.html.

Besides these limits, you should also know that, at the time of writing this book, AWS Lambda only supports Java, Node.js, Python, and C# as programming languages. There are ways in which you can even execute other non-supported languages and codes, such a, PHP, Go, and Ruby, but that is out of the scope of this book, as we will be primarily concentrating on development using Node.js itself. You can still get a good hands-on feel for the other non-supported scripting languages on Lambda by looking at https://aws.amazon.com/blogs/compute/scripting-languages-for-aws-lambda-running-php-ruby-and-go/.

Planning your next steps

With the basics out of the way, it is equally important to understand a few additional concepts about serverless computing and Lambda functions in general. Firstly, when to use what? Here is a simple breakdown of a few AWS services that offer compute capabilities, and when you should ideally use them:

Requirement Management Deployed as AWS Service
Run simple workloads or websites continuously at predictable rates. Less control required. You control the server, its OS, and software. Virtual private servers

Amazon Lightsail

Run almost any workloads at any scale. More control and flexibility required. You control the instance, the OS and software. You can scale and manage your instances. Instances Amazon EC2
Run microservices-based application on Dockerized containers. You control the provisioning and scaling. AWS manages cluster state and deployment of your application. Containers Amazon EC2 Container Service
Run applications that are event driven and stateless. You provide the application code. AWS manages the deployment and scaling of the infrastructure. Code AWS Lambda

Secondly, the code that we are going to be using and developing in this book is predominantly going to be around Node.js, but that shouldn't stop you from using either Java or Python, or even C# for that matter. Do keep in mind however, that each of these programming languages offers a different level of performance. Dynamic languages like Python and Node.js will naturally provide slightly better performances as compared to static languages such as Java and C#. But as I always say, when in doubt, do it yourself, so write a few simple lines of code in each of the supported languages and benchmark the same.

Summary

Let's quickly recap the things we have learned in this chapter. For starters, we got to learn a bit about the birth of serverless computing along with few of its features, pros and cons. With the basics out of the way, we started our journey into the amazing world of AWS Lambda by understanding its nuances and how it works. We then explored the rich AWS Management Console and saw how easy and effortless it is to deploy a simple function. We even learnt how to package and invoke our functions using the AWS CLI as well. Towards the end of the chapter we learnt about how Lambda is priced along with few examples and what some of its limits are as well. Finally, we ended the chapter by exploring a quick comparison between the AWS compute services and learnt which service to use and when.

In the next chapter, we will be turning things up a notch by actually learning the anatomy of writing a Lambda function; its basic building blocks, how to log, and handle few common exceptions, as well as working with versioning and environment variables. So stick around, we are just getting started!

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • ? Leverage AWS Lambda to significantly lower your infrastructure costs and deploy out massively scalable, event-driven systems and applications
  • ? Learn how to design and build Lambda functions using real-world examples and implementation scenarios
  • ? Explore the Serverless ecosystem with a variety of toolsets and AWS services including DynamoDB, API Gateway, and much more!

Description

AWS is recognized as one of the biggest market leaders for cloud computing and why not? It has evolved a lot since the time it started out by providing just basic services such as EC2 and S3 and today; they go all the way from IoT to Machine Learning, Image recognition, Chatbot Frameworks, and much more! One of those recent services that is also gaining a lot of traction is AWS Lambda! Although seemingly simple and easy to use, Lambda is a highly effective and scalable compute service that provides developers with a powerful platform to design and develop Serverless event-driven systems and applications. The book begins with a high-level introduction into the world of Serverless computing and its advantages and use cases, followed by a deep dive into AWS Lambda! You’ll learn what services AWS Lambda provides to developers; how to design, write, and test Lambda functions; as well as monitor and troubleshoot them. The book is designed and accompanied with a vast variety of real-world examples, use cases, and code samples that will enable you to get started on your Serverless applications quickly. By the end of the book, you will have gained all the skills required to work with AWS Lambda services!

What you will learn

• Understand the hype, significance, and business benefits of Serverless computing and applications • Plunge into the Serverless world of AWS Lambda and master its core components and how it works • Find out how to effectively and efficiently design, develop, and test Lambda functions using Node.js, along with some keen coding insights and best practices • Explore best practices to effectively monitor and troubleshoot Serverless applications using AWS CloudWatch and other third-party services in the form of Datadog and Loggly ? Quickly design and develop Serverless applications by leveraging AWS Lambda, DynamoDB, and API Gateway using the Serverless Application Framework (SAF) and other AWS services such as Step Functions • Explore a rich variety of real-world Serverless use cases with Lambda and see how you can apply it to your environments

Product Details

Country selected

Publication date : Aug 11, 2017
Length 300 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781786467690
Vendor :
Amazon
Languages :
Concepts :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now

Product Details


Publication date : Aug 11, 2017
Length 300 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781786467690
Vendor :
Amazon
Languages :
Concepts :

Table of Contents

11 Chapters
Preface Chevron down icon Chevron up icon
1. Introducing AWS Lambda Chevron down icon Chevron up icon
2. Writing Lambda Functions Chevron down icon Chevron up icon
3. Testing Lambda Functions Chevron down icon Chevron up icon
4. Event-Driven Model Chevron down icon Chevron up icon
5. Extending AWS Lambda with External Services Chevron down icon Chevron up icon
6. Build and Deploy Serverless Applications with AWS Lambda Chevron down icon Chevron up icon
7. Monitoring and Troubleshooting AWS Lambda Chevron down icon Chevron up icon
8. Introducing the Serverless Application Framework Chevron down icon Chevron up icon
9. AWS Lambda - Use Cases Chevron down icon Chevron up icon
10. Next Steps with AWS Lambda Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Empty star icon Empty star icon Empty star icon Empty star icon Empty star icon 0
(0 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Top Reviews
No reviews found
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see www.packtpub.com/support and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to www.packtpub.com/account
  • To contact us directly if a problem is not resolved, use www.packtpub.com/contact-us
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.