I can see why they do it, though. There are a bunch of foundational Google infra technologies that are great for building an IaaS on top of, but which can't themselves be offered as IaaS services for whatever reason.
Let's use Google's Colossus (their datacenter-scale virtual filesystem) as an example. Due to the underlying architecture of Colossus, GCP can turn around and give you:
• GCE shared read-only zonal PDs
• near-instantaneous snapshots for GCE and BigTable
• async and guaranteed-durable logging (for GCE and otherwise) and Queues (as Pub/Sub and otherwise)
• zero-migration autoclassed GCS Objects, and no per-operation slowdown on GCS Buckets as bucket size increases
• BigQuery being entirely serverless (vs e.g. Redshift needing to operate on a provisioned-storage model)
But Google can't just sell you "Colossus as a service" — because Colossus doesn't have a "multitenant with usage-cost-based backpressure to disincentivize misuse" architecture; and you can't add that without destroying the per-operation computational-complexity guarantees that make Colossus what it is. Colossus only works in a basically-trusted environment. (A non-trust-requiring version of Colossus would look like Apple's FoundationDB.)
(And yeah, you could in theory have a "little Colossus" unique to your deployment... but that'd be rather useless, since the datacenter scale of Colossus is rather what makes many of its QoS guarantees possible. Though I suppose it could make sense if you could fund entire GCP datacenters for your own use, ala AWS GovCloud.)
Let's use Google's Colossus (their datacenter-scale virtual filesystem) as an example. Due to the underlying architecture of Colossus, GCP can turn around and give you:
• GCE shared read-only zonal PDs
• near-instantaneous snapshots for GCE and BigTable
• async and guaranteed-durable logging (for GCE and otherwise) and Queues (as Pub/Sub and otherwise)
• zero-migration autoclassed GCS Objects, and no per-operation slowdown on GCS Buckets as bucket size increases
• BigQuery being entirely serverless (vs e.g. Redshift needing to operate on a provisioned-storage model)
But Google can't just sell you "Colossus as a service" — because Colossus doesn't have a "multitenant with usage-cost-based backpressure to disincentivize misuse" architecture; and you can't add that without destroying the per-operation computational-complexity guarantees that make Colossus what it is. Colossus only works in a basically-trusted environment. (A non-trust-requiring version of Colossus would look like Apple's FoundationDB.)
(And yeah, you could in theory have a "little Colossus" unique to your deployment... but that'd be rather useless, since the datacenter scale of Colossus is rather what makes many of its QoS guarantees possible. Though I suppose it could make sense if you could fund entire GCP datacenters for your own use, ala AWS GovCloud.)