Skip to content

CONCEPT Cited by 1 source

Serverless Compute

Serverless compute is a model in which the provider runs customer code on demand on managed, shared infrastructure, scaling it from zero to arbitrary concurrency without the customer provisioning, patching, or sizing servers. Customer pays only for actual execution, not for idle capacity.

Defining properties (as articulated by the 2014 Lambda PR/FAQ)

  1. No server management. "Lambda eliminates the operational costs and learning curve for developers by turning any code into a secure, reliable and highly available cloud service with a web accessible end point within seconds." No instance type selection, no cross-AZ failover setup, no OS / runtime / library patching.
  2. Scale range includes zero. Architected such that "one application invocation per month and 1,000 per second are both well supported" on the same code path. See concepts/scale-to-zero.
  3. Fine-grained pay-per-use. Billing at small execution quanta (100ms → 1ms at Lambda); no idle charge; "customers cannot overprovision or underutilize by design." See concepts/fine-grained-billing.
  4. Stateless by contract. Persistent state goes to managed storage (S3 / DynamoDB / etc.); local FS is scratch. This is what enables the provider to scale arbitrarily by just running more copies. See concepts/stateless-compute.
  5. Event-driven. Invoked by other managed services' events (object PUT, stream update, message, schedule, HTTP request). The provider routes events; the user writes a handler.

(Source: sources/2024-11-15-allthingsdistributed-aws-lambda-prfaq-after-10-years)

What customer workload this collapsed

Lambda's origin observation: "we saw that customers had entire EC2 fleets sitting idle, waiting to run simple functions like writing to a database or processing a file." Serverless is the primitive that productises that workaround — the user stops owning the fleet, the provider owns placement and packing.

Trade-offs

  • Cold start is fundamental to the model: if you're scaling to zero, the first request after idle has to bring capacity up. See concepts/cold-start.
  • Isolation density is a provider responsibility: Lambda started with single-tenant EC2 per customer, moved to Firecracker micro-VMs for multi-tenant density. See concepts/micro-vm-isolation.
  • Observability and debuggability trade against black-box operations — the doc explicitly flagged the need to "retain full visibility over the functional and operational performance of their code."
  • Stateful workloads and "lift-and-shift" use cases don't fit; the PR/FAQ explicitly redirects those to Beanstalk/EC2.

Seen in

Last updated · 200 distilled / 1,178 read