Why diagrams drift from reality

An architecture diagram is a snapshot of somebody's intentions on the day they drew it. After that, people add a database for a quick test, copy a project for a customer, or leave a cluster running after a migration. Nothing in the cloud forces anyone to update the picture, so it drifts. After a year or two, the diagram describes a platform that no longer exists.

This matters when you want to cut cost, tighten security or move to another region. Each of them starts with the question "what do we actually have?", and the honest answer is often "we are not sure".

Step one: an inventory

Start from the top. In Google Cloud, the structure is an organisation, then folders, then projects, then resources. Cloud Asset Inventory can list resources across all of it. For one project:

gcloud asset search-all-resources --scope=projects/PROJECT_ID --format="table(assetType,name,location,labels)"

Use --scope=organizations/ORG_ID to cover the whole organisation. Export the result to a spreadsheet or a table, and group it by project and by type. Two numbers come out of this straight away: how many projects you have, and how many resources of each kind. Both are usually larger than anyone guessed.

The same idea works in other clouds. AWS has Resource Explorer and Config, and Azure has Resource Graph. The goal is the same: one list, produced by a tool and not by memory.

Step two: an owner for everything

A resource with no owner cannot be reviewed, because nobody can say whether it is still needed. Agree on a small set of labels that every resource must carry, and keep it short so that people really use it:

  • team: who answers questions about it and pays for it;
  • env: dev, stage, prod or test;
  • product: what it is part of.

Then measure label coverage: what share of resources carry all three? That number is useful in itself, and the resources that do not are your first review list. Make labels part of how things are created, through your infrastructure code, so that coverage rises without a clean-up project every year.

Step three: how things connect

A list of resources tells you what exists. To decide what is safe to change, you also need to know how they relate:

  • Network: which networks and subnets connect, and what is open to the internet.
  • Runs on or attached to: a service on a cluster, a disk on a VM, a database behind an application.
  • Identity: which service account a workload uses, and what it can reach.
  • Data flows: who reads from and writes to a database or a bucket.

Some of this is in configuration, and some only shows up in logs and metrics. Treat each link as a claim with a source and a level of confidence: "this service uses this database" is stronger when a connection log shows it than when a name suggests it.

Keeping the map current

A one-off inventory is out of date within months. Rescan on a schedule, daily or weekly, and compare it with the last scan: what was added, what was removed, what changed. A short weekly diff keeps the picture honest and catches new sprawl while it is still small.

With a current map, the next questions get easy: which resources are idle (see nine kinds of zombie resources), which can be merged, and which should be rebuilt. For a new platform, the best way to avoid this problem is to start with a landing zone built before the first workload. If you want help getting a clear picture of an existing cloud, our cloud architecture and migration consulting starts with exactly this inventory.