“Should this run on a VM, in a container, or as a serverless function?” is one of the most common cloud architecture questions, and the honest answer is that it depends on the workload’s traffic pattern and control requirements — not that one model has simply superseded the others.

Virtual machines: the most control, the most responsibility

A virtual machine (VM) emulates a full computer, including its own operating system, running on shared physical hardware. It’s the closest cloud analog to the on-premises servers discussed in Cloud Computing vs. On-Premises Infrastructure, and it offers the most control of the three models: you choose and configure the operating system, install anything you need, and manage it much like a physical server. That control comes with the most responsibility — patching, security configuration, and capacity planning are all yours — and VMs are typically the slowest of the three to start, often taking minutes, and are billed for the time they’re running regardless of whether they’re actively handling load.

Containers: package once, start fast

A container packages an application together with its dependencies into a single, portable unit, but — unlike a VM — shares the underlying host’s operating system kernel rather than running a full OS of its own. This makes containers dramatically lighter and faster to start, typically in seconds, and consistent across environments: the same container image runs the same way in development, testing, and production. Docker popularized the container format and tooling; its own overview of containerization explains the model in detail, and building smaller, safer images is its own discipline worth getting right. Running containers at any meaningful scale generally means running an orchestrator to handle scheduling, scaling, and failover across many containers and machines — Kubernetes, maintained under the Cloud Native Computing Foundation, is the dominant orchestrator, and the Open Container Initiative maintains the specifications that keep container formats portable across different tools and providers.

Containers sit in the middle of the control spectrum: less operational overhead than managing a full VM’s operating system, but still requiring you to think about orchestration, scaling rules, and the underlying compute the containers actually run on.

Serverless: no servers to manage, billed by execution

Serverless computing — most commonly encountered as Function-as-a-Service (FaaS), such as AWS Lambda — removes server management from the picture entirely. You deploy a function; the platform handles provisioning, scaling (including scaling down to zero when there’s no traffic at all), and the underlying infrastructure completely. AWS describes the model in its overview of serverless computing, as does Google Cloud’s introduction to serverless: billing is typically based on actual invocations and execution time, not on capacity reserved in advance.

The trade-off is control and, for some workloads, latency: cold starts — the delay when a function has to be initialized from scratch after sitting idle — can add noticeable latency to the first request after a quiet period, which matters for latency-sensitive workloads and matters far less for infrequent, asynchronous, or batch-style work.

Matching the model to the workload

A few practical patterns tend to hold:

  • Steady, predictable, high-volume traffic often favors VMs or containers with committed pricing, where serverless’s per-invocation billing stops being cheaper than continuously running capacity — a cost dynamic covered in Why Cloud Bills Get Out of Control.
  • Spiky, unpredictable, or infrequent workloads often favor serverless, since you pay nothing while idle and scale automatically when demand appears.
  • Workloads needing specific OS-level configuration, licensing, or hardware access often need the full control a VM provides.
  • Applications composed of many independent services that need consistent packaging and portable deployment across environments are the classic container-and-orchestrator use case.

Many real systems use all three at once for different components, rather than standardizing on a single model across the board — which is a reasonable outcome, since the underlying trade-offs are genuinely different, not a matter of one model being strictly better.

Key takeaway

VMs, containers, and serverless functions sit on a spectrum from most control and slowest startup (VMs) to least control and fastest, most elastic scaling (serverless), with containers occupying the middle ground. The right choice for a given workload depends on its traffic predictability, latency sensitivity, and control requirements — and a single system built from several workloads often benefits from using more than one model rather than forcing everything into one.

This article explains general compute architecture concepts; specific pricing, cold-start behavior, and features vary by provider and change over time. See our disclaimer.