- a table is updated in Amazon DynamoDB
- an object in an Amazon S3 bucket is modified
- a message arrives in an Amazon Kinesis stream
- a custom event is received from another app or service
This is Amazon's way of delivering a microservices framework far ahead of its competitors. Currently only Node.js is supported for the preview but there are plans to offer more languages and events as the service matures.
So the next logical question is, when should I use AWS Lambda over EC2 or Beanstalk? The FAQ is chock-full of info but I think the docs do a great job explaining this:
When you use Amazon EC2 instances directly, you are responsible for provisioning capacity, monitoring fleet health and performance, and using Availability Zones for fault tolerance. AWS Elastic Beanstalk offers an easy-to-use service for deploying and scaling web applications in which you retain ownership and full control over the underlying Amazon EC2 instances. AWS Lambda is a higher-level service that offers convenience in executing code in exchange for flexibility. You cannot log onto compute instances, customize the operating system or language runtime, or store data on local drives after your function completes execution. In exchange for giving up the flexibility of Amazon EC2, AWS Lambda performs operational and administrative activities for you, including capacity provisioning, monitoring fleet health, applying security patches, deploying your code, running a web service front end, and monitoring and logging your functions. AWS Lambda provides easy scaling and high availability to your code without additional effort on your part.
Demo Use Case
There’s been a lot of talk at Appirio and Topcoder about Lambda and how it can be leveraged for scalable, on-demand compute resources. I wanted to explore using Lambda as a queue to kick off the processing of code submissions. So when a member uploads code for a challenge to S3, the Lambda function grabs the code and pushes it to a github repo for further processing. The video and code below walks through this use case.
‘Github Pusher’ Lambda Function
To interact with Lambda functions you can either use the handy-dandy AWS Lambda (web) console or the AWS CLI. For this demo we are going to create and run a Lambda function uisng the console. It’s just easier to demo.
Disclaimer: This is not production quality code and is meant for demo purposes only. Some values have been hardcoded to make it easier to grok. For setup, configuration and security of AWS resources, please see the docs.
One of the benefits of Lambda is that you don’t have to scale your Lambda functions as usage increases, AWS does this for you. In order for AWS to spin up new instances “within a few milliseconds”, Lambda functions are stateless and must have all the required libraries as part of the uploaded code (in your node_modules directory). It is possible to use native libraries but you’ll need to build them against the Amazon Linux libraries. I initially tried to use nodegit but encountered too many errors while trying to run the code on an EC2 instance. I didn't have a lot of confidence that if I did fix the issue on EC2 the Lambda instance would work.
The code for the Lambda function (index.js). There are a few included libraries but this is the bulk of the code.
There you have it... "Node.js meets IFTTT as a service" as Adrian Cockcroft put it in a recent VentureBeat article.