Lesson 2: The Standard Hybrid Profile

Why a profile comes before any product

When a team says "we need hybrid", they usually mean one of four things, and they rarely say which. If you start from product names you end up choosing the product with the best demo. If you start from a written profile, every later choice in this course can be checked against the same facts: provider hardware on site, managing clusters from the cloud, a metro edge or shipping disks.

Think of the profile as a site survey a builder does before quoting. It is dull and it is short, and it stops expensive mistakes. In this level you will fill one in for a fictional retailer, NorthMart, with a head-office data centre in Leeds and 40 stores.

Step 1: The real reason a region is not enough

There are only four honest reasons, and each one needs a number behind it. A reason with no number is a preference.

A physics sanity check for latency: light in fibre covers about 200 km per millisecond, so each 100 km of real fibre path adds roughly 1 ms to the round trip before any routing or queueing. Measure it rather than guessing:

# Run from a machine AT THE SITE, not from your laptop on the office VPN.
# Create a small test VM in the candidate region first, then:
ping -c 200 34.105.x.x | tail -1
# rtt min/avg/max/mdev = 9.8/11.2/41.7/3.1 ms   <- avg looks fine...

# Averages hide the tail. Collect samples and look at p99:
for i in $(seq 1 500); do ping -c1 -W1 34.105.x.x | grep -oP 'time=\K[0-9.]+'; done \
  | sort -n | awk '{a[NR]=$1} END {print "p99:", a[int(NR*0.99)]}'
# p99: 28.4    <- this is the number that goes in the profile

Gotcha: "Latency" is often the reason given when the real one is "the network team does not trust the WAN". That is the disconnected operation reason, and it needs a different number: hours offline, not milliseconds.

Step 2: The profile template

Keep one file per organisation in version control, with one block per site. YAML works well because reviewers can diff it.

# hybrid-profile.yaml  (NorthMart, v1, 2026-10-30)
why_not_a_region:
  primary: disconnected_operation      # pick ONE as primary
  evidence: "Stores trade 72 h with WAN down (ops policy OPS-14)"
  secondary: latency
  secondary_evidence: "Checkout vision p99 must be <20 ms; region p99 = 28.4 ms"

sites:
  - name: leeds-dc
    count: 1
    power_space: "2 racks free, 16 kW, raised floor"
    connectivity: "2 x 10 Gbps diverse paths to the cloud; private link in place"
    workloads: ["ERP (VMs)", "stock DB (Oracle)", "CI runners"]
    hardware_owner: customer           # customer | provider | partner
    hands_on_staff: "24x7 on-site ops"
    update_window: "Sun 01:00-05:00 UTC, monthly"
    compliance: ["PCI DSS", "UK GDPR"]
  - name: store-template
    count: 40
    power_space: "1 wall cabinet, 1.5 kW, no cooling"
    connectivity: "100 Mbps broadband + 4G backup; outages ~6/yr"
    workloads: ["POS containers", "checkout vision model (GPU)"]
    hardware_owner: undecided
    hands_on_staff: "none, store manager can power-cycle"
    update_window: "02:00-04:00 local, never Black Friday week"
    compliance: ["PCI DSS"]

team_skills:
  kubernetes: medium      # none | low | medium | high
  vms_vmware: high
  terraform: medium
  hardware_field_ops: low

What each field is for:

• Connectivity decides whether a cloud-managed control plane is realistic. A store on 100 Mbps broadband with six outages a year rules out anything that stops working when the link drops.
• Hardware owner is the most important field. When a disk fails in store 37 at 3 a.m., who drives there? If the answer is "nobody", you need provider-maintained or easily swapped hardware.
• Update window matters because some edge services apply updates on the provider's schedule. You can negotiate when updates happen, but rarely whether they happen. Write down your blackout dates now.
• Compliance is a list of named regimes, never a single word like "secure".
• Team skills is honest self-scoring. A team that rates Kubernetes "low" will struggle with anything container-first, however well it scores elsewhere.

Step 3: The cost model the organisation can accept

Finance cares about the shape of the cost as much as the total. Record four things:

cost_model:
  monthly_service_ceiling: "£25k/month across all sites"
  hardware_terms:
    acceptable_commitment_months: [36]     # will finance sign 60?
    capex_allowed: false                   # opex only this budget cycle
  commitments:
    existing_cloud_commit: "£1.2M/yr, 3-yr" # does hybrid spend count toward it?
  data_transfer:
    egress_out_of_cloud_gib_month: 3000    # cloud -> sites
    ingress_gib_month: 9000                # sites -> cloud
    priced_on: "2026-10-30 list prices"

Three points that experience teaches:

1. Hardware terms are long. As a dated example (October 2026), Google's provider-supplied on-site offering bills monthly but requires a 36- or 60-month commitment, and you cannot add machines to a zone after it is deployed. If finance will only sign 12 months, record that now. It removes options early.
2. Data transfer is asymmetric. Inbound data transfer to Google Cloud is not charged, but data sent out to the internet or to your sites is charged per GiB and the rate varies by destination and volume. A profile that only records total traffic hides the expensive direction.
3. Support is part of the price. Some hybrid services require a minimum paid support tier. Put the support line in the model so it does not turn up after the purchase order.

Best practice: Date every price in the profile. Prices in this course are dated examples; a profile with undated prices goes stale without anyone noticing.

Checking the profile is ready

Before moving on, every site should pass this quick check:

[x] One primary reason, with a measured number and its source
[x] Every site has connectivity, workloads, owner, window, compliance
[x] Team skills scored, not assumed
[x] Cost model states ceiling, term length, capex/opex, transfer volumes by direction
[ ] "undecided" fields  -> list them as open questions, don't hide them

NorthMart's store hardware_owner: undecided is an open question, and it is a useful one. It will decide between whole families of services in later levels.

Key takeaways

• There are four honest reasons a region is not enough: latency, data residency, disconnected operation and existing hardware. Each needs a measured number and a source.
• Measure latency from the site at p99, not as an average from your desk. Each 100 km of fibre adds about 1 ms to the round trip.
• Profile every site for connectivity, workloads, hardware owner, update window, compliance and on-site staff, and score team skills honestly.
• The cost model records the monthly ceiling, acceptable hardware term length, capex or opex, existing commitments and data transfer by direction.
• Inbound transfer to Google Cloud is free and outbound is charged, so always record the two directions separately.
• Keep the profile in version control, date every price and list undecided fields as open questions.