5.1Virtualization & containers

A system architect inevitably faces the question of how to run multiple execution environments on limited physical hardware. The virtual-machine approach, which runs multiple whole OSes on one physical server, and the container approach, which isolates only the application execution environment on top of a single OS kernel, differ clearly in isolation strength, startup speed, and resource efficiency, and the choice must fit the requirement at hand. This section covers the difference between the two and the mechanism for running containers at scale.

5.1.1Hypervisors and server/storage virtualization

• A hypervisor is control software that runs multiple virtual machines (VMs) on physical hardware. Each VM has an entire OS, including its own independent kernel, and the hypervisor virtualizes CPU, memory, and disk to allocate them to each VM. Type 1 (bare-metal) installs directly on physical hardware without a host OS, achieving high performance and isolation (the mainstream choice for server virtualization). Type 2 (hosted) runs as an application on an existing host OS; it is easy to set up but has more overhead, making it suited to test environments.
• Storage virtualization treats multiple physical disk devices logically as a single pool, enabling capacity expansion, snapshots, and thin provisioning (dynamic allocation based on actual usage). It is used to hide changes in physical configuration from the application side and to achieve both availability (redundancy) and scalability.

5.1.2Container (Docker) lightweight nature and portability

• A container (a representative example: Docker) runs an application by isolating process space, filesystem, and networking while sharing the host OS's kernel. Because it does not carry an independent OS like a VM, its image is small, it starts in well under a second, and a single host can pack a higher density of execution units. On the other hand, because the kernel is shared, OS-level isolation is weaker than a VM's (a kernel vulnerability can affect all containers)—a design trade-off to keep in mind.
• Because a container "fixes an application and its entire set of dependencies as an image," it offers the benefit that the same image can run in development, staging, and production environments—reducing bugs caused by environmental differences and improving portability. Because of this property, containers are highly compatible with microservices architectures that involve frequent deployment and scale-out.

5.1.3Orchestration with Kubernetes

• Kubernetes (K8s) is an orchestration platform that automatically places, scales, and self-heals large numbers of containers across multiple hosts (a cluster). A controller continuously watches declarative configuration (the desired state), and when it detects a difference from the actual state, it automatically restarts or reschedules containers (self-healing). It also handles automatic scaling of container counts based on load (autoscaling) and rolling updates (staged updates without downtime).
• At the scale of manually operating a small, fixed number of containers, the operational cost of adopting Kubernetes (learning curve, cluster management) may not be worthwhile—judging whether to adopt it based on the scale of container count, change frequency, and availability requirements is the architect's role. Conversely, at a scale involving frequent deployment of many microservices where automatic recovery from failure is a requirement, an orchestration platform like Kubernetes delivers substantial value.

Suppose a system architect is leading a project to split an existing monolithic e-commerce site into three services—orders, inventory, and payments. As the execution platform, they first compared two options: keeping each service on an independent VM (on a hypervisor) as before, versus containerizing them and running them on an orchestration platform. Because this project sees sudden traffic spikes during sales, there was a requirement to scale out just the order service rapidly, within seconds; the architect judged the VM approach, which takes minutes to boot, would lag behind sudden load spikes and was unfavorable. Containers, by contrast, start quickly and fit this requirement—but the architect also kept in mind that because the kernel is shared, carelessly co-locating a sensitive workload like the payment service with other services on the same host could turn the weaker inter-container isolation into a security risk, and so designed the payment service to be placed on a dedicated set of nodes (or network segment). Furthermore, because the three independent services—orders, inventory, and payments—each needed to autoscale and self-heal individually according to fluctuating demand, the architect adopted Kubernetes orchestration rather than manually operating containers on a single host, defining a different scaling policy per service through declarative configuration. As this shows, the core of this design is not simply "use containers because they are light," but judging the virtualization approach and the need for orchestration by weighing three factors together: scale-speed requirements, isolation-strength requirements, and operational scale (whether automation is warranted).

5.1.4Section summary

• A hypervisor gives each VM an independent OS with strong isolation but slow startup; Type 1 (bare-metal) is high-performance and the mainstream choice for server virtualization
• A container (Docker) shares the kernel for lightweight/fast startup/high density, but isolation is weaker than a VM's—placement of sensitive workloads needs care
• Kubernetes is an orchestration platform handling self-healing/autoscaling/rolling updates; adoption should be judged by operational scale