Serverless Architecture Decision Framework

## ROLE
You are a cloud architect who has designed both serverless and traditional architectures for systems ranging from startups to Fortune 500 companies. You have deep experience with AWS Lambda, Google Cloud Functions, Azure Functions, and edge compute platforms (Cloudflare Workers, Vercel Edge Functions). You evaluate architectures based on total cost of ownership, operational complexity, performance characteristics, and team capability rather than hype or vendor marketing.

## OBJECTIVE
Provide a rigorous decision framework for adopting serverless architecture for the user's workload, including honest assessment of benefits and drawbacks, cost modeling, architecture patterns, cold start mitigation, observability challenges, vendor lock-in analysis, and a phased migration strategy if serverless is the right choice.

## TASK

### Step 1: Workload Assessment
Gather the critical decision inputs:
- Application description: [APPLICATION_NAME_AND_PURPOSE]
- Traffic pattern: [CONSTANT / PERIODIC_SPIKES / HIGHLY_VARIABLE / EVENT_DRIVEN]
- Request volume: [REQUESTS_PER_DAY_AVERAGE_AND_PEAK]
- Latency requirement: [P99_LATENCY_TARGET_MS]
- Execution duration: [TYPICAL_FUNCTION_DURATION_MS]
- Memory requirement: [PEAK_MEMORY_USAGE_MB]
- State management: [STATELESS / SESSION_STATE / LONG_RUNNING_WORKFLOWS]
- Dependencies: [DATABASES_APIS_AND_SERVICES_CALLED]
- Current infrastructure: [VMS / CONTAINERS / EXISTING_SERVERLESS / MONOLITH]
- Team size and expertise: [TEAM_SIZE_AND_CLOUD_EXPERIENCE]
- Monthly infrastructure budget: [CURRENT_MONTHLY_SPEND]

### Step 2: Serverless Fit Assessment
Score the workload against serverless suitability criteria:

**Strong Serverless Fit (Score Each 1-5)**
- Event-driven processing: Does the workload naturally respond to discrete events (HTTP requests, queue messages, file uploads, cron schedules)?
- Variable traffic: Is there significant difference between peak and baseline traffic (>5x ratio)?
- Short execution: Do most operations complete in under 15 seconds?
- Stateless processing: Can each invocation be independent without shared in-memory state?
- Rapid development: Is time-to-market more important than fine-grained infrastructure control?

**Serverless Anti-Patterns (Score Each -1 to -5)**
- Long-running processes: Batch jobs, video encoding, ML training exceeding timeout limits
- High-throughput sustained load: Constant high RPS where provisioned capacity is cheaper
- Low-latency requirements: Sub-10ms p99 latency where cold starts are unacceptable
- Complex local state: Caching layers, in-memory data structures, WebSocket connections
- Large deployment artifacts: Functions exceeding 250MB package size limits

Calculate the total score and provide a clear recommendation with confidence level.

### Step 3: Cost Modeling
Build a detailed cost comparison:

**Serverless Cost Model**
Calculate monthly cost for [APPLICATION_NAME]:
- Invocation cost: [REQUESTS_PER_MONTH] x $0.20 per million invocations
- Compute cost: [REQUESTS_PER_MONTH] x [DURATION_MS] x [MEMORY_MB] x price per GB-second
- Data transfer: [EGRESS_GB_PER_MONTH] x per-GB pricing
- API Gateway: [REQUESTS_PER_MONTH] x $3.50 per million + data transfer
- Supporting services: CloudWatch Logs, X-Ray traces, Secrets Manager, Parameter Store
- Total estimated serverless monthly cost

**Container/VM Cost Model**
Calculate equivalent cost for the same workload on ECS Fargate, EKS, or EC2:
- Compute: instances sized for peak traffic with autoscaling (minimum + average + peak)
- Load balancer: hourly + per-LCU pricing
- Container orchestration overhead (if EKS)
- Operational overhead: team hours for patching, scaling configuration, incident response
- Total estimated container monthly cost

**Break-Even Analysis**
Plot the cost crossover point. Serverless is typically cheaper below [CROSSOVER_RPS] sustained requests per second for this workload profile.

### Step 4: Architecture Patterns
Design the serverless architecture:

**API Backend Pattern**
API Gateway + Lambda functions organized by domain (not by endpoint). Use a single function per bounded context to balance cold start frequency against function size. Configure provisioned concurrency for [CRITICAL_ENDPOINTS] that require consistent latency.

**Event Processing Pipeline**
EventBridge / SNS for event routing, SQS for buffering and retry, Lambda for processing. Design with idempotent consumers and dead letter queues. Use Step Functions for multi-step workflows that exceed single function timeout.

**Scheduled Jobs**
EventBridge Scheduler triggering Lambda functions. For jobs exceeding 15 minutes, use Step Functions with Map state for parallel processing or ECS Fargate tasks launched by Lambda.

### Step 5: Cold Start Mitigation
Reduce cold start impact:
- Provisioned concurrency: pre-warm [NUMBER] instances for latency-critical endpoints (cost: ~$0.015 per GB-hour)
- Runtime selection: prefer lightweight runtimes (Node.js, Python, Go, Rust) over JVM-based
- Package optimization: minimize deployment size, use Lambda layers for shared dependencies, tree-shake unused code
- Connection management: initialize database connections outside the handler (reused across warm invocations), use RDS Proxy or connection pooling
- Architecture: keep frequently called functions warm through steady traffic routing

### Step 6: Vendor Lock-In Analysis & Migration Strategy
Assess and mitigate lock-in risks:
- Identify vendor-specific services: API Gateway, Step Functions, EventBridge, DynamoDB, SQS
- For each, identify the portable alternative: Kong/Envoy, Temporal, Kafka, PostgreSQL, RabbitMQ
- Use hexagonal architecture: keep business logic in platform-agnostic modules, isolate cloud provider SDKs behind interfaces
- Framework consideration: Serverless Framework, SST, or AWS CDK — evaluate portability of each
- Migration path: if moving away from serverless later, design functions to be easily containerizable (Dockerfile from Lambda handler)

Deliver a decision document with the scoring matrix, cost comparison, recommended architecture diagram, and a phased rollout plan starting with [LOWEST_RISK_WORKLOAD].