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

91–100 of 126 posts

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

#91

Post by VladTheImpalor »

anytime5704 wrote: post #82

It’s disheartening to read all the comments agreeing with this post. I actually worked on GCP for several years and we always made sure our customer facing API changes were backwards compatible. The decision to deprecate or “sunset” a feature was not taken lightly and needed to be announced O(years) ahead of time. Apparently, my team was an exception rather than the norm.

It's concerning to read your comment on this post, since it suggests you were unaware of all these issues people were facing with Google cloud. Was there not much cross talk or discussion of what issues the customers were experiencing with the platform as a whole?

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

#92

Post by scetron »

vrosas wrote: post #55
Havoc wrote: post #32

Yep. Been navigating the firestore / datastore maze and even though it mostly works I still can’t quite tell how the bits relate to each other. There is firestore on fire base side. And then on gcp side also firestore. Except it’s called datastore there. And comes in native flavour and datastore mode. And then there is firestore compatibility with native mode datastore. But also datastore in datastore mode. And they…

I can understand the confusion. A brief history lesson. Firebase: a paas that google bought that included a real-time nosql db (also casually called firebase) Datastore: googles OG serverless nosql db that was tightly baked into appengine as part of their own paas After buying firebase google decided the db implementation was shit and set out to write their own. In typical google fashion they picked the most confusin…

What would help is including a link from all the respective documentation to this comment.

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

#93

Post by busterarm »

gtirloni wrote: post #85
busterarm wrote: post #43

Earlier quoted context omitted.

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…

> 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 This vendor is certainly not GCP in this case. Every other week? Immediate rewrites? Is this even based on reality?

GCP is the best of Google's offerings and they still manage to do this. If you're using Google APIs like Places, AdWords, Geocoder, etc, they frequently make breaking changes with no announcement.

I've had many, many days in my career of having to drop everything to patch mission-critical glue code to keep up with Google APIs.

Also keep in mind that the documentation for their SDKs is frequently outdated and incorrect, especially around authentication and to the point that I often just deferred to reading the source code over reading their docs. And that's even if their SDK was in a working state, because often their own SDKs would lag behind their own API changes and you'd have to try out ruby, python or php to find one that worked properly (although golang always works, because that's what Googlers actually give a shit about).

Maybe its gotten better in the last few years, but that was solidly my experience from 2010-2018 and those were a lot closer to "Peak Google" than now. Now I write less code against their APIs, but I also have about 10M/yr in GCP infrastructure that I manage and it's also a treadmill even though we stick to the basics (VMs, GCS, Cloud SQL, GKE).

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

#94

Post by icedchai »

grumple wrote: post #66
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 s…

Ok, so don't change or upgrade anything for years. Sounds like a good solution. /s What happens when your VM host craps out and nobody knows how to restore it?

I once had a contract job at place that hadn't updated their systems in over 5 years. One server, a VM like you describe, had a 1500 day uptime. The VP/CIO was in a panic because nothing was supported anymore.

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

#95

Post by dontlaugh »

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.

Not even close. They could've not broken compatibility in the first place. They could've let Python 2 and Python 3 modules import each other in the same process.

With what they provided, even 3-4 years ago it was difficult to run some codebases on Python 3.

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

#96

Post by UncleMeat »

Brian_K_White wrote: post #81
UncleMeat wrote: post #57

Earlier quoted context omitted.

I think that there are competing cultures, and ultimately only one of them has the power to fire people. I'm currently losing a multi-year long siege to kill a project with significant external visibility almost entirely because of organizational structure. A series of reorgs and new VPs have ended up such that our VP doesn't give a crap about our project and the VP that does doesn't have a great relationship with ou…

"My experience is that people really do become proud of the systems that they build and that deleting them is something they avoid." Who is still in the same position or team 10, or even 2 years, or even 6 months later, especially in any faang?

I have been on the same team, maintaining the same system for 10 years here at Google. The median tenure on my team is six years.

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

#97

Post by anytime5704 »

VladTheImpalor wrote: post #91
anytime5704 wrote: post #82

It’s disheartening to read all the comments agreeing with this post. I actually worked on GCP for several years and we always made sure our customer facing API changes were backwards compatible. The decision to deprecate or “sunset” a feature was not taken lightly and needed to be announced O(years) ahead of time. Apparently, my team was an exception rather than the norm.

It's concerning to read your comment on this post, since it suggests you were unaware of all these issues people were facing with Google cloud. Was there not much cross talk or discussion of what issues the customers were experiencing with the platform as a whole ?

GCP is a gigantic organization and I was a cog in a machine.

I was aware that people criticized GCP for various reasons, but there wasn’t much I could do beyond my team/product area.

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

#98

Post by scarface_74 »

noirscape wrote: post #88
scarface_74 wrote: post #74

Earlier quoted context omitted.

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

Yes, in those cases the tradeoffs of lock-in are worth it. With that in mind though - F500 are the absolute peak of the economic market (since you know, that's how Fortune makes that list). They represent less than 1% of the total market in terms of actual needs. In those cases, the vendor lock-in from using a bespoke AWS or Azure solution are absolutely worth it because if AWS or Azure are an active problem they als…

What other parts? Are you suggesting they shouldn’t use SQS, SNS, DynamoDB, Lambda, etc?

Startups should use whatever technology that gets them to market fastest and the last thing they should be worried about is “lock-in”.

If they find product market fit and get customers, in normal times the money will come. Why worry about the “undifferentiated heavy lifting”?

Sure for Dropbox or BackBlaze, managing storage is their competitive advantage for instance.

But creating a AbstractFactoryRepositoryKeyValueFacade to avoid a DynanoDB dependency makes absolutely no sense.

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

#99

Post by lallysingh »

scarface_74 wrote: post #65
lallysingh wrote: post #42

Earlier quoted context omitted.

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”?

If they're getting screwed in pricing or availability vs a competitor, yes. They're asking "how's long do we have to stay with this bad option before we can switch?"
Post reply on HN