
Google Cloud Prediction API End of Life - dotmanish
https://cloud.google.com/prediction/docs/end-of-life-faq
======
boulos
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 hard for this to be
our expected 1 year term, and we had hoped to have a somewhat cookie cutter
guide for "Here's how you reproduce this with TensorFlow". Quite frankly, the
handful of users of the prediction API likely aren't the kind to happily port
to TensorFlow (and this service has existed since the sort of App Engine only
days, so they're mostly hobbyists, but I still care).

It's never great to "have to" turn down a service, but ultimately when forced
between letting the code rot and become a potential security nightmare versus
give the small set of users some time to retool, the decision was made to go
with the latter. No new features is an easy way to keep something running
forever, but keeping the damn thing secure requires a team to stay on top of
it.

Disclosure: I work on Google Cloud.

~~~
tuna-piano
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 negative. AWS' reputation for leaving services alive is also
known, and is a positive.

When companies buy software, they don't want to have to worry about the
future- they just want it to work.

"No one ever got fired for buying IBM" was a big driving force for IBM's
success. "No one ever got fired for choosing AWS" seems to be true these days.

If you want that phrase to be "No one ever got fired for choosing Google
Cloud"\- you probably shouldn't deprecate services like that. I wonder if
anyone got fired for choosing Google Cloud, after Google shuts down one of
their services?

~~~
vgt
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 you to reach your conclusions?

(work at G)

~~~
saurik
> ...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 was probably the least interesting to those of us who care about this
sort of thing :(.

Here is something I wrote four years ago when someone (as from Google!) tried
to pull the "you are just upset about Google Reader" argument.

[https://news.ycombinator.com/item?id=6518473](https://news.ycombinator.com/item?id=6518473)

================

They've shut down much more than Reader (seriously, who said anything about
Reader? was that even a service a developer could rely on?). Even APIs they
don't shut down, such as their OpenID login stack, they routinely replace
(dropping a lot of the maintenance and support, which leads to weird failures)
with "exciting new APIs" that have no migration path, such as with G+ Login (I
am thankfully safe from this issue, as I did something crazy with Portable
Contacts that have me Google user IDs that I started storing before we even
knew what they meant; so, to be clear: I have very little personal axe to
grind on this, but others should be wary).

They thankfully decided to just go commercial-ish with Translate, but the same
can't be said about Charts (which had a long deprecation window and a
replacement, but the replacement is a fundamentally different kind of API that
has different browser requirements and even different charting capabilities).
They also happily will just shut down things like Google Checkout and offer no
replacement at all for key use cases like "sell a physical product" (if you
sell digital goods, you might be able to switch to Google Wallet Objects, an
"exciting new API" released a couple weeks before Checkout was deprecated).

Google Checkout was certainly also targetted at enterprises, had a clear
business model behind it, and had existed since 2006: everyone who built on
that one (again, not me: I avoided Checkout like the plague) got only six
months to migrate to a different provider (and figure out how they are going
to handle any refund requests from recent customers, which will surely be
horribly irritating as they won't be able to just tell Checkout to refund the
transaction anymore). There is simply a patterned lack of care for people who
may have built things on their stacks.

(Yes, some services have deprecation policies, but let's not forget that those
guarantees were themselves attempts to regain faith due to a previous round of
services that had been axed with little warning ;P. After the anger died down
from that they started reversing course, shortening or removing the policy
entirely after the previous guarantees expire. I can only imagine the people
who keep citing these deprecation policies don't have much memory of how this
has all been going down over the past few years ;P.)

[http://googledevelopers.blogspot.com/2012/04/changes-to-
depr...](http://googledevelopers.blogspot.com/2012/04/changes-to-deprecation-
policies-and-api.html)

Yes: you might be able to find alternatives to migrate towards... but if, by
just acknowledging this pattern, you could avoid that bullet--which could
easily come at the "least convenient moment" (such as when you now have some
competition out of nowhere while attempting to launch a new product and raise
finding), requiring you to suddenly drop everything for a couple weeks coming
up with a new implementation of key infrastructure before the clock runs out--
why wouldn't you?

================

Two years ago someone (not from Google, this time) used that argument against
someone again, and I linked to my earlier comment. A few people downvoted my
link, and I responded with the following (which was upvoted, and my link was
also upvoted back to 0).

[https://news.ycombinator.com/item?id=10330249](https://news.ycombinator.com/item?id=10330249)

================

Multiple people (now three!) have downvoted this, but the idea that everyone
who talks about Google service closures is complaining about one specific
service--Google Reader--is the "meme" that we should all be quite tired of, as
it is trotted out like a broken record every single time anyone points out
reservations about Google's track record: no matter the context, no matter how
many services have been shut down or cut down since, no matter what
announcements Google makes about limiting their policies, and no matter
whether the person mentioned Google Reader or not... it is even used against
people like myself, who had absolutely no specific interest in Google Reader
in the first place :/.

It is nothing more than a knee-jerk way to dismiss a rather easily defended
position (due to the large number of closures that have been documented, ones
that are more extreme or would have been considered less likely than Google
Reader) by stereotyping someone's argument down to not just a "strawman" (an
argument that is easily defeated), but essentially a purposely broken and
laughable version of their argument so as to purposely ill-inform other people
(which I feel the need to separate from a "strawman", as the goal is not to
defeat the argument but to belittle the opponent). It is frankly one of the
more underhanded argumentation tactics that people seem to enjoy defending
here.

The reality is that Reader is a non-issue for most people here, as it isn't
something you likely built your business or infrastructure around (and to the
ones who ended up indirectly relying on it, that is a stretch to blame them
for), but when Google randomly shuts down, cuts down, or entirely reboots APIs
and services--something they have done many times, at the extremely painful
end with things like Checkout and Login, but also with things such as App
Engine or Charts--the fact that people seem to seriously have just forgotten
how recent these things have been is distressing, and is made all the worse by
people who insist on perpetuating "you are just whining about Reader" lie :/.

~~~
vgt
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/](https://aws.amazon.com/agreement/)

[1] [https://azure.microsoft.com/en-
us/support/legal/subscription...](https://azure.microsoft.com/en-
us/support/legal/subscription-agreement-nov-2014/)

(work at G)

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

------
vgt
Before folks start comparing this to Reader or point to the general "Google
shuts things down" narrative, Prediction API has been superset by the array of
ML APIs and Google Cloud ML, found at [0].

[0] [https://cloud.google.com/products/machine-
learning/](https://cloud.google.com/products/machine-learning/)

(work at G)

~~~
tuna-piano
I downvoted this comment, because the general "Google shuts things down"
narrative remains. Companies invested real money in integrating Google's
existing services.

If Google's New API is so easy to switch to, and companies will get value from
the switch, then they would do it automatically.

The truth is that the old API probably worked perfectly fine for some
companies, who are now forced to spend time and money migrating.

If you were a purchasing manager in the IT department if a midwestern
manufacturing (for example) company, wouldn't this kind of service shut down
scare you?

AWS seems to support their services forever. That's what Midwestern
manufacturing-type companies want. Hopefully Google will learn this, so AWS
will have legitimate competitors.

~~~
ben_jones
Despite generally disagreeing with the comment I upvoted the parent because I
think it provides an important counterpoint to the discussion.

I think it's too common to make lazy assumptions and not even read the article
when it comes to a stereotype (true or not) such as Google's countless EOL'd
services.

And personally I feel like Google's endgame isn't to provide the best
consumer/enterprise cloud services a la AWS. They're just subsidizing their
own endeavors in mass computing with presumably a tidy profit on the side.
They can afford to alienate a customer here and there because they don't need
a customer here and there. Which is an entirely rational thing to do for a
corporation.

~~~
devoply
But there are other options that are available for the customer is not really
much of a counter point, as there are almost always other options available.

People dislike shutdowns because they have invested time and resources in
implementing something. Now they have to spend the same if not more time
again. This has a cost involved.

How much work is created in our cultures because of the disposable nature of
everything. Businesses use efficiency as an excuse of squeeze every last
dollar out of workers. Yet on the other end the system is exactly the opposite
of efficient.

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

~~~
tuna-piano
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 can't imagine recommending Google for many cloud
use cases, given their propensity to decommission software that companies use!

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

------
random123456
> Q: What will happen with my existing models?

> A: You must recreate your existing Prediction API models using Cloud Machine
> Learning Engine. To learn more, please read our documentation about creating
> models on Cloud Machine Learning Engine.

Slightly edited and corrected answer should be

> A: You must recreate your existing Prediction API models using Cloud Machine
> Learning Engine. But, you know what? You must recreate it using Amazon
> Machine Learning, because we might again shut down this service in favor of
> our next platform. So If you care about your product, move directly to
> Amazon Machine Learning so next time you will not be bothered by us. And
> thanks for using it

~~~
thesandlord
Prediction API was closed source and proprietary. Cloud Machine Learning
Engine is open source Tensorflow.

You can run these models on prem, on AWS, etc.

------
omarforgotpwd
"Let's build our entire stack around Google Cloud. I'm sure they won't shut
down an API we depend on"

~~~
theDoug
This one-year-long deprecation warning comes atop what is a fairly reasonable
migration path for most users. I have yet to hear of a single user of any size
whose “entire stack” relied on a single API, let alone this one, and who would
be left without a faster, easier, or less expensive option in this move.

But you might have info I do not!

(Work at Google Cloud)

~~~
BinaryIdiot
> This one-year-long deprecation warning comes atop what is a fairly
> reasonable migration path for most users

After working at multiple, large companies as well as doing government
contracting, it would take _a year_ just to propose and get funding for very
minor changes. Sometimes it would take _months_ to get critical bugs or
security issues approved and taken care of.

A year works for many tech companies. Maybe even most. But it's laughably tone
deaf when talking about larger companies or government organizations.

This is why the majority of companies I've worked with opt for APIs from, say,
AWS and only consider using a Google API if there is literally no other
choice. No one wants to be focused on X and suddenly have to allocate money to
change something that's working to use something else.

------
jonbarker
Totally misread this as google cloud predict-the-end-of-your-life API.

~~~
microtherion
I misread this as a service to predict the EOL date for a given Google API.

~~~
yahelc
Someone actually built a model back in 2013 to predict risks of various Google
APIs shutting down:

[https://www.gwern.net/Google%20shutdowns](https://www.gwern.net/Google%20shutdowns)

------
iagovar
I'm tired of Google shutting down or screwing up services. I come from
marketing, and while I still use Adwords, I'm more and more moving to other
platforms for research and spending my money. It's not only that, the moment
you have a problem, it's up to yourself, while other companies have a customer
service that actually replies, with more or less success.

I'm also learning programming, basically because I want to get into Data
Science and I'm doing everything I can to avoid using Google Cloud, even
though I found Bigtable to be easy to use and the kind of stuff that I wanted
for a project, but I forced myself into learning how to get a postgre & couch
dbs up. Also using vps's from a local provider (clouding.io).

It's like... I can see myself in the future spending time on modifying stuff
because Google make X decision, instead of doing stuff I enjoy.

~~~
numbsafari
Just curious, were you using the Predict API?

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

------
conradk
tl;dr Cloud Prediction is deprecated in favor of Cloud Machine Learning
([https://cloud.google.com/ml-engine/](https://cloud.google.com/ml-engine/))

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

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

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

------
faragon
Does Google use ML to predict the failure of one service?

------
xena
Why not just make the old API be a wrapper for the new one?

------
ris
Didn't see that coming, eh?

------
koolba
I initially read this title as an API to predict when Google Cloud APIs would
be end of lifed.

------
faragon
TL;DR: if your business relies on a Google API/service, your business is in
risk.

------
subcosmos
It didn't meet our needs in classifying hotdogs vs everything else.

------
debacle
Good on Google for giving people some lead time on deprecating this service.

------
mdekkers
There is no way I will ever build a product, or spec anything for a client,
that depends in some way on a Google offering other than public search.

------
ktamura
Now this is going to be a moneymaker, this is a sensible business move.

People misunderstand Google: they offer things for free because it lets them
collect data (search, gmail, etc.) or it drives competition out (1TB free for
BigQuery, for example).

For everything else, they either shut them down or charge money =)

~~~
CobrastanJorji
The Predictions API costs money. The replacement also costs money. What are
you trying to say?

