AWS Lambda is a service that can run application code on top of Amazon cloud infrastructure, releasing developers from worrying about infrastructure management. This includes operational and administrative tasks such as resource provisioning and scaling, monitoring system health, applying security patches to the underlying resources, and code deployment.

AWS Lambda was released in 2014 and since then its popularity and adoption has grown quickly. Serverless architecture and microservices have been around for several years, so why the current hype around Lambda?

In this article we will discuss AWS Lambda, its features, benefits and several use cases. Finally, we will write a couple of Lambda functions to see how it looks in action.

Microservices and Serverless Architectures

Before delving into Lambda, let’s define two important concepts.

Microservices architecture is a loosely coupled Service Oriented Architecture (SOA) with bounded contexts. In practice, this means a microservice only does as few things as necessary and works within as limited an area of the domain as possible. In other words, it helps isolate functions and uses asynchronous communications , making it independent and as simple as possible.

Serverless architecture leverages third-party services such as Lambda to eliminate the need to establish and maintain the traditional infrastructure sitting behind an application. This approach can significantly reduce time to market as well as operational cost and complexity.

Learn more about the advantages and disadvantages of serverless architecture.

Features and Use Cases

Lambda allows the use of serverless and microservices programming architectures to support ‘Function as a Service’ (FaaS), allowing developers to focus on writing code.

Simple Development and Deployment

AWS Lambda functions can be implemented in JavaScript, Python or any JVM language, such as Java, Scala, Closure and Groovy. At the same time, Lambda functions can be bundled with other deployment artifacts such as libraries and even Linux executable files. In the latter case, the Lambda function can execute other processes by calling such executables. From the practical perspective, to define a new Lambda function or update an existing one, you need to upload your code as a zip or jar archive, then AWS Lambda does the rest.

For simple functions, you can use the internal source code editor that is available online directly in the Lambda Console. Essentially, the labmda function code runs on Amazon Linux, and as such can use any tools included with the OS (including, for example, installation of python packages using pip, or node.js packages using NPM).

Automatic Scaling and Fault Tolerance

AWS Lambda automatically scales the infrastructure depending on the number of requests, without any additional configuration from your side. It is no longer necessary to size your deployment’s capacity for traffic peaks – you simply develop a function to serve one request. Lambda creates as many instances as required to serve the incoming requests in parallel. Lambda maintains compute capacity across multiple Availability Zones in each region to make sure that the service is robust, eliminating infrastructure points of failure, such as individual machine or data center downtimes.

Event Driven Model

AWS Lambda functions can be triggered by different events, including events from AWS services such as S3 (such as changes to S3 buckets), DynamoDB (such as updates to a table in the database), CodeCommit, CloudWatch (such as as a response to an alarm), and AWS IoT. Lambda also allows functions to be triggered as a response to inbound HTTP requests (API Gateway), as a response to inbound messages (SNS, Kinesis), or by a scheduled event. The AWS mobile SDK conveniently supports invocation of Lambda functions from mobile apps.

AWS APIS versus OpenStack APIs – learn all about the differences here

Security

Access to other AWS services, such as DynamoDB or CloudWatch is controlled through IAM roles. This prevents unnecessary data exposure to certain Lambda functions and lowers the attack surface of the microservice in the event of a security breach.

Cost Efficiency

While most traditional PaaS providers, for example, Heroku, require monthly subscriptions, AWS Lambda pricing is based on usage. The Free Tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month. Pricing above the Free Tier usage is based on used memory, the number of requests, and execution duration rounded up to the nearest 100 milliseconds as in these Amazon Lambda pricing examples. Savings can also be obtained since there are no charges between requests (as opposed to keeping up a running EC2 instance, for example), and no need to pay operational staff to set up and manage physical servers or EC2 instances.

Use Cases

AWS Lambda can be used in a number of different use cases. It is easy to get started with, and can run with minimal operating costs. It is ideal for low traffic applications, enterprise IT services, and spiky workloads. Other potential use cases for Lambda include analyzing logs or other data on-the-fly, processing objects uploaded to S3, checking the health and availability of other resources and sites, and so on.

Specifically, AWS Lambda can be used for running serverless web sites. While the static content can be hosted on S3, the web front end can send requests to Lambda functions via API Gateway. Lambda functions can contain the application logic and use DynamoDB or RDS for persistent data. For AWS S3, API Gateway, and Lambda you pay only for the traffic and the number of requests. RDS and DynamoDB require fixed monthly payments.

AWS Lambda Limitations

The AWS Lambda Limits page lists resource limitations per function and per account. For example, the maximum execution duration per request is set to 300 seconds.

In general, serverless architecture is not efficient for running long-lived applications; in such cases, containers or EC2 instances are more appropriate. Another interesting limit is the Lambda function deployment package size, which is set to 50MB (compressed), and the non-persistent scratch area available for the function to use – 500MB.

