6 ms·

Disclosure: I work on Google Cloud (and really care about this). The challenge here is balancing diverse customer workloads against the processor vendors. Hist

by boulos 7y ago

Disclosure: I work on Google Cloud (and really care about this). The challenge here is balancing diverse customer workloads against the processor vendors. Historically, at Google, we just bought a single server variant (basically) because almost all code is expected to care primarily about scale-out environments. That made the GCE decision simple: offer the same hardware we build for Google, at great prices. The problem is that many customers have workloads and applications that they can’t just change. No amount of rational discounting or incentives makes a 2 GHz processor compete with a 4 GHz processor (so now, for GCE, we buy some speedy cores and call that Compute Optimized). Even more strongly, no amount of “you’re doing it wrong” actually is the right answer for “I have a database on-prem that needs several sockets and several TB of memory” (so, Memory Optimized). There’s an important reason though that we refer to N1, N2, N2D, and E2 as “General purpose”: we think they’re a good balanced configuration, and they’ll continue to be the right default choice (and we default to these in the console). E2 is more like what we do internally at Google, by abstracting away processor choice, and so on. As a nit to your statement above, E2 does flip between Intel and AMD. You should choose the right thing for your workloads, primarily subject to the Regions you need them in. We’ll keep trying to push for simplicity in our API and offering, but customers really do have a wide range of needs, which imposes at least some minimum amount of complexity. For too long (probably) we attempted to refuse, because of complexity, both for us and customers. Feel free to ignore it though!

milesward 7y ago
We need some kinda shortcut: like, run your app for a few days on an instance, we chew your stackdriver metrics, we make a new shortcut n3-mybestinstance, which picks the right shape/processor family etc for yah.
- elithrar 7y ago
  As a Googler: take VM rightsizing recommendations - "save $X because you're underutilizing this machine shape" - and extend them to encompass this by including VM-family swaps based on underlying VM metrics? :)
alfalfasprout 7y ago
I mean, this mentality often is wrong. Scaling out actually isn't the right solution for everyone. It works for Google given that primarily web services are offered. It does not work for workloads that heavily rely on the CPU (think financial workloads, ML, HPC/scientific workloads) or have realtime requirements. In fact, for many ETL workloads vertical scaling proves far more efficient. It's long been the "google way" to try and abstract out compute but it's led to an industry full of people trying to follow in their way and overcomplicating what can be solved on one or two machines.
- erulabs 7y ago
  Except, almost without exception, eventually the one or two machines will fall over. Ideally you can engineer your way around this ahead of time - but not always. Fundamentally relying on a few specific things (or people) will always be an existential risk to a big firm. Absolutely agree re: start small - but the problem with “scale out” is a lack of good tooling - not a fundamental philosophical one.
  - aidenn0 7y ago
    Plenty of services can deal with X hours of downtime when a single machine fails for values of X that are longer than it takes to restore to a new machine from backups.
    - chucky_z 7y ago
      I'd like to add to this and say that a server being down for 6 hours, that if over the life of its uptime (months? years?) saves uncountable number of hours on computations and complexity, is so worth it. Heck, even a machine like that being down for a week is usually still worth it.
    - darkwater 7y ago
      I do not agree, and it is not my experience.Mind you that I've always worked in small/mid-sized businesses (50-300 employees) and basically every service has someone needing it for their daily work. Sure, they may live without it for some times, but you will make their lives more miserable. And anyway if you already have all in place to completely rebuild every SPOF machine from scratch in a few hours, go the extra mile and make it an active/passive cluster, even manually switched, and make the downtime a minutes thing.
mdasen 7y ago
This makes a lot of sense, but it doesn't explain why the pricing isn't consistent. Why is an N1 the same price as an N2, except for sustained-use? Why is an E2 cheaper than an N1/N2D, except for sustained-use? E2 is just such an amazing idea that feels like it's going to be under-utilized because it isn't cheaper for the sustained-use case. There doesn't seem to be any reason why E2 would be more expensive (to Google) for sustained-use and not for on-demand or committed. Google Cloud is really nice, but the inconsistent pricing/discounting between the different types seems odd. Like, I'm running something on N1 right now with sustained-use because there's no incentive for me to switch to E2. It feels a bit wasteful since it doesn't get a lot of traffic and would be the perfect VM to steal resources from. However, I'd only get a discount if I did a 1-year commitment. For Google, I'm tying up resources you could put to better use. E2 instances are usually 30% cheaper which would give me a nice incentive to switch to them, but without the sustained-use discount, N2D and N1 instances become the same price. So, I end up tying up hardware that could be used more efficiently.
- throwaway2048 7y ago
  Pricing confusion is a cornerstone of big single shop vendors, the more confusing you make pricing, the more chances a customer is going to spend more than they otherwise might. Also opens avenues for highly paid consultants to dip their beak and promote your products.
