Serverless and Background Compute

A photo resize, an always-connected chat service and a daily report do not need the same kind of worker. Serverless services manage much of the server lifecycle for you, but your application still owns its state, errors and spending.

This lesson compares event-triggered functions with long-running workers. “No server management” does not mean unlimited execution or automatic correctness.

An event-triggered function runs a handler for an invocation. Its environment may be reused, but the application should not depend on local memory or temporary files surviving future invocations. Put durable progress and shared state in a suitable external store.

A long-running worker can keep connections and process a sustained queue. It also needs deployment, health checks and capacity operation. Both models can crash after an effect but before acknowledging work; use stable job IDs and safe repeated effects.

Cold starts are setup work for a new environment. Measure their effect on the relevant latency percentile; not every invocation is cold. Concurrency limits, execution deadlines, payload limits and downstream connection capacity also matter.

If each function opens many database connections, scaling functions can overload the database. Bound concurrency and use supported connection management. A two-hour task cannot simply be squeezed into a function with a shorter invocation limit; split checkpointed work, orchestrate steps or choose another execution model.

Compare the operational responsibility and limits, including the dependency budget.

AWS Lambda Functions provide event-triggered handlers. Azure Functions and Google Cloud Run functions offer related models with their own contracts. Cloud Run services and managed container platforms can support other execution patterns. Knative offers an open-source platform approach, while ordinary workers on VMs remain a valid option.

Read Lambda’s compute-model documentation for the current primitives and limits. Compare the selected function or service, runtime support, timeout, concurrency, state, networking and billing dimensions.

Estimate requests × execution duration × allocated resources, plus storage, logs and transfer under actual pricing. A continuously busy workload may fit a worker economically; an idle workload may benefit from usage-based compute. Test with the real work rather than claiming one model is always cheapest.

Choose compute from duration, connection behaviour, arrival rate and operation. External state, retry safety and dependency limits remain application responsibilities.