Virtualization, Containers and Cloud Resources

Introduction

Modern cloud platforms are built on a separation between physical infrastructure and the computing, storage, database, caching and messaging resources consumed by applications. Virtualization provides this separation through software abstractions such as virtual machines (VMs), virtual networks and virtual disks. Containers provide a lighter abstraction that packages an application and its dependencies while sharing the host operating system kernel. Orchestration platforms coordinate large numbers of containers and supporting services.

For an IT professional, the central design question is not whether one technology is universally superior. It is how to select an execution model and cloud service that satisfies workload, performance, resilience, security, operational and financial requirements. This chapter develops that decision-making ability.

Learning Objectives

By the end of this chapter, you should be able to:

• explain virtualization, hypervisors, VMs, containers and orchestration;
• compare VMs and containers in terms of isolation, portability, performance and management;
• describe container images, registries, networking, storage and scheduling;
• select compute, storage, database, caching and messaging services for a workload;
• analyse availability, scalability, durability, latency and cost trade-offs;
• apply sound security, governance and operational practices.

1. Virtualization and Hypervisors

Virtualization presents a logical resource that is implemented by a different physical resource. A VM appears to have processors, memory, storage and network interfaces, although these are provided by a physical host and controlled by a virtualization layer. The guest operating system behaves as if it owns the virtual hardware.

A hypervisor, also called a virtual machine monitor (VMM), creates and manages VMs. A Type 1, or bare-metal, hypervisor runs directly on the physical host. Examples include VMware ESXi, Microsoft Hyper-V in its hypervisor role, and Xen-based platforms. A Type 2 hypervisor runs as an application above a conventional host operating system, as with VirtualBox or VMware Workstation. Type 1 designs generally provide stronger performance isolation and are common in data centres; Type 2 designs are convenient for laboratories and desktop development.

Hardware-assisted virtualization

Modern processors provide virtualization extensions that allow guest operating systems to execute privileged operations safely without requiring the hypervisor to translate every instruction. The hypervisor still controls memory translation, device access, interrupts and scheduling. Technologies such as Intel VT-x, AMD-V, nested page tables and IOMMUs improve performance and permit controlled assignment of devices.

A VM normally contains:

• virtual CPUs mapped to physical processing capacity;
• virtual memory mapped to host memory;
• virtual disks backed by files, block devices or network storage;
• virtual network adapters connected to virtual switches;
• firmware, device controllers and an operating-system image.

The hypervisor schedules virtual CPUs, manages memory overcommit where supported, handles I/O and enforces boundaries between tenants. Overcommitment can improve utilisation, but excessive overcommitment causes contention and unpredictable latency. Balloon drivers, memory sharing and host swapping are useful mechanisms, but host swapping is usually a last resort for performance-sensitive systems.

VM lifecycle

A professional VM lifecycle includes image selection, sizing, provisioning, configuration, patching, monitoring, backup, snapshot management and retirement. An image should be treated as a controlled artifact rather than manually modified indefinitely. Image templates, infrastructure as code and configuration management reduce configuration drift.

A snapshot records the state of a disk, and sometimes memory, at a point in time. It is useful before a change, but it is not automatically a complete backup. Long chains of snapshots can increase storage and recovery complexity. Backups should be tested by performing restoration exercises.

2. Containers

A container is an isolated process environment that shares the host kernel. It packages application code, runtime libraries, configuration defaults and dependencies into an image. Unlike a VM, it does not normally contain a complete guest kernel. Consequently, containers start quickly and use fewer resources, but their isolation boundary is generally narrower than that of a VM.

Linux containers rely on kernel mechanisms such as namespaces and control groups (cgroups). Namespaces provide views of processes, networking, mounts, users and other resources. Cgroups limit and account for CPU, memory and other resource consumption. A container runtime, such as containerd or CRI-O, obtains an image, creates the required namespaces and cgroups, mounts filesystem layers and starts the process.

A container image is normally composed of immutable layers. A writable layer may be added while a container runs, but important application data should be stored in a persistent volume or external service. Images should be small, reproducible and built from trusted base images. A registry stores and distributes images; it may be public or private.

A Dockerfile-like build process commonly performs the following actions:

