Hacker News Reader

Comment by neya | Hacker News Reader

Holy crap! They're actually doubling the pricing (for some important products)!

I actually followed the links and found this:

    > Coldline Storage Class B operations pricing will increase from $0.05 per 10,000 operations to $0.10 per 10,000 operations.

    > Coldline Storage Class A operations pricing in regions will increase from $0.10 per 10,000 operations to $0.20 per 10,000 operations.

    > Coldline Storage Class A operations pricing in multi-regions and dual-regions will increase from $0.10 per 10,000 operations to $0.40 per 10,000 operations.

    > For all other storage classes, Class A operations pricing in multi-regions and dual-regions will increase to be double the Class A operations pricing in regions. For example, Standard Storage Class A operations in multi-regions and dual-regions will increase from $0.05 per 10,000 operations to $0.10 per 10,000 operations.

This announcement is just an eye wash to hide the fact that they're doubling their pricing structure for some products. And they claim most customers will see a cost decrease.

Sigh, I was just thinking of moving all my stuff, projects and even websites from cloud hosted solutions to my own home server and slapping a cache like CloudFlare on top of it and calling it a day. This is only pushing me in that direction, haha.

Reference: https://cloud.google.com/storage/pricing-announce

View on HN

I’m not defending them, but that’s really an unfair assessment. They are tweaking the model for how the cold storage tier is priced, with some minor reductions on the storage component and price increases on the “operational”/tasking side.

I haven’t managed a hyper cloud service, but I have managed 7-8 figure enterprise services. Sometimes as a service and ecosystem evolves, you need to tweak the business model. For a service like this, I would guess a set of customers stumbled into or found some loopholes that affected the economics of the services.

It is still a simpler model than Glacier, which is the AWS service closest to this.

As a customer, supplier risk is always something to factor. You can’t be religious about tech stacks for this reason and always need to chase dollars. If you have the market power, sometimes you can delay these sorts of actions with termed price contracts. If you don’t have lots of compliance requirements, paying for them baked into GCP may not be a good idea!

If your business (or bonus) is dependent on the beneficence of AWS, Azure, GCP, etc, you need to make sure that you understand that you are rolling the dice and someday the happy times will end.

AFAIK AWS have never increased prices on any specific product offering.

Your overall point still stands, agree you have to have a plan for the day your vendor decides to put the squeeze on (and that can take many forms).

I’m fairly confident they usually raise prices through new generations of compute instances.

That's like saying Apple raises the prices of the iPhone through new generation of iPhone models, which is not true at all. If the same service gets a higher price, then it's a praise raise. If a new service gets a higher price, it's just a new service.

> That's like saying Apple raises the prices of the iPhone through new generation of iPhone models, which is not true at all. If the same service gets a higher price, then it's a praise raise. If a new service gets a higher price, it's just a new service.

I don't think the distinction is that clear: you could just rebrand an existing service and raise the price. "Try our new v2 APIs, guaranteed compatibility with our v1 API and only 10% more expensive!"

I think the reality is somewhere in between, where companies will use new product launches to add stuff for customers and raise prices to protect their margin.

Apple margins are pretty consistent.

Assuming the assumption that intergenerational go up is true, in general compute only gets cheaper over time, so escalating prices implies increasing margin.

> That's like saying Apple raises the prices of the iPhone through new generation of iPhone models, which is not true at all.

I don't know if I'm reading your comment right, but the average selling price of iPhones has been climbing steadily from the start.

It's actually the opposite! To pick a representative example

    Current generation:
    m6i.large: $0.0960
    m6a.large: $0.0864
    m6g.large: $0.0770


    Previous generations:
    m5.large:  $0.0960
    m4.large:  $0.1000
    m3.large:  $0.1330
    m1.large:  $0.1750

https://rbranson.medium.com/rds-pricing-has-more-than-double... is a good example of using the generation abstraction to improve margins. Obviously, this source is not a price increase. It’s just increase in premium over EC2.

https://redmonk.com/rstephens/2021/12/17/iaas-pricing-2021/ Is also great and shows a flatness in price

