Compute Models: VMs vs Containers vs Serverless

Three ways to run the same code

Once you've written an app, you have to *run* it somewhere. The cloud gives you three main options, and they exist on a spectrum from "you control everything" to "you control almost nothing and only pay when it runs": virtual machines → containers → serverless. None is universally best. The skill is matching the model to the job.

The hotel analogy

A VM is a whole house, your own OS, your own everything, idle or not you pay rent. A container is a hotel room, you get an isolated space but share the building's plumbing (the host OS kernel), so it's lighter and faster to move into. Serverless is room service, you don't keep a room at all; you ask for something, it runs, you pay only for that, and it vanishes.

The trade-offs side by side

When to reach for each

Virtual machines

Pick a VM when you need full control of the operating system, you're running legacy or specialised software, or a workload runs constantly at predictable load. You trade convenience for control, and you own patching and scaling.

Containers

The modern default for most applications. Containers package your app with its dependencies so it runs identically everywhere, start in seconds, and pack efficiently onto hosts. The cost is orchestration: at scale you'll want Kubernetes, which has its own learning curve.

Serverless

Brilliant for spiky, event-driven, or infrequent work, an image-resize on upload, a webhook handler, a nightly job. You write a function, the platform runs it on demand and scales to zero when idle (you pay nothing). The catches: cold starts (first invocation after idle is slower) and time/size limits that make it a poor fit for long-running jobs.

The same job, three ways

Notice how the amount of *infrastructure* you describe shrinks as you move right. A container needs an image:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 8080
CMD ["node", "server.js"]

The same logic as a serverless function is just the handler, no server, no port, no Dockerfile. The platform supplies everything around it:

# Runs on demand, scales to zero, billed per invocation.
def handler(event, context):
    name = event.get("name", "world")
    return {"statusCode": 200, "body": f"Hello, {name}!"}

Common mistakes that cost people hours

1. Running idle VMs 24/7. Paying for a always-on house when room service would do. Match the model to the load.
2. Reaching for Kubernetes on day one. Three containers don't need an orchestrator. Start simple; add k8s when the pain is real.
3. Putting long-running jobs on serverless. Functions have time limits. A 30-minute batch job will get killed mid-run.
4. Ignoring cold starts on latency-sensitive paths. If a user is waiting, a cold function start can hurt. Keep critical paths warm or on containers.
5. Lifting a legacy app onto serverless unchanged. Serverless rewards stateless, short, event-driven design. Forcing a monolith into it fights the model.

Where to go next

• Lessons: Compute Models and Serverless vs Containers.
• Get hands-on: the Docker Lab and Kubectl Lab.
• Related read: Docker vs Kubernetes: When to Use Each.