Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS vs. GCP reliability is wildly different

freeman.vc

Post reply on HN
Print view View original

201–210 of 245 posts

Re: AWS vs. GCP reliability is wildly different

#201

Post by ithkuil »

jiggawatts wrote: post #120
outworlder wrote: post #110

Earlier quoted context omitted.

Not really. Or at least not in the same league. AWS doesn't have live migration at all. You have to stop/start. Azure technically does, but it doesn't always work(they say 90%). 30 seconds is a long time. VMWare has live migration (and seems to be the closest to what GCP does) but it is still an inferior user experience. This is the key thing you are missing – GCP not only has live migration, but it is completely tra…

VMware's live migration is totally seamless, so I don't know what you mean by "inferior user experience". You typically see less than a second of packet loss, and a small performance hit for about a minute while the memory is "swapped" across to the new machine. Similarly, VMware has had live storage migration for years. VMware is lightyears ahead of the big clouds, but unfortunately they "missed the boat" on the pub…

You're right to say that VMware has the right fundamental building blocks and that they are mature enough (especially the compute aspect).

But I think you underestimate the maturity and effectiveness of the underlying google compute and storage substrate.

(FWIW, I worked at both places)

Now how the Google's substrate maps onto GCP, that's another story. There is a non trivial amount of fluff to be added on top of your building blocks to build a manageable multitenant planet scale cloud service. Just the network infrastructure is mind boggling.

I wouldn't be surprised if your experience with a "VMware cloud" would surprise you if you naively compare it with your experience with a standalone vsphere cluster.

Re: AWS vs. GCP reliability is wildly different

#202

Post by devxpy »

marcinzm wrote: post #15
devxpy wrote: post #8

Is this testing for spot instances? In my limited experience, persistent (on-demand) GCP instances always boot up much faster than AWS EC2 instances.

In my experience GPU persistent instances often simply don't boot up on GCP due to lack of available GPUs. One reason I didn't choose GCP at my last company.

Oh interesting. Which region and GPU type were you working with? (Asking so I can avoid in future)

Re: AWS vs. GCP reliability is wildly different

#203

Post by DonHopkins »

hericium wrote: post #164
dark-star wrote: post #13

I wonder why someone would equate "instance launch time" with "reliability"... I won't go as far as calling it "clickbait" but wouldn't some other noun ("startup performance is wildly different") have made more sense?

Cloud reliability is not the same as a reliability of already spawned VM. Here it's the possibility to launch new VMs to satisfy dynamic projects' needs. Cloud provider should allow you to scale-up in a predictable way. When it doesn't - it can be called unreliable. Also, "unreliable" is basically a synonym for "Google" these days.

Let me unreliable that for you.

Re: AWS vs. GCP reliability is wildly different

#207

Post by voiper1 »

xyzzyz wrote: post #7
politelemon wrote: post #3

A few weeks ago I needed to change the volume type on an EC2 instance to gp3. Following the instructions, the change happened while the instance was running. I didn't need to reboot or stop the instance, it just changed the type. While the instance was running. I didn't understand how they were able to do this, I had thought volume types mapped to hardware clusters of some kind. And since I didn't understand, I wasn'…

Dunno about AWS, but GCP uses live migration, and will migrate your VM across physical machines as necessary. The disk volumes are all connected over the network, nothing really depends on the actual physical machine your VM is ran on.

Linode also uses live migrations now for most (all?) maintenance.

Re: AWS vs. GCP reliability is wildly different

#208

Post by daneel_w »

endisneigh wrote: post #121
daneel_w wrote: post #118

Earlier quoted context omitted.

It seems entirely fair to me, but the term "reliability" has a few different angles. This time it's not about working or not working, but the ability to auto-scale by invoking resources on the spot, which can be a very real requirement.

unless you're willing to burn $150 a quarter doing this exact assessment, it tells you nothing other than the data center conditions at the time of running. it would be like doing this in us-central1 when us-central1 is down for one provider, and not another, resulting in increased latency, and saying how much faster one is than the other. unlike say a throughput test or similar, neither of these services promise par…

Given the stark contrast and that the pattern was identical every day over a two-week course, it tells me we're observing a fundamental systemic difference between GCP and AWS - and I think that's all the author really wanted to point out. I would not be surprised if the results are replicable three months from now.

Re: AWS vs. GCP reliability is wildly different

#209

Post by eurasiantiger »

pdpi wrote: post #206
yjftsjthsd-h wrote: post #106

Earlier quoted context omitted.

Yeah, 4xx is client error, 5xx is server error.

Yes, and trying to create duplicate resources is a client error.

Still, 409 seems inappropriate, as it is meant to signal a version conflict, i.e. someone else changed something, and user tried to uplod a stale version.

”10.4.10 409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.”

Then again, perhaps it is the service itself making that state change.

Re: AWS vs. GCP reliability is wildly different

#210

Post by marcinzm »

devxpy wrote: post #202
marcinzm wrote: post #15

Earlier quoted context omitted.

In my experience GPU persistent instances often simply don't boot up on GCP due to lack of available GPUs. One reason I didn't choose GCP at my last company.

Oh interesting. Which region and GPU type were you working with? (Asking so I can avoid in future)

I think it was us-east1 or us-east4. Had issues getting TPUs as well in us-central1. I know someone at a larger tech company who was told to only run certain workflows in a specific niche European region as that's the only one that had any A100 GPUs most of the time.
Post reply on HN