Serverless Computing: When and When Not to Use It
Evaluating serverless vs. containers, comparing major provider services, cold start challenges, cost implications, and how to pick the right compute model for your workload.
1. Core Compute Models Compared
The three dominant compute models span a spectrum from full control to zero management:
| Model | Management Scope | Scaling | Billing | Typical Use Cases |
|---|---|---|---|---|
| Virtual Machines | You manage OS, patches, runtime, apps | Manual or autoscaling groups | Per-second or per-hour | Long-running services, custom OS needs, full root access |
| Containers (ECS/EKS, ACI, Cloud Run) | You manage container image, platform manages orchestration | Scale to zero (managed) or manual | Per-second while running | HTTP APIs, background workers, microservices with custom runtimes |
| Serverless (Lambda, Azure Functions, etc.) | You manage only function code and config | Automatic, scales to zero | Per-invocation + resource-time | Event handlers, webhooks, scheduled jobs, lightweight APIs |
Key distinction: Serverless is a deployment and billing model, not a language or framework. The "functions" are just code units managed by a platform that provisions, scales, and bills automatically.
2. Major Serverless Platforms: Vendor Comparison
Each hyperscaler offers function-as-a-service (FaaS) with different runtimes, integration patterns, and pricing. Here is the current landscape:
| Provider | Service Name | Max Memory | Max Duration | Pricing (per GB-s) | Free Tier |
|---|---|---|---|---|---|
| AWS | Lambda | 10,240 MB | 15 minutes | $0.0000166667 | 1M invocations + 400K GB-s / month |
| Microsoft Azure | Azure Functions | 14,336 MB | 10 minutes (consumption) 60 minutes (premium) | $0.0000160 | 1M invocations + 400K GB-s / month |
| Google Cloud | Cloud Functions (2nd gen) | 16,384 MB | 60 minutes | $0.0000025 | 2M invocations + 360K GB-s / month |
| Oracle Cloud | OCI Functions | 1,024 MB (max 6 per function) | 5 minutes | $0.00000417 | 1K invocations / month |
| Alibaba Cloud | Function Compute | 16,384 MB | 60 minutes (container image) | $0.000016 | 1M invocations + 400K GB-s / month |
| IBM Cloud | Cloud Functions | 2,048 MB | 60 minutes | $0.00001111 | 5M invocations / month |
| Tencent Cloud | SCF | 16,384 MB | 60 minutes (container) | $0.00001666 | 1M invocations / month |
Runtime support comparison
| Provider | Native Runtimes | Custom Runtime | Container Image | Provisioned Concurrency |
|---|---|---|---|---|
| AWS Lambda | Node.js, Python, Java, Go, .NET, Ruby | Yes (custom runtime API) | Yes (up to 10 GB) | Yes (provisioned concurrency) |
| Azure Functions | Node.js, Python, PowerShell, Java, C#, .NET | Yes (custom handlers) | Yes | Yes (premium plan) |
| GCP Cloud Functions | Node.js, Python, Go, Java, .NET, Ruby, PHP | Yes | Yes (2nd gen) | Yes (min instances) |
| OCI Functions | Python, Node.js, Go, Java, Ruby | Yes | Yes (container images only) | Yes (pre-provisioned concurrency) |
| Alibaba FC | Node.js, Python, Java, PHP, C++, Go | Yes | Yes | Yes (provisioned concurrency) |
| IBM Cloud | Node.js, Python, Java, Go, Ruby, Swift | Yes | Limited | Limited |
| Tencent SCF | Node.js, Python, Java, C#, Go, PHP | Yes | Yes | Yes (provisioned concurrency) |
Recommendation: AWS Lambda and GCP Cloud Functions (2nd gen) lead in runtime flexibility and event integration. Azure Functions excels for .NET shops. OCI Functions is container-only but tightly integrated with Oracle Cloud. For non-US markets, Alibaba and Tencent offer strong local presence.
3. Serverless vs Containers vs VMs
Choosing a compute model is an architecture decision, not a trend. Here is how to evaluate:
| Factor | Serverless (FaaS) | Containers (managed) | Virtual Machines |
|---|---|---|---|
| Cold start | High (100ms - 5s+ depending on runtime) | Moderate (50ms - 2s) | None (always warm) |
| Scale to zero | Yes, automatic | Yes, on managed platforms | No |
| Billing granularity | Per-invocation | Per-second while running | Per-hour |
| Vendor lock-in | High | Moderate (container images portable) | Low |
| Debugging | Limited local parity | Good (local container run) | Full control |
| Custom dependencies | Limited (layers/custom runtimes) | Full (container image) | Full control |
| Event integration | Extensive (cloud-native events) | Moderate | Manual setup |
| Best for | Bursty, event-driven, glue | HTTP APIs, microservices | Stateful, long-running, custom OS |
Managed container options
If you want serverless benefits without FaaS cold starts, consider managed container platforms:
| Platform | Scale to zero | Pricing model | Notes |
|---|---|---|---|
| AWS Fargate | No (ECS/Fargate) | Per-vCPU-second | ECS or EKS, no cold start, no scale-to-zero |
| AWS App Runner | Yes | Per-second while serving | Build from source or container, scales to zero |
| Google Cloud Run | Yes | Per-second while serving | Knative-based, scales to zero, generous free tier |
| Azure Container Apps | Yes | Per-second while serving | Based on Dapr/KEDA, scales to zero |
| OCI Container Instances | No | Per-second | Simple container run, no orchestration |
Decision matrix: Use FaaS for event-driven glue and bursty workloads. Use Cloud Run / App Runner for HTTP APIs that need scale-to-zero without cold starts. Use Fargate / Container Instances for long-running services that need container flexibility.
4. When Serverless Wins
Serverless is excellent for:
| Use Case | Why Serverless Fits | Provider Strength |
|---|---|---|
| Infrequent jobs | Pay only when running; zero idle cost | All providers |
| Webhooks | Auto-scale on burst; event-native triggers | AWS Lambda + API Gateway |
| File processing (S3/Cloud Storage triggers) | Built-in object store event sources | AWS Lambda (S3 events) |
| Scheduled tasks (cron replacement) | No need to keep a process running | AWS Lambda (EventBridge), GCF (Pub/Sub) |
| Lightweight API backends | Scales with traffic; no capacity planning | AWS Lambda + API Gateway, Cloud Run |
| Real-time stream processing | Push-based event model | AWS Lambda (Kinesis/DynamoDB Streams), GCF (Pub/Sub) |
| Chatbot / voice assistants | Millions of users, zero sustained traffic | AWS Lambda (Lex), Azure Functions (Bot Service) |
| Image/video processing | Burst on upload; parallel processing | AWS Lambda + Step Functions, GCF |
When to pick a specific serverless platform
| Scenario | Recommended Platform | Why |
|---|---|---|
| AWS-centric stack, rich event sources | AWS Lambda + EventBridge + SQS/SNS | Deepest integration with all AWS services, largest ecosystem |
| .NET shop, Visual Studio integration | Azure Functions | Native .NET support, easy local debugging, Azure DevOps integration |
| Data pipelines on GCP, Pub/Sub events | Cloud Functions (2nd gen) | Built on Cloud Run, integrates with BigQuery, Pub/Sub, Vertex AI |
| Oracle Cloud workloads, OCI ecosystem | OCI Functions | Tight integration with Autonomous Database, Object Storage, Streaming |
| Low-latency API, scale to zero | Google Cloud Run or AWS App Runner | Container image support, near-zero cold starts with min instances |
| Multi-region global edge | Cloudflare Workers / Vercel | Edge runtime, sub-50ms cold starts globally |
Guidance: Serverless excels where you have unpredictable traffic, event-driven logic, or short-lived tasks. The cost alignment (pay-per-execution) is its most powerful feature for intermittent workloads.
5. When Containers Win
Serverless is a poor fit when you need:
| Requirement | Why Serverless Fails | Better Choice |
|---|---|---|
| Steady high-throughput | Billed per invocation can outcost reserved VMs | Fargate, Cloud Run with min instances, or VMs |
| Strict cold-start SLAs (<50ms) | Cold starts add hundreds of ms | Cloud Run (min instances=1) or Fargate |
| Long-running processes (>15 min) | Lambda caps at 15 minutes | Containers or VMs |
| Custom runtimes or binaries | Limited by supported runtimes | Container image support |
| Large dependency packages (>250 MB) | Layers add complexity | Container images (Cloud Run, App Runner) |
| Predictable constant traffic | No cost advantage over containers | Reserved instances or committed use discounts |
| Bare-metal networking or GPU | Not available in FaaS | VMs or GPU instances |
| Complex local debugging | Limited local simulation | Containers (run locally, deploy same image) |
6. Cold Start Deep Dive
Cold start is the initialization delay when a serverless platform spins up a new instance of your function. It is the primary performance trade-off of serverless.
Contributing factors
| Factor | Impact | Mitigation |
|---|---|---|
| Runtime/language | JVM/.NET ~ 3-5s; Node.js/Python ~ 100-500ms | Choose a lighter runtime or use container images |
| Deployment package size | Larger packages take longer to download/import | Minimize dependencies, use layers, trim unused code |
| Memory allocation | Higher memory = more CPU = faster init | Allocate more memory if cost permits |
| Initialization code | Heavy setup (DB connections, SDK init) runs per cold start | Lazy-load dependencies, reuse connections in global scope |
| VPC attachment | ENI provisioning adds 500ms-2s on AWS | Use VPC-less design, or provisioned concurrency for VPC functions |
Provisioned concurrency and warmed instances
| Provider | Feature | Use case |
|---|---|---|
| AWS Lambda | Provisioned Concurrency | Keep functions pre-initialized for predictable latency |
| AWS Lambda | SnapStart (Java only) | Snapshots JVM after init, reducing cold starts to <1s |
| Azure Functions | Premium plan | Always-warmed instances, VNET connectivity |
| GCP Cloud Functions | Min instances | Keep N instances always warm |
| OCI Functions | Pre-provisioned concurrency | Keep functions pre-initialized |
| Cloud Run | Min instances | Keep N containers always ready |
Cold start checklist: Measure p99 latency under load. Use provisioned concurrency/min instances for user-facing APIs. Optimize the global scope initialization. Avoid VPC unless necessary. Consider Cloud Run for HTTP workloads where cold starts matter.
7. Cost Modeling and Pricing Models
Serverless is cheap at low volume and can be expensive at sustained high volume. Model before choosing.
Pricing models across providers
| Provider | Pricing Components | Free Tier | Crossover Point |
|---|---|---|---|
| AWS Lambda | $0.20 per 1M requests + $0.00001667 per GB-s | 1M requests + 400K GB-s / month for 12 months | ~5M requests / 20M GB-s (vs. t4g.micro) |
| Azure Functions | $0.20 per 1M executions + $0.000016 per GB-s | 1M requests + 1GB-s / month free | ~6M requests / 16M GB-s |
| GCP Cloud Functions | $0.40 per 1M invocations + $0.0000025 per GB-s | 2M invocations + 360K GB-s / month | ~8M invocations (GCP is cheapest per GB-s) |
| OCI Functions | $0.00000417 per GB-s + $0.0000041 per invocation | 1K invocations per month | Very cheap, but limited free tier |
| Cloud Run | $0.000024 per vCPU-s + $0.0000025 per GB-s | 180K vCPU-s + 360K GB-s + 2M requests / month | Competitive with FaaS for HTTP workloads |
Cost comparison example
A function with 512 MB memory invoked 100 times/second with 100 ms duration:
# Approximate monthly cost (720 hours)
# AWS Lambda:
# 100 * 3600 * 24 * 30 = ~2.6M invocations
# Duration cost = 2.6M * 0.1s * 0.5GB * $0.00001667/GB-s
# Total ~ $640/month
# GCP Cloud Run (min_instances=0):
# Same compute = 2.6M * 0.1s * 0.5 vCPU * $0.000024/vCPU-s
# Plus request cost = 2.6M * $0.0000024
# Total ~ $1,050/month (but no provision time cost)
# Fargate (always on):
# 0.05 vCPU * 730 hours * $0.04048/vCPU-hr
# Plus 1GB memory * 730 * $0.004445/GB-hr
# Total ~ $140/month (but always running)Rule of thumb: Use serverless for bursty or low-trafficked workloads. For anything consistently above 10% of the month's free tier equivalent, calculate whether containers or reserved instances would be cheaper. The crossover point varies significantly by provider and workload profile.
8. Event Sources and Trigger Integration
Serverless functions are triggered by events. Each provider has a different event model and integration surface.
| Event Source | AWS Lambda | Azure Functions | GCP Cloud Functions | OCI Functions |
|---|---|---|---|---|
| Object storage | S3 Event Notifications | Blob Storage Events | Cloud Storage events | Object Storage events |
| Message queue | SQS, SNS | Azure Queue, Service Bus | Pub/Sub | Streaming, Queue |
| Database streams | DynamoDB Streams, RDS | Cosmos DB Change Feed | Firestore, BigQuery | Autonomous DB events |
| HTTP/Webhook | API Gateway | HTTP Trigger | HTTP Trigger | API Gateway |
| Scheduled (cron) | EventBridge (CloudWatch Events) | Timer Trigger | Cloud Scheduler | Events Service |
| File system | EFS mount (container) | Limited | Filestore | File Storage |
| IoT | IoT Core rules | IoT Hub | Cloud IoT Core | Limited |
| Event bus | EventBridge | Event Grid | Eventarc | Events Service |
Orchestration: For multi-step workflows, use Step Functions (AWS), Durable Functions (Azure), Workflows (GCP), or orchestrate with Apache Airflow on managed Kubernetes. Complex logic in a single function is an anti-pattern.
9. Vendor Lock-in and Portability
FaaS platforms are deeply integrated with their cloud's event model, IAM, and managed services. Lock-in is real.
| Strategy | Approach |
|---|---|
| Abstract the platform | Wrap function calls behind an internal interface you control |
| Minimize cloud-specific events | Standardize on HTTP/webhook triggers and message queues |
| Use container-based FaaS | Cloud Run, OCI Functions accept container images |
| Treat functions as glue | Keep business logic in portable code libraries, not in the function |
| Plan for portability | Avoid vendor-specific SDK calls inside functions |
Multi-cloud and hybrid options
| Framework | Description | Languages |
|---|---|---|
| Serverless Framework | Deploy to AWS, Azure, GCP, OCI with one config | Node.js, Python, Java, Go, .NET |
| AWS SAM | Serverless app model, AWS-only | Node.js, Python, Java, Go, .NET |
| Azure Functions Core Tools | Local dev and deployment, Azure-only | All Azure-supported languages |
| Google Cloud Functions Framework | Local testing, GCP or on-prem | Python, Go, Java, Node.js |
| Knative | Kubernetes-native serverless, any cloud | Any (container-based) |
Warning: No framework eliminates lock-in entirely. Multi-cloud adds operational complexity. Choose portability only when you have a real business requirement for it, not as a hypothetical.
10. Pitfalls and Best Practices
Serverless is powerful but easy to misuse. Here are the most common mistakes:
| Pitfall | Consequence | Solution |
|---|---|---|
| Long initialization in global scope | Every invocation pays the cost | Moved heavy init to lazy loading in the handler |
| No monitoring or logging | Hard to debug in production | Use structured logs, correlate with trace IDs, set alerts |
| Ignoring concurrency limits | Silent throttling at scale | Check default quotas, request increases, use provisioned concurrency |
| Putting everything in one function | Hard to maintain, slow cold starts | Decompose into small single-purpose functions |
| Not caching connections | Repeated DB/API connection overhead | Reuse clients outside the handler |
| Ignoring dead-letter queues | Failed events are lost | Configure DLQ for async invocations |
| VPC attachment by default | Adds seconds to cold starts | Only use VPC when accessing private resources |
Best practices summary
| Category | Practice |
|---|---|
| Design | Keep functions single-purpose, stateless, and short |
| Dependencies | Minimize packages, use layers, trim unused code |
| State | Externalize state to managed databases or caches |
| Error handling | Return structured errors, use DLQs, retry with backoff |
| Security | Principle of least privilege IAM roles per function |
| Monitoring | Logs, metrics, traces, and alerts per function |
| Testing | Local unit tests, integration tests with real event payloads |
| Deployment | Infrastructure as code, blue/green or canary deployments |
Final guidance: Serverless removes server management and scales to zero. It is excellent for event-driven workloads, APIs with variable traffic, and glue logic between services. It is a poor default for steady high-throughput systems or workloads with strict latency requirements at cold start. Always model your expected invocation count, duration, and memory before choosing serverless over containers.