Serverless
Chapter 15: Serverless Architecture
Section titled “Chapter 15: Serverless Architecture”Building Applications Without Managing Servers
Section titled “Building Applications Without Managing Servers”15.1 What is Serverless?
Section titled “15.1 What is Serverless?”Serverless computing is a cloud computing execution model where the cloud provider runs the server, and dynamically manages the allocation of machine resources. You write code, and the provider handles everything else.
Traditional vs Serverless =========================
TRADITIONAL: +--------------------------------------------------+ | You manage: | | - Server provisioning | | - OS updates | | - Scaling | | - Capacity planning | | - Patching | +--------------------------------------------------+
SERVERLESS: +--------------------------------------------------+ | Cloud provider manages: | | - Server provisioning | | - OS updates | | - Scaling | | - Capacity planning | | - Patching | +--------------------------------------------------+
You manage: Code only!15.2 How Serverless Works
Section titled “15.2 How Serverless Works”Function as a Service (FaaS)
Section titled “Function as a Service (FaaS)” Serverless Flow ==============
User Request | v +-----------------+ | API Gateway | +-----------------+ | v +-----------------+ | Function | (AWS Lambda, GCP Cloud Functions) | (Container) | - Spawns on demand | - Run code | - Scales automatically | - Return result| - Pay per invocation +-----------------+ | v +-----------------+ | Cloud Services | | - Database | | - Storage | | - Auth | +-----------------+Scaling Behavior
Section titled “Scaling Behavior” Serverless Scaling =================
Requests: 1 -> 10 -> 100 -> 1000 -> 10000
Traditional: +--------------------------------+ | Capacity: Fixed | | More requests = slower | | or fail | +--------------------------------+
Serverless: +--------------------------------+ | Instances: 1 -> 10 -> 100 | | Each request gets resources | | Auto-scales to meet demand | +--------------------------------+
No concurrency limits (within reason)!15.3 Major Serverless Platforms
Section titled “15.3 Major Serverless Platforms”Cloud Provider Comparison
Section titled “Cloud Provider Comparison”| Provider | Service | Languages |
|---|---|---|
| AWS | Lambda | Node.js, Python, Java, Go, .NET, Ruby |
| Cloud Functions | Node.js, Python, Go, Java, .NET | |
| Microsoft | Azure Functions | C#, JavaScript, Python, Java, PowerShell |
| Cloudflare | Workers | JavaScript, Rust, C++ |
AWS Lambda Features
Section titled “AWS Lambda Features”| Feature | Description |
|---|---|
| Languages | Node.js, Python, Java, Go, .NET, Ruby |
| Runtime | Up to 15 minutes execution |
| Memory | 128MB to 10GB |
| Packaging | ZIP or container image |
| Cold Start | 100ms to seconds |
| Pricing | Per request + execution time |
15.4 Serverless Architecture Patterns
Section titled “15.4 Serverless Architecture Patterns”15.4.1 REST API
Section titled “15.4.1 REST API” Serverless REST API ==================
+--------------------------------------------------+ | API Gateway | +--------------------------------------------------+ | +---------------+---------------+ | | | v v v +--------+ +--------+ +--------+ | GET | | POST | | DELETE | | /users | | /users | | /users | +--------+ +--------+ +--------+ | | | v v v +--------+ +--------+ +--------+ | Lambda | | Lambda | | Lambda | +--------+ +--------+ +--------+ | | | +---------------+---------------+ | v +-------------+ | DynamoDB | +-------------+15.4.2 Event Processing
Section titled “15.4.2 Event Processing” Event Processing ================
Event Source Lambda Trigger Processing +---------+ +----------+ +---------+ | S3 | -----> | Lambda | -----> | Send | | Upload | Object | Resize | | to SNS | +---------+ Created +----------+ +---------+ | +---------+ | Email | | Service | +---------+15.4.3 Batch Processing
Section titled “15.4.3 Batch Processing” Scheduled Functions ===================
+--------------------------------------------------+ | CloudWatch Events | | (Every hour) | +--------------------------------------------------+ | v +-----------+ | Lambda | | Process | | Batch Job | +-----------+ | v +-----------+ | Database | | (Write) | +-----------+
Use cases: - Daily reports - Data cleanup - Batch analytics15.5 Benefits of Serverless
Section titled “15.5 Benefits of Serverless”Advantages
Section titled “Advantages”| Benefit | Description |
|---|---|
| No server management | Focus on code |
| Auto-scaling | Handles any load |
| Pay per use | No idle capacity |
| Faster deployment | Quick to ship |
| Built-in availability | High availability |
| Reduced costs | For sporadic workloads |
15.6 Challenges
Section titled “15.6 Challenges”Limitations
Section titled “Limitations”| Challenge | Description |
|---|---|
| Cold starts | Initial latency |
| Execution limits | Timeouts, memory limits |
| Vendor lock-in | Cloud-specific APIs |
| Testing | Harder to test locally |
| Debugging | Distributed debugging harder |
| State | Can’t maintain in-memory state |
Handling Cold Starts
Section titled “Handling Cold Starts” Cold Start Timeline ===================
Request 1 (Cold): +--------------------------------------------------+ | Invoke | Download | Init | Execute | Response | | | Runtime | Init | | | | | (2-5 sec)| | | | +--------------------------------------------------+
Request 2-100 (Warm): +--------------------------------------------------+ | Invoke | Execute | Response | | | | | | | ~10ms | | +--------------------------------------------------+
Mitigation: - Provisioned concurrency (pay for warm) - Keep functions warm (ping) - Design for eventual consistency15.7 When to Use Serverless
Section titled “15.7 When to Use Serverless”Good Fit
Section titled “Good Fit”| Use Case | Why Serverless |
|---|---|
| Web APIs | Variable traffic |
| Event processing | S3 triggers, queues |
| Scheduled tasks | Cron jobs |
| Real-time processing | Chat, notifications |
| Mobile backends | Variable load |
| Proof of concept | Fast to build |
Not Good Fit
Section titled “Not Good Fit”| Use Case | Why Not |
|---|---|
| Long-running processes | 15-minute timeout |
| Consistent high traffic | May be cheaper with dedicated |
| Predictable workloads | Reserved instances cheaper |
| Stateful applications | Hard to maintain state |
| Low-latency requirements | Cold starts |
15.8 Serverless vs Containers
Section titled “15.8 Serverless vs Containers”Comparison
Section titled “Comparison”| Aspect | Serverless | Containers |
|---|---|---|
| Management | Provider | You/Orchestrator |
| Scaling | Automatic | Manual/auto |
| Startup | Cold start | Fast (if warm) |
| Cost | Pay per use | Always running |
| Control | Limited | Full |
| State | External | In-memory possible |
Decision Framework
Section titled “Decision Framework” Choose Serverless when: ====================== - Traffic is variable - Want to move fast - Don't want ops overhead - Event-driven workloads
Choose Containers when: ====================== - Consistent traffic - Need full control - Long-running processes - Complex orchestration15.9 Best Practices
Section titled “15.9 Best Practices”Tips for Serverless
Section titled “Tips for Serverless”| Practice | Description |
|---|---|
| Single responsibility | One function per task |
| Stateless | Use external state store |
| Minimal dependencies | Faster cold starts |
| Async where possible | Queue-based processing |
| Proper sizing | Right memory for cost |
| Monitoring | Use provider tools |
Summary
Section titled “Summary”Key serverless concepts:
- Function as a Service - Code runs on demand
- Auto-scaling - Handles any load automatically
- Pay per use - Cost-effective for variable workloads
- Cold starts - Initial latency, plan for it
- Stateless - Use external services for state
- Vendor lock-in - Consider when choosing
- Event-driven - Works great with events