CLOUD COMPUTING — STUDY NOTES

Virtualization vs Containers
How the Cloud Runs Workloads

1. Foundations & Key Concepts

1.1 The Problem Both Technologies Solve

In traditional computing, one physical server ran one operating system and one application. This
wasted enormous amounts of compute, memory, and storage. Both virtualisation and containers were
invented to solve this resource inefficiency — but they do so in very different ways.

Core Idea
Virtualisation: Simulate entire computers in software so one physical machine can run many
independent OSes.
Containers: Package an application with only what it needs, sharing the host OS kernel for ultra-light
isolation.

1.2 Virtualisation – Deep Dive

Virtualisation creates Virtual Machines (VMs). Each VM is a full software emulation of a physical
computer, including its own OS, kernel, drivers, and applications.

The Hypervisor
The hypervisor (also called Virtual Machine Monitor – VMM) is the software layer that creates and
manages VMs. There are two types:

• Type 1 – Bare-Metal Hypervisor: Runs directly on the physical hardware (no host OS). Highest
performance and security.
◦ Examples: VMware ESXi, Microsoft Hyper-V, Xen, KVM
◦ Used in: Enterprise data centres, public cloud infrastructure (AWS EC2 uses Xen/KVM)
• Type 2 – Hosted Hypervisor: Runs on top of a host OS. Easier to set up but with more
overhead.
◦ Examples: VMware Workstation, Oracle VirtualBox, Parallels
◦ Used in: Developer laptops, testing, desktop virtualisation
VM Architecture (Layered)
Layer Description
Physical Hardware CPU, RAM, NIC, Storage — the real machine
Hypervisor Manages and arbitrates access to hardware; creates VM instances
Guest OS (per VM) Each VM has its own full operating system (e.g., Windows Server,
Ubuntu)
Application The app runs inside the guest OS, fully isolated from other VMs

1.3 Containers – Deep Dive

Containers package an application along with its libraries, dependencies, and configuration into a
single, portable unit. Unlike VMs, containers share the host OS kernel — they do not boot a full OS.

The Container Runtime & Engine

• Container Runtime: Low-level software that runs containers (e.g., containerd, CRI-O, runc)
• Container Engine: Higher-level tooling for building and managing containers (e.g., Docker,
Podman)
• Container Image: A read-only, layered snapshot of the filesystem the container needs
◦ Stored in image registries: Docker Hub, Amazon ECR, Google Artifact Registry
◦ Built using a Dockerfile (Docker) or Containerfile (Podman)

Container Architecture (Layered)

Layer Description
Physical / Virtual Hardware Underlying compute — can be bare metal or a VM
Host OS + Kernel Single OS shared by all containers; kernel provides namespaces &
cgroups
Container Runtime Starts/stops containers, enforces isolation using kernel primitives
Container (per app) App + its own libraries/config; isolated but sharing the kernel

Key Linux Kernel Features Enabling Containers

• Namespaces: Isolate what a process can see (PID, network, mount, UTS, IPC, user
namespaces)
• Control Groups (cgroups): Limit and account resource usage (CPU, memory, disk I/O, network)
• Union File Systems (OverlayFS): Layer-based filesystems for efficient image storage and
sharing

2. Head-to-Head Comparison
2.1 Side-by-Side Comparison Table

Virtualisation (VMs) Containers

Boots a full Guest OS per VM Shares Host OS kernel — no OS boot

Size: GBs per VM image Size: MBs per container image

Startup time: Minutes Startup time: Seconds (or milliseconds)

Strong isolation (separate kernel) Process-level isolation (shared kernel)

Higher resource overhead (RAM, CPU) Very low overhead — near-native performance

Best for: Full OS workloads, legacy apps Best for: Microservices, cloud-native apps

Persistent by nature Stateless by design (data in external volumes)

Managed by Hypervisor Managed by Container Runtime / Orchestrator

Portability: Moderate (large images) Portability: High (small, fast to pull/push)

OS flexibility: Any guest OS OS flexibility: Must match host kernel

(Linux/Windows)

Security attack surface: Larger (full OS) Security attack surface: Smaller (but shared
kernel risk)

2.2 Performance Comparison

