Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Cloud Prediction API End of Life

cloud.google.com

Post reply on HN
Print view View original

91–100 of 124 posts

Re: Google Cloud Prediction API End of Life

#91

Post by vgt »

saurik wrote: post #83
vgt wrote: post #77

Earlier quoted context omitted.

Let me respectfully rephrase your argument. Despite parent's logical argument and evidence, and despite further evidence that Google doesn't really shut down Enterprise services at industry-irregular rates, market narrative has been defined (mostly by Readergate), and you are more inclined to accept said narrative? Alternatively, is there sufficient evidence beyond "market narrative" and Readergate that has allowed y…

> ...mostly by Readergate... Oh, come on... seriously? This argument is trotted out every single time Google shuts down something: "you are still upset about Google Reader". No: we are upset about all of those other things that get shut down, and people from Google shifting blame to Reader over and over and over again is nonsensical at this point: there are so many many examples of things being shut down, and Reader…

I appreciate your passion.

My argument isn't that Google doesn't shut down B2B services. It's that I have seen no evidence that Google does it at a vastly outlying rate relative to the industry.

IANAL, but Both AWS [0] and Azure [1] have 12-month deprecation policies - this is industry standard, as mentioned in the Google Developers blog you link.

[0] https://aws.amazon.com/agreement/

[1] https://azure.microsoft.com/en-us/support/legal/subscription...

(work at G)

Re: Google Cloud Prediction API End of Life

#92

Post by compumike »

boulos wrote: post #62

This shutdown had an incredibly healthy discussion internally. The reality is that this service had been unmaintained for a long while, but we'd previously chosen not to start this deprecation process until we had a GA service we could actually have someone migrate to (Cloud ML Engine). Additionally, it turns out that very few people were using it. That's not an excuse, but the reality of ongoing investment. I fought…

You (and the other commenter from Google Cloud team) do not seem to have compassion for the fact that migrating application code is very expensive.

1. Take a talented, valuable developer off whatever important task they're working on now.

2. Get them review whatever changes have supposedly been made between old version and current version.

3. Get them to read the existing code and think about places where it may break. (Often not obvious.)

4. Deal with doing the upgrade, which may often have dependencies that can break other unrelated things.

5. Write whatever code needed to make changes. (Often not obvious.)

6. Test on some sort of staging setup, which was probably written by some other person a while ago and may or may not have adequate coverage for this specific feature (since it was already working!!!).

7. Deploy and test in production.

8. Hope and pray nothing breaks.

All of that work (time and $$$) must be done to achieve ZERO benefit for your customer. High cost! Zero benefit! That makes developers (and founders) angry.

1 year deprecation is insanely short for public-facing infrastructure APIs. We should be talking about 10 years.

Re: Google Cloud Prediction API End of Life

#93

Post by technofiend »

boulos wrote: post #62

This shutdown had an incredibly healthy discussion internally. The reality is that this service had been unmaintained for a long while, but we'd previously chosen not to start this deprecation process until we had a GA service we could actually have someone migrate to (Cloud ML Engine). Additionally, it turns out that very few people were using it. That's not an excuse, but the reality of ongoing investment. I fought…

Kudos for giving people a year to migrate! I know you're getting drubbed by some for the forced migration, but a year is more than generous, particularly if indeed most of your customers are hobbyists anyway.

Re: Google Cloud Prediction API End of Life

#94

Post by aub3bhat »

CobrastanJorji wrote: post #52
aub3bhat wrote: post #2

I think Google just made job of some sales manager at AWS Rekognition way easier.

You may be confusing the Google Cloud Vision API with the Google Cloud Prediction API.

I know they are different, but Google needs to realize their approach to consumer products does not transfers well to cloud computing.

Re: Google Cloud Prediction API End of Life

#95

Post by jdc0589 »

compumike wrote: post #92
boulos wrote: post #62

This shutdown had an incredibly healthy discussion internally. The reality is that this service had been unmaintained for a long while, but we'd previously chosen not to start this deprecation process until we had a GA service we could actually have someone migrate to (Cloud ML Engine). Additionally, it turns out that very few people were using it. That's not an excuse, but the reality of ongoing investment. I fought…

You (and the other commenter from Google Cloud team) do not seem to have compassion for the fact that migrating application code is very expensive. 1. Take a talented, valuable developer off whatever important task they're working on now. 2. Get them review whatever changes have supposedly been made between old version and current version. 3. Get them to read the existing code and think about places where it may brea…

> 1 year deprecation is insanely short for public-facing infrastructure APIs. We should be talking about 10 years.

Thats a little extreme.

Re: Google Cloud Prediction API End of Life

#96

Post by boulos »

saurik wrote: post #76
FmrAMZN_TA wrote: post #72

Earlier quoted context omitted.

I think this is disingenuous. AWS keeps something running forever, that's true, but in what state? https://forums.aws.amazon.com/thread.jspa?threadID=121711 (We were well aware of this thread, and others like it, internally) Something that exists, but has absolutely no investment and unknown support is probably not a great thing. Given that EC2's recent outage was because they hadn't restarted their services in a lon…

