Dear Google Cloud: Your Deprecation Policy Is Killing You • Hacker News Board

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#181

Post by jto1218 » Sat, Aug 15, 2020, 1:15 PM UTC

remus wrote: post #111

larrymcp wrote: post #54

Earlier quoted context omitted.

I saw that he mentioned a few of them in the article. He writes: I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to... I dunno, _everything_, has forced me to rewrite it all after at most 2–3 years.

Thanks for taking the time to list them out, didn't spot those in the article. Personally, I think most of them seem quite sensible. Having a 'support everything forever' approach is obviously going to impose a huge burden on the teams who maintain this stuff which is then going to limit the ability to make anything better. The depreciation notices generally seem pretty good (12-15 months notice by the looks of it, s…

that’s the whole point of the article though. Why should the “huge burden on the teams who maintain the stuff” be shifted to the customer who has less resources than Google to manage that burden. 12-15 months is not a long time. If you have to rebuild things that already work every year, you’re wasting a lot of time that could be spent building value for your customers.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#182

Post by JimDabell » Sat, Aug 15, 2020, 1:16 PM UTC

BossingAround wrote: post #121

mvn9 wrote: post #61

Earlier quoted context omitted.

Also: functional programming feels better in JS than in Python. On the other hand, it's nicer to write for-loops in Python.

I really love the array.map( e -> e.doStuff() ) syntax. You can do similar in Java and other JVM languages of course. Not sure whether you can do that in Python.

You can do that in most languages.

But map() (in either language) has the semantics of applying a transformation to each item in a collection to produce a new collection, so you wouldn’t really want to use map() to call something like doStuff(). That's what normal loops and forEach() are for. If you aren’t transforming the collection into a new collection, map() is the wrong choice; you’re telling anybody reading it that you’re doing something that you aren’t.

But assuming doStuff() just has a bad name and is actually transformational, then the most direct translation would be to use map() and a lambda:

    new_array = map(lambda e: e.doStuff(), array)

However it’s more idiomatic to use a list comprehension:

    new_array = [e.doStuff() for e in array]

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#183

Post by rikroots » Sat, Aug 15, 2020, 1:21 PM UTC

jto1218 wrote: post #176

rikroots wrote: post #165

Earlier quoted context omitted.

EC2 vs EC2-classic. I got badly burned (mentally) because I had to learn about creating EC2 instances using the company AWS account created before 2014, but then needed to create instances on a client account created in 2014. Also: classic vs application load balancers - especially the health checks. That one drove me nuts for weeks! AWS never seems to "deprecate" anything, but they do enjoy adding services which are…

the main thing here though is the older things you’re moving away from in those cases are still around. AWS didn’t remove classic load balancers and force you onto application load balancers.

Agreed. But they did deprecate EC2-Classic.

"The EC2-Classic platform was introduced in the original release of Amazon EC2. If you created your AWS account after 2013-12-04, it does not support EC2-Classic."

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-clas...

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#184

Post by MaxBarraclough » Sat, Aug 15, 2020, 1:22 PM UTC

aaanotherhnfolk wrote: post #162

It is a total hassle to keep up with Googlers changing everything constantly. It's not just GCP it's every platform they control. Try keeping a website on the right side of Chrome policies, a G Suite app up, a Chrome extension running. Thousands of engineers chasing promotions by dropping support for live code. If it was their code they wouldn't do it. The org is broken. If you want to see what mature software suppor…

I'm reminded of a blog post I once read, which annoyingly I now cannot find, on how the job of a library maintainer is to not break the API. If you break the API, you've failed at your job. This mindset makes more sense than treating API breakages as a routine case-by-case decision. As the article puts it, breaking changes are breaking the library's commitments. (The library/service distinction doesn't matter much here.)

I remember that same old blog post also lamented overhearing a conversation in which a developer bragged about how their idea for a change was so good that everyone agreed to break the library API to implement it. This reminds me of how a startup being 'highly disruptive' is sometimes fetishised as an end in itself, but of course it's even worse than that: they're celebrating undermining the library's dependability.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#185

Post by nonbirithm » Sat, Aug 15, 2020, 1:31 PM UTC

Two things this essay made me think about.

First: Why don't more programs or services go the `make-obsolete` route and allow people to use deprecated APIs forever? If maintaining compatibility is the goal then I can't see how removing a function in a new API version will ever work. Maybe it's because companies are expecting people to be dumb and call support when they use this deprecated API that was specifically designated as unsupported. "But I can use it," they'd say, and still complain that it breaks or something. Maybe that workload is what they're trying to avoid. But maybe they'd silently move away instead if continuing to use the platform meant rewriting everything.

