When serverless fits a production platform

Problem this guide solves

Teams pick Lambda, Azure Functions, Cloud Run or Function Compute because the slide said “no servers,” then discover a timeout, a VPC ENI delay, or a concurrency quota during the first peak. The problem is matching the unit of work to a product whose limits you have actually read.

If the comparison of operating surface is what you need, use Kubernetes vs serverless. If a function already throttles, use quota exhaustion.

Assumptions

• You can name the unit of work (HTTP request, queue message, file event, scheduled job) and a maximum duration you will accept.
• You have read the current limit page for that runtime and hosting plan. Azure Functions Consumption, Premium and Dedicated do not share one timeout. Cloud Run request timeout is not Lambda’s limit.
• You are not using this page to size GPU training. That is GPU and AI cost governance.

How the products differ

These are four products, not one “serverless.” Do not copy a Lambda retry setting onto Azure Functions or Function Compute.

Product	What scales	Limits live on
AWS Lambda	Concurrent executions of a function	Lambda quotas (timeout, payload, burst concurrency, VPC)
Azure Functions	The hosting plan you chose	Scale and hosting (Consumption vs Premium vs Dedicated)
Cloud Run	Container instances serving requests or jobs	Cloud Run timeout, concurrency per instance, CPU allocation, VPC connector / Direct VPC
Function Compute	Invocations in an Alibaba Cloud region	Function Compute limits and networking on the Alibaba help site for the edition you run

Documented product behavior: each vendor publishes maximum timeout, payload, concurrency and VPC rules. Those numbers change. Read the page for the runtime you chose. Do not treat a blog post’s “15 minutes” as Azure or Cloud Run policy.

Concrete examples

Fits. A queue consumer that resizes an object and writes the result, finishes well inside the documented timeout, and can retry safely because the write is idempotent. Lambda with SQS, Azure Functions with a queue trigger, Cloud Run with a Pub/Sub push, or Function Compute with MNS are the usual mappings. Cold start is acceptable or you pay for provisioned concurrency (Lambda) or minimum instances (Cloud Run).

Does not fit. A WebSocket or gRPC worker that must hold a client connection for tens of minutes. A chatty VPC microservice that already runs 24/7 on three nodes. A training job that needs a GPU for hours. Those belong on nodes (Kubernetes or VMs), not on an invocation product.

Borderline. An HTTP API with steady daytime traffic. Calculate: reserved or committed nodes versus function duration charges plus provisioned concurrency. Do not assume serverless is the low-cost option.

Decision filter

Keep the function or request-driven container if all of these are true:

• Work finishes inside the documented timeout for that product and plan.
• Cold start is acceptable or mitigated by a paid warm pool the vendor documents.
• You can accept the provider’s retry and idempotency model (Lambda event source mapping, Azure Functions retry, Cloud Run retry, Function Compute retry are not the same).
• Payload and VPC attachment rules on the current limit page match the design.

If any item fails, use nodes. Engineering recommendation: a VPC microservice that already runs 24/7 on three nodes is usually cheaper and simpler as a Deployment than as thousands of warmed functions.

Trade-offs

• Idle cost. Functions can scale to zero. Nodes do not. Steady high RPS often reverses that and costs less on reserved capacity.
• Operations. You lose SSH and node-level agents. You gain a concurrency quota and a timeout. Debugging is logs and traces, not a shell on the box.
• Networking. VPC-attached Lambda, Azure VNet integration, Cloud Run Direct VPC / connector, and Function Compute VPC all have documented cold-start or ENI behaviour. Treat them as product-specific, not portable.
• Kubernetes still exists. Sidecars, custom CNI and DaemonSets are reasons to stay on a cluster. See Kubernetes cost allocation if the alternative is a shared cluster.

Failure modes

• Throttle. Account or regional concurrency is exhausted. Invocations fail or queue. That is a quota incident, not a code bug. See quota exhaustion.
• Timeout. The vendor kills the invocation. Retries can amplify load on a downstream that is already slow.
• Non-idempotent retry. A payment or email send fires twice because the trigger retries on a 5xx you thought was safe.
• Warm-pool spend. Provisioned concurrency or minimum instances sit idle and show up as a cost spike. Treat them as reserved capacity.
• Two autoscalers. A custom scaler plus the vendor’s concurrency control will fight. Same class of failure as autoscaling failure on a VM group.

Implementation and validation

1. Write the unit of work, timeout you need, and retry contract in the ADR.
2. Open the current limit page for the product and plan. Copy the timeout, payload and concurrency numbers into the ADR with the date you read them.
3. Confirm the regional concurrency or equivalent quota before a launch:

# AWS: current account-level concurrent executions quota (interpret the Applied value)
aws service-quotas get-service-quota \
  --service-code lambda \
  --quota-code L-B99A9384

If Applied is 1000 and a retry storm needs 4000, invocations throttle. That is a quota problem, not a code problem.

Azure: check the Functions plan and regional limits on the scale page, not the AWS quota code. Google Cloud: Cloud Run quotas in the console or gcloud run services describe. Alibaba Cloud: Function Compute quota in the console for that region.

4. Load-test to the concurrency you expect, including a forced cold start.
5. Confirm a failed invocation is idempotent or is not retried.
6. Alert on throttles and on warm-pool spend, not only on 5xx.

GPU training does not belong here. Use GPU cost governance. Pattern comparison: Kubernetes vs serverless.