Virtualisation and containers notes — Unit 2

Virtualisation is the process of creating a software-based (virtual) representation of something, such as virtual applications, servers, storage, and networks. It is the fundamental technology that separates resources from their physical delivery environment.

⇒1.1 Why Virtualise?

Before virtualisation, a physical server typically ran a single operating system and a single application (e.g., an email server). This was highly inefficient, often resulting in server utilization rates of barely 10-15%. Virtualisation allows multiple OS environments to co-exist on the same physical machine, pushing utilization to 80% or higher.

The Virtual Machine Monitor (VMM), commonly called a Hypervisor, is the software layer that enables virtualisation.

⇒2.1 Functionality

The hypervisor sits between the physical hardware and the virtual machines (VMs). It traps and executes OS-level instructions from the VMs and safely multiplexes the physical CPU, RAM, and I/O devices among them. It ensures complete isolation; if one VM crashes, the others are completely unaffected.

A Type 1 hypervisor runs directly on the host's physical hardware to control the hardware and to manage guest operating systems.

⇒3.1 Characteristics

• No Host OS: There is no underlying Windows or Linux OS. The hypervisor is the operating system.
• Performance: Extremely high performance and minimal overhead, as VMs have near-direct access to the hardware.
• Use Case: This is the enterprise standard used in cloud data centers (AWS, Azure).
• Examples: VMware ESXi, Microsoft Hyper-V, Xen.

A Type 2 hypervisor runs as a standard software application on top of a conventional host operating system (like Windows or macOS).

⇒4.1 Characteristics

• Host OS Dependent: If the underlying host OS crashes, all VMs crash.
• Performance: Lower performance than Type 1 due to the overhead of passing instructions through the host OS before reaching the hardware.
• Use Case: Ideal for desktop developers who want to run a Linux VM on their Windows laptop for testing.
• Examples: Oracle VirtualBox, VMware Workstation, Parallels Desktop.

Historically, x86 processors were not designed to be virtualized. Early hypervisors had to use complex, slow software tricks (Binary Translation) to intercept privileged CPU instructions issued by the Guest OS.

⇒5.1 Intel VT-x and AMD-V

CPU manufacturers realized the importance of the cloud and added new instructions directly into the silicon to support virtualisation.

These hardware extensions (Intel VT-x and AMD-V) allow the CPU to natively understand that it is running a hypervisor and guest OSs, eliminating the need for slow software interception. This brought VM performance to near-native speeds.

Virtualisation is not just for servers. The concept is applied across the entire IT stack.

• Server Virtualisation: Partitioning a physical server into smaller virtual servers (VMs).
• Network Virtualisation (SDN): Decoupling the network control plane from the physical routing hardware. Allows creating complex virtual networks (VLANs, firewalls) entirely in software.
• Storage Virtualisation: Pooling physical storage from multiple network storage devices into what appears to be a single storage device managed from a central console.
• Desktop Virtualisation (VDI): Running a user's desktop OS inside a VM on a server. The user's physical laptop acts only as a thin client streaming the screen.

While VMs revolutionized the data center, they have significant drawbacks for modern, rapid software development.

⇒7.1 The Overhead Problem

Every Virtual Machine requires a full, complete Guest Operating System. If you want to run a 50MB Node.js application, you must spin up a VM containing a 2GB Linux OS. If you have 10 identical Node.js apps on a server, you are running 10 identical copies of the Linux kernel in memory. This wastes massive amounts of RAM, CPU, and disk space.

Furthermore, booting a full OS takes minutes, which is too slow for auto-scaling during sudden traffic spikes.

Containers solve the overhead problem of VMs by using OS-Level Virtualisation.

⇒8.1 How Containers Work

Instead of virtualising the underlying hardware, containers virtualise the Operating System. A container packages your application code and its specific dependencies (libraries, runtimes) into a single box. However, all containers on a physical server share the same underlying host OS kernel.

Because they don't contain a full OS, containers are incredibly lightweight (often just megabytes). They start in milliseconds instead of minutes.

• Architecture: VMs run on a hypervisor and include a full Guest OS. Containers run on a container engine (like Docker) and share the Host OS kernel.
• Size: VMs are Gigabytes. Containers are Megabytes.
• Startup Time: VMs take minutes. Containers take milliseconds.
• Isolation: VMs provide strong, hardware-level isolation (very secure). Containers provide process-level isolation (weaker security; if the host kernel is compromised, all containers are compromised).
• Efficiency: You might fit 10 VMs on a server, but you could fit 100+ containers on that same server.

While Linux containers (LXC) existed for years, they were difficult to use. In 2013, Docker democratized containers by creating a simple, standardized way to build, share, and run them.

⇒10.1 Key Docker Concepts

• Dockerfile: A simple text file with instructions on how to build the container (e.g., 'Start with Ubuntu, install Python, copy my code').
• Docker Image: The read-only template built from the Dockerfile. It contains everything needed to run the app.
• Docker Container: A running, executable instance of an Image.
• Docker Registry (Docker Hub): A cloud repository where developers push and pull Images (like GitHub for containers).

Containers fueled the architectural shift from Monoliths to Microservices.

⇒11.1 The Synergy

In a microservice architecture, a massive application (like Netflix) is broken down into hundreds of tiny, independent services (Login Service, Recommendation Service, Billing Service).

Containers are the perfect vehicle for microservices. Each service is packaged in its own container. If the Billing Service needs an update, you only rebuild and deploy that one container, without touching the rest of the application. If the Recommendation Service receives heavy traffic, you can spin up 50 more containers of just that service.

Running Docker on your laptop is easy. But running a microservices architecture in production means managing thousands of containers across hundreds of physical servers.

⇒12.1 The Operational Nightmare

How do you decide which physical server has enough RAM to host a new container? What happens if a server dies and takes 50 containers with it? How do containers on Server A talk to containers on Server B? How do you update 1000 containers without downtime?

Docker alone cannot solve these distributed systems problems. We need a Container Orchestrator.

Originally designed by Google (based on their internal 'Borg' system) and open-sourced in 2014, Kubernetes is the undisputed industry standard for container orchestration.

⇒13.1 What Kubernetes Does

You give Kubernetes a cluster of physical servers. You declare your desired state: 'I want 5 copies of my web-app container running.' Kubernetes handles the rest.

• Scheduling: It intelligently packs containers onto the physical servers to maximize efficiency.
• Self-Healing: If a container crashes, K8s automatically restarts it. If a physical node dies, K8s reschedules its containers onto healthy nodes instantly.

⇒14.1 K8s Architecture

K8s consists of a Control Plane (managing the API and scheduling) and Worker Nodes (running the actual apps). The smallest deployable unit is a Pod, which encapsulates one or more containers.

⇒14.2 Serverless and MicroVMs

While containers are fast, their shared OS kernel creates security risks. AWS developed Firecracker MicroVMs—ultra-lightweight VMs that boot in milliseconds, providing the speed of containers with the impenetrable hardware-level security of traditional VMs, powering modern serverless architectures.