DevOps

Serverless: Lambda, Cloud Functions

iRobot processes data from millions of Roomba robots via Lambda: each robot sends events, Lambda processes them without managing servers. Zero engineers spend time on capacity planning for robot traffic. Serverless is not a technology - it is a decision to buy operational simplicity instead of building it.

**Coca-Cola** automated vending machines via Lambda + IoT Core: each transaction is a Lambda invocation; 65% infrastructure cost reduction versus EC2 servers.
**Capital One** built its entire banking platform on Lambda - 1000+ Lambda functions, fully serverless backend; cold start solved with Provisioned Concurrency for user-facing APIs.
**Nordstrom** uses Step Functions for order processing: ValidateOrder - ChargeCard - UpdateInventory - SendConfirmation in parallel - full execution visibility in the AWS console.

Cold Start

Cold start is the latency on the first Lambda invocation when a new execution environment is initialized. Layers: JVM startup (Java/Kotlin: 500ms-5s), module loading (Node.js: 100-500ms), Python import (50-200ms), ARM64 Graviton2 is 20% faster than x86.

Cold start optimization priority: 1) Move initialization outside handler. 2) Use ARM64 (Graviton) runtime. 3) Keep package size minimal (tree-shaking). 4) Use Provisioned Concurrency only for user-facing APIs where cold start is visible.

What happens when Lambda is not invoked for 15 minutes?

Event-Driven Architecture

Event-driven architecture with Lambda: components react to events rather than direct calls. Sources: S3 events (file upload), SQS messages (queue), EventBridge (scheduled/custom events), DynamoDB Streams (database changes), API Gateway (HTTP requests).

SQS + Lambda + DLQ is the standard pattern for reliable async processing: SQS provides at-least-once delivery with configurable retry, Lambda scales concurrently with queue depth, DLQ captures messages that failed all retries for forensics.

What is a Dead Letter Queue (DLQ) in the SQS + Lambda context?

Step Functions

AWS Step Functions is an orchestrator for complex workflows of Lambda functions. It defines a state machine in JSON/YAML with branching, parallel execution, retry logic, and wait states - all with full visual execution history.

Step Functions Express Workflows are 100x cheaper than Standard Workflows but do not guarantee exactly-once execution. Use Standard for payment workflows; Express for high-volume event processing.

What is the advantage of Step Functions over manually coordinating Lambda functions via SQS?

Production Limits

Lambda limits that drive architectural decisions: timeout 15 minutes (solution: Step Functions or ECS Fargate), concurrent executions 1,000 per region (solution: reserved concurrency per function), payload 6MB sync / 256KB SQS (solution: S3 for large payloads), container image 10GB, deployment package 50MB zipped.

Lambda economics: compute cost is almost zero for infrequent workloads. The real cost at scale is data transfer (S3 events, VPC NAT Gateway) and concurrency limits causing throttling.

Serverless is always cheaper than traditional servers

Lambda is cheaper at unpredictable load with significant idle time. At constant high throughput, EC2 or ECS Fargate is typically more cost-effective.

Capital One calculated that processing 1 billion events/day on Lambda was cheaper than EC2. But a steady 10,000 RPS API is cheaper on EC2 than Lambda, because Lambda's per-request pricing exceeds EC2 amortized cost at that volume.

Lambda timeout of 15 minutes is exceeded by a video transcoding job. What is the correct solution?

Key Ideas

**Cold start** - 100ms-5s delay on first invocation; solved with Provisioned Concurrency for user-facing APIs, SnapStart for Java; SDK initialization outside the handler is mandatory.
**Event-driven** - Lambda reacts to S3, SQS, EventBridge, DynamoDB Streams; SQS+Lambda+DLQ is the reliable queue pattern with retry and failure analysis.
**Limits** - 15-minute timeout, 1,000 concurrent; Step Functions for workflows, ECS for long-running tasks; Lambda is cheaper than EC2 only at variable load.

Вопросы для размышления

If an API receives 1,000 RPS constantly - Lambda or ECS Fargate? Work through the cost calculation.
How do you transfer 1GB of data between two Lambda functions when the payload limit is 6MB?
Under what conditions do Step Functions Standard Workflows justify the cost of $0.025 per 1,000 transitions?