1. select a minimal, supported base image;
2. install only required packages;
3. copy application artifacts;
4. declare the listening port and startup command;
5. run the process as a non-root user;
6. scan, sign and publish the image.

The image should not contain passwords, private keys or environment-specific secrets. Secrets belong in a managed secret store or a protected orchestration mechanism.

VM and container comparison

The distinction is not absolute. Containers can run inside VMs, combining VM-level tenant isolation with container-level packaging. This is common in managed cloud services.

3. Orchestration and Distributed Application Management

Running one container manually is simple; operating thousands across many hosts is not. Orchestration automates placement, starting, stopping, scaling, networking, service discovery, health management and rolling updates. Kubernetes is the most widely recognised example, while cloud providers also offer managed container services and simpler container platforms.

A cluster generally has a control plane and worker nodes. The control plane stores desired state and makes scheduling decisions. Workers run container workloads. In Kubernetes terminology, a Pod is the smallest deployable unit and may contain one or more closely coupled containers. A Deployment manages replicated stateless Pods; a Service supplies a stable virtual endpoint; a ConfigMap stores non-secret configuration; a Secret holds sensitive values; and a PersistentVolume represents storage made available to workloads.

The important orchestration model is desired state. An operator declares, for example, that five replicas of a service should be available. Controllers compare actual state with desired state and take corrective action. If a node fails, the scheduler can place replacement replicas elsewhere, provided capacity and constraints permit it.

Scheduling and scaling

Schedulers consider resource requests, limits, affinity, taints, topology and policy. A request expresses the resources needed for placement; a limit caps consumption. Incorrect values produce either waste or instability. Horizontal scaling changes the number of replicas. Vertical scaling changes resources assigned to an instance. Autoscaling may use CPU, memory, request rate, queue depth or business metrics.

A rolling deployment gradually replaces old replicas with new ones. Readiness probes determine whether a replica can receive traffic; liveness probes identify an unhealthy process that should be restarted. Poorly designed probes can cause restart loops, while missing probes can route users to broken instances.

Service discovery maps a logical service name to changing workload addresses. Ingress or gateway components expose selected services externally and can provide routing, TLS termination, authentication and rate control. Network policies restrict which workloads may communicate, supporting least privilege.

Stateful workloads

Containers are naturally convenient for stateless services, but databases and other stateful systems require careful storage, identity, ordering and recovery design. Stateful orchestration features can attach persistent volumes and provide stable identities, but they do not eliminate the complexity of replication, backup, consistency and failure recovery. A managed database is often safer operationally than running a database inside a general-purpose cluster.

4. Cloud Resource Models

Cloud services are commonly grouped as infrastructure as a service (IaaS), platform as a service (PaaS), container services and serverless functions. IaaS provides virtual machines, networks and block storage; the customer manages the guest operating system and application. PaaS abstracts more operational work, such as patching or runtime management. Serverless functions abstract servers almost entirely and charge according to execution and associated resources, though limits on duration, state and runtime apply.

The shared responsibility model divides security and operations between provider and customer. The provider secures the physical facilities, hardware and foundational service; the customer remains responsible for identities, data classification, configuration, application security and, depending on the service, guest operating systems. The exact boundary varies by service and contract.

Compute selection

Select compute using workload characteristics rather than brand names:

• VMs: suitable for legacy applications, custom kernels, licensed software, specialised agents and predictable long-running services.
• Managed containers: suitable for portable services requiring process isolation, repeatable deployment and independent scaling.
• Kubernetes: suitable when teams need complex scheduling, multi-service networking, portability or a common platform across environments. It introduces substantial operational complexity.
• Serverless functions: suitable for event-driven, short-lived, stateless processing with variable demand. Cold starts, execution limits and platform coupling must be assessed.
• Batch or spot capacity: suitable for interruptible jobs such as rendering, testing and large data processing, if checkpointing or retry is available.

A first-order capacity estimate can use average demand and a safety factor:

Here, N is the number of instances, D is expected demand in a consistent unit such as requests per second, C is sustainable capacity per instance in the same unit, S is a dimensionless safety factor greater than or equal to 1, and ⌈x⌉ means round upward to the next integer. This is an estimate, not a substitute for load testing. It assumes instances have comparable capacity and that demand can be distributed effectively.

