Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

steve-yegge.medium.com

Post reply on HN
Print view View original

71–80 of 126 posts

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#71

Post by noirscape »

scarface_74 wrote: post #70
noirscape wrote: post #56

Earlier quoted context omitted.

It does depend on the managed services you're using. Most SaaS companies do offer the "conventional" services managed; if all you need is a database, a cache and some sort of place to dump a docker container for your backend/frontend and not deal with the wires of manually setting up, connecting and securing all of it against the outside world, their offer makes sense. (And like... this describes the majority of inte…

Have you seen or been involved with overseeing the architecture of a large enterprise or state government? There is such a morass of built up complexity it takes years to complete a migration and many just give up and install a direct connect to their cloud provider and claim they always meant to be hybrid.

I've seen the (broad) architecture of my local government yes (due to keeping tabs on government spending on IT as a personal curiosity). I'm aware of the morass you speak off.

The reality though is that most tech stacks aren't that complicated. Not every company is a venture capital "go big or go bust, we change the entire industry" darling (nor are they necessarily looking to grow that way, especially outside the SV bubble) or a government with 2000 different contracts and enough yellow tape + bureaucracy around those contracts that signing a new contract is just easier than possibly extending an existing one with new features.

For the rest of those tech stacks (which are definitely "enterprise", simply by definition, since they get used in companies and are bespoke enough to be their own tools), it's rare to see a stack more complex than the one I mentioned (backend, cache, db) unless a technical admin decided to play runaway with Azure/Google/Amazon because it's shiny and exciting.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#72

Post by zdragnar »

adrr wrote: post #69
unicornmama wrote: post #13

We noped-out or Google cloud because of this. It wasn’t hard to drive home the argument after they rug pulled Google Domains.

That was a poor decision. Every other cloud provider has domain support. Just left my CTO role at a public company to do a another startup, GCP wasnt even in the running. It was between Azure and AWS. Also the first company i didnt pick GSuite or whatever they are calling it now because they fail to innovate on it. Office365 has been beating it in feature launches like adding an AI copilot and AI generated meeting su…

I don't want innovation in GSuite. I want email and calendar and video calls and maybe the occasional docs.

Of the companies I've worked for, half had GSuite and half had office. Personally, I'll take GSuite any and every time.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#73

Post by hobs »

scarface_74 wrote: post #19
VHRanger wrote: post #16

Earlier quoted context omitted.

I mean, you could still avoid vendor lockin by having proper build scripts and deploying directly to EC2 instances and their equivalent. The lockin happens when DevOps gets lazy and start using a bunch of cloudy functions.

And now you’re going to spend more money on cloud just to treat it like an overpriced collocation center without any of the benefits of moving to it. Have you ever done a large migration at scale? I have - even moving over a lot of VM hosted services involves your project management organization, regression testing, networking, firewall, training, security, working with outside vendors, and the list goes on. The aver…

> I have never in 5 years heard any CTO of any company of any size worry about “lock in” when considering their cloud choices.

The company I got laid off just decided they are going multi-cloud and that anything on their original cloud offering which is vendor specific is verboten in the middle of multiple in flight projects which now probably will never complete because they basically just did it by fiat in an unfunded mandate; no new deadlines, no new thought around how.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#74

Post by scarface_74 »

noirscape wrote: post #71
scarface_74 wrote: post #70

Earlier quoted context omitted.

Have you seen or been involved with overseeing the architecture of a large enterprise or state government? There is such a morass of built up complexity it takes years to complete a migration and many just give up and install a direct connect to their cloud provider and claim they always meant to be hybrid.

I've seen the (broad) architecture of my local government yes (due to keeping tabs on government spending on IT as a personal curiosity). I'm aware of the morass you speak off. The reality though is that most tech stacks aren't that complicated. Not every company is a venture capital "go big or go bust, we change the entire industry" darling (nor are they necessarily looking to grow that way, especially outside the S…

When I say “enterprise”, I’m talking about large F500 companies with lots of moving pieces.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#75

Post by scarface_74 »

hobs wrote: post #73
scarface_74 wrote: post #19

Earlier quoted context omitted.

And now you’re going to spend more money on cloud just to treat it like an overpriced collocation center without any of the benefits of moving to it. Have you ever done a large migration at scale? I have - even moving over a lot of VM hosted services involves your project management organization, regression testing, networking, firewall, training, security, working with outside vendors, and the list goes on. The aver…

> I have never in 5 years heard any CTO of any company of any size worry about “lock in” when considering their cloud choices. The company I got laid off just decided they are going multi-cloud and that anything on their original cloud offering which is vendor specific is verboten in the middle of multiple in flight projects which now probably will never complete because they basically just did it by fiat in an unfun…

