Skip to main content
A function can run successfully and still be on the wrong backend. An authentication handler may need warm capacity. An image processor may need a particular container image and a large temporary working set. A private installation may value control over the runtime more than scale-to-zero. Choose the execution model and the invocation contract together. This article compares synchronous RequestResponse invocations. An asynchronous acceptance response, a queue consumer and a completed handler call are different contracts; the comparisons below do not make them interchangeable. Each comparison is between directed service adapters with Lambda as the origin. Lambda to Cloud Run is one adapter; Cloud Run by itself is the backend, not the complete adapter.

General trade-offs

The target environment determines which execution services are candidates. A hosting choice belongs to the function’s lifecycle configuration; it is not selected independently on each Invoke, and changing a backend does not move in-flight work. The Lambda service catalog identifies each environment’s directed mappings and their packaging, lifecycle and invocation behavior.

Invocation, packaging and capacity

Cloud Adapter preserves the supported Lambda request and response framing while routing the call to the selected execution service. Function readiness, successful transport and a successful handler result are three different observations. A function must be ready before routing is useful; an HTTP success can still carry FunctionError.

Operating responsibilities

For each role, grant only the access needed to operate that component. These assignments do not imply that standalone Cloud Adapter provides BYOC telemetry routing or customer-access approvals.

Google Cloud

Cloud Run

Cloud Run is the documented Google Cloud backend. Google operates its request-driven execution platform; your team supplies the function artifact, identity, resource settings and application recovery. It can fit container-packaged handlers whose memory, execution duration and supported Lambda invocation behavior fit the mapping. It does not supply arbitrary Kubernetes scheduling controls or strict fleet-wide admission merely because the function has a maximum-instance setting. Read the Cloud Run mapping for compute rounding, packaging and concurrency. Its temporary-file writes count against function memory. A handler that fits its heap allocation can still exhaust memory while creating scratch files. A response deadline can expire without terminating the handler, so retries must tolerate late or overlapping completion. See Cloud Run request timeouts.

Workload example: image processing

An infrequent handler includes native image libraries, reads a large input and writes a deterministic output object. It tolerates startup delay, but must preserve correct output after a retry. Cloud Run fits if the real image, largest allowed input and scratch-space demand fit the configured resource envelope. Measure startup after idle, startup after a rollout and execution time separately. Set a stable application job ID and commit output idempotently. A successful HTTP transport response is not proof of handler success; inspect FunctionError and the actual result object. Conversely, a caller timeout does not prove that nothing was written. The probe below distinguishes these observations. Compare configured warm capacity with the workload’s latency budget and idle cost. Keep downstream connection limits independent of the platform instance ceiling. During migration, route each new job ID to one destination, let prior work finish or explicitly retry it, and preserve the old artifact and route until results are accepted. External result objects need their own recovery and retention policy.

Try synchronous retry and completion

This probe checks one logical output across repeated synchronous invocations. It uses Lambda to Cloud Run as a concrete fixture, not a preferred adapter. Apply the same invocation and output checks to other candidates using their deployment and storage setup. It does not certify event-source delivery, asynchronous invocation, aliases or exactly-once execution.
1

Prepare an isolated function and result bucket

Use a disposable Google Cloud test deployment, a bucket named acme-adapter-trial-results that you own, and a function named tradeoff-thumbnail. Substitute your own globally unique bucket name throughout; do not reuse another application’s bucket or function.Deploy this Python handler with the google-cloud-storage dependency through your existing function deployment. Give its target workload identity access only to the test result bucket. Wait for the function to become ready and record its adapter endpoint.
The conditional object creation and content check provide this fixture’s idempotency. Cloud Adapter does not make arbitrary handler side effects idempotent. Before the first run, confirm the two tradeoff/image-100*.json objects do not exist.
2

Inspect the mapping and configure the caller

The AWS profile is the origin-facing identity accepted by the adapter. Google credentials belong to the function and adapter, not this caller. Profile inspection describes the mapping; it does not invoke the handler.
3

Invoke twice with the same job ID

Run this command twice, saving the second response to thumbnail-repeat.json:
Both calls should return no FunctionError and identify tradeoff/image-1001.json. Verify the actual object, not only the response:
Expected content is the fixture’s job_id and thumbnail-ok result. Use the AWS CLI invocation reference for its binary-payload and output-file conventions.
4

Test an ambiguous completion without automatic retries

Save and run the following client. The explicit endpoint is the client-specific alternative to AWS_ENDPOINT_URL_LAMBDA.
Wait for the fixture’s five-second delay to finish, inspect tradeoff/image-1002.json, and then repeat that job through the normal CLI invocation. The expected accepted result is one correct logical output. A timeout before the write is also possible; record whether the first attempt actually committed. Caller timeout is not a cancellation test.If the result is missing, wrong or conflicting, preserve the handler logs, request identity and target object evidence before retrying. Use adapter debugging to distinguish routing, handler and native-storage failures.
5

Clean up this trial

Stop callers, preserve the two response records, and remove only this trial’s two objects and function through their owning lifecycle. Retire the bucket only if it was created solely for the test and is empty. Remove temporary identity grants and clear AWS_ENDPOINT_URL_LAMBDA before returning to native AWS work.

Microsoft Azure

Functions, Container Apps and AKS

