Lesson 1: The Project: One Benchmark From Laptop to Decision

Why this course is one project, not a tour

You have been asked to deliver HPC on GCP or Azure and to pick the compute. The obvious move is to open the spec sheets, compare cores, memory and network speed, and pick the biggest numbers you can afford. This course exists because that move fails often enough to be dangerous.

Think of buying a delivery van by reading the brochures. Top speed and payload are real numbers. But your cost per parcel depends on your routes, your loading dock and your traffic, and no brochure knows those. HPC is the same. A spec sheet describes the machine. It does not describe your code on that machine.

So we work as engineers do: we take one benchmark from your laptop, through containers and Kubernetes, onto real cloud options, and end with a written recommendation backed by measured evidence. Every level adds one piece to the same repository.

What spec sheets can and cannot tell you

Here are two real current offerings (as of October 2026):

• Google Cloud H4D (generally available since March 2026): 192 cores per VM on 5th Gen AMD EPYC, with 200 Gbps Cloud RDMA networking.
• Azure HBv5 (generally available since November 2025): 800 Gb/s of InfiniBand per VM (4 × 200 Gb/s NICs), built for applications limited by memory bandwidth.

It is tempting to read "800 beats 200" and stop there. Look at what Google published itself in the H4D launch post. On the same VM type, the vendor reported about 95% parallel efficiency for LAMMPS on 96 VMs, but 72% for GROMACS on 32 VMs. Same hardware, same vendor, same blog post, and very different scaling. The application changed the answer.

Three things a spec sheet will never give you:

1. Your application's behaviour. Whether your code is held back by the CPU, memory, network or storage decides which number matters. We measure that in the next few levels.
2. The whole system. Time waiting for capacity, image pull time, storage throughput, quotas and Spot interruptions all fall outside the VM's spec, yet they all count toward time to result.
3. Cost per result. A VM that is 30% faster at twice the hourly price loses. Only a measured run time multiplied by a real price tells you which one wins.

Gotcha: vendor benchmarks are honest but selected. They show workloads that scale well on that hardware. Treat them as evidence the machine can perform, not that it will perform for you.

Set up the project repository

One repository holds everything: code, raw results, your notes and the final decision. These commands work in Git Bash, WSL, macOS or Linux.

# 1. Create the project and start version control
mkdir hpc-compute-decision && cd hpc-compute-decision
git init

# 2. One folder per kind of artefact
mkdir -p code/benchmarks   # benchmark source, build scripts, later Dockerfiles
mkdir -p infra             # Terraform and platform config arrive in later levels
mkdir -p results/raw       # untouched output from every run, never edited
mkdir -p results/summary   # tables and charts derived from raw/
mkdir -p notes             # dated lab notebook: what you tried, what broke
mkdir -p decision          # the final one-page recommendation

# 3. Seed the key files
touch notes/$(date +%F)-kickoff.md
touch decision/recommendation.md

Now add a .gitignore before you commit anything:

# Terraform state can hold secrets and belongs in a remote backend, not git
*.tfstate
*.tfstate.*
.terraform/
# Credentials and local env files
*.json.key
.env
# Large scratch data: keep sizes small, store big files elsewhere
scratch/

Pitfall: committing a cloud key or a Terraform state file is the most common early mistake, and git history keeps it after you delete the file. Ignore these files from day one.

A results convention that survives review

Six weeks from now someone will ask, "Which image ran that? In which region?" Save metadata next to every raw result, so the answer sits beside the output:

results/raw/2026-10-31_laptop_stream_run01/
├── output.txt      # exact stdout of the benchmark
└── meta.yaml       # context for the run

# meta.yaml: fill in for every run, even laptop runs
date: 2026-10-31
platform: laptop          # later: gke-kueue, azure-batch, ...
machine: "8-core x86, 32 GB"
image: none               # later: image digest, e.g. sha256:...
benchmark: stream
command: "./stream_c.exe"
cost_usd: 0.00            # always record cost, even when zero
notes: "baseline before containers"

Raw output is never edited. Summaries are rebuilt from it. When a number looks wrong you can always go back to the source.

The deliverables, in build order

Write this list into README.md. It is your course map.

# Deliverables (built in this order)
1. Workload profile: coupling, bottleneck, success criteria
2. Benchmark running natively on the laptop, with results saved
3. Container image of the benchmark, run locally
4. Same image as batch jobs on local Kubernetes
5. Platform path proven with a trivial resource
   (Backstage template -> Harness pipeline -> Terraform)
6. Runs on the candidate GCP and Azure options, with cost logged
7. Weighted scoring matrix built from measured results
8. decision/recommendation.md: one page, with evidence

Why this order? Each step depends on the one before it. You can't judge a cloud run without success criteria (1). You can't tell a cloud problem from a code problem without a laptop baseline (2). Proving the platform path (5) before the expensive runs means you find out early if your organisation's Backstage, Harness and Terraform route blocks you, before you have spent budget.

Best practice: start the recommendation file today with an empty skeleton (Context, Options tested, Evidence, Recommendation, Risks). Fill it in as you go and it writes itself.

Trade-off: we assume no winner in advance. Your organisation may already lean toward one cloud. The point of the evidence is to confirm that preference or overturn it, and the document must allow either result.

Key takeaways

• Spec sheets describe the machine, not your workload. Even a vendor's own published results vary widely by application on identical hardware.
• Time to result and cost per result include queueing, storage, start-up and pricing, and none of those appear on a spec sheet.
• One repository holds everything: code/, infra/, results/raw and results/summary, notes/, decision/.
• Every raw result gets a meta.yaml with date, platform, image and cost. Raw output is never edited.
• Keep state files and credentials out of git from the first commit.
• Build deliverables in dependency order, and prove the platform path before you spend money on cloud runs.
• Date every product claim. Cloud offerings change monthly.