3 ms·

i think it's mostly historical baggage. as soon as gce gets as old as aws, the offering variations they have to offer for historical contacts and what so ever w

by gcb0 11y ago

i think it's mostly historical baggage. as soon as gce gets as old as aws, the offering variations they have to offer for historical contacts and what so ever will be as confusing as aws today

izzym 11y ago
I agree, most of it is accumulation over the years
- wstrange 11y ago
  It's not just accumulation. IMHO, the features of Google Cloud are better thought out. Two examples of things that rock: - Being able to pop up an ssh shell right from your browser - Google Cloud shell. A free Linux shell in the sky with a bunch of dev tools pre-installed (including docker)
williamstein 11y ago
I've been using GCE a lot since 2012 (early beta tester) and the web interface has only improved with time.
- obulpathi 11y ago
  I see a constant flux of features, but the whole Google Cloud ecosystem is well thought of and coherent as if the ease of use is primary thing. App Engine, after 8 years, is still as easy to use as the day it was released.
- darkr 11y ago
  Same with AWS, I've been using that since 2008 or so. At that time, many of the services, or functionality within certain services were either not usable (as in couldn't be accessed) via the web interface, only via the APIs.
deleted 11y ago
[deleted]
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 ago
  why do you think amazon did not do the exact same things, before they accumulated years of baggage?
  - boulos 11y ago
    There'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!).

by gcb0 11y ago

i think it's mostly historical baggage. as soon as gce gets as old as aws, the offering variations they have to offer for historical contacts and what so ever will be as confusing as aws today

izzym 11y ago

I agree, most of it is accumulation over the years

wstrange 11y ago
It's not just accumulation. IMHO, the features of Google Cloud are better thought out. Two examples of things that rock: - Being able to pop up an ssh shell right from your browser - Google Cloud shell. A free Linux shell in the sky with a bunch of dev tools pre-installed (including docker)

williamstein 11y ago

I've been using GCE a lot since 2012 (early beta tester) and the web interface has only improved with time.

obulpathi 11y ago
I see a constant flux of features, but the whole Google Cloud ecosystem is well thought of and coherent as if the ease of use is primary thing. App Engine, after 8 years, is still as easy to use as the day it was released.
darkr 11y ago
Same with AWS, I've been using that since 2008 or so. At that time, many of the services, or functionality within certain services were either not usable (as in couldn't be accessed) via the web interface, only via the APIs.

deleted 11y ago

[deleted]

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 ago
why do you think amazon did not do the exact same things, before they accumulated years of baggage?
- boulos 11y ago
  There'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!).