AWS Lambda: the server that wasn't there
Tim Wagner told the crowd in Las Vegas on November 13, 2014, that nobody was going to use his new service for video transcoding. The runtime ceiling was 60 seconds, memory topped at a gigabyte, and concurrency was capped at 25 simultaneous requests per account. AWS Lambda, he explained, was a glue service — an event handler, a way to stitch other AWS services together without standing up a single machine.
Wagner had proposed the service a year earlier through a PRFAQ, Amazon’s internal ritual of forcing engineers to write a fictional press release before a line of code is written. The problem he was solving was peculiar in its banality: AWS customers were running fleets of EC2 instances around the clock just to handle intermittent events — a file uploaded here, a DynamoDB row changed there — because that was the smallest unit of compute available. An EC2 instance billed by the hour whether it ran code or not. Jeff Barr, AWS’s longtime chronicler, recalls a 2013 meeting where Wagner illustrated the alternative by gesturing upward, as though tossing code into the air: the cloud would catch it, run it, and bill for the milliseconds it consumed.
What Lambda delivered at launch was a stripped-down architecture: write a function in Node.js — the only supported language in November 2014 — point it at an event source from a short list (Amazon S3, DynamoDB, or Kinesis), and wait. When the event fired, Lambda ran the function in an isolated environment, billed in 100-millisecond increments, and discarded the container when the work was done. No operating system to manage. No autoscaling configuration. No floor on cost: if your function never triggered, you paid nothing.
That last part — scale to zero — was the structural novelty. EC2’s model assumed compute was a resource you provisioned and held; Lambda’s model assumed compute was a utility you consumed on demand, like electricity metered by the watt-second. The difference sounds minor until you are running a service that handles ten requests on Tuesday and ten million on Saturday.
Wagner was wrong about the video transcoding, which became one of Lambda’s canonical use cases once Amazon lifted the runtime ceiling to 15 minutes and removed the concurrency caps. The name, at least, was accurate: Lambda comes from the λ-calculus tradition of anonymous functions — computations not bound to any particular identity, defined entirely by what they do rather than what they are called.
The word “serverless” didn’t fully attach to the model until Amazon API Gateway launched in July 2015, giving Lambda functions a public front door and touching off a naming debate that has never quite resolved. Martin Fowler and Mike Roberts later drew the useful distinction between Backend-as-a-Service (offloading state and identity to managed platforms) and Functions-as-a-Service (offloading compute itself) — Lambda being the canonical instance of the latter. What both share is the same premise Wagner had sketched in that PRFAQ: that infrastructure is a solved problem, and the interesting question is what happens when you stop thinking about it.
The servers didn’t disappear. They just moved somewhere you couldn’t see them.
Sources
- Amazon Web Services Announces AWS Lambda — AWS Press Center — official announcement dated November 13, 2014; initial capabilities, 100ms billing model, event triggers.
- AWS Lambda turns ten — AWS Blog — Jeff Barr’s account of the 2013 meeting with Tim Wagner, the PRFAQ origin, and the “toss code into the air” illustration.
- Serverless Architectures — Martin Fowler — BaaS vs FaaS distinction, API Gateway’s July 2015 launch, architectural implications of the serverless model.
- AWS Lambda — Wikipedia — lambda calculus naming etymology, launch date, Node.js as the initial runtime.