If you’ve ever wanted to write a web app or API without messing around with the server, Amazon’s Lambda might be what you’re looking for.

Amazon Web Services (AWS) is a collection of developer tools that Amazon develops and publicly offers.This article will get you up and running with Lambda, a tool in the AWS suite. We’ll be using Lambda to create an HTTP GET endpoint that will make requests using the GitHub API to pull repository info from GitHub and return a JSON response.

The Lambda tagline is “Run Code without Thinking about Servers”. At first glance, this may sound confusing. Where or how does the code run then? Let’s find out.

To follow along with this article, you’ll need an AWS account of your own. You can create a free AWS account at aws.amazon.com.

Serverless and Functions as a Service

“Serverless” is a software infrastructure term you may have heard about. It describes a solution for on-demand code execution. The term “serverless” can be misleading because there are still servers in the equation. A better descriptor is FaaS, or “functions as a service.”

Both definitions describe a new development and deployment experience. This experience is considered “serverless” because you, as a developer, no longer have to manage, monitor, or scale any servers that are running your code. You upload your code to a FaaS provider (AWS Lambda, in this case), and the FaaS provider executes it and manages any infrastructure for you behind the scenes.

The Pros and Cons of Serverless Architecture

Given this expanded definition of the “Serverless” architecture, let’s look at some of the pros and cons when working with Lambda.

Pros

• On-demand usage pricing.
  Traditional server hosting uses a recurring billing cycle. Your server is always up and running, using resources and waiting for input. You pay a monthly or yearly fee to keep it running for the duration of your billing cycle. With Lambda, you’re only billed for computational resources that you use, not idle time. Lambda has two usage pricing models: duration and concurrency.

• Duration pricing
  Lambda duration pricing calculates prices based on the time the function begins executing until it terminates. This price calculation is beneficial for projects using short-lived computational resources. You can save a significant amount of money over traditional “idle” hosting solutions.

  Lambda duration pricing is as follows:

  • $0.20 per 1 million requests
  • $0.00001667 for every GB-second duration of computing time, with every execution rounded up to the nearest 100ms

  The duration pricing is dependent on pre-configured memory usage of your deployed function. This duration and memory variability creates a pricing matrix that’s further detailed on the Lambda pricing page.

• Concurrency pricing
  “Provisioned Concurrency” mode pricing calculates the price from the time it’s enabled until disabled. Concurrency mode keeps lambda functions ready and removes any startup time from duration mode.

  Lambda concurrency pricing is as follows:

  • Provisioned Concurrency is $0.0000041667 for every GB-second
  • Requests are $0.20 per 1M requests
  • Duration is $0.0000097222 for every GB-second

  The AWS pricing page includes further details and examples of the pricing matrix. Learn more on the Lambda pricing page.

• Built-in auto scaling
  In a traditional hosted infrastructure, there comes a time where you may need to worry about performance and scaling. As the traffic and usage of your application increase, you may need to add more hosted servers to your infrastructure to keep up with demand. Self-managed scaling can cause failures and bottlenecks for your users. Lambda takes care of scaling automatically when needed, removing additional cognitive overhead.

Cons

• Inconsistent local development workflow.

  You can write Lambda function code locally and test it in isolation. Still, you won’t be able to simulate a production environment locally without creating your hacked-together version of Lambda.

Lambda Key Concepts: Code and Triggers

Lambda has two main concepts: code and triggers. Code is self-explanatory. In our case, it’s the JavaScript code that you write and upload to Lambda to produce your desired behaviors.

Once uploaded, the code won’t execute on its own. This is where triggers come in. Triggers are events fired by other AWS services that pass data to the Lambda function for execution.

Some example triggers are seen when:

• an HTTP request to AWS API Gateway fires Lambda code
• an event is fired on an interval, like a cron job from CloudWatch Events
• a DynamoDB table is updated and triggers Lambda code

Lambda code function signature

You define a Lambda function by exporting a regular function from JavaScript that matches the expected Lambda signature:

exports.myLambdaFunction = (event, context, callback) => {
   // Use callback() and return
}

The function receives three arguments:

• event: a key-value pair dictionary of “trigger data” that Lambda passes to the function.

• context: AWS internal information such as AWS request ID, Lambda expiration timeout, and Log info. For more info, see the Lambda docs.

• callback: a standard async JavaScript callback handler. For more info see the Lambda docs

Continue reading
Create Serverless Microservices with Node.js and AWS Lambda
on SitePoint.