As a big and long time user of AWS I thought it was pretty obvious that SimpleDB was deprecated when DynamoDB came out, and am surprised you think it is somehow bad to maintain a service in a "zombie" state is somehow worse than killing it... the way AWS plays this allows customers using the service to decide to move to a new service because it is better or cheaper, and on their own time scale (!), rather than being…

See my new comment at https://news.ycombinator.com/item?id=14344415 (I'm on a plane, so late to the party). I'm disappointed in this particular service deprecation, but your broader point applies regardless of the specific service: once you start using several, there's the potential for burning a lot of your engineering budget just rewriting and retooling.

On a meta level, I've seen an incredibly high number of risk averse companies just using EC2/S3 or GCE/GCS. That's not to say I disagree with using tons of services (that's how you get value!), but it's clearly food for thought.

I'd love to see historical data on the various cloud service turndowns, though I suspect there's too little track record to draw meaningful conclusions (and for some folks, abandonware is just as bad as turndown).

[Edit for disclosure since I wasn't in this thread before]

Disclosure: I work on Google Cloud.

Re: Google Cloud Prediction API End of Life

#97

Post by macspoofing »

compumike wrote: post #92
boulos wrote: post #62

This shutdown had an incredibly healthy discussion internally. The reality is that this service had been unmaintained for a long while, but we'd previously chosen not to start this deprecation process until we had a GA service we could actually have someone migrate to (Cloud ML Engine). Additionally, it turns out that very few people were using it. That's not an excuse, but the reality of ongoing investment. I fought…

You (and the other commenter from Google Cloud team) do not seem to have compassion for the fact that migrating application code is very expensive. 1. Take a talented, valuable developer off whatever important task they're working on now. 2. Get them review whatever changes have supposedly been made between old version and current version. 3. Get them to read the existing code and think about places where it may brea…

On the other hand, that's the reality of software development and should already be priced in. WannaCry was so painful because WinXP and Server 2003 were still in operation, and I bet that was because there were applications that just couldn't be migrated away.

Re: Google Cloud Prediction API End of Life

#98

Post by compumike »

jdc0589 wrote: post #95
compumike wrote: post #92

Earlier quoted context omitted.

You (and the other commenter from Google Cloud team) do not seem to have compassion for the fact that migrating application code is very expensive. 1. Take a talented, valuable developer off whatever important task they're working on now. 2. Get them review whatever changes have supposedly been made between old version and current version. 3. Get them to read the existing code and think about places where it may brea…

> 1 year deprecation is insanely short for public-facing infrastructure APIs. We should be talking about 10 years. Thats a little extreme.

5 years ago was 2012. Do you have code written in 2012 still in production? Almost certainly.

10 years ago was 2007. So you have code written in 2007 still in production? Less likely, but I bet there are enough "yes" answers out there.

Re: Google Cloud Prediction API End of Life

#99

Post by compumike »

macspoofing wrote: post #97
compumike wrote: post #92

Earlier quoted context omitted.

You (and the other commenter from Google Cloud team) do not seem to have compassion for the fact that migrating application code is very expensive. 1. Take a talented, valuable developer off whatever important task they're working on now. 2. Get them review whatever changes have supposedly been made between old version and current version. 3. Get them to read the existing code and think about places where it may brea…

On the other hand, that's the reality of software development and should already be priced in. WannaCry was so painful because WinXP and Server 2003 were still in operation, and I bet that was because there were applications that just couldn't be migrated away.

Sure. But are you going to choose API provider "A" with a history of keeping stable APIs working 10+ years, or API provider "B" which can and does change stuff every year? What's your expected maintenance cost over the lifetime of the service?

Re: Google Cloud Prediction API End of Life

#100

Post by jfoster »

vgt wrote: post #77
tuna-piano wrote: post #70

Earlier quoted context omitted.

How much does Google Cloud spend on marketing and sales of its services, how much business do they lose from companies who believe that Google could shut down their services in a few years? How much would they have spent on maintaining this service? I can tell you, from my experience at mid-market size non-tech clients looking to move to the cloud, that Google's reputation for shutting down services is known and is a…

Let me respectfully rephrase your argument. Despite parent's logical argument and evidence, and despite further evidence that Google doesn't really shut down Enterprise services at industry-irregular rates, market narrative has been defined (mostly by Readergate), and you are more inclined to accept said narrative? Alternatively, is there sufficient evidence beyond "market narrative" and Readergate that has allowed y…

I was using Google Wallet for the web. Not a huge number of subscribers, but substantial. Google shut it down with no migration path or notification to Wallet customers. Actually, it still seems to be running, but only for use with Google. (eg. Buying Google Drive storage)

I don't hold too much of a grudge about it, but it has shaped my perception of Google services. Except for the extremely established ones, the possibility of an early shutdown should be factored in before choosing to go with a Google service.

Post reply on HN