AWS Lambda — One Function, Billed by the Tenth of a Second

AWS Lambda was announced on 13 November 2014, at Amazon's re:Invent 2014 conference, and released the same day as a preview. It ran a piece of code — a function — in response to an event, and charged only for the requests and the time the code actually ran, in units of 100 milliseconds. There was no server to choose, size or patch. Lambda left preview and was declared ready for production on 9 April 2015; support for a second language, Java, followed on 15 June 2015.

The idea now goes by the name serverless. In November 2014 it was a narrow service: one language, a 60-second limit and three regions.

What was announced

Jeff Barr's post on the AWS blog that day opened with the goal: to let developers focus on their code in a cloud environment where scalability and reliability could be "simply taken for granted". Accounts from the conference put the announcement in Werner Vogels's keynote on the second day, which also introduced the EC2 Container Service for running Docker containers.

The preview had clear limits:

The memory setting did more than set memory. According to Barr, it also determined the share of CPU, network and I/O bandwidth a function received. The free tier's compute allowance depended on the memory chosen for the same reason.

How it worked

A Lambda function was a stateless piece of code. It could not keep durable data on the machine it ran on; Barr's post said functions should use S3 or DynamoDB instead. AWS started copies when events arrived and stopped them when they were done.

The examples were about reacting to things that had already happened inside AWS: an image uploaded to an S3 bucket that needed a thumbnail, a change in a DynamoDB table, a record arriving on a Kinesis stream. Barr stressed that there were no EC2 instances to launch or manage and no capacity to reserve. The bill covered the work alone.

That billing was the real change. Since S3 in 2006, AWS had sold capacity by the gigabyte-month and the instance-hour. Lambda sold it by the request and the tenth of a second.

From preview to production

On 9 April 2015 Barr announced that Lambda was in full production. The same update added:

• Synchronous invocation, so a caller could wait for a function's result instead of only firing an event
• Amazon SNS notifications as a trigger
• Calling functions from the AWS Mobile SDK for Android and iOS
• A simpler permission model built on a single IAM role
• A default limit of 100 concurrent executions per account, up from 50 during the preview

Java was not yet in that release; the post listed it as coming soon. It arrived on 15 June 2015, when Barr wrote that developers could now write Lambda functions in Java 8.

The first decade

When AWS marked Lambda's tenth anniversary, Barr recalled that it started from an informal conversation with Tim Wagner about letting developers focus on code rather than infrastructure, after which Wagner wrote the PRFAQ — Amazon's internal press-release-and-FAQ proposal — for the service. The anniversary post listed what came after the preview, year by year:

The billing unit is the clearest thread: from 100 ms in 2014 to 1 ms in 2020. AWS also gave a usage figure for 2024 — 1.5 million users and tens of trillions of invocations a month. That is AWS's own count.

Where Lambda sits

Lambda did not invent the idea of handing code to a platform and not managing servers. Google App Engine had done that for whole web applications in 2008. What Lambda changed was the unit — a single function, triggered by an event and billed per call — and that unit is what the word serverless came to mean.

It arrived in the same week as AWS's container service, and in the same year Google open-sourced Kubernetes. Functions and containers offered two different answers to the same question — how to run code without managing a whole machine — and the container answer had been made practical by Docker the year before.

The company is covered on Amazon, and the wider sequence on the cloud computing timeline.