The Serverless Promise
Serverless (Functions-as-a-Service) promises: deploy code, pay per execution, no servers to manage. AWS Lambda, Google Cloud Functions, and Azure Functions deliver on this.
Advantages:
- Pay only for execution: 1 million requests costs same whether you have 1 or 1000 functions
- Automatic scaling: no capacity planning needed
- No operations: AWS manages security patches, updates
- Fast to market: focus on code, not infrastructure
Disadvantages:
- Cold starts: first invocation takes 1-5 seconds (languages matter)
- Execution limits: Lambda has 15-minute timeout
- Vendor lock-in: Lambda code doesn't run elsewhere
- Debugging complexity: distributed logs, limited observability
- Stateless only: no long-running background jobs
The Container Advantage
Containers (Docker, Kubernetes) package applications with dependencies, running identically everywhere.
Advantages:
- Full control: run any code, language, framework
- Warm starts: containers start in seconds, respond immediately
- No artificial limits: run as long as needed
- Portability: same container runs on laptop, on-premise, cloud
- Resource efficiency: run multiple services per container
Disadvantages:
- Operations overhead: manage container orchestration, updates, security
- Higher baseline cost: even idle containers cost money
- Complexity: Kubernetes learning curve is steep
- Capacity planning: must predict and provision capacity
Cost Analysis
Serverless pricing (AWS Lambda):
- $0.20 per 1 million requests
- $0.0000166667 per GB-second
- 1 million monthly requests, 256MB memory, 1-second average = ~$30/month
Container pricing (AWS ECS/EKS):
- t3.small instance: ~$20/month (always-on cost)
- Data transfer: $0.02 per GB egress
- At 10 million monthly requests spread across instances = ~$100-200/month
For bursty traffic (few requests/day), serverless wins. For steady traffic (thousands/second), containers win.
When to Use Serverless
Ideal use cases:
- APIs with variable traffic
- Scheduled tasks (daily exports, cleanup)
- Webhooks and event handlers
- Image processing and file operations
- Light ETL jobs
Example: Razorpay webhook receiver. Receives unpredictable spikes, handles event processing, completes in <1 second.
When to Use Containers
Ideal use cases:
- Long-running services (web servers, APIs)
- Stateful applications
- Complex systems needing full OS access
- Teams preferring ops control
- Multi-region deployments
Example: Your main SaaS application. Receives steady traffic, requires low latency, needs fine-grained monitoring.
Hybrid Approach
Most production systems use both:
- Containers for core application (Next.js server, API)
- Serverless for background jobs (email sending, analytics)
- Serverless for webhooks (payment handlers, integrations)
This balances complexity and cost.
Migration Path
Start with containers if uncertain. Containers are forgiving:
- Move to serverless for specific workloads later
- No wasted learning on serverless-specific patterns initially
- Easier to debug and troubleshoot
As you grow, extract serverless-suitable work: scheduled tasks, webhooks, image processing.
The Cold Start Problem
Serverless cold starts hurt user experience. Mitigate by:
- Keeping functions small: smaller packages load faster
- Using compiled languages: Go, Rust beat Python, Node
- Provisioned concurrency: pay extra for warm functions
- Scheduled warmup: periodically invoke functions to keep warm
For user-facing APIs, containers beat serverless if response time matters.
Frequently asked questions
Can we run a Next.js app on serverless?
Yes, through Vercel's serverless functions or AWS Lambda. But traditional long-running connections (WebSockets, SSE) don't work. Better: host Next.js on containers, use serverless for specific functions. Vercel abstracts this complexity for convenience.
How do we handle databases with serverless?
Serverless requires managed databases (AWS RDS Proxy, Supabase) handling connection pooling. Traditional databases expect persistent connections; serverless functions create and destroy connections constantly. Connection overhead becomes significant.
Is Kubernetes necessary for containers?
For small scale (<10 containers), orchestration overhead outweighs benefits. Use AWS ECS, Docker Swarm, or managed services. Kubernetes makes sense at scale (100+ containers) with complex networking and orchestration needs.