[jrsdav]

I've done pretty extensive work in all three major cloud providers. If you were to ask me which one I'd use for a net new project, it would be GCP -- no question. Nearly all of their services I've used have been great with a feeling that they were purposefully engineered (BigQuery, GKE, GCE, Cloud Build, Cloud Run, Firebase, GCR, Dataflow, PubSub, Data Proc, Cloud SQL, goes on and on...). Not to mention almost every service has a Cloud API, which really goes a long way towards eliminating the firewall and helps you embrace the Zero Trust/BeyondCorp model. And BigQuery. I can't express enough how amazing BigQuery is. If you're not using GCP, it's worth going multi-cloud for BigQuery alone.

But there is something to be said of AWS. Their SDKs are complete and predictable, their APIs are very fast and consistent, and AWS IAM, while having a steep learning curve, never leaves you guessing around what your principals have access to. For me, the real challenge with AWS has been introducing multiple AWS accounts. Governance just flat out sucks when you begin to scale past a handful of accounts (but it is getting better).

Azure on the other hand, has terrible consistency issues between their APIs, their SDKs are awful, and it just feels like the entire product is an extension of the MCP System Administrator persona of old, where it's expected that someone's job will be sitting in front of a UI and clicking around to get things done (the whole blade thing with their portal has to be one of the worst user experiences I've ever seen). However, I do like their Logic Apps, and Azure Policy with auto remediation (when it works as advertised -- ref API consistency and how long it takes for things to propagate through their system) has tons of potential. But they still have a ways to go before I'd consider it for my workloads.

[skrebbel]

I love the idea of GCP but I can't shake the fear that one colleague, using the company Gmail account, posts something somewhere on the internet that Google's morality-du-jour considers unacceptable, and the Google AI Killbot disables our entire account, GCP included, ruining the business, with nobody to call, nothing to do, except tweet and post on HN and hope someone at Google listens.

I don't mean this as a flamebait hyperbole, this is truly the single thing that keeps from moving our business to GCP because, like you say, that BigQuery thing tastes sweet.

How do you deal with this? Is there any sort of guarantee with GCP that I missed where they promise not to do this?

[williamstein]

I've been using GCP since 2014 to run cocalc.com, and at some points in the past people have used it to launch attacks or mine bitcoin (we make that much more difficult now). Google did temporarily block or suspend our resources, but the experience was nothing like "nobody to call, nothing to do". Instead, Google contacts you immediately, and you message back and forth with real people who have the power to instantly fix things. In any case, in my experience the reality of being a GCP customer is not the same as the fear, uncertainty and doubt that you have.

[skrebbel]

That's great to hear, thanks!

It still appalls me how it's the norm these days for providers to first suspend service, and then ask questions (to the point that you describe it as a positive experience in an HN comment). But I think most big providers do that, ie it's not unique to GCP. And your experience is way better than my impression of Google (incl their paid services) so great to hear.

[boulos]

Disclosure: I work on Google Cloud.

I am not a lawyer, nor your lawyer, however the terms you're looking for are the Acceptable Use Policies for both Google Workspace (née GSuite) [1] and GCP [2].

Both Workspace and GCP offer support (start at cloud.google.com/support). The included Workspace support ("Standard Support") includes phone support and a "Four hour SLO for P1 Support cases".

So if one of your employees did somehow get flagged for violating the Acceptable Use Policy, there is phone support included that would let your resolve this. You can pay more for higher levels of support with shorter response times, dedicated representatives, and so on.

Edit to add: if you're really concerned (and some folks are, I get that), I've seen some organizations make a separate domain for production. I don't love the ergonomics of switching accounts like that, but it's also not the worst thing I've seen people do.

[1] https://workspace.google.com/terms/use_policy.html

[2] https://cloud.google.com/terms/aup

[bedatadriven]

Our service has depended on GCP/AppEngine for the last 8+ years. Our business depends on it and Google has proven to be reliable partner. We pay ~400/month for a support package and have always been able to get someone on the phone.

The only time we've ever really needed it was when one of our customer's (satellite) IPs was once flagged incorrectly as originating from Cuba and blocked because of sanctions. We reached an engineer via phone support and they were able to get the Google team responsible for their Geo IP database to correct the entry.

We've also had support engineers based locally call us to check in periodically, and I doubt we are in the top 10% of their customers by spend.

Definitely would recommend GCP without reservation.

[antonvs]

I haven't encountered that situation but we use GCP and use their support: https://cloud.google.com/support

We can easily get a Google person on the phone when we need to, so I wouldn't be terribly concerned about this scenario since we have a relationship, a contact route, and (possibly) some kind of contractual accountability.

[theptip]

Echoing this. GCP support is responsive and fairly effective. It’s a bit expensive, but that is a different matter.

This comes up on HN periodically, and I think folks have very mistaken assumptions about GCP based on Google’s reputation for poor or non-existent support on free consumer-facing services like gmail; GCP and Gsuite are very much serious enterprise services.

[skrebbel]

I can't find the links back, but there's been stories on HN about paid GCP accounts being blocked because of actions taken in connected GSuite accounts (or GMail? ie the mail was free but the GCP was paid? Can't recall) that Google's automation deemed malicious.

Surely the consumer stories are much more prevalent, but to my memory it's not only been that.

[theptip]

I’m sure someone has been taken down in this way on GCP, and if you’re on AWS you could get taken down like this too (see Parler). It’s really hard to quantify the risk here but my priors are that if you are a normal business that is not doing anything illegal then the risk is vanishingly small, and that GCP is not worse than AWS.

I think that building on a cloud platform (or other SaaS like an Oracle DB) and getting your license cost increased is a much bigger business risk.

Either way building your system to be easy to lift and shift to another provider (or on prem) has merit to hedge against these risks, but it also slows you down.

[antonvs]

> Either way building your system to be easy to lift and shift to another provider (or on prem) has merit to hedge against these risks, but it also slows you down.

Not necessarily. Kubernetes is a great way to hedge against that. You can write fully cloud-native autoscaling apps that have minimal dependencies on the hosting environment.

[gundmc]

This story was debunked/refuted:

https://old.reddit.com/r/google/comments/8l231x/google_banne...

[wmf]

A paid account != a Production or Premium support account, though.

[deathanatos]

In every cloud provider I've used, filing a support ticket was done from within their web UI. And that meant logging in.

If Google bans your org for unknown/nebulous reasons, and you're not able to log in, can you get to those support channels?

[antonvs]

We have email addresses and phone numbers we can call, so yes. Phone support is available on any of the paid support options.

[AlchemistCamp]

Agreed, I've lost both a Gmail account and a YT account to Google's "acceptable bug rate" coupled with nearly fully automated support.

In both cases, the problem arose not from my behavior but from their merging, splitting and changing their product offerings. As dependent as I am on Google personally, I couldn't in good conscience tie a business to their whims if there were any reasonable alternative.

In terms of search and video as marketing channels, they've pretty much got a monopoly. In cloud services, there's more choice.

[forty]

We don't use GCP a lot, but just a note: it's possible to login to GCP using your SSO rather than gmail addresses. I guess it would limit the risk you are worried about.

[pmontra]

You shouldn't share one single company account across the team. Everybody should have their own account, of course on the company domain, and use that one.

Advantages

1. You know who does what.

2. If Google bans an account the others keep working.

3. Permissions per employee, because not everyone need to to everything.

4. If an account is compromised, you ban the account.

5. When an employee leaves, you ban the account instead of changing the password.

6. N people sharing a common password on an account nobody has particular responsibility for, ouch.

[tomnipotent]

> You shouldn't share one single company account across the team

No one said anything about using a single account.

> Everybody should have their own account

This is moot if your company uses GSuite. The concern is that if a GSuite account is linked to a GCP account, and suspicious activity happens on Google Apps that it can result in interruption to GCP (and vice versa).

[renewiltord]

I definitely use a separate google account for all of this. The support for it is pretty good and I don't see why one would ever use a personal account.

[jacques_chester]

This risk exists for other providers. Corey Quinn calls it the "underpants problem".

https://twitter.com/quinnypig/status/1120780385460391939

[mhh__]

I would still be more worried about Google canning the service you're using.

The "shout at it on HN until it gets fixed" customer service is awful, but I don't think they're going to hurt their bottom line like that - and besides, if you have (for the sake of argument) someone spouting wrongthink on the company account you're really playing with fire in the first place.

[Thaxll]

There are no proof / example whatsoever that GCP is related to other Google products. I've never heard or seen my GCP account was shutdown because Youtube / gmail / google account etc ...

[pratio]

Azure UI, Flows almost everything feels half baked. They have this weird segue like UX in some places where trying to go back to a previous screen feels like moving a big picture around, it annoys me so much, The best thing that we found with Azure was using Azure AD, works as advertised and the SSO integration was smooth.

I still prefer AWS services like S3 because they're predictable and I've yet to run into an issue which AWS support wasn't able to solve.

[techlatest_net]

I completely second this. We publish VM solutions in all the three marketplaces and find GCP the best as a partner and as a customer. The VMs spin in seconds , cost is the lowest for most of the common services and the web console is fast and does not have the clutter like that of AWS or Azure.

Ever since they got Thomas Kurien as new CEO, there is more focus on the marketing and partnering outside of US & Europe. The recent deal with ARAMCO to setup data center in KSA reflects this.

From a customer base perspective, our experience is that GCP has more developer & startup focused customer base, Azure has more enterprise crowd where as AWS is a good mix of every one.

[dmitriid]

I can kinda agree on GCP with one exception: Dataflow. I have no idea what the future holds for it.

It is a managed Apache Beam service and is very useful for certain scenarios (like "hey, we have a million incoming PubSub messages that we need to transform into a dozen different branching streams of data"). It looks like even BigQuery actually transforms SQL statements into a bunch of Dataflow jobs.

But...

But...

- Minor version updates to Google Dataflow SDK once every couple of months while deprecating most other minor versions? Check.

- No visible contributions to Apache BEAM itself? Check. In 2021 I still don't know if I can use any Java versions beyond Java 8 to develop for and run in Dataflow. And Google is arguably one of the biggest users of Apache BEAm, and definitely a user with the largest pile of money to throw at the problem.

- They've recently sent out a questionnaire about Dataflow to some of their customers that feels like a "hey, we're definitely considering deprecating this, we're gauging the potential impact"

[boulos]

Disclosure: I work on Google Cloud (and with the Dataflow folks on occasion).

Sorry, if you're getting mixed messages. Dataflow is here to stay. Google, Spotify, Twitter, and many other large customers heavily depend on it. Twitter moved their entire ad revenue pipeline to it [1] last year.

A quick perusal though of https://github.com/apache/beam/commits/master shows decent Googler activity. Can you highlight where you were looking for "no visible contributions"? (Maybe we do a bad job of being visible?).

[1] https://cloud.google.com/blog/products/data-analytics/modern...

[runT1ME]

Interesting comment, definitely want to hear more. I have concerns about Beam/Dataflow, but they seem different to yours.

The dataflow product seems to run older versions of Apache Beam just fine, so minor deprecations don’t seem like an issue in practice, but maybe I’m mistaken.

“No visible contributions to Apache BEAM itself”. I don’t think this is true, I’m a contributor and somewhat active on the developer mailing list, it seems the majority of the contributions these days come from google employees.

If the questionnaire you’re referring to was the paid Apache Beam survey, I participated and definitely didn’t get the impression that they were considering deprecating the service. It was much more focused on how they can improve docs, examples, and help developers use it.

Now, I think the project is too ambitious even for google. They don’t need to support Spark/Dataflow/Flink on three different languages (java/python/go) imo. I’m also frustrated with some of the bugs that slip through.

The fact that there is no back pressure support for a streaming framework is such a google thing to do: why worry about back pressure if you can just tell another team to increase their throughput for downstream sinks? /s

Dataflow does seem to be one of GCP’s most popular services (spotify and twitter are both users now) so I would guess it is here to stay in some form.

[ignoramous]

And GCP's Director of Outbound Product Management saying things like, "I’ve been thinking about the cool ways @GCPcloud reinvented public cloud... Sometimes you have to leave the past behind, and we haven’t hesitated to re:tire services and features. HIYOOOOO! We’re getting better though :)" doesn't really inspire any confidence either.

[0] https://archive.is/l6s5Q

[antonvs]

I love Dataflow, but share the same concerns. It feels like something that's going to die of neglect even if it's not intentional.

[GordonS]

I mainly use work with Azure, but have worked with AWS too, and not yet with GCP. I'm a bit fan of Azure - the service on offer and the tooling.

Azure's UI is unusual, polarising even - you either love it or hate it, but I'm more on the "love it" side. When it was first released some years ago, it had some perf problems, but it got over those long ago. In use, I find it to be a really good UX - not sure I ever recall swearing at it because it was in my way :) I like that it has themes (e.g. dark mode), and for the most part, I also find it far more consistent than the AWS UI, which often feels like it's been cobbled together by several different teams. I also find the AWS UI feels pretty "clunky" and dated. And in terms of cost management, Azure is way more transparent and useful than AWS.

Regarding SDKs, not sure if you were really thinking of a single service in particular or more generally, but assuming the latter, I mostly disagree about Azure's SDKs. Some of the SDKs have had too much churn for my liking, and the docs don't always keep pace with those changes. In general though, I find them really good.

I'm not a huge fan of ARM templates for anything but the simplest deployments, but they get the job done. Bicep[0] shows MS are improving things, and there are a couple of nice OSS alternatives now, like Farmer[1].

I'm not a big fan of PowerShell in any form, but it's cross-platform, and I use it on occasion for Azure automation, and again it gets the job done without issues.

Azure CLI, I really like - it's OSS, cross-platform, and covers pretty much all services. Extensions/plugins mean that even new services are covered quickly. The syntax and commands are very consistent (there are a few exceptions, of course), and being able to output results in either JSON or CSV is great for parsing from the likes of Bash scripts. Also like the way you can filter and project output, without the need for something like jq.

Don't recall a single instance of something I could do in the UI but not via automation; aside from monitoring, cost reporting and quickly deploying throw-away stuff during dev, I don't feel compelled to use the UI.

[0] https://github.com/Azure/bicep

[1] https://compositionalit.github.io/farmer/

[wdb]

My mine gripe with GCP is that most projects don't have any examples or support how to use it on GCP compared to the always AWS examples. That's always a bit of a bummer

[mxz3000]

Working with multiple AWS accounts is definitely a pain, but it definitely should get better in the future given that it's a super important use case for internal services.

Internally we have best practices that dictate to split services into their own accounts, with one account per stage (i.e. beta, gamma, prod).

I'd like to also mention that CDK also makes working with cross-account/cross-stack resources a lot easier.

[jvolkman]

Those internal policies have been in place for at least 6-7 years and multi-account still sucks.

[foobiekr]

GCP's potential for product abandonment and their terrible customer support are their primary weaknesses. And then there's the issues well-described in [1].

[1] https://medium.com/@steve.yegge/dear-google-cloud-your-depre...

[nojvek]

I’ve used GCP and I quite like it. However I would not recommend betting big on it. GCP as an extension of google has the same problems, they are way too big to care about small companies. They change their minds every now and then without upfront notice and kill things or deprecate them. Support is hard to reach.

In any case, think for your own self what you care about. There are tradeoffs of each cloud providers. I’ve found AWS provided me with a human touch and cares about my problems. Never quite used Azure (their portal is too complex).

In my mind, Google’s gonna be Google. They value automation and algorithms over human touch. It’s in their DNA. It’s what their hire for.

[jordanbeiber]

I can only agree - Azure is a mess in a lot of ways when you try to automate it as an IaaS. They seem to have some sort of pattern issues in regards to UI and async API operations, and it bites you often enough to drive you crazy when automating.

I've had API calls fail because an Azure portal tab was open in my browser obviously locking or otherwise interfering with API operations until the I close, what looks like, a completely idle tab.

Also... dog slow provisioning compared to the "other two".

[mlthoughts2018]

I also have significant experience in all 3 and I couldn’t disagree more. GCP support & documentation alone is a dramatic reason to avoid GCP. GCS CLI utilities are supposed to be S3 API-compatible, but they are not. GCP keyfile-based access is a horrid anti-pattern, but the rules for human IAM user vs service account vs impersonation are not uniform across all products (eg, if you need developers to have ad hoc non-console access to both GCE VMs and Dataproc clusters, you have to manage two very different approaches to identity-based access).

GCP’s region-level SLA are poor for most products and over a window of a few years, they don’t actually meet their region SLAs. GCP has all kinds of nasty legalese about “beta” features that aren’t supported by the SLAs, and if you use them, you forfeit your right to claim credits after SLA-violating outages. For GKE in particular, Google’s rules basically exclude every aspect of Kubernetes you need to actually use it in production, which is a blatant attempt to force users into Anthos.

In machine learning in particular, GCP has horrible offerings that are massively over-priced and/or are 100% hype-driven (TPUs are a good example, but also things like running Kubeflow or Feast).

Google Cloud Functions and Google Cloud Run have such severe limitations to resource sizing, especially memory, that they are irrelevant, whereas by comparison Fargate is excellent for ML workloads. There really is no equivalent in GCP, since Cloud Run can’t handle large Docker containers needing high RAM, so you’ll just be rerouted to GKE where because of the SLA legalese you can’t actually use any of the tools you want. And then on top of this, configuring any type of hybrid open internet / internal data center service with Cloud Functions or Cloud Run is miserable. You need a full Networking team just solely to manage Cloud Function or Cloud Run service access, it is absolutely nowhere close to self-service for normal backend teams.

GCP is a miserable, miserable choice for cloud vendor. It is typically chosen solely due to being cheap in the short term and allowing bulk deals on GSuite, Ads credits and other deal sweeteners. It’s so stupid to choose GCP for these short-term deals, because Google absolutely will lock you in and raise prices for their garbage tools and poor customer service.

For my money both Azure and AWS are still lightyears ahead of GCP and I would gladly pay a premium to use either just to avoid GCP.

[theptip]

> For GKE in particular, Google’s rules basically exclude every aspect of Kubernetes you need to actually use it in production

I’ve been using GKE in prod for ~4 years, and have never needed beta features. What beta features do you think are required?

I’ve also always been able to assign permissions to a user, group, or service account. When have you not been able to do so?

[mlthoughts2018]

I think you are probably confused. There are many beta features in Kubernetes and they are enabled by default. For a long time, very critical features could remain beta for years, such as all of Ingress and all of CronJob.

- https://kubernetes.io/blog/2020/08/21/moving-forward-from-be...

One of the big issues with the GKE SLA is that your organization must only consume Kubernetes from the Stable channel, but given the large amount of enabled-by-default, critical beta features, many (probably most) production deployments of Kubernetes rely on non-stable channels intentionally for the sake of critical beta features that have been de facto production features. In my company for example, we must run a slightly older version of Kubernetes and upgrades are very slow, so we are way behind the stable channel with no way to upgrade fast unless the stable channel supports all sorts of enabled-by-default beta features and older versions. So we could never run a hybrid cloud with GKE, it would violate the SLA restrictions from first principles. This has created a nasty, painful rift in my org between the on-prem Kubernetes and the cloud (essentially useless) GKE Kubernetes.

Beyond this there are other features that are critical and uncovered, like multi-region ingress for example. We operate some very very large data ingestion services for customers and we absolutely need a higher SLA uptime on it than what a single region offers in GCP. So we have to operate multi-region ingress, but all of the non-Anthos solutions are no longer supported by GCP, and void out the individual region SLAs. It’s madness.

On top of all this, Google does not actually publish clear lists of features that are or are not covered by the SLA. The way it’s worded relies solely on the Kubernetes alpha / beta / GA channels, but nothing actually ties Google legally to that. They can arbitrarily define the SLA terms to mean whatever they want it to mean at any time. While you likely can’t avoid a cloud provider with that freedom, at least you could expect them to actually publish and document it.

> I’ve also always been able to assign permissions to a user, group, or service account. When have you not been able to do so?

Please check again in my comment. I mentioned specific examples (user-based, not service account-based, workflows in Dataproc, for example), where it’s not possible in GCP, as in the product itself disallows it. It’s not an issue of me or you or anyone being able to create IAM policy or service accounts. It’s an issue that different products within GCP fundamentally disallow some auth workflows (like Dataproc cluster creation being fundamentally disallowed for user-based auth workflows) that then force you to manage multiple different auth flow patterns even within the same user workflow (for example, user-based auth flows for GCE VMs but impersonating service accounts for the exact same steps for a Dataproc cluster), leading to much more overhead, more inscrutable errors, more round trips through security approval. The issue is the poorness of the product design, not some general inability for a user to figure out a service account.

[theptip]

I was assuming you meant GKE beta features, not k8s beta, since the latter is ridiculous, can you point me to the bit of the SLA you’re referring to here?

[znpy]

Not a GCP user myself, but I've read a lot of stories about GCP deprecating products at a very fast rates (as google does with the general public).

I don't know if I'd be okay with this? Once a project is done I wouldn't want to do any re-engineering that's not strictly needed (and outside general maintenance).

[andreilys]

How long do you reckon before google shuts down GCP?

I suppose that’s part of the gamble when you bet on them.

[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.

[rootusrootus]

> I suppose that’s part of the gamble when you bet on them.

That or they just shut down your GCP.

Lack of a real, responsive support channel is what keeps me from spending money for Google services.

[antonvs]

We use GCP and have a real, responsive support channel. See https://cloud.google.com/support .

Are you saying lack of a responsive free support channel?

[renewiltord]

This is such an unlikely event. Anyone with any knowledge of the cloud space would declare this nigh impossible.