Metric VMs Containers Winner

Boot Time 1–5 minutes < 1 second Containers
Memory per unit 512 MB – several GB Tens of MB Containers
CPU overhead 5–15% hypervisor tax < 1% (near-native) Containers
Storage per unit GB (full OS image) MB (layered images) Containers
Isolation Strong (kernel Moderate (namespace) VMs
boundary)
Security Strong isolation Shared kernel risk VMs
Density/server Tens of VMs Hundreds of containers Containers

3. Virtualisation & Containers in the Cloud

3.1 How Cloud Providers Use Virtualisation

Every major public cloud is built on virtualisation. When you launch a cloud instance, you are renting a
VM on a physical server in the cloud provider's data centre.
 • AWS EC2: Uses the Nitro Hypervisor (custom KVM-based). Each EC2 instance is a VM.
• Azure Virtual Machines: Uses a custom Hyper-V hypervisor
• Google Compute Engine: Uses KVM hypervisor
• Cloud providers achieve multi-tenancy (many customers on one physical server) through VM
isolation

Cloud Virtualisation Benefit

You get dedicated, predictable compute — and the provider's hypervisor ensures one tenant
cannot access another's memory or storage, even on the same physical machine.

3.2 How Cloud Providers Use Containers

Containers are the foundation of cloud-native development. Cloud providers offer managed container
platforms so you don't need to manage the underlying infrastructure.

Container-as-a-Service (CaaS) Offerings

Provider Service What It Manages
AWS ECS (Elastic Container Container scheduling on EC2 or Fargate
Service) (serverless)
AWS EKS (Elastic Kubernetes Managed Kubernetes control plane
Service)
Azure AKS (Azure Kubernetes Managed Kubernetes control plane
Service)
GCP GKE (Google Kubernetes Managed Kubernetes (Google invented
Engine) Kubernetes)
GCP Cloud Run Fully serverless containers — pay per request
AWS AWS Fargate Serverless containers — no EC2 to manage

3.3 Kubernetes – The Container Orchestrator

When you run many containers across many machines, you need an orchestrator. Kubernetes (K8s) is
the industry-standard open-source platform for container orchestration.

Key Kubernetes Concepts

Pod: The smallest deployable unit in K8s. A pod wraps one or more containers that share storage and
network
Node: A physical or virtual machine that runs pods. Managed by the Kubernetes scheduler
Cluster: A set of nodes managed by a control plane
Deployment: Declares the desired state — how many replicas of a pod should run
Service: Stable network endpoint to expose pods (load balancing across pod replicas)
Namespace: Virtual cluster within a cluster — used for environment separation (dev/staging/prod)
Ingress: Manages external HTTP/HTTPS traffic routing into the cluster
ConfigMap / Secret: Inject configuration and sensitive data into containers without baking them into
images

What Kubernetes Does Automatically

• Self-healing: Restarts failed containers; replaces and reschedules pods on failed nodes
• Horizontal scaling: Scale pods up or down based on CPU/memory metrics (HPA)
• Rolling updates: Deploy new container versions with zero downtime
• Load balancing: Distribute traffic across healthy pods
• Service discovery: Pods find each other by DNS name, not IP address

4. When to Use VMs vs Containers

4.1 Use VMs When…

• You need strong, hardware-level isolation between workloads (e.g., multi-tenant SaaS)
• You run different operating systems on the same host (e.g., Windows and Linux)
• You are running legacy monolithic applications not yet containerised
• Your workload requires kernel-level access or custom kernel modules
• Compliance/regulatory requirements demand full OS isolation
• You run stateful workloads that need persistent storage tightly coupled to compute

4.2 Use Containers When…