They also don't discontinue any service as long as at least 1 customer* uses it. Which means: you will have the old (in your opinion probably lower) price forever, as long as you don't upgrade.

That's a very important distinction: increasing prices for users who can't go away and increased prices for users which migrate on their own to the new pricing structure. As far as I know, Google does the former which always has a "fader Beigeschmack" (DE; dulm aftertaste?) IMHO.

* = whatever that means :)

"We are reaching out to inform you that we will be retiring EC2-Classic on August 15, 2022. This message contains important information about the retirement and steps to take before the retirement date

How does this impact you? Your AWS account currently has EC2-Classic enabled for EU-WEST-1 Region"..

To be fair, "EC2-Classic is a flat network that we launched with EC2 in the summer of 2006", so I'm not complaining, but thought it was an interesting counterpoint.

It's not a counterpoint, though.

They're retiring a product that's been deprecated for half a decade.

No prices are being raised...

edit: I misunderstood, I thought we were still talking about prices.

The GP said “ They also don't discontinue any service as long as at least 1 customer* uses it.”

The person you are replying to gave the counterpoint that AWS is discontinuing a service that the person is currently using.

This seems like a valid counterpoint to me.

I thought that at the time I got that notification.

But it turns out I don't have any EC2-Classic instances, and was really just a notification I wouldn't be able to create new one.