For example, if demand is 240 requests per second, each instance sustains 80 requests per second, and the safety factor is 1.25, then N = ⌈(240 × 1.25) ÷ 80⌉ = ⌈3.75⌉ = 4. The result must still be checked against memory, database capacity, failure scenarios and service-level objectives.

5. Cloud Storage

Storage selection depends on access pattern, latency, durability, sharing, capacity and cost.

Durability is the probability that stored data is not lost over a stated period; availability is the probability that the service is accessible when requested. Replication can improve both, but replication is not a substitute for independent backups. Deletion, corruption and ransomware may be replicated as well. Versioning, immutability, lifecycle policies, encryption and tested restoration are important controls.

A storage design should specify data classification, retention period, recovery point objective (RPO), recovery time objective (RTO), access controls and geographic requirements. RPO states the maximum acceptable amount of data loss measured in time. RTO states the maximum acceptable time to restore service.

6. Databases, Caches and Messaging

Databases

Relational databases provide structured schemas, transactions, joins and mature integrity controls. They are appropriate for orders, payments, inventory and other systems requiring strong consistency and relationships. Managed relational services commonly provide automated patching, backups, replicas and failover, but the application must still choose indexes, transactions and connection behaviour carefully.

NoSQL services include key-value, document, wide-column and graph databases. They can provide scalable access for specific patterns, but their data model and consistency semantics must be understood before design. A schema designed around known access patterns is often more successful than attempting to reproduce arbitrary relational queries.

Read replicas can increase read capacity, but replication may be asynchronous. An application that reads immediately after writing may observe stale data unless it uses a primary, consistency option or an appropriate session strategy. Multi-region replication introduces latency, conflict and recovery considerations.

Caching

A cache stores reusable results closer to the application. It can reduce database load and latency, but it introduces invalidation, stale data and failure-mode concerns. Common strategies include cache-aside, read-through and write-through. In cache-aside, the application reads the cache, obtains a miss from the database, then populates the cache. A time-to-live limits staleness but does not solve every invalidation problem.

A cache should not be the only durable copy of critical data unless its service explicitly provides that guarantee and the design requires it. Capacity, eviction policy, hot keys, stampedes and access control must be monitored.

Messaging

A queue decouples producers from consumers. It absorbs bursts and permits workers to process tasks independently. A topic or publish-subscribe service distributes an event to multiple subscribers. Messaging improves resilience and scalability, but creates eventual consistency and operational requirements.

Important concepts include delivery semantics, ordering, retention, acknowledgement, retry, dead-letter handling and idempotency. At-least-once delivery is common: a message may be delivered more than once, so consumers should safely repeat processing. Exactly-once effects are usually achieved through application-level deduplication or transactional design rather than assumed from a marketing label.

7. Resilience, Performance and Cost

Resilience is designed through redundancy, failure isolation and recovery. Replicas should be distributed across failure domains such as availability zones. A multi-zone design is not automatically resilient if all replicas depend on one database, network route or identity service. Dependencies must be mapped as a graph and tested under failure.

Useful measures include latency percentiles, throughput, error rate, saturation, availability, durability, RPO and RTO. Average latency can hide severe tail behaviour; p95 or p99 latency is often more informative for user-facing systems. Load tests should represent realistic payloads, concurrency, cache state and downstream limits.

Cost analysis should include compute time, storage capacity, requests, data transfer, managed-service fees, licenses, observability and personnel. A lower unit price may be economically inferior if it increases administration or outage risk. Rightsizing, autoscaling, lifecycle policies, reserved capacity where demand is stable, and interruption-tolerant capacity where appropriate can reduce cost.

8. Security, Governance and Ethics

Security controls include least-privilege identity, network segmentation, image and dependency scanning, signed artifacts, patch management, encryption in transit and at rest, central logging, vulnerability response and secrets rotation. The orchestration control plane deserves special protection because compromise can affect many workloads.

Governance requires approved regions, tagging, budgets, audit trails, retention rules and policy-as-code. Regulatory obligations may concern personal data, payment data, health information, data residency and breach notification. Data should be classified before selecting replication locations or third-party services.