And how is that adding any business value? Are they constantly testing for cloud portability like Uber does?

Is it giving your former company a competitive advantage?

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#76

Post by coredog64 »

mh- wrote: post #64
jvolkman wrote: post #48

I had this experience with AWS earlier this week. ======== Hello, This is a reminder to update your policies to avoid changes to your access to AWS Billing, Cost Management and Account consoles. Our records indicate that you are still using retired actions to access these consoles. If your policies are not updated with new actions by December 11, 2023, your users’ access to the AWS billing, Cost Management, and Accou…

I've been getting these too, and it all feels very messy and out of character for AWS. If automatable changes are required.. pop up a dialog and ask me to confirm them?

The automation all happens on your side of the control plane. AWS isn’t going to update IAM roles for any customer. The closest you get is that roles can consume managed policies, and those could change but you know that going in.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#77

Post by bradleyjg »

ksplicer wrote: post #49
bradleyjg wrote: post #20

Google engineers just don’t seem to value back compat in their bones. I’ve read they have tools and processes internally that let them make breaking changes and globally find / fix callers. That’s cool, but the rest of don’t have that. No one likes getting an email that says “we’ve changed the way X works, you have until Y to change your code or it will break.” Not even if Y is a year from now. A rule that says no br…

This has nothing to do with what Google engineers value and everything to do with what management above them values. At Google you don't get promotions or raises for maintaining products, you get them for launching new products. That's the full story of how you get all these deprecations. Google management has been trying it's harded to kill the company for a long time.

Sure, it’s almost always the case that a corporate culture is heavily influenced by the incentives put in place by management. But those incentives and that culture influences what engineers value. That’s how the mechanism works.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#78

Post by mschuster91 »

adrr wrote: post #69
unicornmama wrote: post #13

We noped-out or Google cloud because of this. It wasn’t hard to drive home the argument after they rug pulled Google Domains.

That was a poor decision. Every other cloud provider has domain support. Just left my CTO role at a public company to do a another startup, GCP wasnt even in the running. It was between Azure and AWS. Also the first company i didnt pick GSuite or whatever they are calling it now because they fail to innovate on it. Office365 has been beating it in feature launches like adding an AI copilot and AI generated meeting su…

> Google needs to fire their leadership. They will be the next IBM if they dont.

Which is still a pretty good position... endless amounts of money coming in from legacy services.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#79

Post by pargon »

jvolkman wrote: post #48

I had this experience with AWS earlier this week. ======== Hello, This is a reminder to update your policies to avoid changes to your access to AWS Billing, Cost Management and Account consoles. Our records indicate that you are still using retired actions to access these consoles. If your policies are not updated with new actions by December 11, 2023, your users’ access to the AWS billing, Cost Management, and Accou…

I've built a startup on AWS, and same. Since we started about a year ago, I've gotten two "action required" messages from AWS.

One involved migrating our Go-based lambdas from the "Go 1.x Runtime" to a more generic one that AWS wants to use for compiled binaries across languages. They provided a very helpful guide, including the Cloudformation template changes. I implemented them, and they worked perfectly just as promised.

The other message I got was rather urgent and telling me I need to upgrade the SSL cert on my RDS. The due date on that action is August 22, 2024.

There are a few areas of AWS I've found to be pretty abandoned. (Don't try to send push notifications using the AWS Platform Application + SNS approach, woof.) But overall, I've been very happy with AWS as a developer.

Re: Dear Google Cloud: Your Deprecation Policy Is Killing You (2020)

#80

Post by ufmace »

crote wrote: post #58
f33d5173 wrote: post #41

Earlier quoted context omitted.

A major critique of the python transition is that they forced you to port your code instead of supporting python 2 code alongside python 3.

Python 3 was released in 2008. Python 2.7 was supported until 2020. They supported Python 2 alongside Python 3 for 12 years. They provided an automatic conversion tool. They provided libraries which made it possible to run the same code on both 2 & 3. The transition sucked, but they did everything they could to make it as smooth as possible.

My impression is rather different. The automatic conversion tools and compatibility libraries were only provided several years and versions into the v3 transition because the community was demanding it so hard and most users refused to do anything with v3 without it. Most of it probably wouldn't have been necessary at all, or would have been there on day 1, if they had made backwards compatibility the priority instead of going hard on the everyone rewrite everything to the new v3 style right away. I'm sure they didn't want to support Python 2 for 12 years but were instead basically forced to because the transition was so difficult for so many major projects.
Post reply on HN