Another significant issue to consider is AWS Lambda Cold Start. It takes some time for the Lambda function to handle a first request, because Lambda has to start a new instance of the function. The cold start can be a real problem for your function, if at any time you expect a fast response and there are no active instances of your function. The latter can happen for low traffic scenarios, when AWS terminates instances of your function when there have been no requests for a long time. One workaround is to send a request periodically to avoid the cold start and to make sure that there is always an active instance, ready to serve requests.

Other functional limitations include:

Lambda functions are short-lived, therefore they need to persist their state somewhere. Available options include using DynamoDB or RDS tables, which require fixed payments per month. Lambda functions write their logs to CloudWatch, which currently is the only tool to troubleshoot and monitor your functions.



Practical Examples

Example #1: A simple HTTP handler as Lambda

In this example, we will create a simple HTTP handler (service) that will respond to any HTTP method with a simple hard-coded message.

To create a new Lambda function, open the AWS Console and select AWS Lambda service. Select Create a Lambda function (or select Get Started Now if you do not have any Lambda functions yet). On the Select blueprint page, select the Blank Function blueprint. On the On the Configure triggers page, click the empty box and select API Gateway from the drop-down list, then click Next : On the next page, set these parameters: On the next page, set these parameters: In the API Name field, the name of your service, for example, MyHTTPService. From the Security drop-down list, select Open. Click Next. On the next page, enter the function name, for example, “myHTTPService”. From the On the next page, enter the function name, for example, “myHTTPService”. From the Runtime drop-down list, select Node.js 4.3 , then enter the following Lambda function code:

exports.handler = ( event , context, callback) => {

callback( null , {

statusCode: ‘200’ ,

body: ‘Hello from MyHTTPService’ ,

headers: {

‘Content-Type’ : ‘text/html’ ,

} ,

} );

} ; On the Lambda function handler and role page, select Create new role from template(s) from the Role drop-down list, then enter myHTTPServiceRole in the Role name field. Our Lambda function does not require any special permission and basic Lambda permissions such as logging to CloudWatch are automatically added: Click Next, then click Create function. Click Next, then click Create function.

On the next page, find the HTTPS endpoint for the API Gateway:

When you click the link, your browser displays message returned by our Lambda function:

Hello from MyHTTPService

On the Monitoring tab, you can find different metrics for your Lambda function. You can also view logs of your function in CloudWatch:

Note that we used the “Blank Function” blueprint and there is another blueprint “microservice-http-endpoint”, which allows creating a simple backend (read/write to DynamoDB) with a RESTful API endpoint using Amazon API Gateway. You can use this blueprint instead. The only difference is that it contains a Node.js code to handle different HTTP methods (GET/PUT/POST/DELETE) and it requires an additional permissions to access DynamoDB.

Example #2: A simple S3 object handler as Lambda

In this example, we will implement a simple S3 object handler using a Lambda function – this handler will be triggered every time a new object is added to an S3 bucket, and copy it to a second bucket. First, you’ll need to create two new buckets in S3. The first one will be your source bucket and the second will be your destination.

Note: Both buckets and our Lambda functions should reside in the same AWS region.

We will use the existing blueprint “s3-get-object-python”. Select the source bucket and select Object Created (all) from the Event Type drop-down list. Also select Enable trigger:

Use the following Python code. Set the dst variable to the name of your destination bucket:

from __future__ import print_function



import json

import urllib

import boto3



print(‘Loading function’)



s3 = boto3.client(‘s3’)



def lambda_handler(event, context):



src = event[‘Records’][0][‘s3’][‘bucket’][‘name’]

dst = ‘…’

key = urllib.unquote_plus(

event[‘Records’][0][‘s3’][‘object’][‘key’].encode(‘utf8’))



response = s3.get_object(Bucket=src, Key=key)

s3.put_object(Bucket=dst,

Key=key,

ContentType=response[‘ContentType’],

Body=response[‘Body’].read())

return response[‘ContentType’]

Then create the function as usual. By default, the blueprint we used assigns a read-only permission for S3. To fix this, open IAM service, select “Roles”, find a new created role for your function and find an attached policy with name “AWSLambdaS3ExecutionRole-…”.

Edit it,and add write permission (“s3:PutObject”):

{

“Version”: “2012-10-17”,

“Statement”: [

{

“Effect”: “Allow”,

“Action”: [

“s3:GetObject”,

“s3:PutObject”

],

“Resource”: “arn:aws:s3:::*”

}

]

}

After that you can test your function: upload an arbitrary file to the source bucket and check that the same file appears in the destination bucket. Our Lambda function does not transform the object. Your Lambda function can do the necessary transformation, for example, generating thumbnails for every image uploaded to the source bucket.

Summary

Though PaaS and “Serverless” are not new concepts, they are still evolving with a long road ahead. Nonetheless, with AWS’s massive market share, Lambda is one of the accelerators driving a disruptive change in IT infrastructure management.

With AWS Lambda, the cloud is not only about removing the hassle of traditional data center management, and not just about “infrastructure-as-code”. Lambda takes cloud, automation, and DevOps to the next level — completely re-defining IT infrastructure.

Finally, a simple way to build and scale infrastructure with AWS-compatible services on-prem