2.3System Configuration and Virtualization

System configuration options keep multiplying, but what AP requires is not merely recognizing names—it is the ability to explain, as a practical judgment, the tradeoffs each configuration is built on. This section precisely organizes the judgment axes underpinning modern system infrastructure: virtualization vs. containers, and the cloud's shared-responsibility split.

2.3.1Hypervisors vs. containers

• A hypervisor is control software that splits and allocates physical hardware resources to multiple virtual machines (VMs). The bare-metal type (Type 1), which runs directly on physical hardware, has lower overhead since it does not route through an existing OS, and it dominates server use cases. The hosted type (Type 2), which runs as an application on top of an existing OS, is easier to set up but incurs more overhead by routing through the host OS.
• A container (e.g., Docker) is a technology that isolates and runs an application and its dependencies at the process level while sharing the host's OS kernel. Because it does not need to boot a separate guest OS, it starts in seconds or even hundreds of milliseconds—much faster than a VM—and consumes less memory and storage. However, because it shares the kernel, it does not provide isolation as strong as a VM's (a kernel vulnerability can potentially affect every container), which is a tradeoff worth keeping in mind.

2.3.2Load-balancing methods and the cloud responsibility split

• Representative load-balancing methods include the round-robin method, which assigns requests to each server in turn (simple, but ignores each server's current load), and the least-connections method, which preferentially assigns requests to whichever server currently has the fewest in-progress connections (better reflects each server's actual load). When request processing time varies widely, the practical judgment favors least-connections over plain round robin, since it better avoids imbalance.
• The IaaS/PaaS/SaaS cloud service models differ in their shared-responsibility boundary—who, the customer or the provider, manages what. IaaS provides only infrastructure such as virtual servers and networking, leaving the OS and everything above it (including middleware and applications) to the customer. PaaS also provides the application runtime platform (language runtime, middleware), leaving the customer responsible for implementing the application and its data. SaaS provides the finished business application, leaving the customer responsible only for usage configuration and data entry.

Consider a redundancy choice in a practical scenario. When a core system demands extremely high reliability such that "an incorrect computed result must never be produced," a dual system—where two independent processing systems perform the same processing on the same input independently and then cross-check the results for agreement—becomes a candidate. It lets you mutually verify the correctness of the result itself, but running two systems in parallel at all times raises cost. Many business systems, however, only need "if one side fails, processing can be handed over promptly," which a duplex system satisfies: normally only the primary (active) system processes work, switching to the standby (backup) system on failure. Duplex systems further split into hot standby (the standby stays powered on and kept in the same state as the primary at all times, for the fastest switchover), warm standby (the standby's program is already running, but data is synchronized only periodically), and cold standby (the standby is not even powered on until needed, minimizing cost but taking the longest to switch over)—you choose among these based on whether recovery speed or cost matters more. The same judgment axis applies to cloud adoption. For something like a core-business database that needs fine-grained custom tuning or middleware configuration, you build it yourself on IaaS; when a development team wants to be freed from infrastructure management to focus on application development, you choose PaaS (e.g., a managed application runtime or database service); and for industry-standard operations such as attendance tracking or accounting, you use SaaS rather than building it yourself. The rational judgment is to keep only what genuinely needs to be custom under your own management, and hand everything else off to the provider.

2.3.3Section summary

• Hypervisors are bare-metal (Type 1, low overhead) or hosted (Type 2, higher overhead). Containers share the OS kernel for fast startup, but with weaker isolation than a VM
• Load balancing: round robin (simple) vs. least connections (reflects actual load). IaaS/PaaS/SaaS differ in their responsibility boundary; managed scope narrowest to broadest is SaaS < PaaS < IaaS
• Dual system = two systems cross-verifying each other (high cost, high reliability). Duplex system = a primary plus a standby (hot/warm/cold standby trade off recovery speed against cost)