Updates to Google Cloud’s infrastructure capabilities and pricing
cloud.google.com
cloud.google.com
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.
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
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...
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.
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.
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.
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'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.
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.
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.
What is that? Not having much luck: https://www.google.com/search?q=Rathole+software
"rathole proxy" search will find it, vs "rathole software".
> "A secure, stable and high-performance reverse proxy for NAT traversal, written in Rust"
It compares itself to these other big projects:
In Romania, etc. you're looking more at like 15-25k.
Americans don't know how good they have it.
I've worked with many an offshore team, and have yet to find myself on a call with anyone over 40.
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.
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.
Either way, it's easy to hire an extra mid-to-senior engineer or two for the costs of many cloud services.
Interesting technology though.
Oracle Cloud has serious issues around service and feature pairity, but if you can work around those, it's a lot cheaper.
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.
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.
>>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.
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.
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 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.
Assuming the assumption that intergenerational go up is true, in general compute only gets cheaper over time, so escalating prices implies increasing margin.
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.
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.1750https://redmonk.com/rstephens/2021/12/17/iaas-pricing-2021/ Is also great and shows a flatness in price
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 :)
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.
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 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.
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 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."
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.
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.
But I would say that the AWS glacier pricing model is/was… inscrutable to say the least. There’s probably a reason for that! :)
https://mobile.twitter.com/0xdabbad00/status/106819770559422...
yes you are.
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.
Oracle gets the reputation, but Microsoft probably liberates more bullshit dollars from companies than anyone else. They are like taxes, minus deductions.
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.
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.
That’s the closest I’ve seen.
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).
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.
Good thing you didn't follow the other link to the changes in pricing for (egress) network traffic!
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.
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.
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.
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.
After merging two companies I had to move a bunch of stuff over to a new bankaccount. three weeks later and I'm still not 100% sure that I got it all, the interfaces are so opaque and the different ways in which you can get billed so confusing (never mind the bills themselves) that it is nearly impossible to get a clear picture.
This does not feel like it is an accident, and this message is very much in line with that.
I always wonder how such systems come about. The number of confusing error messages you have to deal with for pretty basic stuff is off the scale. You can name anything, except of course when it actually matters and then only some cryptic UID is shown. Don't get me started on users and permission management, or how it is perfectly possible to orphan an entire project[1] if a person leaves your org. (Gsuite and GCP may superficially appear to share a bunch of stuff but that just sets you up for some very cute surprises, from which it can be extremely difficult to recover.)
[1] https://cloud.google.com/resource-manager/docs/project-suspe...
The amount of blank stares and "Oh..."s that happened when asked about relatively simple, everyone-would-need-it use cases for management, visibility, etc was mind boggling.
GCP feels like Google rediscovering being Microsoft of the 1990s. If you have strong product teams, but no strong overarching experience teams, your resulting system is going to be a hash of well-polished but distinct products, with an extremely ugly unification layer.
(This was also the first time I heard Reader mentioned at the C level as in “what will we do when you cancel it?”)
Everybody who loved reader is now at the Director/VP/Csuite Tier, the sunsetting of reader also burned so much goodwill
For example, I contributed a fix to AWS documentation as a SDE in the Kindle org. This is the kind of improvements you get with dogfooding.
Billing is terrible, although it has gotten a bit better. Cognito is probably one of the worst services on AWS, and it's only getting worse (there are now two SDKs with different APIs for no reason at all). While things like EC2 and Lambda work pretty well.
I don't have much detail on Amazon's policy, but there was an AWS devrel on Twitter a while back saying they had to run and pay for their own AWS account as if they were any regular user for their own playing around/research/etc.
Same for Google. Everything that's in use by Googlers is pretty dope - calendar, video conferencing, docs, search obviously, maps, etc. Everything that's not - less so.
They definitely care about their customers, and many things were made better through subsequent fixes.
But the larger point is that the processes and mid-high+ level management structure at Google don't seem to prioritize cohesive, customer-centric experience. Which means teams will always miss things... because the process doesn't ensure they're caught.
This is in contrast to say Azure, where plenty of Microsoft employees are using the same resource manager APIs and even using the portal. I think even the billing related features get used as part of internal budgeting (they want teams to try to keep resource utilization reasonable). While teams developing parts of azure itself may be utilizing internal APIs (for example Microsoft Graph is basically just a giant wrapper around a variety of internal APIs), most of the rest of the company sees and interacts with azure in the same way we do. (Except that they also have access to dogfood/PPE environments that we don't, such that endpoints for say integration tests don't need to run on production azure).
I'm also not certain that Azure really has the right internal pressures to produce great UX results. In my experience Azure's culture internally is very lackadaisical with only a few teams really pushing the platform forward.
And still they don't have this incredible complicated and not understandable IAM. Most user I know just give everyone root because it's not possible to just allow some specific API operations for a specific set of credentials. Or maybe I am to AWS.
Not good enough when I kept being charged on an account I closed.
I contacted support and the first thing they asked is which browser I'm using. Brave.
Turned off the shield and everything magically worked. I got a small laugh out of that one.
Shutdown project also needed some billing permissions maybe? Cryptic messages.
I actually like the "project" permissions model, but I don't like how often I have to figure out why clicking around in the admin page as the "admin" causes problems.
On AWS side the admin policy is pretty broad, and the root account seems to really work as root.
Admin policy (AWS):
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}AWS may have arbitrary names that don't follow any patterns, and Azure may have names that are grandiose, but at least you know with both of those clouds that they will always capitalize the name of all their service/product in documentation. There's no confusion if they are talking about a load balancer in the abstract, or their specific managed offerings.
- Cloud Logging - stores logs
- Google Compute Engine - VMs, compute
- Cloud Monitoring - stores metrics, monitors stuff
- Cloud Storage - stores stuff
- Google Kubernetes Engine - runs Kubernetes clusters
- BigQuery - runs multi-billion row queries with ease
- Cloud Functions - FaaS run time
Now sure, Cloud Spanner is a DB, without DB in the name, so you'll have to read the docs for a few seconds, but let's compare that to Cognito (brains?), X-ray (medical imaging?), Kinesis (something to do with mitosis?).
Take the example of "GKE Ingress for HTTP(S) Load Balancing." It's overly generic and doesn't tell you at a quick glance whether you are buying a specific managed load balancer or running something yourself, and whether you are using basic exits to the public internet or buying into a global network accelerator.
Maybe not the best example since this (unlike other IAM oddities) actually makes sense - it can only happen when you don't have a top-level org tied to a project, like when you do something like using a gmail.com account to spin up GCP resources. Inside a GSuite org, this is not the default and I can't imagine how it'd happen by accident.
If your project is not attached to an org, and all the accounts tied to are gone, then what else do you expect?
> Gsuite and GCP may superficially appear to share a bunch of stuff but that just sets you up for some very cute surprises, from which it can be extremely difficult to recover
The way it's implemented is actually quite nice for complex scenarios/defense in depth - for instance, you can set it up such that whoever owns the GSuite org does not automatically get access to all GCP resources. Of course, any security measures good enough to restrict an org admin's privileges also have the potential of locking yourself out in a way that's semi-irrecoverable.
No, that's AWS.
And then some edge case where I was charged on an account I closed because some subscription was still left open while I could no longer login...
There is a zero percent chance they haven't ran the analysis and concluded what % of customers would see a bill increase. It's high. If its low-to-zero, cloud companies are clear about how the prices are changing, and usually outline how many customers are would be negatively impacted. If it's high, they're ambiguous about what is changing, and shift the blame onto customers; if its still expensive for you, you're just not using it right.
The "Always Free" egress change is probably going to mostly affect the large pool of free and near-free cloud users. So a very large number of people who "have Google Cloud accounts" may see costs go down.
But the costs will go up for all the customers heavily investing in Google Cloud and using Google Cloud for storage of a lot of data. So the overall outcome will be more money for Google, in an update that claims a cost reduction for a large number of users.
Put another way, if the cost was going down do you really think they’d avoid saying that because people might start to use more?
So, your bill is going up.
Zero percent is correct. I'm a GCP customer, and today I received an email from Google with a table explaining precisely how my bill would have changed, with columns labeled, e.g., "List Price $ increase in monthly bill due to data replication", and a corresponding dollar amount. My bill will increase by 5% overall if I don't make any changes.
- Using multi-regional storage (used to be a 30% premium, now much more)
- Making lots of object writes (Class A) vs lots of reads (Class B)
So, if you can:
- Move to regional or dual-region (NAM4) storage
- Snowball your writes into bigger overall objects, <3 immutability
- Keep your data in the same region as access
Then you can reduce the impact here.
They are also closing the Coldline/Nearline loophole, where you could use a bucket lifecycle policy to keep your objects in Standard (cheap access) for a few weeks/months, and then move them to a cheap long term storage tier (Nearline/Coldline), because that move is another Class operation, that just got a lot more expensive. This is inline with two years ago when they quietly moved lifecycle operation pricing from the origin service tier (e.g. cheap Standard storage) to the destination tier (e.g. much more expensive Coldline), cutting down on the savings of tier jockeying.
I don't like the price increases either, but it's kind of clear they're trying to make sure multi region buckets aren't the default a user uses just because it's there. It costs gcp more to run this, and for most users multi regional doesn't make sense.
Lots of enterprise orgs don't even use multi region because of either gdpr, or regional laws. The data has to either be classified as public/not sensitive for a real use case of it.
> Reading data in a Cloud Storage bucket located in a multi-region from a Google Cloud service located in a region on the same continent will no longer be free; instead, such moves will be priced the same as general data moves between different locations on the same continent.
If I understand correctly (do I?), this means that storing frequently used data in a multi-region bucket is suddenly very expensive — we go from paying $0 to $0.02/GB. Reading 10TB / hour goes from $0/year to $1.75M/year.
We can switch to single-region buckets, but it's quite an effort to move all the data.
Who cares about DR, and having 3x copies of your data 100mi apart from each other? Small startups, or Enterprises? Enterprises can just push those costs to their DR budget.
Instead, huge price increases? That's... confusing. I honestly wonder if Google wants to kill off Cloud, given how much money they lose on it every year.
I wonder if CF will be able to satisfy the storage demand once they release R2.
For me it started in 2020 when Google announced my Firebase storage usage would go from maybe $20 per year to something like $800 per year, for a single app. Apparently they had forgotten to charge Firebase users for egress, for years.
But then also Gmail stopped adding more storage at some point so I was forced to get a Google One subscription or migrate 15 years of emails to some other service.
Etc.
I suspect Google has realized it's better to reduce its storage customers and just keep the ones that are ready to pay more, instead of expanding their storage capabilities ad infinitum.
Building top down process to improve costs to enable price drops is one of Amazon's core strengths. It is core to how they run all their businesses.
According to Google's own calculations (in the email they sent about the price changes), this will increase our GCS bill by about 400% (and our entire Google Cloud bill by about 60%).
It would seem that we have until October to move elsewhere... :(
the biggest fear especially with this class of infrastructure (long term cold storage) is that they can make it too expensive to leave at any time by upping the retrieval / egress costs. How expensive is that move going to be?
At this point we are doing this with on-premise tape backup but that is in part because I'm yet to be convinced that we can trust cloud providers with this, especially since our future retrieval needs are unclear (some outlier scenarios could see us needing to retrieve substantial fractions of the data). Not to mention that even the coldest cloud storage seems to still be substantially more expensive than DIY tape archival (admittedly, not taking into account things like internal IT staff costs etc).
I think this is the third time we've been slapped with a new charge for something that used to be free. (In this case, egress from multi-region storage to a local region.) That's not going to burn us super hard, but maybe it's only a matter of time before they add a new charge that hikes our bill by 50%.
they first introduced container registry, which made us pay for the storage (before you only paid for invocation and egress)
> If your functions are stored in Container Registry, you'll see small charges after you deploy because Container Registry has no free tier. Container Registry's regional storage costs are currently about $0.026 per GB per month.
recently they sent an email telling us new functions are going to use to “Artifact Registry” and prompting to migrate our old functions
> Cloud Functions (2nd gen) exclusively uses Artifact Registry.
Artifact Registry price: $0.10 per GB per month
i'd recommend checking serverless framework (serverless.com) or openfaas (openfaas.com)
best thing you can do is not get involved with provider-specific APIs: use Docker/Kubernetes for building and executing your code, Postgres-compatible database (Hasura if you want Firebase experience) and S3 for object storage, send e-mails using SMTP
again, don't use provider-specific API's
If you run k8s clusters anywhere, OpenFaaS and KNative are both solid options. OpenFaaS is seems better suited for short running, less compute intensive things. Whereas KNative is a great fit for API's.. it just removed a bunch of the complexity around deployment (like writing a helm chart, configuring an HPA, etc).
And GCF v2 is running on KNative on Cloud Run... turtles all the way down.
1) You wouldn't expect zero margin, you would expect normal margin, that is, these companies should have around the same margin as the average of the rest of the economy.
2) Commodity markets don't have to be low margin, because a commodity market with high market concentration will be a high margin market.
Cloud is not a commodity product. Commodities are easily interchangable. For the most part, a banana is a banana, a pound of corn is a pound of corn, a ton of steel is a ton of steel. There can be quality variations of course, but at any given level of quality there are still multiple suppliers, and the costs of switching between them are fairly low.
That is not true of the cloud. Every cloud is unique in their own special snowflake ways, the APIs are often fairly different, the switching costs are high and there is a small number of suppliers.
It's surprising that vendors make their custom cloud features (e.g. SQS) more expensive than running the same thing yourself - because those have the most vendor lock-in.
This announcement adds an additional $0.008+/GB for the cost of outbound data moving through the load balancer, so effectively that's a 9% increase on the standard tier bandwidth pricing.
As someone who's used AWS for most of my professional career, I've only ever seen prices being reduced to be more competitive rather than increased to 'align' with offerings of other vendors.
Newer generations of compute and storage are often cheaper and faster than previous generations which shows they are able to invest in technology to make things cheaper for the customer and lower cost for them to maintain which is impressive.
Does AWS have anything similar to Cloud Run?
That said: neither AWS nor MS are particularly attractive either, none of these companies really have my sympathy, it is choosing the least bad rather than choosing the best. Technical merits, pricing, cost to switch, company image, it all factors into decisions like these.
GCP was trying to "loss lead" in to dominance, does not look like that was working out since even being more expensive AWS and Azure were still killing them.
Of course if you only choose GCP because of cost you have little reason to stay so...
AWS has never afaik increased prices which is a pretty strong selling point even if specific services likely are a loss for them perpetually as a result if mis-priced initially.
Technically true, but they do it a little different, where by they add different SKU;s with higher prices, and discontinue the old SKU's forcing you to move to a "new product" instead of just increasing the prices.
Not all services are like that but they just did that with compute instances, I believe this is the second time they have killed off a "generation" of compute
https://www.statista.com/chart/18819/worldwide-market-share-...
It's not hard to imagine some customers jumping to AWS or Azure, which most large organizations are likely to already be familiar with[1] moves like this & that looming mandate causing C-level concerns since everyone knows GCP is not profitable at the current pricing but is expected to become so soon. A lot of big organizations prefer to pay a predictable amount of money than run the risk of price increases blowing their budget.
The other possibility I was thinking about is consolidation in the less popular providers — e.g. what happens if IBM sells their cloud service to Oracle or Salesforce, or a major customer switches a lot of volume to them. Oracle comes to mind since their bandwidth pricing is like an order of magnitude lower than AWS — I'm sure Zoom negotiated hefty discounts but they still picked Oracle for a reason and I'd bet it's the fact that their business is largely network egress.
1. e.g. if you use Office 365 and GCP, there is a valid argument for consolidating on a single vendor and I'd be surprised if that didn't work on a few customers since there's approximately a 0% chance that the Microsoft reps aren't going to toss some discounts around to encourage it.
You'd have to rewrite the entire application to port it to another cloud provider.
It seems like only the new players will lower prices.
So they're raising prices.
But but but cloud prices only go down /s
Whenever reading these announcements, if price decrease isn't seen within the first few paragraphs (the earlier the better), it's basically them trying to explain away price increases for the vast majority.
The fact that they even have to try to argue/explain whether prices are decreasing/increasing is a worse sign.
> Cloud storage and multi-region replication and inter-region access are changing in pricing.
> The introduction of a lower cost option in archive snapshots for Persistent Disk pricing.
> New pricing for Load Balancing (to bring it in line with other providers. Read: very likely AWS pricing)
> A new price for Network Topology, now included in the price is Performance Dashboard and Network Intelligence Center.
All without what the new prices will be so based on the fact that it is several services with varying prices based on usage it could be a substantial change or not much at all.
Quite vague and unhelpful of a post by Google other than to give you a heads up to not be surprised about your bill in October.
> This page covers Cloud Storage pricing changes which will become effective on October 1, 2022. See the Pricing page for current prices.
Search for "increase" and you will find 15 results.
But I don't know if 100xing the free egress offsets all the doubling storage costs...
Judging by the comments here, I was right.
Sounds like a sneaky way to win some quick revenue because they know a huge number of customers are not going to be able to go back and re-engineer their storage use in time, so will end up out-of-pocket even while Google gets to pretend they are saving everyone money.
It seems particularly problematic to increase prices on anything to do with long term cold storage. That is where customers are placing the most trust in their vendor since much of this data is held for mandatory compliance reasons and retrieval costs are sufficient that it is completely infeasible to migrate out.
> Storage Transfer Service will be available free-of-cost for transfers within Cloud Storage, starting April 2 until the end of the year
Is this a loophole to get free retrieval of data from cold storage that we could exploit for other reasons?
Said Amazon never.
If you expect to use many terabytes of bandwidth, then it's time to rent a server or VPS and probably set up a torrent too.
It's probably worth setting up a cheap torrent-seeding server too.
I don't get why it's not just "easier" to make the effects super obvious. If people are going to leave, they're going to leave.
They are man-childs that during a lockdown can't even make a pot of coffee of their own, that work on "cool stuff".
I speak to different prospective and existing customers multiple times a week, sometimes multiple times a day, over chat, email, video conference and occasionally in-person (pre-pandemic).
I worked from home and made two pots of coffee today - one pour-over and one drip.
So, is GCP struggling for growth?
So I think it's more like: sorry guys, we ran an analysis and found that when we raise the price, most people won't migrate away and we make more money :]
If the price would be determined by costs, why would their cloud be multiple times more expensive than Hetzner.
The pandemic has global chip manufacturing, but left SSD and HDD untouched?
How?
If you’re not, however, things haven’t been so bad - Apple, AMD, Intel, etc. haven’t had the equivalent of those Teslas shipping with missing parts. There has been the pox of cryptocurrency’s ever higher demands for waste affecting GPU buyers but that looks like it’s far more an issue of demand than supply.
I'm not seeing that. In the last 2-3 years prices haven't changed much, when comparing drives of the same performance and warranty. And the best price per TB are still 1TB SSDs, large SSDs are still very expensive.
"Existing customers will see prices rise by 10% per year, because we know leaving is hard, and new customers will get a massive discount and loads of free credits. If you migrate in from Amazon we'll pay your final AWS bill for all the data transfer.".