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

61–70 of 126 posts

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

#61

Post by scarface_74 »

garganzol wrote: post #52
diarrhea wrote: post #31

Earlier quoted context omitted.

I guess the point is then: once you’re migrated over, you live happily. For a while. The next migration will come. It’s only a question of when. What then? You’re now so far removed from simple Unix-like principles, tools and platforms that migration will be harder by an order of magnitude (and you noted how much work it is!).

> You’re now so far removed from simple Unix-like principles, tools and platforms that migration will be harder by an order of magnitude Exactly my experience. Some services I manage are still entrenched in Big Co. Cloud, and it's a hell. This lock-in costs us additional money (thousands per year), but that amount is less than it would cost us to migrate those apps immediately. Unix is cool not because it's a Unix, b…

“Thousands of dollars a year” is probably a rounding error in your organization

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

#62

Post by Pet_Ant »

renegade-otter wrote: post #47
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…

Google culture in general seems to be "this is not fun or a very profitable, so we are just going to, like, not do it anymore". Fundamentally it comes from the fact that they don't have to do any of it anyway . Anyone using AdWords knows that it's a money-printing machine. Google is thousands of fresh CS graduates who want to do "cool green-field stuff" but not really the day-to-day grind we are all part of and what…

I'm doing boring enterprise maintenance for a lot less than Google money, maybe I should just apply. "No, I'm not Ivy league or MIT, but I'm great at taking abuse and grinding away thanklessly". Any chance that buys me a pass on not being great at memorizing algorithims?

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

#64

Post by mh- »

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?

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

#65

Post by scarface_74 »

lallysingh wrote: post #42
scarface_74 wrote: post #29

Earlier quoted context omitted.

Because in the grand scheme of things “your code” and even changing your code is just a minuscule part of what it takes if a migration did ever happen. So the question remains, have you ever been a part of a large scale migration? Have you ever been in the room when the planning was happening?

Yikes, no. Your code is the one thing you control. You can make it an asset for migration or a liability.

And “your code” is probably a tiny part of the entire enterprises architecture. The average enterprise has 250+ SaaS dependencies. Do you really think the CTO of a large organization is staying up late at night because a developer chose to use DynamoDB and didn’t put a facade over it to “avoid lock-in”?

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

#66

Post by grumple »

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 run things at a mid sized company and I get AWS emails like this daily. There's always something that needs attention. Except sometimes it doesn't really need attention. Other times it's something absolutely critical. Sometimes can't tell unless I read 50 pages of documentation and talk to their support.

Meanwhile at my old job, we had actual servers and vms in house. We had a machine running some obscure service sitting in a corner for two decades with no problems. Magical.

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

#67

Post by kuchenbecker »

busterarm wrote: post #43
gtirloni wrote: post #5

Just a rant about having to react to things that the author didn't want to react to. But these are facts of life. I find GCP policies pretty reasonable. I was never caught off guard by them.

When you have 30 engineering teams all using different parts of the platform and your Product team is crushing your whole org with their aggressive roadmap, you will no longer feel like GCP policies are reasonable. When everything takes 20% longer to ship than you planned because every other week some random team(s) is forced to do unplanned, immediate rewrites by a vendor, that vendor starts to look like a dick and…

That backwards compatibility strategy to update defaults on new versions while leaving existing the same is to avoid the scenario you're complaining about by not changing behavior for existing customers.

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

#68

Post by scarface_74 »

zmgsabst wrote: post #33
scarface_74 wrote: post #29

Earlier quoted context omitted.

Because in the grand scheme of things “your code” and even changing your code is just a minuscule part of what it takes if a migration did ever happen. So the question remains, have you ever been a part of a large scale migration? Have you ever been in the room when the planning was happening?

No — changing your code makes every one of those aspects harder, more time consuming, and thus a worse option. (Again, except network topology.) And yes — I’ve helped migrate global systems on the peta-scale, for finance where compliance is legally mandated. The idea that changing your code at the same time is irrelevant is laughable: Changing your software significantly while migrating has caused major errors in pro…

Again, you’re looking at your little piece of work that is a speck in an entire organization. Your CTO is working with your CIO, compliance department, finance department, product owners, the PMO organization, etc.

They are talking to the board about strategic decisions and what will give them a competitive advantage. He’s not losing sleep over whether you put a facade over your data access layer because in some distant future long after he is gone, AWS may raise prices.

If the spend is large enough, he’s going to talk to his dedicated sales rep to lower prices long before he comes to zmgsabt and asks him did he make his data access class “cloud agnostic”.

A dependency always slips in somewhere unless you are constantly testing and preparing for portability like Uber does.

Hell, I released code that was part of a major official open source “AWS Solution” and got complaints a few weeks later that it was dependent on a region and that’s not the first time I’ve seen that happen.

Let alone a dependency on all of the arns always having “aws” in them not thinking they wouldn’t work in China or gov-cloud. I hardcoded the partition.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

Another case is that “we are using MySQL to avoid lock in with AWS”.

Years later.

“Oh shit. The data team is loading data into the database using the AWS extension that lets you load data from S3 using a sql query”

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

#69

Post by adrr »

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 summaries. Spend less effort renaming products and more time building features.

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

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

#70

Post by scarface_74 »

noirscape wrote: post #56
diarrhea wrote: post #31

Earlier quoted context omitted.

I guess the point is then: once you’re migrated over, you live happily. For a while. The next migration will come. It’s only a question of when. What then? You’re now so far removed from simple Unix-like principles, tools and platforms that migration will be harder by an order of magnitude (and you noted how much work it is!).

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.
Post reply on HN