Virtual Machine

Explanation

A hypervisor (VMware ESXi, Microsoft Hyper-V, KVM, VirtualBox) runs on physical hardware and manages multiple VMs. Each VM has virtualized hardware (CPU, memory, disk, network), a complete OS, and complete isolation from other VMs on the same host. The host machine's physical resources are divided and allocated to VMs. VMs provided the foundation for cloud computing: AWS EC2, Google Compute Engine, and Azure Virtual Machines are all VMs. You provision a VM (choose CPU, RAM, storage), the cloud provider allocates those resources from their physical servers, and you get a fully independent server to configure and run whatever you want. VM advantages over containers: stronger security isolation (separate kernel means a kernel exploit doesn't affect other VMs), ability to run different operating systems on the same host (Windows VM on a Linux host), and full OS access for legacy applications that require specific OS configurations. VM disadvantages: slower startup (minutes vs milliseconds for containers), larger resource overhead (each VM runs a full OS), and larger image sizes. Virtualization types: Type 1 hypervisor (bare metal — runs directly on hardware: ESXi, Hyper-V, KVM), Type 2 hypervisor (runs on a host OS: VirtualBox, VMware Workstation — used for development). Cloud providers use Type 1 hypervisors for performance and security.

Code Example

# Virtual machine lifecycle (AWS CLI example)

# Launch an EC2 instance (a VM in AWS)
aws ec2 run-instances   --image-id ami-0abcdef1234567890 \  # the OS image (e.g., Ubuntu 22.04)
  --instance-type t3.micro \          # VM size: 2 vCPU, 1GB RAM
  --key-name my-key-pair   --security-group-ids sg-0123456789   --subnet-id subnet-0123456789

# SSH into the VM once running
ssh -i my-key-pair.pem ubuntu@

# VM vs Container mental model:
# VM: you ordered a complete physical server (just virtual)
#   - Has its own kernel, firewall, networking stack
#   - Takes minutes to start
#   - You manage the OS (patching, updates)
#
# Container: you ordered a process that runs in an isolated environment
#   - Shares the host kernel
#   - Starts in milliseconds
#   - You only manage your application code
#
# Production reality: most modern deployments run containers INSIDE VMs
# (e.g., Kubernetes pods run in EC2 instances)
# You get both: strong VM-level isolation + container efficiency

Why It Matters for Engineers

Understanding VMs clarifies the entire cloud computing model: when you deploy to AWS, GCP, or Azure, you're renting VMs on someone else's hardware. EC2 instances are VMs. Understanding that containers typically run inside VMs in production (a Kubernetes node is a VM running containers) gives you the complete mental model of modern cloud deployments. VMs are also the right tool for certain use cases: running Windows applications in a Linux environment, providing guaranteed resource allocation to a tenant in a multi-tenant SaaS, or running legacy software that requires specific OS configurations. Knowing when to use VMs vs containers vs serverless is a practical deployment decision.