Functions as a service let you upload a handler and pay only while it runs. No servers to patch, no capacity to plan, and scaling from zero to thousands of copies is the platform's problem. That's real, and it's why functions are the default glue in cloud systems. But the three big clouds have built their function platforms on quite different execution models, and the model decides the cost, the cold starts and the failure modes.
The course's sync vs async and queues and workers lessons cover where event-driven code fits. This page compares the platforms.
Side by side
| AWS Lambda | Google Cloud Run functions | Azure Functions (Flex Consumption) | Self-hosted | |
|---|---|---|---|---|
| Execution model | One request per execution environment at a time (concurrency) | Deployed as a Cloud Run service, so an instance can take many requests | Configurable per-instance concurrency, Linux only | Knative or OpenFaaS on Kubernetes |
| Isolation | Firecracker microVMs (NSDI 2020) | Containers on Cloud Run | Containers on Azure's hosting | Whatever your cluster gives you |
| Scaling limits | 1,000 concurrent executions per Region by default; each function adds up to 1,000 environments every 10 seconds | Cloud Run's instance and concurrency settings | Up to 1,000 instances per app; a regional core quota shared by all Flex apps | Your cluster size |
| Cold-start tools | Provisioned concurrency; SnapStart for Java, Python and .NET | Minimum instances | Always-ready instances | Keep pods warm |
| What you pay per | Requests plus GB-seconds (pricing) | Cloud Run's request-based or instance-based billing | Execution time and executions, plus always-ready baseline (billing) | Cluster cost |