Live data from Hacker News

Removing data transfer fees when moving off Google Cloud

cloud.google.com

31–40 of 113 posts

Re: Removing data transfer fees when moving off Google Cloud

#31
post #18

Earlier quoted context omitted.

I read through a couple of these responses to the CMA by MS, Google and AWS and their smaller competitors as expected the hyperscalers refuse to acknowledge that the free ingress and expensive egress is a lock-in mechanism, and their smaller competitors complain bitterly about this the hyperscalers say they have to charge egress fees to pay for the costs in building their networks, but for some reason doesn't apply t…

>but for some reason doesn't apply to ingress (which they're silent on) The industry standard for peering is paying the 95th percentile of egress or ingress depending on whichever is greater. Ingress is free for these clouds because egress > ingress overall.

> The industry standard

Pfft...

> for peering is paying the 95th percentile of egress or ingress depending on whichever is greater. Ingress is free for these clouds because egress > ingress overall

How about customers pay for actual usage, rather than some [fake] averaged-across-all-customers usage?

Re: Removing data transfer fees when moving off Google Cloud

#32
post #29
post #18

Earlier quoted context omitted.

I read through a couple of these responses to the CMA by MS, Google and AWS and their smaller competitors as expected the hyperscalers refuse to acknowledge that the free ingress and expensive egress is a lock-in mechanism, and their smaller competitors complain bitterly about this the hyperscalers say they have to charge egress fees to pay for the costs in building their networks, but for some reason doesn't apply t…

> the hyperscalers say they have to charge egress fees to pay for the costs in building their networks, but for some reason doesn't apply to ingress (which they're silent on) This doesn’t pass the red face test IMO. The hyperscaler networks are indeed very expensive, but that’s because they need to provide non-blocking or near non-blocking performance within the availability zone, and the clouds don’t charge for this…

> they need to provide non-blocking or near non-blocking performance within the availability zone

I see you've never tried GCP.

Re: Removing data transfer fees when moving off Google Cloud

#33
post #32
post #29

Earlier quoted context omitted.

> the hyperscalers say they have to charge egress fees to pay for the costs in building their networks, but for some reason doesn't apply to ingress (which they're silent on) This doesn’t pass the red face test IMO. The hyperscaler networks are indeed very expensive, but that’s because they need to provide non-blocking or near non-blocking performance within the availability zone, and the clouds don’t charge for this…

> they need to provide non-blocking or near non-blocking performance within the availability zone I see you've never tried GCP.

I have, but not for a use case where this matters.

FWIW, Google has been working on these fancy nonblocking networks for a very long time. They’re very proud of them. Maybe they don’t actually use them for GCP, but Google definitely cares about network performance for their own purposes.

Re: Removing data transfer fees when moving off Google Cloud

#34
post #33
post #32

Earlier quoted context omitted.

> they need to provide non-blocking or near non-blocking performance within the availability zone I see you've never tried GCP.

I have, but not for a use case where this matters. FWIW, Google has been working on these fancy nonblocking networks for a very long time. They’re very proud of them. Maybe they don’t actually use them for GCP, but Google definitely cares about network performance for their own purposes.

The whole concept of blocking is inapplicable to packet-switched networks. The whole time I was there I never heard anyone describe any of their several different types of networks as non-blocking. Indeed, the fact that they are centrally-controlled SDNs, where the control plane can tell any participant to stop talking to any other participant, seems to be logically the opposite of "non-blocking", if that circuit-switching terms were applicable.

Your message seems to imply that these datacenter networks experience very little loss, and this is observably far from reality. In GCP you will observe levels of frame drops that a corporate datacenter architect would consider catastrophic.

Re: Removing data transfer fees when moving off Google Cloud

#36

So on the one hand Google now accepts that egress fees are outrageous. Great! On the other hand, they're only reducing (removing) the fees when you leave them. If this move were really about acting in customers' best interests, they would reduce the fees for everyone. Doing this only for departing customers feels performative.

Unless they’re planning to kill GCP entirely. Then everyone is a departing customer /s

But seriously, it seems like a fair-ish compromise. The 60 day limit is tough though. As long as you’re continuing your usage and not using offsite backups, ingress/egress isn’t probably too problematic. It’s only problematic when you try to suddenly egress all data you’ve ever stored, which you probably wouldn’t do unless you’re migrating away.

Re: Removing data transfer fees when moving off Google Cloud

#37

