7 ms·

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 chos

by boulos 9y ago

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 9y ago
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?
- FmrAMZN_TA 9y ago
  Ever? What if they had a 10 year deprecation policy?
  - compumike 9y ago
    10 years would be a reasonable good start for a deprecation policy for an API-providing infrastructure company. It is not uncommon to have 5-year-old systems in production, and a factor of two above that sounds like a good minimum.
- vgt 9y ago
  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)
  - kingbirdy 9y ago
    One well reasoned comment on HN won't change the entire market's perspective.
    - vgt 9y ago
      I agree wholeheartedly. My argument is that there is not sufficient evidence to claim that "Google shuts things down nilly-willy" within the context of B2B (conflation with B2C is the real issue here). Rational thinkers should be swayed by evidence, rather than "market perspective", especially within the context of what boulos posted. For some perspective on "market perspective", see [0]: https://twitter.com/gigabarb/status/839536072698712064 https://twitter.com/gigabarb/status/839536072698712064 (work at G)
      - Denzel 9y ago
compumike 9y ago
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.
- jdc0589 9y ago
  > 1 year deprecation is insanely short for public-facing infrastructure APIs. We should be talking about 10 years. Thats a little extreme.
  - compumike 9y ago
    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.
    - joshuamorton 9y ago
      There's a difference between code written and tools you used. Just to compare, 2007 was the time of python 2.5, Java 6 and Windows Vista. I would certainly hope people have upgraded to newer tools than those.
      - 9y ago
technofiend 9y ago
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.
czardoz 9y ago
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.

by boulos 9y ago

tuna-piano 9y ago

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?

FmrAMZN_TA 9y ago
Ever? What if they had a 10 year deprecation policy?
- compumike 9y ago
  10 years would be a reasonable good start for a deprecation policy for an API-providing infrastructure company. It is not uncommon to have 5-year-old systems in production, and a factor of two above that sounds like a good minimum.
vgt 9y ago
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)
- kingbirdy 9y ago
  One well reasoned comment on HN won't change the entire market's perspective.
  - vgt 9y ago
    I agree wholeheartedly. My argument is that there is not sufficient evidence to claim that "Google shuts things down nilly-willy" within the context of B2B (conflation with B2C is the real issue here). Rational thinkers should be swayed by evidence, rather than "market perspective", especially within the context of what boulos posted. For some perspective on "market perspective", see [0]: https://twitter.com/gigabarb/status/839536072698712064 https://twitter.com/gigabarb/status/839536072698712064 (work at G)
    - Denzel 9y ago

compumike 9y ago

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.

jdc0589 9y ago
> 1 year deprecation is insanely short for public-facing infrastructure APIs. We should be talking about 10 years. Thats a little extreme.
- compumike 9y ago
  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.
  - joshuamorton 9y ago
    There's a difference between code written and tools you used. Just to compare, 2007 was the time of python 2.5, Java 6 and Windows Vista. I would certainly hope people have upgraded to newer tools than those.
    - 9y ago

technofiend 9y ago

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.

czardoz 9y ago

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.