Serverless
Serverlessrunning code without a server you can see, patch, or pay for while idle. Billed per run rather than per hour.Full glossary entryIntroduced in Serverless computing allows developers to deploy and run application code without provisioning, configuring, or managing underlying servers. Instead of paying for allocated virtual machine capacity that runs around the clock, you provide your application logic and define event triggers. The cloud platform provisions compute resources on demand, executes your code, and meters billing in millisecond increments strictly for the execution duration. When traffic drops to zero, compute allocation scales down to zero, and billing ceases entirely.
While the financial appeal of paying only for active compute is substantial, serverless architecture fundamentally reshapes how software is engineered. Building effectively on serverless platforms requires understanding execution lifecycles, initialization latencies, runtime limits, and downstream database saturation.
Functions
At the center of serverless compute is the Functiona single-entry-point piece of code the provider runs in response to a trigger, with a maximum run time and no memory between runs.Full glossary entryIntroduced in Serverless (often referred to as Function-as-a-Service or FaaS). A function is a discrete block of application code with a single entry point, packaged with its runtime dependencies and wired to an event source. Triggers span a wide spectrum: incoming HTTP requests via an API gateway, messages landing on a queue, files uploaded to an object store, change-data-capture records from a database, or scheduled cron timers. When an event fires, the provider instantiates a sandboxed execution environment, passes the event payload to your handler, and releases the resources when execution completes.
Function execution is strictly stateless. Providers make no guarantees that subsequent invocations will execute on the same physical host or reuse the same memory space. Local disk storage is ephemeral and cleared between executions. Any state that must persist across requests—such as user sessions, transactional data, or uploaded assets—must be written to an external database or object bucket.
Cold starts
When a function is invoked after a period of inactivity, or when incoming traffic exceeds existing concurrency, the provider must allocate a microVM, boot the language runtime, download application assets, and execute top-level initialization code before handling the event. This initial latency penalty is a Cold startthe delay when a function runs after a quiet period and the provider has to start a container and load the code first.Full glossary entryIntroduced in Serverless.
Cold start duration varies widely depending on the runtime environment and package footprint: lightweight runtimes like Node.js, Go, or Python often initialize in tens of milliseconds, whereas heavier runtimes like Java or .NET with substantial dependency injection frameworks can take several seconds. Once initialized, an execution environment remains warm for a short window, allowing subsequent invocations to execute almost instantaneously. For latency-sensitive public APIs, providers offer pre-warmed capacity (often called provisioned concurrency or minimum instances), which eliminates cold starts at the expense of reintroducing an idle hourly reservation charge.
Limits
Serverless functions operate within strict guardrails enforced by the provider:
- Execution timeouts: Functions enforce hard execution ceilings, typically between 5 and 15 minutes. Long-running data imports, extensive video encoding tasks, or persistent background daemons will be abruptly terminated when they reach the timeout threshold.
- Resource boundaries: Providers enforce fixed limits on maximum memory allocation, virtual CPU shares, and ephemeral disk space.
- Downstream connection exhaustion: Serverless functions scale horizontally in seconds, rapidly creating hundreds or thousands of concurrent instances in response to traffic spikes. However, traditional relational databases enforce strict connection limits. If a thousand function instances attempt to open dedicated database connections simultaneously, they will overwhelm the database server and trigger widespread connection timeouts. Mitigating this requires intermediate connection poolers or queue-buffered consumer designs.
Choose serverless functions when workloads meet four criteria. Otherwise, adopt container runtimes.
- The execution duration finishes well within the provider's hard function timeout window.
- The workload is triggered by asynchronous events or bursty traffic patterns rather than running continuously.
- Low or erratic traffic makes scaling down to zero a tangible financial advantage.
- Downstream dependencies (such as relational databases) can absorb the rapid concurrency scaling without connection exhaustion.
Managed containers
Between raw serverless functions and full Kubernetes clusters sits an increasingly popular middle tier: the Managed container runtimea service that runs a container image and scales the copies with traffic, often to zero, with no cluster to own. Where most new HTTP services should start.Full glossary entryIntroduced in Serverless. These services execute standard container images on demand, automatically scaling instances based on incoming request volume while abstracting away underlying server nodes and cluster management.
Managed container runtimes combine the operational simplicity of serverless with the flexibility of containers. Unlike functions, which enforce proprietary packaging formats and rigid language runtimes, managed containers run any binary, library, or framework that can be packaged into an OCI image. Crucially, single container instances can process multiple concurrent HTTP or gRPC requests simultaneously, dramatically reducing connection thrashing against downstream databases while preserving scale-to-zero cost efficiency during idle hours.
Event-driven design
Serverless architectures naturally guide engineering teams toward event-driven topologies. Rather than orchestrating workflows through synchronous HTTP calls between microservices, components communicate by publishing events to topics and queues. An image uploaded to a storage bucket automatically triggers an image resizing function, which emits an event to a topic, which in turn triggers notification and indexing services in parallel.
While this pattern provides exceptional decoupling and independent scaling, it shifts complexity into system observability. When a business transaction spans multiple decoupled functions and message queues, diagnosing failures requires comprehensive distributed tracing and structured log aggregation. As described on the messaging page, incorporating robust dead-letter queues and workflow orchestrators is essential for maintaining operational visibility across complex event flows.
Terms introduced
- Serverless: running code without a server you can see, billed per run rather than per hour.
- Function: a single-entry-point piece of code the provider runs in response to a trigger.
- Cold start: the delay when a function runs after a quiet period and the provider has to start a container first.
- Managed container runtime: a service that runs a container image, scaling the copies with traffic, with no cluster to own.
How providers do it
Serverless architectures across AWS, Azure, and Google Cloud have converged around two primary models: event-driven function handlers (FaaS) and serverless container runtimes. While both models provide automated scaling down to zero and sub-second billing increments, the providers take different approaches to concurrency and event routing.
| Concept | AWS | Azure | Google Cloud |
|---|---|---|---|
| Function execution | AWS Lambda | Azure Functions | Cloud Run functions |
| Managed container runtime | AWS App Runner, Amazon ECS on Fargate | Azure Container Apps | Cloud Run services |
| HTTP ingress endpoint | Amazon API Gateway, Lambda function URLs | HTTP trigger bindings | Cloud Run default HTTPS service URL |
| Event source triggers | Event source mappings (SQS, S3, DynamoDB) | Input bindings (Service Bus, Blob, Event Grid) | Eventarc triggers |
| Scheduled cron triggers | Amazon EventBridge Scheduler | Azure Functions timer triggers | Google Cloud Scheduler |
| Pre-warmed instances | Provisioned Concurrency | Always-ready instances (Premium/Flex tiers) | Minimum instances (--min-instances) |
| Batch job execution | AWS Batch, Fargate standalone tasks | Azure Container Apps jobs, Azure Batch | Cloud Run jobs, Google Cloud Batch |
| Workflow state machine | AWS Step Functions | Azure Durable Functions, Azure Logic Apps | Google Cloud Workflows |
| Centralized event bus | Amazon EventBridge | Azure Event Grid | Google Cloud Eventarc |
Every product name and technical mapping above is confirmed against provider documentation. Specific maximum execution timeouts and warm-instance pricing structures are marked unconfirmed in the provider tabs below.
A fundamental architectural distinction exists in request concurrency:
- AWS Lambda allocates one isolated execution environment per concurrent request. If 500 requests arrive at the same millisecond, Lambda spins up 500 distinct microVM instances, each opening its own dedicated TCP connections to downstream databases and caches.
- Google Cloud Run defaults to multiplexed concurrency, allowing a single container instance to process up to 80 (or more) concurrent requests simultaneously over shared memory and connection pools. This drastically reduces the number of container instances required for high-throughput HTTP workloads, preventing downstream database connection exhaustion.
- AWS
- Azure
- Google Cloud
What this maps to: AWS Lambda is the function product. Managed containers come as AWS App Runner or ECS on Fargate. Step Functions orchestrates several of either into a flow.
| Concept | On AWS | Status |
|---|---|---|
| Function | A Lambda function, deployed as a zip or a container image | confirmed |
| Triggers | API Gateway or a Lambda function URL for HTTP; SQS, SNS, S3, EventBridge, DynamoDB Streams, Kinesis for events; EventBridge Scheduler for timers | confirmed |
| Keeping containers warm | Provisioned concurrency, billed for the time the containers are reserved | confirmed |
| Maximum run time | Fifteen minutes | unconfirmed; check current quotas |
| Concurrency limit | A per-region account limit, shared across all functions, raisable by request. Reserved concurrency caps one function so it cannot starve the others | confirmed |
| Managed container runtime | App Runner builds and runs a container from an image or a repository, with autoscaling and a public URL. Scale-to-zero pauses compute but still bills for provisioned memory | unconfirmed; check current pricing |
| Orchestration | Step Functions runs a state machine that calls functions, waits, retries, and branches | confirmed |
| Event bus | EventBridge routes events between services and from SaaS sources | confirmed |
Their vocabulary
| Standard term | Their term |
|---|---|
| Trigger | Event source, or event source mapping for queues and streams |
| Warm container | Execution environment |
| Managed container runtime | App Runner, or a Fargate service |
Where to look
The Lambda console shows invocations, errors, duration, and throttles per function. Each invocation's output ends up in CloudWatch Logs. To follow one request across several functions, use X-Ray.
Last verified: never.
What this maps to: Azure Functions for functions, Azure Container Apps for managed containers, and Durable Functions or Logic Apps for orchestration.
| Concept | On Azure | Status |
|---|---|---|
| Function | An Azure Function inside a function app, which groups functions sharing a runtime and plan | confirmed |
| Hosting plan | Consumption and Flex Consumption bill per execution and scale to zero. Premium keeps pre-warmed instances and removes cold starts at a fixed cost. Dedicated runs on an App Service plan | confirmed |
| Triggers | HTTP, timer, Storage queue and blob, Service Bus, Event Hubs, Event Grid, Cosmos DB change feed, and more, through bindings that also connect outputs | confirmed |
| Keeping containers warm | Premium plan's always ready instances, or Flex Consumption's always-ready setting | unconfirmed; check current plan features |
| Maximum run time | Depends on the plan; Consumption has a default and a maximum, Premium and Dedicated can be unbounded | unconfirmed; check current limits |
| Managed container runtime | Container Apps, running images with HTTP or event-driven scaling through KEDA, scaling to zero, with revisions and traffic splitting | confirmed |
| Orchestration | Durable Functions writes an orchestration as code with checkpoints; Logic Apps is a visual workflow designer with connectors | confirmed |
| Event bus | Event Grid routes events from Azure services and custom sources to functions, webhooks, and queues | confirmed |
Their vocabulary
| Standard term | Their term |
|---|---|
| Trigger | Trigger binding |
| Pricing model | Hosting plan |
| Managed container runtime | Container Apps |
| Deployment slot for testing | Slot, on plans that support them |
Where to look
Application Insights, attached to the function app, shows invocations, failures, duration, and dependencies per function.
Last verified: never.
What this maps to: Cloud Run is the centre of Google Cloud's serverless offering and covers both shapes on the core page. Cloud Run services run a container image and scale with traffic, including to zero. The function shape is Cloud Run functions, formerly Cloud Functions, which wrap a function in the same runtime.
| Concept | On Google Cloud | Status |
|---|---|---|
| Function | A Cloud Run function, deployed from source in a supported language; Google builds the container | confirmed |
| Managed container runtime | A Cloud Run service, from any container image that listens on a port | confirmed |
| Triggers | HTTPS directly; Eventarc for events from Pub/Sub, Cloud Storage, Audit Logs, and other sources; Cloud Scheduler for timers | confirmed |
| Keeping containers warm | Minimum instances on the service, billed while idle | confirmed |
| Maximum run time | A per-request timeout you set, with a hard ceiling; Cloud Run jobs for work that runs to completion rather than serving requests | unconfirmed; check the current ceiling |
| Concurrency | A Cloud Run instance handles many requests at once, up to a per-instance concurrency you set. This lowers the connection count the core page warns about | confirmed |
| Orchestration | Workflows chains services and APIs with retries and branches | confirmed |
| Older platform | App Engine, Google's original platform as a service, still supported | confirmed |
Their vocabulary
| Standard term | Their term |
|---|---|
| Function | Cloud Run function |
| Managed container runtime | Cloud Run service |
| Warm container | Minimum instances |
| Deployment of a service | Revision; traffic can be split between revisions |
Where to look
The Cloud Run console shows request count, latency, instance count, and cold-start-affected requests per service. Cloud Logging holds each request's output.
Last verified: never.