Automation and AI-assisted operations can recommend capacity, detect anomalies and summarise incidents. They should not be granted unrestricted authority by default. Recommendations require human review, explainable evidence, access controls and testing for false positives, bias and unsafe automated remediation. Logs may contain personal or confidential information and should be minimised and protected.

9. Applied Case: Illustrative Online Retail Platform

Background. An online retailer operates a catalogue, customer accounts, checkout, payment integration and shipment notifications. Demand is highly variable, with large peaks during promotional campaigns.

Problem. The existing monolithic VM deployment requires manual scaling. A slow database causes checkout latency, while batch notification work competes with customer requests. The retailer requires an RTO of 60 minutes and an RPO of 15 minutes.

Analysis. Catalogue images and product documents are large, accessed by URL and do not require transactional updates; object storage with a content delivery layer is appropriate. Orders and payments require transactions and relationships; a managed relational database is appropriate. Search and frequently viewed catalogue data can use a cache, provided stale prices cannot be presented at checkout. Notification work can be placed on a durable queue so workers scale independently.

Approach. The team packages stateless catalogue, account and checkout services as containers. A managed container platform schedules replicas across at least two availability zones. The database uses automated backups, multi-zone failover and a tested restore process. Checkout validates authoritative price and inventory data against the database rather than trusting the cache. An autoscaling worker service consumes notification messages. Images are stored in object storage with versioning and lifecycle rules. Infrastructure is defined as code, images are scanned in the delivery pipeline, and dashboards track p95 latency, queue age, database connections and error rate.

A capacity test estimates 240 requests per second at peak. If one application replica sustains 80 requests per second and the safety factor is 1.25, four replicas are required by the first-order estimate. The team then tests node failure and database connection limits; it may provision more replicas because service capacity is not perfectly linear.

Outcome. Customer-facing traffic scales independently from notification work, database load falls through carefully controlled caching, and recovery procedures meet the stated objectives in testing. The solution is more complex than a single VM, so the retailer retains managed services and documented operational ownership rather than adopting a full Kubernetes platform without need.

Learning points. Architecture follows workload characteristics. Caches do not replace authoritative data, queues require idempotent consumers, replicas do not remove the need for backups, and operational simplicity is itself a design objective.

10. Best-Practice Decision Framework

A practical selection sequence is:

1. classify data and regulatory constraints;
2. describe workload shape: steady, bursty, interactive, batch or event-driven;
3. define latency, throughput, availability, RPO and RTO targets;
4. choose the least complex compute abstraction that meets requirements;
5. select storage by access pattern and durability rather than convenience;
6. choose database consistency and data model deliberately;
7. add caching only where measured access patterns justify it;
8. use queues or topics to decouple suitable workloads;
9. model failure domains and dependency behaviour;
10. estimate total cost and operational skill requirements;
11. validate with security review, load testing and recovery exercises;
12. monitor actual behaviour and revise capacity and architecture.

Chapter Summary

Virtualization abstracts physical resources into VMs managed by hypervisors. VMs provide full guest operating systems and strong, familiar isolation, whereas containers package processes while sharing a host kernel. Orchestration manages desired state, placement, health, scaling, service discovery and updates across many containers. Cloud compute may be supplied as VMs, managed containers, Kubernetes platforms or serverless functions, each offering different control and operational burden.

Object, block, file and ephemeral storage serve different access patterns. Relational databases support transactions and relationships; NoSQL systems support specialised scalable access patterns. Caches reduce latency and load but introduce staleness and invalidation concerns. Queues and topics decouple services and absorb bursts, while requiring retry and idempotency design. Resilience depends on redundancy across failure domains, tested backups and recovery procedures. Security, governance, cost and operational simplicity must be evaluated alongside technical performance.

Key Terms

Virtualization: Abstraction of physical computing resources into logical resources.

Hypervisor: Software that creates and manages virtual machines.

Virtual machine: An isolated software-defined computer with a guest operating system.

Container: An isolated process environment that shares a host kernel.

Container image: An immutable packaged filesystem and metadata used to create a container.

Registry: A service that stores and distributes container images.

Namespace: A kernel mechanism that gives processes isolated resource views.

Cgroup: A mechanism for limiting and accounting for resource consumption.

Orchestration: Automated management of distributed workloads and services.

