4 ms·
Actually, we've made some explicit choices along the way to avoid this cruft. For example, we haven't introduced different "generations" of machine types, and
by boulos 11y ago
Actually, we've made some explicit choices along the way to avoid this cruft.
For example, we haven't introduced different "generations" of machine types, and instead have stuck with "n1-standard-1" even across different architectures (we then document which underlying processor architectures are available on a zone-by-zone basis at https://cloud.google.com/compute/docs/zones#available https://cloud.google.com/compute/docs/zones#available for people that care).
Similarly, instead of introducing "Local SSD instances", we let you attach Local SSD partitions to any VM arbitrarily. And Preemptible VMs are just a boolean option on any VM.
So you don't see a machine-type matrix explosion on GCE, and that's on purpose.
Disclosure: I work on Compute Engine.
- gcb0 11y agowhy do you think amazon did not do the exact same things, before they accumulated years of baggage?
- boulos 11y agoThere's a real trade off. I didn't mean to dismiss it (apologies if it came across that way). For some workloads, a 2.3 GHz Haswell runs absolute circles around a 2.5 GHz Sandy Bridge (mostly vectorization friendly ones). So if you care about newer architectures, now the API either needs to let you choose a processor type per zone (painful) or you end up taking it on as the provider (each zone has a single processor type). We also elect to maintain single-threaded performance across a variety of benchmarks which is a double-edged sword. So they made a different choice: let the customer just decide explicitly. We went with "let the customer decide if they want". Most people internally at Google don't bother and I'd say we've been proven correct in the marketplace as well; if you need to care, we're transparent (otherwise, who cares!).