#AWS #Lambda – Run Code in the Cloud

We want to make it even easier for you to build applications that
run in the Cloud. We want you to be able to focus on your code,
and to work within a cloud-centric environment where scalability,
reliability, and runtime efficiency are all high enough to be simply
taken for granted!

Today we are launching a preview of AWS Lambda, a brand-new way to build and run
applications in the cloud, one that lets you take advantage of your
existing programming skills and your knowledge of AWS. With
, you simply create a function, give it
permission to access specific resources, and then connect the
function to your AWS resources. Lambda will automatically run code
in response to modifications to objects uploaded to Amazon Simple Storage Service (S3) buckets,
messages arriving in Amazon Kinesis streams, or table updates in
Amazon DynamoDB.

Lambda is a zero-administration compute platform. You don’t
have to configure, launch, or monitor EC2 instances. You don’t have to
install any operating systems or language environments. You don’t
need to think about scale or fault tolerance and you don’t need to
request or reserve capacity. A freshly created function
is ready and able to handle tens of thousands of requests per hour
with absolutely no incremental effort on your part, and on a very
cost-effective basis.

Let’s dig in! We’ll take a more in-depth look at Lambda,
sneak a peek at the programming model and runtime environment, and then walk through a
programming example. As you read through this post, keep in mind that
we have plenty of items on the Lambda roadmap and that what I am
able to share today is just the first step on what we expect to be an
enduring and feature-filled journey.

Lambda Concepts

The most important Lambda concept is the Lambda function, or function for short. You write
your functions in Node.js (an event-driven, server side implementation
of JavaScript).

You upload your code and then specify context information to
AWS Lambda to create a function. The context information specifies
the execution environment (language, memory requirements, a timeout
period, and IAM role) and also points to the function you’d like to
invoke within your code. The code and the metadata are durably
stored in AWS and can later be referred to by name or by
ARN (Amazon Resource Name).
You an also include any necessary third-party libraries in the upload (which takes the form of a
single ZIP file per function).

After uploading, you associate your function with specific AWS resources (a
particular S3 bucket, DynamoDB table, or Kinesis stream). Lambda will then arrange
to route events (generally signifying that the resource has changed) to
your function.

When a resource changes, Lambda will execute any functions
that are associated with it. It will launch and manage compute
resources as needed in order to keep up with incoming requests. You
don’t need to worry about this; Lambda will manage the
resources for you and will shut them down if they are no longer
needed.

Lambda is accessible from the AWS Management Console, the AWS SDKs and the AWS Command Line Interface (CLI). The
Lambda APIs are fully documented
and can be used to connect existing code editors and other development tools to Lambda.

Lambda Programming Model
Functions are activated after the associated resource has been
changed. Execution starts at the designated Node.js function and
proceeds from there. The function has access (via a parameter
supplied along with the POST) to
a JSON data structure. This
structure contains detailed information about the change (or other
event) that caused the function to be activated.

Lambda will activate additional copies of function
as needed in order to keep pace with changes. The functions cannot
store durable state on the compute instance and should use S3 or
DynamoDB instead.

Your code can make use of just about any functionality that is
intrinsic to Node.js and to the underlying Linux environment. It can
also use the AWS SDK for JavaScript in Node.js to make calls to other AWS services.

Lambda Runtime Environment
The context information that you supply for each
function specifies a maximum execution time for the function. This
is typically set fairly low (you can do a lot of work in a couple of
seconds) but can be set to up 60 seconds as your needs dictate.

Lambda uses multiple IAM roles to manage access to your
functions and your AWS resources. The
invocation role gives Lambda permission to
run a particular function. The execution role
gives a function permission to access specific AWS
resources. You can use distinct roles for each function in order
to implement a fine-grained set of permissions.

Lambda monitors the execution of each function and stores
request count, latency, availability, and error rate metrics
in Amazon CloudWatch. The metrics
are retained for 30 days and can be viewed in the Console.

Here are a few things to keep in mind when as you start to think
about how you will put Lambda to use:

  • The context information for a function specifies the amount of
    memory needed to run it. You can set this to any desired
    value between 128 MB and 1 GB. The memory setting also determines
    the amount of CPU power, network bandwidth, and I/O
    bandwidth that are made available to the function.
  • Each invocation of a function can make use of up to 256
    processes or threads. It can consume up to 512 MB of local storage and
    up to 1,024 file descriptors. It can also create up to 10
    simultaneous outbound network connections.
  • Lambda imposes a set of administrative limits on each AWS
    account. During the preview, you can have up to 25 invocation
    requests underway simultaneously.

Lambda in Action
Let’s step through the process of creating a simple function using the
Management Console. As I mentioned earlier, you can also do this from the SDKs and the
CLI. The console displays all of my functions:

I simply click on Create Function to get started. Then I fill in all
of the details:

I name and describe my function:

Then I enter the code or upload a ZIP file. The console also offers a choice of
sample code snippets to help me to get started:

Now I tell Lambda which function to run and which IAM role to use
when the code runs:

I can also fine-tune the memory requirements and set a limit on execution time:

After I create my function, I can iteratively edit and test it from within
the Console. As you can see, the pane on the left shows a sample of the JSON
data that will be passed to my function:

When the function is working as expected, I can attach it to an event
source such as Amazon S3 event notification. I will to provide an invocation role
in order to give S3 the permission that it needs to have in order to invoke the
function:

Lambda collects a set of metrics for
each of my functions and sends them to Amazon CloudWatch. I can
view the metrics from the Console:

On the Roadmap
We have a great roadmap for Lambda! While I won’t spill all of the beans today,
I will tell you that we expect to add support for additional AWS services and
other languages. As always, we love your feedback; please leave a note in the
Lambda Forum.

Pricing & Availability
Let’s talk about pricing a bit before wrapping up! Lambda uses a fine-grained pricing
model. You pay for compute time in units of 100 milliseconds and you pay for each request.
The Lambda free tier includes 1 million free requests per month and up to
3.2 million seconds of compute time per month depending on the amount of
memory allocated per function.

Lambda is available today in preview form in the US East (Northern Virginia), US West (Oregon), and Europe (Ireland) Regions.
If you would like to get started,
register now.

Jeff;

Related posts