That's a very important distinction: increasing prices for users who can't go away [as an example of something Amazon doesn't do]

That's an important note for Glacier, where a significant price increase could lead to a situation of "You can pay punitive rates for retrieval of all the data to migrate it or you can pay us a higher price every month going forward."

As anecdata I was an early user of a product called SimpleDB. Long after the product disappeared from their website my application still worked. I didn't like the early version of Dynamo enough to switch. I don't remember what happened, this was 12+ years ago now since I wrote it

That could also mean that AWS bakes in incredible margin, so they can absorb underlying component price increases without going upside down on margin.

Agreed, but in that case every AWS offering should always be more expensive, right? Is that the case?

Probably not literally, but in my experience the answer is more or less just "yes, aws is more expensive than competitors"

This is the opposite of my experience, although it does depend on workload.

Thinking more, I guess I'm comparing to more creative / niche competitors or different approaches, rather than just doing the same thing on azure / gcp.

This is not my experience with AWS, not at all. AWS deserves huge praise for this.

That's fine, because as a business I can decide whether or not that price is acceptable to me.

On the other hand, if they are known to occasionally significantly increase the price of their offering, then I have to factor that risk into my budget (let's face it: most businesses are locked in to their current cloud provider to a significant extent) so the price on the label is misleading.

I much prefer to pay a bit more up front than to have to constantly guesstimate how much financial risk is introduced by my cloud provider's erratic business decisions.

As an ex aws senior leader many products in aws operate at a loss when the underlying infrastructure becomes more expensive for some reason. Glacier is a great example of this, they ran at a steep loss as they mis-bet that hard drive prices would drop faster than tape storage and had to retire their original architecture and redevelop a tape infrastructure. It would have been totally reasonable to increase prices then decrease them once the new platform was available, but they chose instead to operate at a loss and not adjust prices. I believe they actually decreased prices once the tape infra was up.

That said margin is why they could do this. Aws as an overall portfolio of services is profitable enough that they can loss lead on many products that operate at a loss for many reasons.

Finally pricing is done with margins enough to later lower prices, mostly done to ensure they don’t end up in a permanent loss leader situation by misjudging margin or some other aspect prior to launch. But at least when Andy Jassy was in charge there never would have been a price increase - ever. We all knew down was the only thing he would consider, and lowing prices was a good way to get promoted.

I don’t follow AWS pricing closely enough to comment.

But I would say that the AWS glacier pricing model is/was… inscrutable to say the least. There’s probably a reason for that! :)

It’s not never, but it’s rare. They renamed to cloud map and took a free product and started charging for it

https://mobile.twitter.com/0xdabbad00/status/106819770559422...

>I’m not defending them

yes you are.

OP has a fair assessment. It's an unfair defense. Whenever I've relied on Google, I eventually got !@#$%.

I've never had that problem with Amazon. Microsoft also doesn't do it much these days. This is really specific to Google (and Oracle; but Oracle !@#$% in the wallet, but at least realizes driving customers out-of-business is bad for business).

Not all GCP customers will be !@#$% here, but many will. People who rely on Google inevitably regret it at some point.

They will all let you down. If you think you aren’t getting screwed by Microsoft, you either don’t do a lot of business with them or aren’t paying attention.

Oracle gets the reputation, but Microsoft probably liberates more bullshit dollars from companies than anyone else. They are like taxes, minus deductions.

>> Coldline Storage Class A operations pricing in multi-regions and dual-regions will increase from $0.10 per 10,000 operations to $0.40 per 10,000 operations.

>>Default replication pricing in the us, nam4, eu, and eur4 locations will increase from $0.00 per GB to $0.02 per GB. >>Default replication pricing in the asia, and asia1 locations will increase from $0.00 per GB to $0.08 per GB.

Quadrupling pricing. And a couple of bumps up from "free". Wow.

Do it! I just moved my stuff into my own home and it's been great. Cloudflare's tunnel thing (Argo?) works a treat, but if you'd prefer a setup a bit more complicated, you can use something like Rathole (which is amazing, btw) to tunnel out to the cheapest EC2/Droplet/etc you can buy.

> Rathole

What is that? Not having much luck: https://www.google.com/search?q=Rathole+software

Appears to be https://github.com/rapiz1/rathole

"rathole proxy" search will find it, vs "rathole software".

Not actually answering your question but reverse SSH is also an option. Port on a remote host (i.e. cheap vps) forwards connections to your local machine.

https://unix.stackexchange.com/a/46271

Yes. that's an option. I should also add comparison between rathole and `ssh -R`. One reason that people keep inventing this kind of software is that `ssh -R` is slow and lacks of customization. (I'm the author of rathole)

I think its just Tunnel https://www.cloudflare.com/products/tunnel/

Duckduckgo had https://github.com/rapiz1/rathole listed half way down the first page. Google search results have become jumbled garbage.

Bing has it 3rd for [rathole software]

I searched for rathole by itself and it worked.

The signal from HNers searching and click on it may have bumped-up its ranking.It's a long-tail(hah!) search term it likely doesn't much to push it up the page.

Rathole: https://github.com/rapiz1/rathole

> "A secure, stable and high-performance reverse proxy for NAT traversal, written in Rust"

It compares itself to these other big projects:

frp: https://github.com/fatedier/frp

ngrok: https://github.com/inconshreveable/ngrok

For anything that's not a hobby or personal website moving it to your home isn't really an option, for most businesses the pricing change is probably not going to make a big dent if you think about how high salaries are compared to cloud hosting costs.

This is quite a myth. Maybe these prices are low compared to US salaries, but in India or Romania or other big outsourcing places, salaries in the 4-5k EUR/month (48-60k EUR/year) are the norm, and it's easy to get even higher bills from cloud services if you're not very careful, even from testing and dev activities.

60k would be a pretty good salary even in the UK, Germany or Sweden.

In Romania, etc. you're looking more at like 15-25k.

Americans don't know how good they have it.

brutal age discrimination in the USA though

And they love 58-year old programmers in Serbia?

I've worked with many an offshore team, and have yet to find myself on a call with anyone over 40.

Actually, I haven't seen any clear sign of age-based discrimination here in Romania. There are two other factors that can give that impression, though.

For one, the programming demographics are extremely skewed towards younger people. There was almost no programming being taught or practiced in 1980s or 1990s Romania (and the same is true for all of the former Eastern bloc basically), and then there was a huge burst in the 2000s as the country decided to push this particular segment (even today, you don't pay the 16% income tax on your salary as a programmer with a relevant college degree). Overall this means that there are far, far more 30-ish programmers working in Romania today than 50-ish ones. I believe the same is true to one extent or another in most of the formerly Eastern bloc countries.

The second reason is less rosy. Big outsourcing firms, which make up at least a plurality of the programming market, have little need for experts. Their hiring and retention practices greatly emphasize cheap junior hires, whom they don't want to retain past some point. They will usually have a handful of seniors around for the more advanced contracts, but they don't have any reason to keep around a workforce that gains in experience. This is mostly greedy but also partly rational - unlike a traditional business where you get to accumulate valuable context as you gain experience, in outsourcing you will rarely spend more than a few years on the same project, so the advantage of having been around the company for years and years is much less.

I'd say it's the same in Lithuania.

Basically everyone that studied something like computer science in the 90s were electrical engineers and the computer stuff was barebones, it was more hardware. Software development like we know it wasn't a thing back then so people started late compared to the west.

I have a dev in his 40s and a sysadmin in his 50s as co-workers but that's rare because of the things you mentioned. With that much experience, high demand and low competition at that level they're going to have cushy jobs that they want to have and won't be sitting at crappy outsource shops.

I was going for the upper range, and including taxes - so, company costs per employee, not what the employee gets.

Either way, it's easy to hire an extra mid-to-senior engineer or two for the costs of many cloud services.

It's plausible. But anyone who has used cloud hosting for a personal website knows how ridiculously expensive it is - and it scales linearly! Mostly egress costs - they want to hold your data hostage.

Interesting technology though.

I seriously doubt this. In what scenario is this actually true?

For a good tunneling option, Oracle Cloud has always-free instances with 20TB/mo of outbound bandwidth.

Imagine, Oracle doing better than the current "BigTech"

If Larry wants to have one less yacht to subsidize me and compete with the big boys, count me in.

Oracle Cloud has serious issues around service and feature pairity, but if you can work around those, it's a lot cheaper.

What service issues are you referring to?

Good luck actually provisioning such an instance though. At least for the past month I have been unable to actually provision one of the free-tier instances due to no available capacity in the regions I tried.

Be careful with that! You can launch free tier instances anywhere you like in Oracle cloud, but unless they are in your home region, Oracle will charge you full price.

I've never had problems launching out of San Jose, CA, which is the closest region to me, but I can't say I've tried others.

Sounded exciting. I looked it up right away. Seems to be only 10TB yet. But it is also great. Source: https://www.oracle.com/cloud/free/#always-free

Dang, you're right. I know it used to be 20TB/mo, and you can find other references to it around the Internet. I wonder when it changed...

Unless they relicense zfs into GPL compatible one, I'm not going to touch Oracle products.

They're killing such a great innovation that no one can replace in the past 15 years and not likely for another 10 years.

But thanks to Ubuntu I can still use it with relative confidence.

Given that these price increases are for things like long term storage I wouldn’t start thinking about home hosting as an alternative. The whole point is having a secure backup and your home isn’t going to cut it.

I’ve had pretty good luck with B2 for storage. In my case it is as an online backup for my home hosted services (storage + DB).

If it's just for your off-site backup, Glacier Deep Archive is 1/5 the cost of B2... until you need to restore it.

Yeah, I did the maths on that (and similar from GCP and Azure) and deep archive could be less expensive, but the cost of not only restore but also egress made me quite apprehensive.

The current monthly cost is totally affordable and in the case I need to restore I’m not facing any additional charge… Now, I’m backing up a bit over 1TB - depending on the amount of data you might come to a different conclusion.

Restore by itself is just fine on Amazon. 20x smaller than on GCP. The problem is entirely egress.

I wouldn't discourage anyone from home hosting really. It's getting to be pretty clear that it's cheaper, far better for privacy concerns, and gives you much more control. It seems that companies are beginning to ramp up the prices now - since once you've put your data with them, they can increase charges whenever they like. They know they have a large portion of the population using these data storage solutions, and they're likely going to start abusing that power. If you know what a desktop is, I would suggest trying to self host - even if it's just dead simple raid10 on OpenVPN with syncthing. Heck, put one at another family members place and you probably have a more geographically diverse setup for your data than Amazon does.

Check out r/selfhosted if you are here.

My home _absolutely_ cuts it. All my data is stored locally in Raid 1 and backed up once a day, immutably, to a remote location. I trust my setup far more than I'll ever trust Google Cloud, or whatever else.

I'll store your stuff at my home if it makes you feel better.

C2C IaaS YMMV YHIHF

Same here, at least for self-hosting! Although I use a cheap AWS Lightsail instance to route over Wireguard to my home machine but it's the same idea.

As a Coldline user myself I'm not exactly happy about this, but Coldline is also the cheapest class of archival storage that Google offers. This means the increased costs will not kick in unless you actually need to un-archive data, which for typical archival cases like old logs happens quite rarely.

And there's no gotcha there, Google's always been open that retrieval fees are the tradeoff for Coldline being otherwise so cheap. Nearline is the better option for data you'll access more once a quarter.

"so cheap" might be a bit overly relative in this usage..

I guess the only time you would use Coldline is if you rarely access the data, but when you do access it, a retrieval delay is unacceptable. If you access it frequently, use a cheaper retrieval tier; if you can tolerate a delay, use Glacier or GCP's Archive tier.

> if you can tolerate a delay, use Glacier

S3 recently added a Coldline-like "Glacier Instant Retrieval" class, FYI. Their "Deep Archive" class (the cheapest) still does require restore operations that take hours to complete, though.

https://aws.amazon.com/s3/storage-classes/glacier/instant-re...

> or GCP's Archive tier

AFAIK, the GCS Archive tier has the same availability characteristics as Coldline and the same latency as all GCS class (10s of milliseconds). It seems like the primary factor for how you'd choose a GCS storage class would be your cost projections based on how long you store objects for and how frequently you access them.

https://cloud.google.com/storage/docs/storage-classes#archiv...

> AFAIK, the GCS Archive tier has the same availability characteristics as Coldline and the same latency as all GCS class (10s of milliseconds).

That's true as far as I know. And the combination of "the data is accessible instantly" with "there is no low priority retrieval, there is only the ultra expensive kind" implies that their architecture is extremely weird and/or some very manipulative pricing is happening.

Neither. It only means that hot and cold storage live right next to each other and pricing is used as a carrot/stick, as well as a signal, so that the two classes tend to stay the same (mainly to prevent cold from getting hot, of course) and a desirable balance is preserved. You could call it manipulative, if you want, but it's more like incentives.

Amazon can apparently get data cheaply out of cold storage with a day or so of warning.

Can google not do that? And if they did, they could still maintain the same kind of tiering.

If they can't do it, that's a very strange system.

If they refuse to do it, that's manipulative.

For archival storage Google's charging three and a half years of storage costs to retrieve data. Even in the most flattering scenario where roughly all of the cost is in doing the I/O, and disk space is "free", that implies that retrieval is at least 75% profit. If I/O is half the cost of storage and disk space is half the cost of storage, then retrieval approaches 90% profit.

Sir, we live in a capitalist economy. Prices don't mirror costs.

My complaint is that the competition is awful here.

Capitalism is supposed to pit companies against each other and drive profit margins below 50%. And it's failing to do that here.

And moreso, it's a very cruel pricing system because it lures you in with low numbers, then overcharges to get your data back when you need it. Being antagonistic to your customers does have negative effects in the long run. And I think it's worth pointing out situations like that when people are shopping around.

If you're doing disaster recovery, do you really want to wait a day for your data? I don't understand why you want Google to slow things down. Why can't Amazon get cold data faster? It's fairly simple: all Google storage is online. There is public material on how it all works. Maybe you can ask them to add an artificial delay. There is offline storage, yes, but that's tape, which has bigger issues...

Your pricing model is flawed, because you're not taking into account other factors such as rebalancing. Years ago, I would have loved for retrieval to be that cheap to perform behind the scenes.

> If you're doing disaster recovery, do you really want to wait a day for your data?

I'd like to have the option.

The point isn't that I want to wait, it's that I want it to be super low priority to make it cheaper.

For a super low priority job, why should reading be multiple times as expensive as writing?

> Your pricing model is flawed, because you're not taking into account other factors such as rebalancing. Years ago, I would have loved for retrieval to be that cheap to perform behind the scenes.

I don't understand. If rebalancing happens behind the scenes, then that has to get paid for as part of storage.

Which means the cost of 1 single I/O is a smaller fraction of the storage cost.

Which means the profit margin for retrieval is significantly higher than my estimate.

My cost estimate uses the most flattering possible case for the retrieval pricing. Any storage costs I didn't account for, deliberately or accidentally, make my argument stronger.

> For a super low priority job, why should reading be multiple times as expensive as writing?

Because the particular aggregate mix of storage helps drive down overall costs. Changing that mix affects the entire stack, as well as capacity planning. Ok, make cold storage very cheap to retrieve. What happens now? Everybody will buy that and abuse it for more demanding applications, with quality of service for latency sensitive traffic going down the toilet. So you end up throwing more resources at the problem and/or charging more across the board. Pricing is one of the few factors that users really pay attention to in the real world, not best practices. Unfortunately.

Furthermore, to implement what you want, you can keep a request open for hours, which causes issues all over the stack (where do you keep that state? How does that interact with load balancers?) or you mark the cold object and return temporary failures until it's finally retrievable. That's extra state and extra complexity that doesn't exist right now. Those extra costs would have to be recouped somewhere.

> I don't understand. If rebalancing happens behind the scenes, then that has to get paid for as part of storage.

Why? Rebalancing doesn't happen in a vacuum. It's linked to the traffic mix. You can't look at just the total bytes used in a cluster and figure how many HDs, SSDs, CPUs, RAM and NICs you need to serve that data while still meeting your SLOs. Unless it's a W/O cluster, you need more signals. Amount and behavior of cold vs hot storage are two of those.

Anyway, cold storage that warms up most likely requires extra rebalancing that wouldn't have happened otherwise. How would you price that? Who would you charge?

Again, your cost estimate for retrieval does not take into account how things actually work. Rebalancing is not purely a storage cost. Yes, your argument is strong, but only if you start from flawed assumptions.

> Because the particular aggregate mix of storage helps drive down overall costs. Changing that mix affects the entire stack, as well as capacity planning. Ok, make cold storage very cheap to retrieve. What happens now?

It doesn't have to be very cheap. Let's start with just trying to match the price of writes. That shouldn't really affect the total amount of I/O, and there's no reason reads should be harder on the system than writes.

> Furthermore, to implement what you want, you can keep a request open for hours, which causes issues all over the stack (where do you keep that state? How does that interact with load balancers?) or you mark the cold object and return temporary failures until it's finally retrievable. That's extra state and extra complexity that doesn't exist right now. Those extra costs would have to be recouped somewhere.

I suppose. But the cost of keeping a request open should be much much less than the current cost of having everything fully accessible in milliseconds.

> Anyway, cold storage that warms up most likely requires extra rebalancing that wouldn't have happened otherwise. How would you price that? Who would you charge?

Reads that cost a significant amount of dollars each don't require rebalancing. I'm not suggesting they go so cheap that rebalancing is required. You'd still do only one read to a completely separate hot storage system, like it currently works.

I think you might be missing that this is an operation count price tweak. How many ops could you possibly need for cold storage? Zip up your files and you end up with one op.

40 cents per 10k ops is still so cheap. They probably tweaked this to take advantage of their lazy enterprise customers that don’t care how much they’re paying for op counts, so they use a bajillion ops.

Has AWS ever done this?

To my knowledge they have not, and this is the third time (at least) that google has done this. Managed Kubernetes and Google Maps API are the other 2 that I know of.

I only ever remember seeing AWS lowering prices but I am curious if there are instances I am unaware of.

This continues me wondering how anyone can think going with google cloud is a good idea.

Maps also has one of the most restrictive licenses I've ever seen in the industry. If you stop using Maps you're required to delete all data and all derived data. The only time I've ever seen a more restrictive license was when using Bloomberg. At least in that case it made some modicum of sense given that there was a lot of manual data entry going on in the background.

The larger issue is that even though I would like to use Google in some cases, I know that I can't trust them. As a company they need to seriously rethink their approach to fostering customer trust.

AppEngine has redone its pricing model at least once, possibly twice, in a way that upset people.

I’ve seen parameter store (free) ”switch” to secrets manager (paid). But old parameter store is still there.

That’s the closest I’ve seen.

Secrets is a different product with additional capability.

> Sigh, I was just thinking of moving all my stuff, projects and even websites from cloud hosted solutions to my own home server ...

Good thing you didn't follow the other link to the changes in pricing for (egress) network traffic!

Hold on, they said in the announcement that some customers could see a price decrease. Do you mean to imply that Google used vague and imprecise language to hide substantial price increases? If so, color me shocked!

But the increase is not about the storage price it's about the API calls if I'm right?

Let’s be real here: nobody pays sticker prices for GCP. The only reason big customers use it is the deep discount Google gave.

Now this price hikes signals us two things: Alphabet is tired of losing money on GCP or they are looking to drive customers away so they can shut it down (it’s not like a free chat app they can just stop supporting, sunsetting GCP will have to take a little longer).

GCP has had a ton of price hikes and price reductions.

This change tells us one of two things:

1) they want to use price as a way to influence customer behavior

2) A PM wants to get promoted and this is a way to hit whatever arbitrary metrics they need.

