What is serverless computing?

A serverless deployment is a small number of moving parts:

• A trigger - an HTTP request, a queued message, a stored-object event, or a schedule.
• The package - the function and its dependencies, uploaded once and versioned.
• A lifetime - each invocation starts, runs, produces a result or a side effect, then stops.
• Limits - memory and a maximum duration, set per function and enforced by the platform.
• Outputs - a response, a record written elsewhere, or another event raised downstream.

Ephemeral execution is the design constraint behind all five. Nothing written to the local disk survives the next invocation, so state lives in databases, object stores or caches outside the function, and work that cannot finish inside the time limit has to be split or moved to a longer-running model. Cold starts - the first invocation after idle - are the latency cost of not owning the machines.

Event-driven glue suits the model well: webhooks, scheduled maintenance, image or document processing, API fronts behind bursty traffic, and coordination logic between services. The appeal is that a function handling rare events costs nothing while it waits, and no capacity planning is required for the quiet periods.

It fits less well for long-running numerical work, tightly coupled cluster jobs, workloads needing specialised hardware or persistent high throughput, and anything that must hold a process open for hours. Those belong on machines you rent directly or on a scheduled cluster. Packaging and moving between environments is simpler when the unit is a container, which is how several platforms accept serverless-style deployments as well.

Cost behaviour deserves its own note, because it inverts the usual worry. Nothing is reserved, so a quiet system costs close to nothing while a loop that never terminates bills itself without a ceiling unless someone set one. Budgets, alarms and per-function limits belong to the design of the deployment rather than to its administration, and the teams that skip them are the ones who discover the bill before the code.

Serverless is usually placed alongside PaaS rather than beside it: the provider operates even more of the stack, down to deciding where code executes. The trade is the same one, pushed further - more convenience and finer-grained billing in exchange for less control over placement, timing and the environment beneath the handler.

Because billing follows execution rather than allocation, the model has different questions attached to it: what an invocation costs, how often a trigger fires, and what runaway looks like when a loop bills itself. For how the three traditional models compare, see IaaS, PaaS and SaaS on VirtEngine.

The same handler can be packaged and run on a container platform as well, which blurs the category in a useful way: what separates the options is who owns the idle time between executions. That question - reserving capacity in advance or paying only while code runs - is the same one a tenant answers whenever it moves between layers, and it is worth answering deliberately from the workload's shape rather than by adopting whichever option a project happened to start with.

On VirtEngine, a serverless-style offering is published with its runtimes, limits and price per unit of execution spelled out, so a buyer can see what an event-heavy workload will cost before deploying it. The tenant funds an escrow account when ordering; the provider can verify that the budget exists before accepting the lease.

Metering then follows the executions themselves: each invocation contributes a signed usage record, those records accumulate over the lease, and validated line items are taken from escrow once the dispute window closes. Spending is bounded by the escrow balance rather than by an open account, and identity verification on both sides happens before the first invocation.