Use the Azure profiles to establish eligibility before pricing. A requirement for cluster-specific networking or scheduling can favor evaluating AKS; an application with compatible hosting requirements and no cluster operator can evaluate the managed choices. Neither is an across-the-board recommendation.

Workload example: interactive authentication

Consider a synchronous token-validation handler with quiet periods, sudden login bursts and a database with a limited connection budget. Compare Azure Functions Premium with Flex Consumption. Premium exposes a resource envelope and warm-capacity allocation that must be matched to the handler’s requirements. The application keeps its Lambda client and handler contract. Tensor9 packages the runtime and routes the supported invocation to Azure’s hosting service. Warm allocation reduces reliance on starting a new worker for the first request; it does not eliminate deployment or burst scale-out startup. Include idle-capacity charges in either plan’s configured cost. Measure the first call after idle, the first call after deployment and a burst larger than the warm fleet separately. Do not average those results into one latency number. A maximum-instance setting also needs a downstream connection budget: old and new deployments can overlap, and a replica ceiling is not proof of an exact simultaneous-request bound. Flex Consumption has its own code-package requirements and resource controls. Azure offers always-ready controls on Flex; this is not a universal warm-versus-cold product distinction. Compare the configured plans, packaging and measured behavior, including their warm allocation, rather than choosing from the names alone. See Azure hosting choices.

Check container isolation and downstream demand

For a handler using temporary files or process-local caches, test concurrent requests and a worker failure. On Container Apps, record how the configured workers share resources. On AKS, record the replica resources and node placement. The installed workload’s isolation behavior matters more than the word container in the product name. For either option, measure the deployment overlap as well as steady state: old and new workers can use database connections at the same time. Include image production, dependency updates, rollback artifacts and application-side idempotency in the operating record.

OCI

OCI Functions or OKE function Deployments

For a small synchronous transformation, test OCI Functions against the real package, first-call latency and response deadline. For a workload requiring a cluster placement or resource setting unavailable in that mapping, examine the OKE profile rather than assuming all Lambda configurations fit Functions. Compare the OCI Functions profile with the same handler contract. Both candidates need a failure test after a side effect but before the caller receives success. Keep application data outside temporary worker storage, preserve idempotency keys and verify the target result before retrying an ambiguous completion. Include native identity and the permitted database network path in the test, not only a no-op handler.

Scaleway

Serverless Containers, Knative or Kubernetes Deployments

For occasional internal jobs, compare the measured idle allocation and startup delay of all eligible options. For steady traffic on an operated cluster, compare allocated worker capacity with Knative’s platform costs and the managed service’s resource model. The Scaleway profile and cluster profiles define different operating responsibilities. Run the largest input, an overlapping retry and a deployment under traffic. A change of execution service does not transfer output objects or drain existing work automatically. Preserve the old route until in-flight work and result correctness have been reconciled.

DigitalOcean

Kubernetes Deployments

The documented backend is a function Deployment on Kubernetes. This can fit handlers that need an operated cluster in DigitalOcean and whose owners accept allocated workers, node capacity and cluster recovery. It does not mean DigitalOcean’s separate native function products are Lambda adapters. Measure idle replicas, simultaneous handler bursts and node replacement with the real images. A function’s replica count is an allocation decision, not an exact upper bound on application-side effects or downstream calls. Use the Kubernetes mapping, assign a platform recovery owner and test the application’s timeout and retry contract before deployment.

Akamai

Knative or Kubernetes Deployments

Both documented backends run on the target cluster. Knative adds request-driven scheduling and capacity policy with its own platform operation; plain Deployments allocate workers without that extra platform. For many quiet functions, compare reclaimed idle allocation against startup delay and Knative’s operating footprint. For steady handlers, compare the same throughput and rollout budget on allocated replicas. The platform team owns node capacity, networking and recovery for both options. Test simultaneous bursts across functions and a failed shared routing component, not only one isolated handler. See the Knative mapping and Kubernetes mapping.

Private Kubernetes

Knative or Kubernetes Deployments

Both options keep execution in the customer’s cluster. Choose between them using per-function latency, aggregate resource demand and the platform team’s capacity to operate Knative. Private placement does not itself establish invocation isolation, data durability or a Lambda-style admission limit.

Workload example: many mostly idle functions

A customer has an existing Kubernetes cluster and many low-volume internal handlers. Compare Knative with plain Kubernetes Deployments, both inside that cluster. Knative’s request-driven scheduling allows different functions to have different warm-capacity policies, including reclaiming eligible quiet functions’ idle allocations. Compare configured warmth and measured startup against each handler’s latency budget. The customer’s platform team must own Knative networking, upgrades, scheduling and recovery in addition to Kubernetes itself. Plain Deployments allocate workers through replica counts without adding Knative’s execution platform. Measure idle resource consumption, request routing and available capacity alongside Knative’s scaling behavior and platform footprint. Replica counts establish allocated workers, not a Lambda-style fleet-wide admission guarantee. Both alternatives need downstream connection limits and a response-timeout policy. Test several functions bursting together. A per-function test can look healthy while their aggregate memory demand exceeds available nodes. Include cold image pulls, a worker crash, a rollout and failure of a shared routing component. Confirm that temporary files and process-local caches are not treated as durable state.

Next steps

Record the selected directed adapter, packaging, resource budget, response deadline, retry behavior and operating owner. Warmth and memory do not turn synchronous invocation into durable asynchronous delivery. Configure the chosen backend with Tuning AWS Lambda.