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.
• Size GPU training on GPU and AI cost governance.

How the products differ

These are four products, each with its own limits. Do not copy a Lambda retry setting onto Azure Functions or Function Compute.

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). An invocation product will hit the duration limit.

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. There is no 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 each VPC attachment as specific to that product.
• 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. Treat it as a quota incident. Check the applied concurrency before you change the function. 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. Treat it as a quota incident and check the Applied value first.

Azure: check the Functions plan and regional limits on the scale page. The AWS quota code above applies to Lambda. 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, warm-pool spend and 5xx.

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