I've used GCP in the past, including decisions on which cloud providers to use where we spent north of 1M USD/month.
Honestly Google's efforts are best focused on support issues like this and customer service rather than features to compete with AWS at the moment. A lot about GCP's setup is simpler and their network/hardware is well known to be better per dollar spent.
However, I've always found the ability to contact an AWS rep and work through a tough situation on billing/quotas to be much more convenient.
That often shifts the decision in Amazon's favor.
To be clear, this person seems to have reached Support (I'll know more if they reach out to me) but is probably mid-way through the "Are you sure you didn't do this?" or something particular to debit cards.
Enterprises don't have the same experience, because you don't use a credit/debit card to pay for $1M/month in anything :). As an Enterprise, you also have dedicated folks in sales and professional services working with you, and so on.
I don't disagree that Support and customer empathy are huge factors of what goes into picking a provider. We need to improve, likely more than other providers. We all hate knowing that if you happen to know someone at Google, you get better help.
But, tl;dr: GCP Support != Google consumer "support" and individuals on credit/debit cards != Enterprises.
I didn't mean for my response to be perceived as negative for GCP, was only hoping to inspire those at GCP to continue to focus on the customer experience rather than features. AWS certainly needs the competition and I've also had great experiences using Google's cloud platform.
The services that Google dropped were either big bets that ended up as massive failures in the marketplace (e.g. wave, google+) or services that were neither big nor strategic to google (e.g. google reader, google code).
GCP is neither.
If you're not convinced by the fact that Google has been pouring billions into Google Cloud for over 10 years now, organizes multi-day conferences promoting it, launches new features monthly, then no rational argument will convince you that they won't drop GCP because they also dropped google reader.
Sure. But this one little service inside GCP? Tiny.
I'm not the to make commitments but our history has been solid, and our deprecation policy is embedded in our terms of service for every Cloud user.
The only product I can remember us deprecating in GCP was Prediction API in favor of the much-preferred Cloud Machine Learning Engine, and with that came communication to every single affected admin and a _year_ before cut-off.
Unless one is twitter sized limiting ones exposure to googles arbitrary decisions is quite reasonable.
I can get a person to talk to at microsoft for my tiny account easy and I know neither they nor Amazon will just shut me down overnight.
It's not just the consumer side; Google doesn't exactly have a spotless reputation for developers, and assuming the post must be somebody faking being concerned for "Internet Cool Guy points" is just tone deaf.
Didn't they just 10x the price of Maps api calls recently?
Amazon has a bad track record when it comes to hardware products but hasn't had much volatility when it comes to services they offer.
It's reasonable for a company not to guarantee support timeframes during a beta program.
This is a very understandable concern, given the importance of having a platform on which you can rely.
Contractually Google Cloud provides a 1 year notice before discontinuing (or making backwards incompatible changes) to products. This is for generally available (GA) products. Cloud Run is in beta, so technically it could be decided not to bring it to GA. This is why some conservative orgs tend to wait for products to be GA before releasing them.
From a technical perspective, Cloud Run was designed to be highly portable and idiomatic. If the service were discontinued (or you just didn't like it), you should be able to take your container image, and run it anywhere else. Odds are you would be using some other Google Cloud Services, so you would likely want to run in an environment with low network latency to Google Cloud (Compute Engine and Kubernetes Engine being obvious candidates).
From a historical perspective, I'd say that Google Cloud goes above and beyond in supporting older products. App Engine is about to hit its 11th anniversary. We are still running PHP 5.5 apps and backporting security patches to the runtime, despite the language losing community support 3 years ago. We are still turning down an old product called "Managed Virtual Machines", which has now been in a deprecated (but running) state for longer than it was GA!
From an emotional perspective, I think that Google is eyed with a lot of suspicion for turning off products. Google Reader - enough said. But as someone on the thread pointed out, Google Cloud is a very different business from the rest of Google. Google (!cloud) is a consumer company at a scale where if a product matters when it hits a billion users. Google Cloud is an enterprise company. Scale still matters, but not in the same way it does in consumer.
I can't wait for hacker news folks to try Cloud Run. Its an awesome product.
Ah that's one reason not to use GCP betas. Another big one is the complete lack of any public uptime target. In my opinion, this makes the betas nearly as bad as alphas with respect to using them in production.
That's precisely the point: don't use Betas in production, unless you're okay with that. Do you have a suggestion on wording for the help text to reiterate that more clearly?
The background here is that a Beta product is still in flux. In particular, it might not be GA yet because it hasn't yet met its internal SLO for enough time, proving that it can consistently meet the SLO for its SLA.
While we could let products ship randomly, since SLAs "just" mean we pay you if we don't meet them, we choose not to. Customers expect that if a product says "this is our SLO/SLA" that we intend to hit that.
We hear you though; we don't like super long Beta durations any more than you do. Sometimes though, we reached Beta and didn't realize we hadn't met the quality bar we wanted.
We usually extend the deprecation timeline if a product is important or is hard to migrate.
Master/Slave datastore deprecation takes 3 years since the announcement of deprecation.
Python2.5, 4 years since deprecation announcement to fully deprecated.
Java 6 was officially deprecated in July 2017 but if you still have an app deployed in Java 6, chances are they can still serve traffic just fine. Same applies to Java 7 (this is partially due to JVM backward compatibility but there are non-trivial engineer works involved)
I hope this gives you some confidence in Google's cloud offering.
For all deprecated features of App Engine, you can see https://cloud.google.com/appengine/docs/deprecations/ (note alpha/beta features are deprecated in less than 1 year which is WAI)
The early access was based on a user account being added to an access list. But, I'm not sure why your team member had access without explicitly asking for it.