Hacker News new | past | comments | ask | show | jobs | submit login

Hi. I manage App Engine (the original "serverless" product at Google).

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.

Disclaimer: I work for Google on App Engine.

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)

This is a great answer. Thanks for being thorough and up front with your responses

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.

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.

Disclosure: I work on Google Cloud.

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.

Really depends our your capacity for risk. If you're a small startup team, getting the benefit of automatic scaling with extremely little management overhead (especially compared to something like Kubernetes) could be worth the lack of explicit uptime SLAs.

Hey Matt, Please bring Ruby to App Engine standard! Thanks :).

Spoiler alert. Sign up for the alpha by requesting to join this Google Group: https://groups.google.com/forum/#!forum/appengine-standard-r...

Matt & Mike, so excited! Gonna check out the session and sign up for the alpha!!!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact