Google Cloud Offers a Model For Fixing Google's Product-Killing Reputation (arstechnica.com) 49
An anonymous reader quotes a report from Ars Technica: Google's reputation for aggressively killing products and services is hurting the company's brand. Any new product launch from Google is no longer a reason for optimism; instead, the company is met with questions about when the product will be shut down. It's a problem entirely of Google's own making, and it's yet another barrier that discourages customers from investing (either time, money, or data) in the latest Google thing. The wide public skepticism of Google Stadia is a great example of the problem. A Google division with similar issues is Google Cloud Platform, which asks companies and developers to build a product or service powered by Google's cloud infrastructure. Like the rest of Google, Cloud Platform has a reputation for instability, thanks to quickly deprecating APIs, which require any project hosted on Google's platform to be continuously updated to keep up with the latest changes. Google Cloud wants to address this issue, though, with a new "Enterprise API" designation.
Enterprise APIs basically get a roadmap that promises stability for certain APIs. Google says, "The burden is on us: Our working principle is that no feature may be removed (or changed in a way that is not backwards compatible) for as long as customers are actively using it. If a deprecation or breaking change is inevitable, then the burden is on us to make the migration as effortless as possible." If Google needs to change an API, customers will now get a minimum of one year's notice, along with tools, documentation, and other materials. Google goes on to say, "To make sure we follow these tenets, any change we introduce to an API is reviewed by a centralized board of product and engineering leads and follows a rigorous product lifecycle evaluation."
Despite being one of the world's largest Internet companies and basically defining what modern cloud infrastructure looks like, Google isn't doing very well in the cloud infrastructure market. Analyst firm Canalys puts Google in a distant third, with 7 percent market share, behind Microsoft Azure (19 percent) and market leader Amazon Web Services (32 percent). Rumor has it (according to a report from The Information) that Google Cloud Platform is facing a 2023 deadline to beat AWS and Microsoft, or it will risk losing funding. Ex-Googler Steve Yegge laid out the problems with Google Cloud Platform last year in a post titled "Dear Google Cloud: Your Deprecation Policy is Killing You." Google's announcement seems to hit most of what that post highlights, like a lack of documentation and support, an endless treadmill of API upgrades, and Google Cloud's general disregard for backward compatibility. Yegge argues that successful platforms like Windows, Java, and Android (a group Yegge says is isolated from the larger Google culture) owe much of their success to their commitment to platform stability. AWS is the market leader partly because it's considered a lot more stable than Google Cloud Platform.
Enterprise APIs basically get a roadmap that promises stability for certain APIs. Google says, "The burden is on us: Our working principle is that no feature may be removed (or changed in a way that is not backwards compatible) for as long as customers are actively using it. If a deprecation or breaking change is inevitable, then the burden is on us to make the migration as effortless as possible." If Google needs to change an API, customers will now get a minimum of one year's notice, along with tools, documentation, and other materials. Google goes on to say, "To make sure we follow these tenets, any change we introduce to an API is reviewed by a centralized board of product and engineering leads and follows a rigorous product lifecycle evaluation."
Despite being one of the world's largest Internet companies and basically defining what modern cloud infrastructure looks like, Google isn't doing very well in the cloud infrastructure market. Analyst firm Canalys puts Google in a distant third, with 7 percent market share, behind Microsoft Azure (19 percent) and market leader Amazon Web Services (32 percent). Rumor has it (according to a report from The Information) that Google Cloud Platform is facing a 2023 deadline to beat AWS and Microsoft, or it will risk losing funding. Ex-Googler Steve Yegge laid out the problems with Google Cloud Platform last year in a post titled "Dear Google Cloud: Your Deprecation Policy is Killing You." Google's announcement seems to hit most of what that post highlights, like a lack of documentation and support, an endless treadmill of API upgrades, and Google Cloud's general disregard for backward compatibility. Yegge argues that successful platforms like Windows, Java, and Android (a group Yegge says is isolated from the larger Google culture) owe much of their success to their commitment to platform stability. AWS is the market leader partly because it's considered a lot more stable than Google Cloud Platform.
Too late. (Score:5, Insightful)
It's nice that Google's got their PR company working hard at this and all but we all know they're a profit-driven company and what to expect from that.
Re: Too late. (Score:2)
Re: (Score:2)
As well as expectation driven. Problem is what happens if something isn't a quick success. Maybe we should ask Netflix. The company known for giving a show enough time to mature and find success.
Re: (Score:1)
Google's reputation for aggressively killing products and services is hurting the company's brand.
Wrong.
Google makes $120 Billion a year, almost entirely from advertising and most of it advertising on websites not owned by Google. Google is not a "tech company", they are an advertising company. They have no "brand". It is impossible for Google to "hurt their brand" because nobody gives a half a fuck about Google's brand.
Re: (Score:3)
Re:Too late. (Score:4, Funny)
As long as you remember that this is their product cycle and therefore to never to buy any product from Google, you'll be fine.
How long till they kill Enterprise APIs? (Score:5, Interesting)
I'll trust it when I see them offering massive penalties for deprecation in contracts.
TBH though, everybody deserves a second chance and this might, finally, be someone in Google beginning to understand that customer service is important. Now just got to address the internal incentives to prioritize new and shiny over fixing customer problems.
Re: (Score:3, Insightful)
Seriously are you kidding. Google three main faults, making them a corporation AGAINST humanity.
They are censorous freaks for the establishment against the people, not even pretending not to be, pushing propaganda hard and censoring any opposition they feel they can get away with, without killing the propaganda station, YouTube. They actively seek to corrupt democracy in their favour.
In a time of catastrophic climate change, they push wasteful consumption harder than any other corporations, the shittiest
Re: (Score:2)
Most what they censor on YouTube are lies by those who actually seek to corrupt democracy in their favour.
I'm not sure what wasteful Google products you are talking about, but they sell very few physical products. Their in house Android phones good reviews and are supported longer then other Android phones.
Google doesn't sell user data, or give it away like candy like Facebook did. They use that data to target ads, but advertisers don't get access to the data.
I wonder when microsoft will learn that lesson (Score:3, Interesting)
Re: (Score:2)
Yeah, hell even microsoft wouldn't expect to catch up to AWS in two years and they are way way ahead of where google is.
Which must be a bitter pill for Google, being their app-engine pretty much started this whole cloud PAAS type shenanigans.
Move fast (Score:4, Funny)
and cancel things.
Too little (Score:5, Insightful)
One single initiative, with one feature, of one product, of one platform, is not proof that Google is starting to provide adequate support for its products. The fact that Google hasn't said, "OK, we are henceforth always supporting everything for at least X years", means this is just one team's wimpy attempt to stave off the whales from jumping ship before 2023.
GCP is dead, it just doesn't know it yet. At this point, I don't know why anyone would bother, when you have two extremely capable competitors who actually care about support a whole lot.
Re: (Score:2)
I don't see how the headline matches the content.
All I see is that they're going to stabilize the API to Google Cloud Platform. But that doesn't say anything about killing products.
I thought maybe they're going to let you run instances of those products on GCP so you can resume using the feature in private, but nope.
A stable API means nothing in the context - it doesn't say Google isn't going to kill GCP tomorrow if they wanted to. Or that you could resurrect killed projects as private instances.
GCP isn't d
Itâ(TM)s not hard (Score:3)
Yeah stability matters (Score:5, Interesting)
This reminds me of something about 5-6 years ago.
There was a certain programming language that was popular with the new graduates just coming out of school, and certain other programmers (mostly young ones).
They talked about how much you hey liked this new programming language, and they wrote software in it. Some of the scripts looked useful, so I tried to use it, but just got butt load of error messages about syntax errors every time. Eventually I found out that's because they wrote it a year ago, and used the version of $programming_language that came out a year or two ago. In this language, software doesn't work a year or two after you write it. They break the syntax every year or so.
Eventually I had figured out that over the last three years, they had come out with three mutually incompatible versions of the language. Breaking even simple stuff like "print" each time. So they broke "hello world" three times in three years.
On the other hand, the C and sh examples from the 1980s copy of The Unix Programming Environment I got from my mom still worked. Thirty years later, the same syntax still worked fine in those languages. NEW syntax had been added. New options were available in new versions; they didn't break the existing functions and syntax.
I had four programmers on my team at work other than myself. We maintained a very large software suite written in Perl.
What do you think I said when new members of my team wanted to to start writing some of our software in Python? The language that had totally broken compatibility three times in three years? If you guessed "you quoted a Bishop Bullwinkle song", you guessed correctly.
Backward compatibility matters. Several years later, I use a bit of Python where it's a good fit, mostly personal use stuff that I'll only use once or twice, so bug-reducing features like type safety don't matter much. I'll never forget that Python burned all the users three times in three years, though, so I'll probably never allow it for any code that really matters.
When you trash months of effort by your users because you're not smart enough to make new parameters OPTIONAL, they don't like that.
Re: (Score:1)
You lost me at Perl. Enjoy your trashcan, Oscar.
About 100 times (Score:2)
Perl had actually released new versions just about 100 times.
The reason you don't hear weeping and waling and gnashing of teeth every time is the following.
When Python decides to add a "direction" parameter to sort() they do something like this:
3.2.7: sort(list)
3.2.8: sort(direction, list)
You can't upgrade from 3.2.7 to 3.2.8 without breaking things, because there is a new parameter. Here's how Peel (and all sane languages) add a "direction" parameter:
Perl 1.2.1: sort(thing)
Perl 1.2.2: sort (thing, directio
Re: (Score:3)
3.2.7: sort(list)
3.2.8: sort(direction, list)
The sort function in the Python standard library is and has always been called 'sorted', with the list to be sorted as the first argument. Double-dotted releases are bugfix releases, not feature releases, so you must have made up this example. Also, adding minor parameters to the beginning of a function argument list is very un-Pythonic; I don't think you'll find any change like that in standard library for any Python version.
So I ask you again: what specific backward-breaking incompatibity issues did you r
HelloWorld (Score:2)
Let me ask you this. Do you WANT Python to do well?
Do you WANT people to think it's a good language, or a piece of crap?
Hold on to those answers and we'll get back to them in a minute.
> for arcane features or rare edge cases.
Ah yes, rare edge cases like literally the second line of code you'll see in any tutorial for any language, the famous "hello $name" example. Here it is in one version of Python:
print( "Hello {}".format(name) )
There are two things just in that one common line that break in different
Re:Yeah stability matters (Score:5, Interesting)
I had gotten started with Qt near the end of Qt 2's lifespan. People complained about the API breakage, but I shrugged the complaints as unwarranted. I then wrote several significant projects (some personal, some commercial) using Qt 3.x. Then Qt 4 came with an API that broke every single significant Qt 3 program I had ever written. The compatibility libraries didn't work, so I decided to port one of my projects to Qt 4.
It took an entire year to port just one program. It wasn't feasible to port any of the others, so I loaded the only remaining important one into a Linux VM, and called it good. I then understood the complaints I had heard about the prior API breakage, and didn't want to go through that ever again.
The Java programs I wrote in the mid to late 1990's still run in binary form as-is, and still build with the latest Java without even a single modification. After weighing those two options, I returned to writing my applications in Java.
I agree that backwards compatibility is important. It weighs more heavily than most other factors combined.
Re: (Score:2)
Re: (Score:2)
Java and Qt occupy completely different spots in the application stack.
Java can occupy lots of different spots in the application stack, including the exact same spot as Qt (I have lots of desktop programs to demonstrate it). Can you elaborate on why you think otherwise?
Re: (Score:2)
Re: (Score:2)
This reminds me of something about 5-6 years ago. ... they wrote it a year ago, and used the version of $programming_language that came out a year or two ago. ... Eventually I had figured out that over the last three years, they had come out with three mutually incompatible versions of the language. Breaking even simple stuff like "print" each time. So... What do you think I said when new members of my team wanted to to start writing some of our software in Python? The language that had totally broken compatibility three times in three years?
Apparently, you claim that Python broke compatibility thrice between 2012 and 2015, including 'print'. Could you be more specific? The great incompatibility (including new print syntax) that people complain about was with Python 3.0, which came out in 2008.
Re: (Score:2)
Five or six years ago I nixed Python development because they HAD broken the language three times in three years. I acted five or six years ago based on what the Python team had done in previous years. That count of three doesn't include the 2.8 unrelease. It's four times in three years if you count 2.8.
Re: (Score:2)
So:
1st compatibility break: python 3.0.
2nd: python 2.8 unrelease.
What are the other two?
Re: (Score:2)
2.6, 2.7, and 3.0 are the mutually incompatible official releases, three in three years.
2.8 would be a fourth, but that was officially cancelled.
Android? (Score:2)
Re: (Score:2)
As a mobile developer, I can completely agree. It's _mostly_ stable from an ABI perspective, but definitely not from a source or submission to Google Play perspective.
Tick Tock (Score:2)
So when are we taking bets for "Enterprise API" being depreciated?
more of the same (Score:3)
GCP...we promise not to kill it........until 2023 (Score:5, Informative)
Re: (Score:3)
Precisely. This is probably the worst Slashvertisement in the history of /.
Floating the idea that Google Cloud Platform is about to have a much more stable API on /. is brilliant. Even if the article is a lie, it made me want to take another look at GCP. Finishing with the idea that GCP will get defunded if it doesn't beat out AWS and Azure in a measly two years is a deal breaker. Google could give GCP away and not catch up in two years. Google is facing off against two very serious competitors with
Re: (Score:2)
Re: (Score:2)
Whew! Sure glad I read all the way down to your post! ;) Although I learned years ago to never ever ever trust Google not to kill things. And they never care. Anything some article says about commitment and Google is basically false. They should just give up trying to offer dependable things and own it.
Sounds good in principle (Score:2)
4 things to never believe (Score:2)
"I won't cum in your mouth"
"I'll still respect you in the morning"
"Do no evil"
and Google's 'promise' as stated in this article.
My own little story (Score:5, Interesting)
I have my own open source project, not too big, not too small. From the start we used paid gmail as our email provider, used google docs, paying something like $12/month per person. This is important: we were paying customers albeit small.
At some point we decided to try to monetize our project and created a web site. The site needed a way to contact us, so we used google's Forms for feedback: the customer fills out the form, we get an email and the request is saved to a spreadsheet. The form was simple and straightforward: your email, your name, your company, free-form text for a message. And all was fine for a while.
Each form has a little button in the left bottom corner which anyone can use to "report" the form, essentially to complain to Google that the form is somehow bad. So, someone used that button on our form. I don't know if maliciously or just for fun. Do you think google reviewed the complaint and found it completely frivolous? Do you think google informed us that someone complained? Of course not. They are google. They just closed the form without telling anyone. We found out about it from a customer why found a way to contact us through github. OK, after a quick investigation we found the form was suspended. Google graciously offers a link to appeal the suspension. We pressed it. Then again. And again. I filed that stupid appeal form 5 or 6 times. They never replied even with an automated reply. The form was never restored. So, we ripped out the crap that google Forms are from everywhere and replaced with a home-brew solution.
Google's customer service is an absolute horrible trash. They are good at automation and they treat customers as automata too. Everything is done by statistics. And they don't seem to learn.
Backwards compatibility (Score:2)
But Google breaking backwards compatibility is bad because backwards compatibility is good.
It seems, among nerds, backwards or forwards compatibility with their own positions are also anathema.
Re (Score:1)