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).

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.

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!

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!

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.

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

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.

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.

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.

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:

3. 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.

4. 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)

5. 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).

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.

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.

6. 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.
7. 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:

3. 3. 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" 
                } 

4. 4. 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:

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.

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.

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:

3. 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.
4. 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" 
            } 
          ] 
        } 

5. 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.

6. 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

7. 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.

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:

8. 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.

9. 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/.

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:

2. 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:

3. 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.
4. 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.
5. 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:

6. 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:

6. • 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.

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/.

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:

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.

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!