Second: Why don't people usually have automated API refactoring tools? When I was trying to port a Minecraft mod to a later version I found a bunch of things had changed in the engine. Okay, go to MCP and look at what changed. Guess what? It's all a bunch of Markdown. They painstakingly went through the process of labeling every single API change and method renaming and so on, and they put it all in Markdown.

There was so much missed potential there. Imagine if you had a policy encouraging your developers to put down every API change you make in your program in a machine-readable, schematized format that could be printed to a webpage or Markdown or something else, but could also be combined with a static analysis tool to at least print out the parts that need changing, if not refactor them, just like Google's internal tooling? If developers don't notate those changes by hand then that information is going to be permanently confined to unparseable changelogs and obscure IRC conversations. That's the kind of thing that a semver increment can never capture the nuance of. Why guess what broke or manually parse changelogs based on a major version increment when you can have a computer do all the work for you?

Maybe it's because a changelog is "information to throw away," that you'd have the painful time trying to read through the moment things break and then can forget about a couple of days later when the refactoring is done. But the changelogs and migration steps are essentially a bridge closing a chasm, with your entire userbase on one end trying to get to the other, and if it's not made easy enough for them to cross they will either give up and leave or stay on the other side forever.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#186

Post by walki » Sat, Aug 15, 2020, 1:35 PM UTC

packetslave wrote: post #100

walki wrote: post #78

I have personally used a large number of cloud compute services: AWS, packet, Alibaba, Digital Ocean, nimbix, Azure, Oracle, ... I still use all of these services from time to time. If you carefully look at my list of cloud vendors you realize that there is only one of the big cloud vendors missing: GCP. Why? When GCP came out I wanted to switch from AWS to GCP because AWS was costing me a lot of money and GCP was ma…

Let me guess, you're based somewhere in Europe? I don't remember the specifics, but the "business only in Europe" thing was 100% the fault of the EU's (tax?) laws. Not sure if that ever got resolved, actually.

Yes, I am based in Europe. If this was EU's fault then why didn't any of the other cloud vendors have this requirement?

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#187

Post by tejohnso » Sat, Aug 15, 2020, 1:36 PM UTC

larrymcp wrote: post #54

remus wrote: post #35

I'd be interested in some concrete examples of things GCP have depreciated. I'm an (admittedly fairly light) user of GCP and haven't come across any myself.

I saw that he mentioned a few of them in the article. He writes: I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to... I dunno, _everything_, has forced me to rewrite it all after at most 2–3 years.

I wonder what the complaints are regarding App Engine. I've been using it for over five years without any issue.

Come to think of it, the Channels API shut down was a bit of a nuisance. But it never worked all that well, and deprecation seemed like a reasonable move to me.

Here's a detailed list[1].

[1]: https://cloud.google.com/appengine/docs/deprecations

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#188

Post by walki » Sat, Aug 15, 2020, 1:37 PM UTC

merb wrote: post #101

walki wrote: post #78

I have personally used a large number of cloud compute services: AWS, packet, Alibaba, Digital Ocean, nimbix, Azure, Oracle, ... I still use all of these services from time to time. If you carefully look at my list of cloud vendors you realize that there is only one of the big cloud vendors missing: GCP. Why? When GCP came out I wanted to switch from AWS to GCP because AWS was costing me a lot of money and GCP was ma…

that was sily because they only asked for a company name but you could've entered "Individual" inside the box and they would not care!

They also asked for the VAT number of the company...

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#189

Post by k__ » Sat, Aug 15, 2020, 1:39 PM UTC

Weren't GCP users running around telling everyone "Google only shuts down consumer products and not its cloud services!!"

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You

#190

Post by Jgrubb » Sat, Aug 15, 2020, 1:39 PM UTC

EarthLaunch wrote: post #175

skohan wrote: post #169

I've been hiring dev ops engineers lately, and the consensus seems to be in the candidates I've talked to that all of the cloud providers are somewhat painful to work with. I've worked the most with AWS so I'll use it as an example, but it seems like they sell on "new services", so they are incentivized to release quickly, which leads to services with a lot of holes and poor documentation, making it almost essential…

That sounds like DigitalOcean’s approach.

Idk, DO is adding a lot of managed services lately so it doesn't feel like they're going for the simple, well implemented commodity play for the long run.