Or a combo.

There is a zero chance alphabet as a parent company cares about the specific pricing of super specific SKU. And there is a zero percent chance they will shut down the fastest growing non-ads business they have...

GCP is extremely profitable, they are just reinvesting in more growth.

(I'm a Ex GCP employee)

Edit: I want to make it clear I'm not supporting this decision. Arbitrary (or what seem like arbitrary from a customer viewpoint) price hikes is one of the reasons I left.

We pay sticker price for GCP by choice over other cloud providers quite happily.

What makes you happier compared to other vendors?

I feel like the interface is more intuitive, has sane defaults and has really good setup wizards when you are provisioning things. Also, my understanding is that GCP is pretty much cheaper across the board compared to AWS, but I could be wrong about that. To be fair, the only real major headache we've had with AWS in recent history was EKS stuff, and GKE really shines on GCP.

> For all other storage classes, Class A operations pricing in multi-regions and dual-regions will increase to be double the Class A operations pricing in regions.

This is the real impactful change. This is for ALL STORAGE CLASSES, not just Coldline. As someone who manages billions of objects in GCP, I know very well that each of those object write is a Class A operation, so 2x in price.

Also keep in mind that anyone storing objects durably (DR, anyone?), e.g. your customer data, is using multi-region, so this is a notable cost impact.

Note that there is a curious inflection point where, the Class A/B operations on an object cost _more_ than the (bytes) storage cost, depending how long you retain the data. That's where this is very impactful.

Annual multi-regional Standard _storage_ cost for a 19MiB object

e.g. 0.026 $/(GiBmo) 12 mo/yr * 19 MiB/yr = 5.95E-06 $/yr/obj

Annual multi-regional Standard storage cost for an object that you 1x write (A), and 2x read (B).

e.g. 0.05/1e4 $/A req + 2 * 0.004/1e4 $/ B req = 5.80E-06 $/yr/object

Here we see that the old annual "storage" carrying cost for this 19MiB object was less than the "request" cost. Now double the cost of the operations and you should consider storing fewer, bigger objects.

All data on GCS is stored durably (14 9s or something ridiculous like that). The only reason to use dual/multiregion is for lower latency, you're basically paying for geo replication.

Of course, I'm sure many users are not aware of this, and it's not helped by the GCP console defaulting to multi when creating new buckets.

Also for availability, if you need extremely high uptime - single-region outages are not unheard of, and even if your data is still there when they come back, you might have lost a significant amount of money and/or trust in the meantime.

Durability is great, but availability is also crucial, unless your business can tolerate hours or more of availability outages.

Let's say us-central1 is down for some reason (has happened a number of times), but your customer workloads need to keep running uninterrupted, so you fail over to us-west2. Where should your customer files, that need to be read/written for the customer workloads, be written then? If you kept them all in the region that's on the fritz, you've got upset customers, broken SLAs, etc.

It’s been far easier and cheaper to just rent a dedicated server for personal projects and websites.

You should for personal stuff. There are nicer VPS options too. Cloud usually makes sense when considering onprem costs to do the same thing which can add up for companies.

Thanks for breaking it down, the overview doesn't help much.

Reply on news.ycombinator.com