New AMD EPYC-based Compute Engine family, now in beta • Hacker News Board

Re: New AMD EPYC-based Compute Engine family, now in beta

#121

Post by endymi0n » Wed, Feb 19, 2020, 6:28 AM UTC

PudgePacket wrote: post #119

erulabs wrote: post #98

Earlier quoted context omitted.

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.

I've heard lots of anecdotes from big sites doing fine with a small number of machines. eg stackoverflow only has 1 active DB server, and 1 backup. https://stackexchange.com/performance

Actually, this makes a lot of sense. Reasoning about a single machine is just way simpler and keeps the full power of a modern transactional database at your fingertips. Backups keep taking longer and disaster recovery isn‘t as speedy anymore, but we‘re running on Postgres internally as well and I‘d scale that server as big as possible (even slightly beyond linear cost growth, which is pretty huge these days) before even thinking about alternatives.

Re: New AMD EPYC-based Compute Engine family, now in beta

#122

Post by mrich » Wed, Feb 19, 2020, 7:05 AM UTC

erulabs wrote: post #98

alfalfasprout wrote: post #93

Earlier quoted context omitted.

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 wa…

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.

The solution often is to have a warm standby that can take over immediately. You do not get any distributed overhead that is present in a fully load-balanced system during normal operation, and only pay a small amount in the very exceptional failure case.

Re: New AMD EPYC-based Compute Engine family, now in beta

#123

Post by smueller1234 » Wed, Feb 19, 2020, 7:52 AM UTC

bob1029 wrote: post #104

wmf wrote: post #25

Earlier quoted context omitted.

They don't say that but that's the only way to provide 224 threads.

Their topology tells far richer tales than the press releases when you dig deeper on the numbers. 224 threads = 112 HT cores = 2 x 56 core CPUs. This is 8 cores short of the 64 core flagship. 8 cores == 1 CCX. It seems exceedingly unlikely that AMD would produce a Rome CPU with 7 out of 8 CCX in perfect health, but have the 8th CCX completely missing (functionally). It seems more likely that the 8th CCX is there with…

Re: New AMD EPYC-based Compute Engine family, now in beta

#124

Post by cm2187 » Wed, Feb 19, 2020, 8:26 AM UTC

boulos wrote: post #82

mdasen wrote: post #31

Since people from Google Cloud are likely here, one thing I'd like to ask/talk about: are we getting too many options for compute? One of the great things about Google Cloud was that it was very easy to order. None of this "t2.large" where you'd have to look up how much memory and CPU that it has and potentially how many credits you're going to get per hour and such. I think Google Cloud is still easier, but it's get…

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 prob…

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?

Re: New AMD EPYC-based Compute Engine family, now in beta

#125

Post by cm2187 » Wed, Feb 19, 2020, 8:30 AM UTC

alfalfasprout wrote: post #93

boulos wrote: post #82

Earlier quoted context omitted.

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 prob…

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 wa…

And even when it could make sense, the cost of redeveloping a system, validating its logic, ensuring it is production ready is often prohibitive compare to the cost of a bigger server (and a risk a business may not be willing to take).

Re: New AMD EPYC-based Compute Engine family, now in beta

#126

Post by cm2187 » Wed, Feb 19, 2020, 8:33 AM UTC

adamc wrote: post #64

scardycat wrote: post #37

Earlier quoted context omitted.

Customers like having choices. Enterprises typically will "certify" one config and would like to stay on that till they absolutely need to move to something else.

That reflects the lumbering, bureaucratic nature of enterprises.

Until you are at an airline counter desk not able to board your flight home because of an IT meltdown.

Enterprises have these processes not just because they like bureaucracy (though they also often like bureaucracy too).

Re: New AMD EPYC-based Compute Engine family, now in beta

#127

Post by darkwater » Wed, Feb 19, 2020, 9:20 AM UTC

aidenn0 wrote: post #100

erulabs wrote: post #98

Earlier quoted context omitted.

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.

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.

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.

Re: New AMD EPYC-based Compute Engine family, now in beta

#128

Post by cma » Wed, Feb 19, 2020, 9:35 AM UTC

thesz wrote: post #55

sdesol wrote: post #52

Earlier quoted context omitted.

They really are doing something disruptive. I can't quite remember if this is correct (it has been a while since I last studied business), but in business there is a "blue ocean strategy". The basic premise is, if you can provide a product for half the price, with the twice the value, you will destroy the incumbent. What AMD is doing is really insane in my opinion. I'm not sure if they are pricing their processors lo…

Smaller chips have better yield. As AMD's current chips are composed from several smaller ones (I believe two or three), each composite has better yield than one bigger of same real estate size. So yes, they figured out how to produce cheaper solutions.

It also sets them up to go forward into EUV where shot noise is unavoidable. And they had a contract with global foundries to still buy some large amount from them at a worse process node, the chipper design let’s them use that for the IO die.

Re: New AMD EPYC-based Compute Engine family, now in beta

#129

Post by nemothekid » Wed, Feb 19, 2020, 11:06 AM UTC

alfalfasprout wrote: post #93

boulos wrote: post #82

Earlier quoted context omitted.

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 prob…

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 wa…

Google doesn’t have ML workloads (Basically all of search) or real-time (basically all of RTB) requirements?

I agree not everyone can develop like Google, but it’s wrong to say that “it doesn’t work”

Re: New AMD EPYC-based Compute Engine family, now in beta

#130

Post by Bad_CRC » Wed, Feb 19, 2020, 12:21 PM UTC

alfalfasprout wrote: post #112

erulabs wrote: post #98

Earlier quoted context omitted.

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.

It is a philosophical one when you design around scaling out at a high rate. You incur significant additional complexity in many cases along with increased overhead. It's fallacious to think that relying on "n" things is strictly safer than "3" things where n is large. That's not quite true due to the significant complexity increases when dealing with large "n" and accompanying overhead. For web applications (which I…

I work a lot with voip systems and it's much much easier to have one big machine that trying to make it work distributed...