Virtual Machines & Containers
The history of cloud compute is basically: first we virtualized hardware into VMs, then we containerized applications with Docker. Understanding both — and the shift from one to the other — is foundational to modern cloud and AI infrastructure.
What is a Virtual Machine?
A Virtual Machine (VM) is a software emulation of a physical computer. It runs its own operating system and appears to applications as if it's a real, dedicated machine — but it's actually sharing physical hardware with other VMs through a layer called a hypervisor.
How Hypervisors Work
A hypervisor (like VMware ESXi, KVM, or Hyper-V) sits between the physical hardware and the VMs. It partitions CPU, RAM, and storage — giving each VM its own isolated slice. VMs can't see each other's memory or processes. One VM crashing doesn't affect another.
VMs in the Cloud
When you launch an EC2 instance on AWS, you're getting a VM running on Amazon's physical servers. You pick the size (CPU, RAM), choose an operating system image, and within ~60 seconds you have a virtual computer to work with. You SSH in, install software, run your workloads — it behaves like a real server.
What is a Container?
A container is a lightweight, portable package that includes your application code plus everything it needs to run — libraries, dependencies, configuration — but NOT a full operating system. Multiple containers share the host OS kernel, making them much lighter than VMs.
Docker: The Container Revolution
Docker (launched 2013) made containers accessible. You write a Dockerfile that describes your app and its dependencies. Docker builds it into an image. That image runs identically on your laptop, on AWS, on Google Cloud, or anywhere Docker runs. "It works on my machine" became "it works everywhere."
Containers vs. VMs: The Size Difference
A typical Linux VM image is 5–20GB (full OS included). A typical Docker container image is 50–500MB (just your app and its dependencies, sharing the OS kernel). You can start a container in seconds vs. 30–60 seconds for a VM. Run 10x more containers than VMs on the same hardware.
VMs vs. Containers: Side by Side
🖥️ Virtual Machines
- Full OS per VM (GBs each)
- Strong isolation (separate kernel)
- Boot in 30–60 seconds
- Best for: stateful apps, legacy software, GPU workloads
- Security: higher (kernel isolation)
- Examples: EC2, GCE, Azure VMs
📦 Containers
- Shared OS kernel (MBs each)
- Process-level isolation
- Start in milliseconds
- Best for: microservices, APIs, ML inference serving
- Security: lower (shared kernel)
- Examples: Docker, Kubernetes pods
Containers & VMs for AI Workloads
Training: VMs Win
GPU training jobs need bare-metal-like access to GPU hardware. Containers can use GPUs (with NVIDIA Container Runtime), but training clusters are usually launched as VM instances (AWS p4d, GCP A3) where you get direct GPU access and can configure CUDA, NCCL, and networking precisely.
Inference Serving: Containers Win
Once a model is trained, serving predictions is a stateless API operation. Containers are perfect: package your model + inference server (TorchServe, Triton, vLLM) into a Docker image, deploy to Kubernetes, and autoscale based on request volume. Fast startup, efficient packing, easy rollbacks.
Frequently Asked Questions
Can containers run on Windows?
Yes, Docker Desktop runs on Windows and Mac, but Linux containers (the most common type) require a Linux kernel underneath — on Windows, Docker runs a lightweight Linux VM internally. There are also native Windows containers, but they're far less common. In production cloud environments, containers almost always run on Linux VMs.
What is a container image vs. a container?
A container image is the blueprint — a read-only snapshot of your application and its dependencies, stored in a registry (Docker Hub, AWS ECR, Google Artifact Registry). A container is a running instance of that image. One image can spawn dozens of containers simultaneously. It's the same relationship as a class (image) and an object (container) in programming.
Is Docker the only container technology?
Docker is the most popular, but not the only one. containerd (which Docker uses internally) is the CNCF runtime standard. Podman is a Docker alternative that doesn't require a root daemon. rkt was CoreOS's alternative (now deprecated). In practice, "containers" means Docker images + the OCI standard they defined — interoperable across all these runtimes.
Should I use VMs or containers for my web application?
For a new web application in 2025, start with containers. Package your app as a Docker image and deploy to a managed container service (AWS ECS, Google Cloud Run, Kubernetes). You get faster deploys, easier scaling, and better resource efficiency. Only use raw VMs if you have specific requirements (OS-level customization, legacy software, GPU ML training) that containers can't handle.
Frequently Asked Questions
What will I learn here?
This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.
How should I use this page?
Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.
What should I read next?
Use the navigation below to continue to the next lesson or explore related topics.