Live data from Hacker News

Dear Google Cloud: Your Deprecation Policy Is Killing You

medium.com

171–180 of 417 posts

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

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

The only option I can see as an alternative "minimal" cloud is one that runs Kubernetes on one of the "mid-tier" hosting platforms.

DigitalOcean, Linode, heck even OVH now have K8s offerings with ready-to-go (and free) control node/panel instances.

Of course K8s isn't shallow but at least when you master their way of doing things you're free to go and do whatever you want.

It's cheaper too.

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

#172

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…

Unfortunately I understand that Azure is not exactly what one would call "mature software". I have a colleague who's been using it for a few months, and he complains about it constantly. He's had to submit a couple of pull requests for somewhat silly issues like string escaping not working properly.

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

#173
post #166

Earlier quoted context omitted.

It might be even deeper than that. I don't know if it's representative, the few Googlers I talked to were there only for the money. Their view of the company was actually quite negative. Keeping backward-compatibility requires people that care. That have enough pride in their work to counter-balance the grind.

Obviously having people that care about the work they do is a positive thing, but there are plenty of people in plenty of industries managing to do a good job despite only being in it for the money. It might not be a good business decision for Google, but surely if they create enough positions that are solely focussed on the boring stuff but are paid better to make up for it, there is a price point at which they'd ge…

The fact that most people are there mostly for the money (which I'm pretty sure is the case) actually works in their favor if they wanted to prioritize maintenance more. Currently people don't do it because they're not rewarded for it, not because they don't care. It's actually far easier to steer people towards certain behaviors if you have lots of money and all you need to do is give more or fewer RSUs or bonus $$s.

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

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

There is map in Python, but nowhere near as nice as in JavaScript IMO.

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

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

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

#176

> I’m not actively developing on AWS, so I don’t have as much of a sense for how often they sunset APIs that they have previously dangled alluringly before unwitting developers. SimpleDB still works, it's not even deprecated or grandfathered to not accept new users. There is really nothing else you need to know about how AWS treats deprecation than that single example. Deprecation is practically unheard of in AWS. If…

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.

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

#177

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…

Not only that I had to go and update some zombie app I've left running on App Engine that I haven't touched in years because I got some email saying "we have changed something, and your app is running Python blah blah and that runtime will blah blah soon. Please log into the Cloud Console..."

I guess you can't just set it and forget it on Google Cloud either even though everything was legit fine at time of deployment; I mean come on, it's a simple Python Rest API, what you want me to do 7 years later? xD

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

#178
post #147

Earlier quoted context omitted.

I've never been hired or approached by Google. However, as a University lecturer I know a lot of people Google have employed. In my opinion, they have rejected some of the greatest students I have ever taught, and accepted some idiots who know how to speak well. While they have employed some good people, I believe they purposefully taret the type of people who think working at Google makes you a fundamentally better…

As a counter argument, I don't hold much confidence in my former professor's ability to rank the real-world competence of their student's.

You may be right, I can only give my point of view.

Also, even if I am right, real-world competence may involve more bluffing, less high quality knowledge of algorithms, than I would like.

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

#179

Earlier quoted context omitted.

My armchair thought: what if the CEO said "wow, Yegge is right, we've gotten really off trail here. you need to show leadership in maintaining a 3+ year old system at Google for promotions?" Could that happen and would it work?

Yes, but there might be other downsides... Suddenly every developer turns into 'maintenance man' just refactoring existing code to make it neater without adding much.

The solution to this is more qualitative performance evaluations. People are really good at gaming quantitative systems, so once it becomes a rule that more releases == more promotions, people will prioritize that over actual value creation. Same for if maintenance work becomes the metric.

You need the people evaluating performance to really understand the work, and make informed, discretionary decisions about who to promote to maximize real value creation.

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

#180
post #99
post #66

> Let’s say hypothetically that Apple was dumb enough to pull a Guido van Rossum, and declare that Swift 6.0 is backwards-incompatible with Swift 5.0, much in the way that Python 3 is incompatible with Python 2. Damn, I was waiting for this. The whole essay was a setup for this paragraph. Reframes the argument using a shared traumatic experience for everyone. This humanizes the effect, we all know someone that lost s…

Apple already pulled the Python 3 stunt twice with swift. Swift 1 to Swift 2 to Swift 3 were all very much incompatible. Of course the language wasn’t as broadly used back then and Apple is known for quicker churn than Python so the need to write code compatible across Swift versions was much less pronounced

Swift can be very painful from this perspective. I just recently had to do surgery on a project because one of my dependencies changed the tools version.

The back-compat promise is one of the reasons I'm investing in Rust for new projects, even if I find the actual programming much more pleasant in Swift.

But I'm a bit less optimistic about Rust now given the recent layoffs at Mozilla.

Post reply on HN