[HN Gopher] Removing data transfer fees when moving off Google C...
___________________________________________________________________
Removing data transfer fees when moving off Google Cloud
Author : LukeLambert
Score : 153 points
Date : 2024-01-11 15:49 UTC (7 hours ago)
(HTM) web link (cloud.google.com)
(TXT) w3m dump (cloud.google.com)
| ShakataGaNai wrote:
| That's a cool thing for them to do, an interesting business
| choice, but cool. It certainly helps the companies feel a little
| better about vendor lock-in, which is terribly plentiful in the
| cloud.
|
| The TLDR is that when you tell them you want to cancel, you have
| 60 days to do so and during that time you'll have no egress fees.
| Makes sense.
|
| Biggest problem though is... if you have a substantial amount of
| data or need to do a complex and seamless transition - this
| probably won't work for you. I would have to be on the DevOps
| team that's told to move a complicated and data-heavy
| application, and they only had 60 days to do so. Also the bulk of
| the data movement is, in my experience, one of the first steps of
| migration - not the last.
|
| My hope is that, if nothing else, this will spur similar
| behaviors in other large cloud providers ::cough::aws::cough::.
| diggan wrote:
| > I would have to be on the DevOps team that's told to move a
| complicated and data-heavy application, and they only had 60
| days to do so. Also the bulk of the data movement is, in my
| experience, one of the first steps of migration - not the last.
|
| Couldn't you wait to tell Google until you've more or less
| figured out the logistics, then tell Google that you're
| leaving, fees for egress gets disabled and you initiate the
| move. Then you have 60 days to complete the move.
|
| But yeah, if the move takes 30 days because you have a ton of
| data, and you figure out after the move is complete, that you
| missed 10%, you only have 30 days to figure out how to get that
| out too.
| kentonv wrote:
| Sounds like they're trying to technically address EU
| regulators' concerns without providing any real value to
| customers.
|
| In real life it's probably extremely unusual for any company to
| altogether cancel their Google Cloud contract. More likely is
| the scenario where you move the bulk of your cloud usage to a
| new provider, but still have various straggler infrastructure
| on the old one, which is not worth the effort to clean up. Or,
| you go to a multi-cloud strategy so you want to move half your
| data off Google but keep the other half around. Google's egress
| fees are still standing in the way of these cases.
| thrtythreeforty wrote:
| Yep, for a sufficiently large account, this strikes me as an
| offer they know will never be taken. "Migrating" typically
| means "stopping $XXX,XXX spend per month" not "completely
| ceasing use of all GCE services."
|
| They know this and this is mainly marketing, I think.
| op00to wrote:
| You migrate use cases, not entire environments!
| andersa wrote:
| I bet there's some new regulation being implemented here that
| they just happened to forget to mention in the post.
| loosescrews wrote:
| > Certain legacy providers leverage their on-premises software
| monopolies to create cloud monopolies, using restrictive
| licensing practices that lock in customers and warp competition.
|
| I like to see them publicly call out Microsoft and Oracle.
| SteveNuts wrote:
| I think the "Legacy" and "licensing" portions are specifically
| calling out MS and Oracle, but they very sneakily are calling
| AWS out too on the fact that egress makes it insanely expensive
| to leave their platform.
|
| I've worked at some orgs where to either move their data out of
| S3 would cost $20k, or to even delete it would cost thousands
| in API calls.
| zinekeller wrote:
| You don't need the "I think" for Microsoft: while not
| mentioned directly, the links on "unfair legacy software"
| points to Microsoft.
| dspillett wrote:
| _> but they very sneakily are calling AWS out too_
|
| That, and any of the smaller "clouds" with egress/delete fees
| that need to be considered when leaving. Seems massively
| disingenuous given that until this announcement they also had
| such fees ("look, those people try rip you just like we were
| doing until five minutes ago!") but that is pretty standard
| for marketing materials.
|
| This makes them a better option as the first cloud provider
| to try, other things being equal, because leaving (back to
| on-prem or to another provider) is easier. I assume they are
| trying to remove a little of the huge the distance between
| them and the two leading players by reducing concerns that
| might add on-boarding friction.
| solatic wrote:
| > to even delete it would cost thousands in API calls
|
| _raises eyebrow_
|
| It's a well-known trick (proposed by AWS Support as well) to
| set S3 lifecycle rules to empty buckets with too many objects
| to cycle through via List calls. Doesn't cost anything.
| SteveNuts wrote:
| There's still a cost for transitions even if it's not list
| calls. That might be cheaper I haven't looked in a while.
| seatac76 wrote:
| Getting ahead of antitrust I see. Big tech has gotten so big that
| we will now see this peace meal stuff being done to appease
| regulators to stave off any major action.
| trhway wrote:
| don't think so. Google is the distant 3rd in the Cloud, so
| hardly a subject to antitrust. It is more likely that failing
| hard on their goals for the Cloud set to that division about 3
| years ago (and it was rumored that either they achieve the
| goals or it is "or else" for the Cloud division) they are
| starting the blame game whining about licensing/unfair
| competition/etc. (whereis they should blame only themselves as
| they would never bend over to the enterprise customer like say
| AWS would do who for example developed MS SQL (Transact SQL)
| interface to their own db - that is how you deal with the
| competition and software lock-in instead of whining (reminds
| that phrase from Babel - "that is why Benja is the king, while
| we are sitting on the cemetery fence"). In this case for
| example I remember how AWS was hunting down laid off Sybase
| (where T-SQL comes from) engineers whereis being an experienced
| enterprise software developer is viewed by Google is more like
| a disadvantage and results in meager offer (several my
| acquaintances had similar experience), so GCP losing enterprise
| game doesn't look that surprising to me. And now that
| enterprise customers are starting to add huge AI related
| workloads the GCP is hardly ever mentioned)
| kaonwarb wrote:
| Google Cloud has ~10% market share; I don't think this is an
| antitrust avoidance play. More likely, it's removing a concern
| companies might have with bringing workloads onto a relatively
| smaller player. Especially one that has a history of
| discontinuing products.
| SteveNuts wrote:
| > Especially one that has a history of discontinuing
| products.
|
| Let's just hope this isn't step 1 for their plan to do
| exactly that.
| aaomidi wrote:
| The issue isn't as much market share as it is how sticky
| picking a cloud platform is. At that point the market share
| doesn't really matter, especially if your name is Google.
| pimlottc wrote:
| > peace meal
|
| *piecemeal
| Mortiffer wrote:
| but i guess this won't impact Google Cloud Storage egress fee
| CobrastanJorji wrote:
| That is exactly what this impacts, if you're leaving Google
| Cloud.
| jdon wrote:
| 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.
|
| [1] https://www.gov.uk/cma-cases/cloud-services-market-
| investiga...
|
| [2]
| https://assets.publishing.service.gov.uk/media/652e958b69726...
| jiveturkey wrote:
| 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.
| oh_sigh wrote:
| 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.
| donalhunt wrote:
| This. I see this as purely an attempt to influence AWS in
| lowering the barriers of migrating between clouds. But also
| makes sense for those who want the option to test the
| waters with no downside.
| blibble wrote:
| 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 to ingress (which they're silent on)
|
| if they want to play this game then the CMA should simply make
| them charge the same for ingress and egress
|
| that way they can "fund their network costs" without issue, and
| if they want to make them both free then that's their decision
| charcircuit wrote:
| >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.
| blibble wrote:
| I accept there's some level of cost, but the prices are so
| high it's hard to describe it as anything other than
| gouging to prevent competition
| toast0 wrote:
| My personal feeling is they're moving costs around so
| that egress has a big margin and other items have a
| smaller or potentially negative margin.
|
| I've seen this at other providers. We did a competitive
| pricing exercise at my last company, and our overall cost
| went down, but the mechanism was per hosts costs went
| down significantly and egress costs went up
| significantly, and the per host cost decrease outweighed
| the egress cost increase.
|
| It still doesn't make sense to charge for ingress,
| because everybody knows that should be free, unless
| you're a residential ISP.
| logifail wrote:
| > 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?
| scottlamb wrote:
| Why would the cloud provider charge for usage that
| doesn't actually cost them money? Unless usage patterns
| drastically change industry-wide, the ingress really
| doesn't matter to them. The egress does.
|
| It seems entirely reasonable to look more skeptically at
| cloud providers' exact charges vs cost for egress,
| particularly when high egress fees might contribute to
| lock-in, and when the public price sheet vs the preferred
| customer pricing might differ radically. But asking them
| to totally restructure the charges, inventing a charge
| for ingress when their actual total ingress cost is zero
| and, short of major industry-wide usage pattern changes,
| will remain zero? Why would you do that?
| amluto wrote:
| > 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 service.
|
| The Internet egress part ought to be straightforward on top
| of this: plug as much bandwidth worth of connections into the
| aforementioned extremely fancy internal network. Configure
| routes accordingly.
|
| It's worth noting that the big clouds will sell you private
| links to your own facilities, and they charge for these links
| (which makes sense), but then they charge you for the traffic
| you send from inside the cloud to these links, which is
| absurd since they don't charge for comparable traffic from
| inside the cloud to other systems in the same AZ.
| jeffbee wrote:
| > they need to provide non-blocking or near non-blocking
| performance within the availability zone
|
| I see you've never tried GCP.
| amluto wrote:
| 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.
| jeffbee wrote:
| 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.
| dekhn wrote:
| 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.
| jeffbee wrote:
| The whole word smacks of Bellhead thinking. With ethernet
| you put a frame on the wire and hope.
| dekhn wrote:
| That's an exceptional simplification of modern network
| approaches.
|
| if the world was bellhead, ATM would have won.
| TulliusCicero wrote:
| "Egress can be no more expensive than ingress" seems like a
| reasonable rule.
| qwertox wrote:
| But not during normal operation when egress to consumers is
| in higher demand than ingress. This would raise ingress
| prices unnecessarily.
| mschuster91 wrote:
| > 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)
|
| because ingress traffic volume is _a fraction_ (in my
| experience, in website hosting of a well known household
| brand, barely 1%!) of egress traffic volume, and most peering
| connections are 1:1 in ingress /egress bandwidth so the
| egress bandwidth cost sets the price.
| NBJack wrote:
| This also holds true on thebflip side for most consumer
| internet speeds (at least in the US).
|
| Many people have a x00 Mbps or even x Gbps downstream, but
| most have no more than x0 Mbps upstream. Literally their
| ability to pull traffic from websites is 50X in some cases
| than to push information out. Going beyond that (greater
| uploads) often costs significantly more.
|
| Whether or not these two are actually related isn't clear
| to me, but it _is_ interesting.
| skywhopper wrote:
| At face value this is a good thing, but I gotta say it's pretty
| rich for Google to try to diss other cloud vendors for leveraging
| their effective monopolies given its moves in search and now
| browsers. Sorry, but GCP doesn't get a pass on Google's other
| behavior just because currently a loser in the cloud infra
| market.
| xnx wrote:
| When you don't have many customers [as AWS] there's much less to
| lose by eliminating these fees. Also makes AWS look bad by
| comparison. Smart move.
| gnfargbl wrote:
| 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.
| vineyardmike wrote:
| 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.
| gnfargbl wrote:
| > 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.
| Patrick_Devine wrote:
| 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/
| timenova wrote:
| Can you give a few more details on the flaky nature of R2?
|
| Does it lose files? Fails to write but gives an error? Fails
| to read sometimes? Silently fails?
| ado__dev wrote:
| Good move.
|
| I still feel that the egress fees charged by the big 3 are way
| too high.
| hiroshi3110 wrote:
| Good move, but if you have data in GCS colder than nearline it
| may cost you still.
| pwarner wrote:
| Egress fees are way too high. And it doesn't keep anyone in
| cloud, if you want to move out, you do it. In fact, I think the
| fear of egress costs keeps more people OUT of cloud than it keeps
| people in. This is a smart move that won't cost them anything and
| may increase their business.
| londons_explore wrote:
| I know plenty of companies who can't afford the Aws egress fees
| to get their data out of Aws, and it's far cheaper to just pay
| storage for one more month and kick the can down the road.
| londons_explore wrote:
| The process seems a bit cumbersome...
|
| Why not:
|
| 1. Migrate your data out.
|
| 2. Close your account.
|
| 3. You will automatically be refunded all network egress fees
| incurred in the final 60 days, capped at the number of gigabytes
| you had stored in our products in the preceding 60 days.
| arccy wrote:
| your suggestion sounds more cumbersome (and probably refunds
| less)
| hipadev23 wrote:
| Wait so if I close my GCP account I get free egress, if I stay I
| don't?
___________________________________________________________________
(page generated 2024-01-11 23:00 UTC)