cm2187 7y ago
I presume the downside of a fragmented offering is that it is easier to run out of stock of a particular type of configuration. Does that happen much on any of the major clouds? Ie if we script the provisioning of a new VM, is it something to watch for or is it a really rare event?
merb 7y ago
well the biggest problem is that commited usage discount is not replaceable with the cheaper e2 choices. btw. when we commited our usage to n1, e2 was not available.

by boulos 7y ago

milesward 7y ago

We need some kinda shortcut: like, run your app for a few days on an instance, we chew your stackdriver metrics, we make a new shortcut n3-mybestinstance, which picks the right shape/processor family etc for yah.

elithrar 7y ago
As a Googler: take VM rightsizing recommendations - "save $X because you're underutilizing this machine shape" - and extend them to encompass this by including VM-family swaps based on underlying VM metrics? :)

alfalfasprout 7y ago

I mean, this mentality often is wrong. Scaling out actually isn't the right solution for everyone. It works for Google given that primarily web services are offered. It does not work for workloads that heavily rely on the CPU (think financial workloads, ML, HPC/scientific workloads) or have realtime requirements. In fact, for many ETL workloads vertical scaling proves far more efficient. It's long been the "google way" to try and abstract out compute but it's led to an industry full of people trying to follow in their way and overcomplicating what can be solved on one or two machines.

erulabs 7y ago
Except, almost without exception, eventually the one or two machines will fall over. Ideally you can engineer your way around this ahead of time - but not always. Fundamentally relying on a few specific things (or people) will always be an existential risk to a big firm. Absolutely agree re: start small - but the problem with “scale out” is a lack of good tooling - not a fundamental philosophical one.
- aidenn0 7y ago
  Plenty of services can deal with X hours of downtime when a single machine fails for values of X that are longer than it takes to restore to a new machine from backups.
  - chucky_z 7y ago
    I'd like to add to this and say that a server being down for 6 hours, that if over the life of its uptime (months? years?) saves uncountable number of hours on computations and complexity, is so worth it. Heck, even a machine like that being down for a week is usually still worth it.
  - darkwater 7y ago
    I do not agree, and it is not my experience.Mind you that I've always worked in small/mid-sized businesses (50-300 employees) and basically every service has someone needing it for their daily work. Sure, they may live without it for some times, but you will make their lives more miserable. And anyway if you already have all in place to completely rebuild every SPOF machine from scratch in a few hours, go the extra mile and make it an active/passive cluster, even manually switched, and make the downtime a minutes thing.

mdasen 7y ago

This makes a lot of sense, but it doesn't explain why the pricing isn't consistent. Why is an N1 the same price as an N2, except for sustained-use? Why is an E2 cheaper than an N1/N2D, except for sustained-use? E2 is just such an amazing idea that feels like it's going to be under-utilized because it isn't cheaper for the sustained-use case. There doesn't seem to be any reason why E2 would be more expensive (to Google) for sustained-use and not for on-demand or committed. Google Cloud is really nice, but the inconsistent pricing/discounting between the different types seems odd. Like, I'm running something on N1 right now with sustained-use because there's no incentive for me to switch to E2. It feels a bit wasteful since it doesn't get a lot of traffic and would be the perfect VM to steal resources from. However, I'd only get a discount if I did a 1-year commitment. For Google, I'm tying up resources you could put to better use. E2 instances are usually 30% cheaper which would give me a nice incentive to switch to them, but without the sustained-use discount, N2D and N1 instances become the same price. So, I end up tying up hardware that could be used more efficiently.

throwaway2048 7y ago
Pricing confusion is a cornerstone of big single shop vendors, the more confusing you make pricing, the more chances a customer is going to spend more than they otherwise might. Also opens avenues for highly paid consultants to dip their beak and promote your products.

cm2187 7y ago

I presume the downside of a fragmented offering is that it is easier to run out of stock of a particular type of configuration. Does that happen much on any of the major clouds? Ie if we script the provisioning of a new VM, is it something to watch for or is it a really rare event?

merb 7y ago

well the biggest problem is that commited usage discount is not replaceable with the cheaper e2 choices. btw. when we commited our usage to n1, e2 was not available.