So on the one hand Google now accepts that egress fees are outrageous. Great! On the other hand, they're only reducing (removing) the fees when you leave them. If this move were really about acting in customers' best interests, they would reduce the fees for everyone. Doing this only for departing customers feels performative.

Unless they’re planning to kill GCP entirely. Then everyone is a departing customer /s But seriously, it seems like a fair-ish compromise. The 60 day limit is tough though. As long as you’re continuing your usage and not using offsite backups, ingress/egress isn’t probably too problematic. It’s only problematic when you try to suddenly egress all data you’ve ever stored, which you probably wouldn’t do unless you’re m…

> ingress/egress isn’t probably too problematic

It's problematic to me. I run a system partly on GCP and partly on another provider. I'd like to move some of the stuff that's on the other provider over to GCP VMs, but I am prevented from doing so solely by the GCP egress fees.

My general complaint is that high egress fees prevent users from developing hybrid cloud solutions which mix components from different cloud vendors. Instead, you are forced to choose a platform, and then you're locked into it. That seems textbook anti-competitive. We shouldn't be grateful for the opportunity to switch vendors, we should be angry that "choosing a single cloud vendor" is a thing at all.

Re: Removing data transfer fees when moving off Google Cloud

#38
post #34
post #33

Earlier quoted context omitted.

I have, but not for a use case where this matters. FWIW, Google has been working on these fancy nonblocking networks for a very long time. They’re very proud of them. Maybe they don’t actually use them for GCP, but Google definitely cares about network performance for their own purposes.

The whole concept of blocking is inapplicable to packet-switched networks. The whole time I was there I never heard anyone describe any of their several different types of networks as non-blocking. Indeed, the fact that they are centrally-controlled SDNs, where the control plane can tell any participant to stop talking to any other participant, seems to be logically the opposite of "non-blocking", if that circuit-swi…

Blocking is a common concept in packet switched networks; for example, a packet switch with a full crossover can be called "non-blocking". A switch is either going to queue or discard packets, and at the rates we're discussing, there is not enough buffer space so typically if a switch gets overloaded it's going to drop low priority packets. Obviously many things have changed, there are ethernet pause frames and admission control and SDN management of routes, but we still very much use the term "blocking" in packet switched networks.

What google decided long ago is that for their traffic patterns, it makes the most sense to adopt clos-like topologies (with packet switching in most cases), and not attempt to make a fully non-blocking single crossbar switch (it's too expensive for the port counts). More hops, but no blocking.

Scaling that got very difficult and so now many systems at Google use physical mirrors to establish circuit-like paths for packet-like flows.

GCP is effectively an application that runs on top of google's infrastructure (I believe you already worked there and are likely to know how it works) that adds all sorts of extra details to the networking stack. For some time the network as a user-space Java application that had no end of performance problems.

Re: Removing data transfer fees when moving off Google Cloud

#39
post #12

Looks like it's a response to the recent cloud services market investigation by the CMA [1]. Which highlighted "Egress fees harm competition by creating barriers to switching and multi-cloud leading to cloud service providers entrenching their position" [2]. It's also interesting that they are calling out problems with software licensing, as that is another thing the CMA is investigating in their cloud market review.…

I don't see it that way at all. Those egregious egress charges still apply while you are actively using GCP, encouraging you to put everything in GCP, and eschew multicloud. This seems to me more of a "try us out for free" play. Bring your big data here, if you end up not liking it, we won't penalize you for taking your data out. Given that GCP is running at a very distant 3rd, they need to make plays like this.

It could also be a method to put pressure on AWS to get rid of their egress fees.

If it doesn't work - GCP looks a little better compared to AWS

If it does work, AWS users will have an easier time extricating themselves from the platform, and possibly going to GCP.

Re: Removing data transfer fees when moving off Google Cloud

#40

So on the one hand Google now accepts that egress fees are outrageous. Great! On the other hand, they're only reducing (removing) the fees when you leave them. If this move were really about acting in customers' best interests, they would reduce the fees for everyone. Doing this only for departing customers feels performative.

Google is part of Cloudflare's Bandwidth Alliance [1] which is removing most egress fees. Google still charges for egress, but it's half of what AWS is charging. We moved everything off of S3 anyway and have been using Cloudflare's R2 storage along with Google Compute Engine instances. R2 can be a little flaky, but the cost savings for us more than makes up for it.

[1] https://www.cloudflare.com/bandwidth-alliance/

Post reply on HN