An AWS Lambda Alternative: Container-Backed Serverless

AWS Lambda proved that serverless is the right default for a huge class of backend work: no servers to patch, pay for what you run, scale to zero. If you are looking for an AWS Lambda alternative, it is usually not because that idea is wrong — it is because the packaging and operational model around Lambda got in your way. This post is an honest look at what pushes teams to look elsewhere, what a container-backed alternative changes, and — just as importantly — what it does not.

What actually sends people looking for a Lambda alternative

It is rarely the pricing model. It is the friction:

• The packaging dance. Native dependencies mean zip files, layers, and the classic “works on my machine, Error: cannot find module in the cloud.” Lambda layers help but come with their own limits (a 250 MB unzipped cap across layers) and their own build tooling to get right.
• The runtime ceiling. Anything that needs a system library, a headless browser, an ONNX model, or a binary you shell out to fights the deployment package model.
• Everything is a separate service. The function is Lambda, the HTTP front is API Gateway, the queue is SQS, the schedule is EventBridge, the logs are CloudWatch, permissions are IAM. Wiring five services with the right roles to ship one endpoint is a lot of yak-shaving for “run this code when a request comes in.”
• Local-to-prod drift. Reproducing the Lambda environment locally is its own cottage industry.

None of this means Lambda is bad. It means that for a lot of teams the incidental complexity outweighs the essential work, and they start looking for something with less ceremony.

What a container-backed alternative changes

Inquir keeps the serverless idea — deploy a function, get an HTTP endpoint, scale automatically — but runs each function in its own container instead of a zip-package sandbox. That one change removes most of the friction above:

• Native dependencies just work. Because it is a real container with the full language runtime, you use native modules, system libraries, and heavy packages without a layer-packaging ritual. Shared dependencies are attached as layers for Node, Python, or Go, resolved at invoke time rather than re-uploaded per function.
• The gateway, secrets, schedules, and observability are one platform. Route-level auth (API keys or bearer), per-function secrets injected as environment variables, cron triggers, background jobs, and execution traces are part of the same product — not five services you wire together with IAM.
• Three real runtimes, mixable. Node.js 22, Python 3.12, and Go 1.22 behind one gateway; pick per function, mix freely.
• Deploy from the browser. Edit and ship a function from a web IDE — useful for a quick fix without a full local toolchain — alongside CLI and CI/CD paths.

The mental model shrinks from “wire up Lambda + API Gateway + SQS + EventBridge + CloudWatch + IAM” to “deploy a function, give it a route, read its secrets, watch its traces.”

Being honest about the limits it does not remove

An alternative that only listed advantages would be marketing, not engineering. Two things are worth stating plainly, because they are the same on any responsible serverless platform:

• Cold starts are not zero. Container-backed functions hide cold starts with hot/warm pools (a warm pool per function, min 1 up to 8, so steady traffic stays warm), but the first invoke after a deploy or an idle recycle still pays a cold path. If a specific endpoint is latency-critical, keep it warm — do not expect magic.
• There is still a per-invocation time limit. Each function or step has a timeout (5 s default, up to 15 minutes max). “Serverless with no timeout” is not a real thing anywhere. The right pattern for long work is the same as it should have been on Lambda: acknowledge fast, then run the long part as a durable background job with retries and a dead-letter path, rather than holding one request open for an hour.

If your workload genuinely needs a single process running for hours with a persistent socket, that is not a serverless-function shape on any platform — it is a service, and you should run it as one.

When Lambda is still the right answer

A good alternative tells you when not to switch:

• You are deep in the AWS ecosystem and your functions are glue between AWS services (DynamoDB streams, S3 events, Step Functions). The gravity of staying where your data and events already live is real and worth respecting.
• You need a specific AWS integration — a trigger source or a compliance boundary — that only the native service provides.
• Your team’s whole toolchain is already AWS-native and the incidental complexity is complexity you have already paid down.

Switching platforms has a cost. Do it when the friction you are escaping is bigger than the migration.

What migrating actually looks like

The good news: a Lambda handler and an Inquir handler are close cousins. The gateway passes an API-Gateway-style event (httpMethod, path, headers, queryStringParameters, body as a string), and you return { statusCode, body } or bare JSON:

export async function handler(event) {
  const body = JSON.parse(event.body ?? '{}');
  // your existing logic, mostly unchanged
  return { statusCode: 200, body: JSON.stringify({ ok: true }) };
}

Most of the migration is deletion: the layer-build scripts, the IAM role JSON, the API Gateway wiring, the SQS consumer boilerplate. The handler logic largely survives; the plumbing around it gets replaced by platform features.

The takeaway

The reason to want an AWS Lambda alternative is almost never “serverless was a mistake.” It is that the packaging model, the runtime ceiling, and the five-services-to-ship-one-endpoint tax added up. A container-backed platform keeps the part that was right — deploy a function, get an endpoint, scale automatically — and removes the ceremony: native dependencies without the layer dance, one platform instead of six services, three runtimes behind one gateway.

Just keep the honesty that separates engineering from marketing: cold starts are reduced, not eliminated; long work belongs in background jobs, not a held-open request; and if you live inside AWS, staying may still be right. Match the tool to the shape of the work, and switch when the friction you are leaving is real.