Cloud without a vendor

Why this matters

Ask ten engineers what "cloud" means and you get ten answers, most of them the name of a console. That is a problem the first time you are in a room where one team runs on one provider, another runs on a second, and somebody has a hypervisor in a cupboard that everybody has agreed to pretend is not there. If your vocabulary is one vendor's product names, you cannot compare those three, you cannot design something that moves between them, and you cannot tell a supplier that what they are offering is not what you asked for.

There is a neutral vocabulary, and it is older than most of the products. It comes from NIST SP 800-145, which is two pages long and defines cloud computing by *characteristics* rather than by products: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Everything in this course is described in those terms first, and in a vendor's terms second.

Your lab machine plat01 is not a cloud. It has one of everything and no API you did not write. But it does have compute, storage, network and identity, and it has a container engine that behaves enough like a small cloud to let you provision, change and destroy resources all day. Starting from a machine you can see all of is a better foundation than starting from a console you cannot.

Concepts

The three service models are a statement about where the boundary of your responsibility sits.

• Infrastructure as a Service (IaaS) gives you virtual machines, disks and networks. You get an operating

system and everything above it; the provider keeps the hypervisor and the building.

• Platform as a Service (PaaS) gives you a place to run an application. You get the application and the

data; the provider keeps the runtime, the operating system and everything below.

• Software as a Service (SaaS) gives you the working software. You get your data and your access

decisions; the provider keeps the rest.

The important word in all three is *boundary*, not *service*. Shared responsibility means the provider is accountable for their side and you are accountable for yours, and nobody is accountable for the gap unless somebody writes it down. The single most common cloud incident is not a provider outage; it is a customer leaving something open on their own side of a boundary they had not read.

The four deployment models are about who the tenants are: public (anyone), private (one organisation), community (a group with shared concerns), and hybrid (two or more of those, joined). Ultiblob runs a private cloud across two sites; that is a deployment model, not a lesser kind of cloud.

Regions and zones. A *region* is a geography — it decides latency, and it decides which laws apply to your data. A *zone* is a failure domain inside a region — separate power, cooling and network, so that one zone failing does not take the others. Two copies in one zone protect you from a disk. Two copies in two zones protect you from a building. Two copies in two regions protect you from a region, and cost you latency and sometimes legality. Your lab has exactly one of everything, so it can teach you the vocabulary and not the behaviour; the course says so wherever that matters.

Elasticity is the ability to acquire and release capacity quickly, in proportion to demand. It is the characteristic that most changes how you design: if capacity is elastic, you scale out and you treat instances as disposable; if it is fixed, as on this machine, every capacity decision is a scheduling decision about a supply that does not grow. Neither is wrong. Designing as though you had the first when you have the second is.

Cost as a design constraint. In a rented environment, a design decision is a spending decision, and the bill arrives monthly whether anyone reviewed it or not. This course quotes no prices — prices change and we have measured none of them — but it takes the habit seriously: when a design has two shapes that work, the one whose cost you can predict is usually the one to choose.

The neutral primitives this course uses throughout, and which every provider maps onto:

  compute instance      a thing that runs your code
  block storage         a disk attached to one instance at a time
  object storage        addressable blobs, no filesystem, no single attachment
  virtual network       an address space your instances share
  firewall / security    a rule set saying who may reach what
  identity / principal  something a permission can be granted to
  image / template      the starting state of a new instance

Every cloud has all seven under different names. Your lab machine has five of them and a documented gap.

Guided exercise

You will inventory this machine and fill in a worksheet. The numbers will be your machine's, not the ones printed here, and that is the point: the check for this lesson recomputes them.

1. Sign in to plat01 as ubuntu and copy the worksheet:

cp ~/templates/primitive-map.md ~/notes/primitive-map.md

1. Measure the machine. Run each command and write the answer into the ## Measured facts block of your copy, one key: value per line:

nproc                                          # vcpu
awk '/^MemTotal:/ {print $2}' /proc/meminfo    # memtotal_kib
uname -r                                       # kernel
. /etc/os-release; echo "$VERSION_ID"          # os_version
docker version --format '{{.Server.Version}}'  # docker_server
tofu version -json | jq -r .terraform_version  # tofu_version

On the machine this lesson was written against, those printed:

vcpu: 16
memtotal_kib: 32864316
kernel: 6.6.114.1-microsoft-standard-WSL2
os_version: 24.04
docker_server: 29.1.3
tofu_version: 1.12.6

Two of those deserve a second look. The vCPU count and memory are what the machine *reports*, which on a virtualized or containerised host is not always what it has been *allocated* — a distinction that matters the first time you size something from nproc and wonder why it is slow. And the kernel version tells you what kind of machine you are on, which is worth knowing before you conclude anything about performance.

1. Look at each primitive on this machine and write what provides it:

lsblk; df -h /                 # block storage
docker network ls              # virtual network
id; getent group docker        # identity
docker images                  # image
iptables -S 2>/dev/null | head # firewall rules the engine writes

1. Fill in the mapping table. For each neutral primitive, name the equivalent in two public clouds and in Proxmox VE, from those providers' own documentation, and cite the page you used. Where there is no honest equivalent — object storage on this machine, for instance — write that instead of inventing one.

1. Finish the worksheet's last two sections: the shared-responsibility answers for IaaS, PaaS and SaaS, and a short paragraph on where the analogy between this machine and a cloud breaks down. Be specific. "It is smaller" is not a finding; "I can read the bytes under any container here, which no tenant of a public cloud can do" is.

Troubleshooting

Symptom → jq: command not found when reading the OpenTofu version. → jq is installed on this template, so this usually means the command was typed as tofu version | jq, without -json. → tofu version -json produces JSON; tofu version produces prose, and jq cannot read prose.

Symptom → The check reports measured facts wrong or missing and names memtotal_kib. → The value was copied from this lesson instead of from your machine, or free -m was used instead of /proc/meminfo. → Re-run the exact command; MemTotal in /proc/meminfo is in kibibytes and does not change between runs, while free -m rounds.

Symptom → The check says the mapping table has too few filled rows. → A row with an empty cell is not filled. → Every cell needs something, including "no equivalent"; leaving a cell blank is how a mapping table quietly becomes a wish list.

Symptom → docker version prints only the client version and an error about the daemon. → The engine is not running. → sudo systemctl status docker, and start it with sudo systemctl start docker. The --format '{{.Server.Version}}' template needs the server half of that output.

Check your understanding

Summary and next step

• Cloud is defined by characteristics — self-service, pooling, elasticity, measured service — not by products,

and NIST SP 800-145 is the two-page reference worth actually reading.

• Shared responsibility is a boundary; the incidents happen in the gap nobody wrote down.
• Seven neutral primitives cover almost everything, and your own machine provides five of them, which is

enough to learn on and not enough to conclude everything from.

Next you will look at the other half of the job: not what a cloud provides, but what a *platform team* provides to the people who use it.

References

• NIST SP 800-145, *The NIST Definition of Cloud Computing* — https://csrc.nist.gov/pubs/sp/800/145/final (accessed 2026-09-20)
• CNCF *Platforms White Paper* — https://tag-app-delivery.cncf.io/whitepapers/platforms/ (accessed 2026-09-20)
• Docker documentation, *Networking overview* — https://docs.docker.com/engine/network/ (accessed 2026-09-20)
• OpenTofu documentation — https://opentofu.org/docs/ (accessed 2026-09-20)