Pod: Kubernetes’ smallest deployable unit, containing one or more containers.

Service discovery: Mapping a logical service identity to changing workload endpoints.

Object storage: Scalable storage accessed through objects and APIs.

Durability: Probability that stored data remains preserved over a stated period.

Availability: Probability that a service is accessible when requested.

RPO: Maximum acceptable period of data loss after a failure.

RTO: Maximum acceptable time to restore service.

Cache: A faster temporary copy of reusable data.

Queue: A messaging structure that buffers work between producers and consumers.

Idempotency: Property whereby repeating an operation produces the same intended effect.

Shared responsibility model: Allocation of security duties between provider and customer.

Review Questions

Short Answer Questions

1. What is the difference between a Type 1 and Type 2 hypervisor?
2. Why do containers usually start faster than virtual machines?
3. What roles do namespaces and cgroups play in containerisation?
4. Distinguish durability from availability.
5. Why should a message consumer be idempotent?

Long Answer Questions

1. Compare VMs, containers and serverless functions for a regulated financial application.
2. Explain how an orchestration platform maintains desired state and supports rolling deployment.
3. Discuss the selection of object, block and file storage for a media-processing company.
4. Explain the benefits and risks of database replication, caching and asynchronous messaging.
5. Develop a resilience and governance plan for a multi-zone cloud application.

Analytical / Application Questions

1. A service receives 360 requests per second. Each instance sustains 90 requests per second, and the required safety factor is 1.2. Calculate the minimum number of instances using the capacity equation, then identify two reasons load testing may require more.
2. Design a compute, storage, database, cache and messaging architecture for a university examination-results system. Justify each selection using consistency, confidentiality, availability and workload requirements.
3. A containerised application repeatedly loses data when nodes are replaced. Diagnose the likely storage-design error and propose a recovery-oriented redesign, including backup testing and RPO/RTO considerations.

Multiple Choice Questions with Answers

Question 1

Which component creates and manages virtual machines?

A. Hypervisor

B. Message broker

C. Object-storage gateway

D. Cache invalidator

Correct Answer: A. Hypervisor

Question 2

What is the principal reason containers generally require fewer resources than virtual machines?

A. They do not use networking

B. They share the host operating-system kernel

C. They permanently disable security controls

D. They store all data in memory

Correct Answer: B. They share the host operating-system kernel

Question 3

Which orchestration feature determines whether a workload should receive traffic?

A. Readiness probe

B. Image registry

C. Object lifecycle rule

D. Block snapshot

Correct Answer: A. Readiness probe

Question 4

Which storage type is most appropriate for large media files accessed through APIs?

A. Object storage

B. Ephemeral local storage

C. CPU cache

D. VM firmware storage

Correct Answer: A. Object storage

Question 5

A queue primarily helps an architecture by doing what?

A. Removing the need for authentication

B. Decoupling producers and consumers while buffering work

C. Guaranteeing zero message duplication

D. Replacing all databases

Correct Answer: B. Decoupling producers and consumers while buffering work

Question 6

A workload requires relational transactions and joins. Which service category is the most appropriate starting point?

A. Relational database

B. Image registry

C. Object storage

D. DNS cache

Correct Answer: A. Relational database

Question 7

Expected demand is 240 requests per second, instance capacity is 80 requests per second, and the safety factor is 1.25. What is the minimum estimated instance count?

A. 2

B. 3

C. 4

D. 5

Correct Answer: C. 4

Question 8

What does RPO measure?

A. Maximum acceptable time to restore service

B. Maximum acceptable amount of data loss measured in time

C. Average application latency

D. Number of replicas in a cluster

Correct Answer: B. Maximum acceptable amount of data loss measured in time

Question 9

Why should a cache not normally be treated as the only durable copy of critical data?

A. Caches cannot reduce latency

B. Cached data may be evicted, lost or become stale

C. Caches cannot store keys

D. Caches always require a guest operating system

Correct Answer: B. Cached data may be evicted, lost or become stale

Question 10

Which practice best supports container supply-chain security?

A. Embedding passwords in images

B. Running every process as root

C. Scanning and signing trusted image artifacts

D. Disabling image versioning

Correct Answer: C. Scanning and signing trusted image artifacts