• You are building cloud-native, microservices-based applications
• You need fast deployment, scaling, and rollback cycles (DevOps / CI/CD pipelines)
• You want consistent environments from developer laptop to production (solve 'works on my
machine')
• You need to maximise server density — run hundreds of services on one host
• You want serverless-style, event-driven compute with fast cold starts
• Your app is stateless or you store state externally (databases, object storage)

4.3 Using VMs AND Containers Together

In practice, most modern cloud architectures combine both. This is the standard pattern in production:

Typical Production Stack

Physical Server --> Type-1 Hypervisor --> VM (Guest OS + Container Runtime) --> Containers

Kubernetes nodes are VMs. Containers run inside those VMs.

 You get the strong isolation of VMs AND the density and speed of containers.

5. Security Considerations

5.1 VM Security
• VM escape: A critical vulnerability where a malicious VM breaks out of the hypervisor to access
the host or other VMs. Extremely rare with modern hypervisors.
• Hypervisor attack surface: The hypervisor itself must be patched and hardened
• Snapshot risks: VM snapshots can contain sensitive data in memory
• Guest OS must be patched independently — each VM is its own attack surface

5.2 Container Security

• Shared kernel risk: If the host kernel has a vulnerability, all containers are potentially affected
• Image vulnerabilities: Container images may include outdated packages with CVEs — scan
images with tools like Trivy, Snyk, or AWS Inspector
• Privilege escalation: Running containers as root is dangerous. Use non-root users and read-
only filesystems
• Container breakout: A container escaping its namespace to access the host OS or other
containers
• Supply chain attacks: Malicious base images in public registries — use trusted, verified images

5.3 Security Best Practices

Practice Applies To Description
Least Privilege Both Run workloads with minimum required permissions
Image Scanning Containers Scan images for CVEs before deployment (Trivy,
Snyk)
Network Segmentation Both Isolate workloads at the network level
Patch Management VMs Regularly patch guest OS and installed software
Immutable Containers Never patch running containers — rebuild and
Infrastructure redeploy images
Secrets Management Both Never store secrets in images or environment
variables; use vaults
Runtime Monitoring Both Detect anomalous behaviour at runtime (Falco for
containers)
Hypervisor Hardening VMs Patch hypervisor promptly; disable unused VM
features
6. Emerging & Related Technologies

6.1 Serverless Computing

Serverless abstracts away both VMs and containers. You deploy a function and the cloud provider
handles all infrastructure. Under the hood, serverless often uses micro-VMs or containers.
• Examples: AWS Lambda, Azure Functions, Google Cloud Functions
• You pay only for execution time — no idle compute costs
• Cold start latency can be an issue for latency-sensitive apps

6.2 MicroVMs
MicroVMs combine the security of VMs with the speed of containers. They are lightweight VMs that
boot in milliseconds.
• AWS Firecracker: Used under the hood in AWS Lambda and Fargate. Boots in <125ms, uses
<5MB memory per VM
• gVisor (Google): Container sandbox that provides a user-space kernel, adding VM-like isolation
to containers
• Kata Containers: OCI-compatible containers backed by lightweight VMs for stronger isolation

6.3 WebAssembly (WASM)

WASM is emerging as an ultra-lightweight alternative for running code in sandboxed environments. It is
even more portable and smaller than containers, though less mature for general server-side workloads.

7. Key Terms Glossary

Hypervisor: Software that creates and manages virtual machines (Type 1 = bare-metal, Type 2 =
hosted)
Virtual Machine (VM): A software emulation of a complete computer, running its own OS
Guest OS: The operating system running inside a VM
Host OS: The operating system on the physical machine (Type 2) or the OS that VMs run on
Container: A lightweight, portable package containing an app and its dependencies, sharing the host
kernel
Container Image: Immutable, layered filesystem snapshot used to instantiate containers
Container Runtime: Low-level software that runs containers (containerd, runc, CRI-O)
Docker: Popular container engine and toolchain for building and running containers
Kubernetes (K8s): Open-source container orchestration platform for automating deployment, scaling,
and management
Pod: The smallest unit in Kubernetes — wraps one or more containers
Namespace (Linux): Kernel feature that isolates what a container process can see
cgroups: Kernel feature that limits and monitors resource usage per container
Orchestration: Automated management of container lifecycle across many machines
CaaS: Container-as-a-Service — managed container platform offered by cloud providers
Serverless: Cloud model where you deploy code without managing servers or containers
MicroVM: Lightweight VM that boots in milliseconds — combines VM security with container speed
Immutable Infrastructure: Never modify running containers — always replace with a new image build

Study Notes — Cloud Computing | Virtualisation vs Containers