Maps is a consumer facing service for which revenue is derived from the data collected and advertising. That business model is nothing like selling commodity compute services to enterprises.
If anything, I think GSuite is a portent of how Google will treat GCP. That is, the set of products has been relatively and consistently stable for quite some time, which has driven fairly decent adoption into the enterprise market.
There've a couple of product shifts, specifically around voice, hangout, and chat, but that seems to settled at this point.
I speculate that the changes that have raised the most ire have been around gmail, which I suspect has a fragmented product management team as it's both a free consumer service getting monetized through ad revenue as well as an enterprise product sold directly to customers.
So selling access to an API that businesses depend on is nothing like selling access to other resources that businesses depend on?
https://gadgets.ndtv.com/apps/features/google-maps-apis-new-...
Prices have gone up as much as 14 times in certain scenarios
Selling access to the Google maps API is wholly superfluous to Google's business model. Certainly, it doesn't clock anywhere near a billion in revenue.
Prices have gone up because Google doesn't have any interest in sustaining the product. The total addressable market is miniscule by comparison to cloud or even enterprise productivity apps.
It doesn’t matter how large the “addressable market” is if Google doesn’t have the will or talent to compete. Social is also a large market, how did that work out for Google?
Isn’t that the entire pitch of every startup? “If we just get 10% of the market, we will be huge”.
And “revenue” is meaningless is GCP profitable? There was a submission on the front page of HN yesterday about Google’s management not being happy about how GCP waS doing and they have three years to turn it around or “lose funding”.
At worst, they'll sell off or divest the business entirely. They'll expose themselves to tremendous liability if they attempt to wind it down like their other properties.
On the other hand, AWS announced something as minor as that they were discontinuing one form of accessing publicly available S3 urls that was deprecated in 2010 for the newer one. After a vocal outcry from the internet about how many websites that it would break, they backtracked:
https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-...
On the otherhand, how many Urls were broken when Google discontinued it's link shorterning service?
Google has shown time and time again that it can't be relied upon for any important infrastructure.
Yes, it's true that Google capriciously kills products for various business reasons without any regard for customer sentiment. My counter-point to that is that GCP products exist under different conditions, specifically legal and business realities. They have contractual obligations to corporations with very large legal departments. There is also the business reality that if they're going to compete with AWS and Azure then to be competitive they have to behave in similar ways. If they piss on customer sentiment as they have with their b2c services, they'll fail and I think this is very clear to them.
That's not to say that they aren't already failing. As I mentioned up thread, their support is laughably bad and when pressed about that fact, they don't seem to actually acknowledge how that could be a problem.
Also the GCP panel is truly awful, much much worse than the AWS console.
However, their support is absolute shit and they're absolutely devoid of the customer first mentality that AWS demonstrates.
Doesn't matter what is the product. They're ready to kick GCP to the curb if it doesn't perform up to expectations. I wouldn't host anything important on it.
In the case of GCP, the product is the product rather than the user, so there's a greater expectation that it'll not get shut down or that pricing will change easily.
Further, they're obviously committed to being competitive with AWS which requires that they behave similarly.