Serverless from First Principles: What Actually Runs Your Code?

You deploy an API route, open its URL, and receive a response. It feels as if your code simply appeared on the internet.

But code cannot run by itself. Somewhere, a CPU executed its instructions, memory held its data, and a network interface carried the response back to you.

Serverless computing does not remove those machines. It changes who manages them, when execution environments are created, and what you must think about.

This article builds that mental model from the hardware upward.

Every request eventually reaches a machine

Consider a small HTTP handler:

export async function GET() {
  return Response.json({ status: "ok" })
}

For that function to answer a request, something must:

1. Receive the network request.
2. Find the deployed function.
3. Prepare a JavaScript runtime.
4. Give the runtime CPU time and memory.
5. Execute the handler.
6. Return the result to the client.

You can operate this system yourself, or you can ask a cloud platform to operate it. The physical requirements remain the same.

The difference lies in the abstraction you choose.

The compute abstraction ladder

Infrastructure can be understood as a stack. Each level hides more operational work while giving you less direct control over the machine.

These are not stages that made the previous ones obsolete. They are different operating models with different trade-offs.

Physical servers

A physical server gives you direct access to a machine. You choose the operating system, install runtimes, configure networking, patch software, and replace failed hardware.

This offers maximum control, but every operational concern belongs to you.

Virtual machines

A hypervisor divides a physical server into virtual machines. Each VM behaves like a separate computer and normally runs its own operating-system kernel.

You stop managing physical hardware, but you still maintain the guest OS, runtime, capacity, deployments, and scaling.

Containers

A container packages an application with its files and dependencies. Unlike a VM, it does not normally carry a complete guest operating system.

Multiple containers can share the host kernel. That makes them lightweight, but it also gives them a different isolation boundary from a VM.

Containers make software portable. They do not automatically solve scheduling, load balancing, monitoring, patching, or capacity planning.

Serverless functions

With a serverless function, you provide code and describe how it should be invoked. An HTTP request, queue message, scheduled event, or uploaded file might act as the trigger.

The provider decides where to create an execution environment, how many environments are needed, and when unused environments can be removed.

What “serverless” actually means

The name is misleading. Serverless applications still run on servers.

What disappears is the need to provision and operate a long-running server for each application workload.

In a traditional deployment, you might rent a VM, keep an application process alive, and reserve enough capacity for expected traffic.

You remain responsible for questions such as:

• How many instances should run?
• What happens when one fails?
• How will traffic be distributed?
• When should another instance start?
• How are the OS and runtime patched?

In a serverless deployment, the provider owns most of that lifecycle. You concentrate on the function, its permissions, and the event that invokes it.

That gives us a practical definition:

Serverless is an execution model in which the platform provisions and scales environments around demand while developers deploy code without managing those environments directly.

It is an ownership boundary, not the absence of infrastructure.

From reserved capacity to execution on demand

Suppose your API receives no requests overnight.

A long-running VM usually remains allocated unless you explicitly stop or resize it. You pay for the reserved machine because the capacity is still yours.

A serverless platform can reduce the number of active execution environments when demand falls. Some services can scale a workload to zero active instances.

When traffic returns, the platform creates or reuses enough environments to process it. If traffic rises, it can add more environments without waiting for you to provision servers manually.

This elasticity is the central benefit of serverless computing.

It also changes pricing. Function platforms commonly meter requests, execution time, memory, CPU, and network usage instead of charging only for a permanently reserved machine.

That does not guarantee a lower bill. A steady, compute-heavy workload may be cheaper on reserved infrastructure. Serverless is especially attractive when demand is uneven or operational simplicity matters.

The execution environment

A function does not run directly on abstract “cloud capacity.” It runs inside an execution environment prepared by the provider.

That environment contains the language runtime, your deployed code, configured memory, temporary storage, environment variables, and the permissions available to the function.

The exact isolation technology belongs to the platform. It might involve a lightweight virtual machine, a sandboxed runtime, or another mechanism.

We will compare those mechanisms in the next article. For now, the important idea is that an environment must be ready before your handler can execute.

Why cold starts happen

Imagine that a request arrives and no suitable environment is ready.

The platform must prepare one. It may need to fetch your deployment, initialize the language runtime, load dependencies, and run code declared outside your handler.

Only after that work can the request reach your function.

This preparation is called a cold start.

Request
  → prepare execution environment
  → start runtime
  → load application code
  → run initialization
  → invoke handler
  → return response

Cold-start time is not a universal number. It depends on the provider, runtime, deployment size, initialization work, configuration, and demand at that moment.

Large dependencies and expensive top-level setup make the function’s portion of initialization slower.

Why the next request may be faster

Providers do not necessarily destroy an execution environment as soon as one invocation finishes.

They may retain it for later work. If another request reaches that environment, the runtime and application code are already initialized.

This is commonly called a warm start.

First request:  initialize → invoke → respond
Later request:               invoke → respond

A warm environment may also retain objects created outside the handler and temporary files. That makes reuse useful for SDK clients, caches, and database connections.

Reuse is an optimization, not a promise. The platform may replace an environment at any time, so your application must remain correct when no previous state exists.

Serverless functions should be treated as stateless

Suppose one invocation stores a shopping cart in a global variable. The next request might reach the same environment, a different environment, or a newly created one.

The cart would sometimes exist and sometimes disappear.

Durable state should live in a system designed to preserve and share it, such as a database, object store, distributed cache, or queue.

An execution environment may keep temporary state for performance. Your function’s correctness must not depend on that state surviving.

This distinction—reuse when available, never require it—is one of the most important rules in serverless design.

What the platform handles—and what it does not

Serverless removes server management, but it does not remove engineering decisions.

The platform usually handles:

• Provisioning execution environments
• Replacing failed environments
• Adding and removing capacity
• Connecting triggers to functions
• Maintaining the underlying compute fleet

You still handle:

• Application logic and dependencies
• Identity and permissions
• Timeouts, memory, and concurrency configuration
• Retries and idempotency
• Observability and error handling
• External state and database capacity
• Cost controls and platform limits

Serverless moves the infrastructure boundary. It does not move responsibility for application behavior.

A reliable mental model

When a serverless function runs, picture this sequence:

1. An event reaches the platform.
2. The platform finds or creates an execution environment.
3. A runtime passes the event to your handler.
4. Your handler performs its work.
5. The platform returns or records the result.
6. The environment may remain available for reuse.

From this model, the major serverless trade-offs follow naturally:

• Automatic scaling is possible because the platform controls environments.
• Cold starts exist because an environment may need initialization.
• Warm starts are faster because initialized work can be reused.
• Local state is unreliable because environments are replaceable.
• Costs follow usage differently because capacity is allocated dynamically.

Key takeaways

• Serverless still runs on physical machines.
• The provider manages execution environments instead of giving you a permanent server to operate.
• Serverless functions are invoked by events and scale with demand.
• A cold start prepares a new environment before the handler runs.
• A warm start reuses an initialized environment, but reuse is never guaranteed.
• Durable state belongs outside the function environment.
• Serverless trades infrastructure control for elasticity and operational simplicity.

What comes next

We now know that a platform needs fast, secure environments for running application code.

That creates a difficult engineering question: how can one machine execute workloads from many customers without letting those workloads interfere with each other?

The next article compares two answers: Firecracker microVMs and V8 isolates.

Further reading

• AWS Lambda execution environment lifecycle (opens in a new tab)
• Docker: containers versus virtual machines (opens in a new tab)