[antonvs]

You're understandably thinking of Google's track record with many of its other products that were discontinued. However, most of those products were "free" to the user, and as such Google had no real obligation to its customers.

GCP is a very different kind of product. Customers pay for it directly, and often their business depends on it. It's covered by all sorts of contractual agreements, including service level agreements. It's backed by a great deal of physical hardware around the world that Google wouldn't otherwise need. Its revenue is growing fast, currently over $12 billion/year. That's revenue from customers paying it directly. In Q2 2020 it had 43% growth, even though Alphabet had its first quarterly revenue drop.

It's not the kind of thing they're going to dump on a whim, and if they did decide to exit that space, it would most likely be by letting another company acquire it, since it would be hugely expensive to just drop it.

[temp667]

Tell that to folks building on the paid maps API's.

I don't think AWS has every really screwed anyone. My simpleDB kept running long after I even remembered it used simpledb! I can't even remember a price increase, much less a 10X gotcha one with no grandfathering! Ouch!

Google will kill your account, change pricing etc much more commonly than AWS. The nightmare of google+ and being forced to jam a profile onto everything - they give two sh** about user stability / happiness on some things if the command comes down to blow the house up which it seems to periodically.

[antonvs]

Google Maps API is still not a comparable kind of business. And Google+ is completely irrelevant.

> I don't think AWS has every really screwed anyone.

The apples-to-apples comparison is not to AWS, but to Amazon. There are plenty of complaints against Amazon for ways they've screwed shoppers, book authors, publishers, etc.

If you want to compare Google Cloud to AWS, you won't have nearly as much to complain about.

It's perfectly reasonable to say you don't want to deal with or depend on Google because they've screwed you in the past. But the claim that there's a serious risk that GCP will suddenly be discontinued is just silly.

[trhway]

>But when we looked at performance on the 16-core benchmark, none of the winning machines ran Intel processors. In fact, the AWS custom-built Graviton2 Processor, which uses a 64-bit ARM architecture, edged out GCP and Azure’s winning machines, both of which ran AMD processors.

Google/GCP plays catch-up, and while GCP has been coming to the level of AWS on services, the AWS already gets new CPU platform, and Google doesn't have ARM thus leaving GCP several years behind - this will become pretty clear in the coming years. With ARM beating x86 on performance and power AWS can undercut - typical AMZN/Bezos - the GCP on price or use the extra margin to expand and finance even more R&D of AWS. I also think that Apple with M1 will become a huge cloud player, at least for various mobile apps, etc. ie. encroaching into GCP market, while not necessarily into enterprise market of AWS nor Azure. That way the GCP will be squeezed from all sides.

>Its revenue is growing fast, currently over $12 billion/year.

The tough question here for GCP is whether that revenue is supporting the R&D to match the R&D of AWS and Azure (and probably Apple in the coming years), especially the investment required to get their own ARM. If i remember correctly Google gave GCP till 2023 to become a leader comparable to AWS or something like this. I think they wouldn't reach the goal, and as result Google will start counting money when it comes to GCP and will just drop GCP from the top priorities, and the GCP will just linger lagging behind more and more.

[antonvs]

You're addressing a different question from what was being discussed. Even if GCP "lingers lagging behind more and more," that gives users plenty of opportunity to move, they won't suddenly find themselves without a provider.

Given Google's stated commitment to their cloud business (see e.g. https://www.cnbc.com/2020/10/29/google-wants-to-show-how-ser... ), even if their efforts fail it's likely to take many years before anything like that is remotely an issue for customers. "But we might need to migrate in 5-10 years" is not a very persuasive argument for most businesses, for good reasons. Note that GCP is already 13 years old.

I do advise people to keep an eye on their dependencies on a particular provider, since moving providers can be needed for all sorts of reasons, not just the death of a provider. Luckily there are all sorts of tools and approaches to doing this. I've been involved in migrations between all the major providers, and concern about the provider's future wasn't an issue in any of those cases.

[trhway]

>gives users plenty of opportunity to move, they won't suddenly find themselves without a provider.

in some sense what i describe is worse than just sudden (i.e. a 1 year like notice which is pretty sudden in the enterprise time scales) death of a provider as the customers will be "slowly boiled like that frog" not feeling urgency to move at any given time while the platform will be falling behind and into more neglect.

>concern about the provider's future

it is concerns about provider's ability and, most important, willingness to support (i.e. to invest in) the state-of-the-art of the platform in the years to come. There is no such doubts about AWS nor Azure. It is too unfortunate for GCP that ARM popped these couple of years - Google has to decide right now and that is already pretty late whether they are going to invest a bunch of billions in having [competitive] ARM in the GCP. It is not just a matter of getting an ARM license and printing the chips, it is whole stack optimization to get those "40% faster at 20% cheaper" (as claimed by AMZN and with such improvements even native platforms of large slow BigCo-s like ours will probably move to support ARM while x86 will become more like PowerPC "supported too"). I think the Google management wouldn't risk venturing into ARM, at least not to the scale needed.