Live data from Hacker News

Google Cloud Prediction API End of Life

cloud.google.com

111–120 of 124 posts

Re: Google Cloud Prediction API End of Life

#111
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…

Just out of curiosity, is this API used inside Google at all?

I ask because it would probably be pretty tough to deprecate this API if it was being used widely internally too.

Re: Google Cloud Prediction API End of Life

#112
post #77

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…

You've picked a tricky occasion for making this argument. AWS haven't announced that they're shutting down anything today, but the same can't be said for Google Cloud.

Re: Google Cloud Prediction API End of Life

#113
The discussion seems to have pretty well settled on Google's policies around service deprecation, but in case anyone's interested in chatting about the replacement API, I'm excited about the long-term prospects of their ML Engine product.

The open-source distributed tensorflow stuff is pretty nice, but it still requires a huge amount of hand coding and tuning the machinery, reminding me quite a lot of just rolling the damn thing in MPI yourself. I'm very excited to see where distributed tf will be in a year or two, but it's a chore today.

The hope is that using Google's secret sauce to auto-distribute the execution graphs and associated data ingestion makes things "just work". At the moment, the documentation and examples for that are a bit all over the place at the moment, and require writing models to conform to the newish tf.contrib.learn.Experiment API, which is also a bit underdocumented and underexampled. Using it for very large datasets (say >tens of TB) seems to be pretty challenging at this moment (to me at least).

At any rate, I've been banging around on it for a few weeks and am really hopeful. I will follow Cloud ML Engine's career with considerable interest.

Re: Google Cloud Prediction API End of Life

#114
post #78

Earlier quoted context omitted.

If I had built a commercial product on that API how much money would this have cost me to move to the API. Also would the new API allow me to provide a better service to my customers or would it just be a pointless upkeep task.

If you build a product on an API you don't control, you'd better always have some realistic contingency plans on hand. A years notice is probably one of the easiest cases to handle out of the many scenarios that might force you to switch APIs.

or build it on aws

Re: Google Cloud Prediction API End of Life

#115
post #95

Earlier quoted context omitted.

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

Most of my company's clients have code from 1997 still in production, and at least a third have code from 1987 still in production. A few have code from 1977 still in production.

I'll give you one guess what sector :D

Re: Google Cloud Prediction API End of Life

#116
post #95

Earlier quoted context omitted.

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

But many of the companies whose APIs you might have started using in 2007 are long dead: bankrupt; acquihired; pivoted into completely different verticals...

If you truly want API longevity at that scale, we probably need some force beyond that of quarterly-profit-driven companies to actually achieve it. Maybe some nonprofit (the Internet Archive, maybe) could offer "API insurance" packages, where—in exchange for your premiums—they'd build and maintain API-compatible replacements for any and all services the insurance-holders rely on, if said services should happen to die.

Then you'd just need to insist (with force) that all network-RPC-based "client" libraries have configuration to let you easily change their endpoints and expected X.509 trust anchors...

Re: Google Cloud Prediction API End of Life

#117
post #91
post #83

Earlier quoted context omitted.

> ...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/…

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

Something to keep in mind but it's very difficult to find anything AWS has removed. They have APIs / features that have existed since their launch. While they may have such a policy it's essentially unheard of.

For Azure I'm not as familiar with but a few Google searches and I also can't find an API they killed.

There is a difference between a rate in practice and a rate in policy. I don't have the numbers to know what any of the big cloud provider's rates actually are but as someone who has worked for large companies and organizations one year is simply not long enough for almost any change especially one that is necessary for non-business reasons. Regardless of who's suggesting it.

Re: Google Cloud Prediction API End of Life

#119

One thing that I find so amazing about AWS (Amazon Web Services) is that I'm not aware of them ever EOLing one of their apis (I could be wrong). We still have a bunch of code that still uses SimpleDB and even though they haven't promoted SDB for a while, they haven't EOLed it.

Exactly this. Companies are still running on-prem software from decades ago, because it's not economical to migrate. Why should the cloud be different? It's very scary to a purchasing manager at a company to know that when they invest $100k+ in developer/consultant time implementing a solution, that every 3-5 years they will need to spend an additional $xk to simply keep the solution alive! AWS is doing this right. I…

Salesforce gets this right too. All of their APIs get built with the intention of supporting them for 20+ years. Companies can't build on quicksand.
Post reply on HN