Hacker News Reader

Comment by noahl | Hacker News Reader

The trouble is that if you have to understand or correctly guess internal Google politics like this in order to know which products you can really rely on, then it's effectively not reliable.

With that said, I'd feel fine relying on VMs, disks, managed SQL, managed Kubernetes, etc. Maybe I'm too optimistic. And Google is giving exactly the guarantees they promised - 1 year of notice before shutting down a product.

View on HN

> And Google is giving exactly the guarantees they promised - 1 year of notice before shutting down a product.

This is mostly true, but a bit more nuanced than one might think. Let's take the Go 1.9 runtime for App Engine. It was deprecated on June 27, 2019. [1] Existing deployments will keep working for an undetermined time, however new deployments won't be accepted starting October 1, 2019. That's just a 3 month notice! The offered solution is to migrate to Go 1.11 [2], however that's not straightforward either, because the Go 1.11 runtime is using 2nd generation App Engine, which means a bunch of App Engine specific code that you had working before will need to be rewritten. To make things even more spicy there's already a migration path to Go 1.12 which deprecates every single App Engine specific API. [3] Google is basically slowly shutting down the whole 1st generation App Engine.

[1] https://cloud.google.com/appengine/docs/standard/go/release-...

[2] https://cloud.google.com/appengine/docs/standard/go111/go-di...

[3] https://cloud.google.com/appengine/docs/standard/go112/go-di...

Note: I work on App Engine. Go 1.11 supports all legacy 1st generation APIs. It's in the first section of the doc [2] that you posted although perhaps we can make this even clearer. We maintained support for these APIs precisely to make this migration extremely straightforward for our existing users as we moved to a more modern underlying technology stack and a version of Go supported by the language community. We absolutely want App Engine to be a place you can confidently build a business upon.

Was this done proactively or reactively after many months of negative feedback? If it was the former that gives me a lot more faith in app engine after trialing in some years ago and giving up on it.

Proactively. It was in the initial email about the Go 1.9 turndown sent to users. We definitely understand that any code change is painful, no matter how trivial. Supporting legacy APIs on a modern Go runtime seemed like the right balance between keeping up with the language community while bringing along our existing users.

And if Google finally figures out that they're slowly re-implementing half of Erlang, badly, then half of this could evaporate within a couple years.

(Given their history I'd expect it's more likely they build their own BEAM and put a new language on top of it)

Is there Takeout or equivalent for all your VM configs and persistent disks? How hard is it to flip between Google and AWS and back?

Reply on news.ycombinator.com