Live data from Hacker News

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

steve-yegge.medium.com

111–120 of 126 posts

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

#111

Earlier quoted context omitted.

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 dist…

> Again, you’re looking at your little piece of work that is a speck in an entire organization.

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

Of course not — he’s paying experts to avoid that situation, aligning with his strategic priorities.

That’s my job.

You also resorted back to personal attacks because you can’t make your point directly.

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

Like this ridiculous comment to someone whose job is being hired by CTOs looking to migrate.

They literally come to me, for help doing exactly that.

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

> I hardcoded the partition.

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

Yes — that’s why companies pay me: I’m used to doing things that can’t depend on a region, service, etc while AWS engineering frequently makes that mistake (eg, all the US-East-1 magic).

That’s precisely my point:

Quality coding avoids and bounds mistakes like that, which slow your migration.

- - - -

So you’ve resorted to personal attacks, but didn’t actually respond to my specific example, and were insistent on my credentials but still haven’t shared the largest system you personally have migrated.

But please keep it up: I make my money from people like you causing CTOs to hire people like me to clean up the mess — “whoops, accidentally wrote regionalized code!” or “we need over a year to migrate 100 VMs due to self-induced complexity!”

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

#112

Earlier quoted context omitted.

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 dist…

> Again, you’re looking at your little piece of work that is a speck in an entire organization. > 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. Of course not — he’s paying experts to avoid that situation, aligning with his strategic priorities. That’s my job. You also resorted back to personal attacks because…

Scenario: I have $aLotOfData in S3 and I need to move it to a MySql database.

Are you going to:

A) write an ETL job that is going to be slower and more complex to avoid the “lock-inz”

Or

B) just call run

“load data from S3…”

As a sql extension?

Are you going to tell them that they can’t use Glue? Athena? Redshift? Quicksite?

When your company needs a call center are you going to tell them not to use Amazon Connect? Now they need to integrate the call center with Salesforce - are you going to tell them they can’t do that because they have to use Lambda?

They want to have speech to text - now they need Amazon Lex.

Then they want a reporting dashboard that comes from their contact trace records. Now they need Kinesis which is going to stream to S3.

The typical company uses over 250 SaaS products that they have some form of integration with. Are you going to tell them not to use any of those either? Are you going to tell them not to use Salesforce? ServiceNow? Microsoft Office?

If you work in the health care industry are you going to tell them not to use Epic?

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

#113

Earlier quoted context omitted.

> Again, you’re looking at your little piece of work that is a speck in an entire organization. > 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. Of course not — he’s paying experts to avoid that situation, aligning with his strategic priorities. That’s my job. You also resorted back to personal attacks because…

Scenario: I have $aLotOfData in S3 and I need to move it to a MySql database. Are you going to: A) write an ETL job that is going to be slower and more complex to avoid the “lock-inz” Or B) just call run “load data from S3…” As a sql extension? Are you going to tell them that they can’t use Glue? Athena? Redshift? Quicksite? When your company needs a call center are you going to tell them not to use Amazon Connect? N…

That question depends on their priorities as a company: how do they value developer time vs lock-in vs complexity?

Which contrary to your repeated personal attacks is the sort of conversation I have with corporate leaders: they determine the strategy; I make it work technically.

But yes — there are clients who insist on avoiding those services (and generally would, if they’re migrating out of S3).

And in this particular context, we were explicitly discussing the decision of how to migrate a product into the cloud where I advocated using the cloud solution but taking a small step which would both ease that transition and any future ones — and you flipped out.

- - - -

To address your dramatic nonsense:

You don’t have to use Lambda to integrate with Salesforce; and you know that non-AWS call centers are used by most AWS customers.

> Are you going to tell them not to use any of those either? Are you going to tell them not to use Salesforce? ServiceNow? Microsoft Office?

This is just ridiculous dramatics completely unrelated to anything I said.

- - - -

Let’s ask a few questions to refocus:

- why were you so insistent on my credentials, but won’t share yours? …are you embarrassed by your largest migration?

- why can’t you address my specific example? …because it shows I have good advice and you spouted nonsense?

- why are you melting down into unrelated dramatics? …or pretending I advocated against using cloud solutions? …or integrations at all?

I think you’re just throwing up arguments at random because you can’t admit that on the original issue I was right.

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

#114
> 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. But I have a suspicion it’s nowhere near as often as happens at Google, and I believe wholeheartedly that this source of constant friction, and frustration, in GCP, is one of the biggest factors holding it back.

AWS very rarely deprecates APIs. The last API they deprecated (that I can recall) was EC2-Classic, and that was after 15 years of service AND having a vastly better alternative (EC2 with default VPCs) that almost everyone was already using.

In fact, AWS S3 is another example of a well-built, time-tested platform that passes the backwards compatibility test. AWS S3 spun up in 2006 or thereabouts. Even though the version of their most-current API schema is from *2012*, IIRC, you can still use code that you wrote back in 2006 to create stuff into buckets and store them.

Same with EC2 VPCs and core networking.

> Go ahead, I dare you. Follow the link and click the button. Choose “yes” to get all the default parameters and deploy the cluster to your Google Cloud project. Haha, joke’s on you; it doesn’t work. None of that shit works. It’s never tested, starts bit-rotting the minute they roll it out, and it wouldn’t surprise me if over half the click-to-deploy “solutions” (now we understand the air quotes) don’t work at all. It’s a completely embarrassing dark alley that you don’t want to wander down.

Azure 100% does the same thing with their Marketplace AMIs, and I'm almost certain that AWS has a ton of quickstart guides that straight-up don't work. My guess is that a Solutions Architect or Presales Engineer wrote the solution for a small handful of customers to use, then published it for "impact" and completely forgot about it to move onto the next big problem to solve. (Guilty as charged.)

However, if someone contacted Azure and AWS after running the broken quickstart asking for help, if they have enough money for support, they will absolutely get an SA to help them get up and running. Not sure about GCP. I suppose it's probably the same.

> Larry & Sergey got rid of all the unhealthy snacks by 2006 though.

I will always tell people about how when I worked there in Corp Eng in 2015 (worst job ever, unfortunately), all of the doors on their (many) fridges had large frosted glass films covering their bottom halves. The top half had "heatlhy" soft drinks and juices, along with seltzers and other low-calorie beverages. The bottom half? Good ol' fashioned American sodas...including diet, zero-calorie sodas!

You could go absolutely crazy gorging yourself on their infinite frozen yogurt and snacks (they definitely 10000% had unhealthy snacks when I was there) twice/day, but good luck finding the Diet Dr Pepper, I guess?

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

#115

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…

> A rule that says no breaks ever is probably not optimal either but it’s a big deal and should be treated as such. Maybe require a VP sign off or something.

Works for Microsoft, though!

See also: all of the super crusty VB6 and Win32 apps from 20+ years ago powering a double-digit percentage of everything on the planet

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

#116

Earlier quoted context omitted.

Scenario: I have $aLotOfData in S3 and I need to move it to a MySql database. Are you going to: A) write an ETL job that is going to be slower and more complex to avoid the “lock-inz” Or B) just call run “load data from S3…” As a sql extension? Are you going to tell them that they can’t use Glue? Athena? Redshift? Quicksite? When your company needs a call center are you going to tell them not to use Amazon Connect? N…

That question depends on their priorities as a company: how do they value developer time vs lock-in vs complexity? Which contrary to your repeated personal attacks is the sort of conversation I have with corporate leaders: they determine the strategy; I make it work technically. But yes — there are clients who insist on avoiding those services (and generally would, if they’re migrating out of S3). And in this particu…

You absolutely do have to use Lambda to integrate your call center with Salesforce. Your call center agents use their familiar Salesforce screen when a customer calls in.

But you’re so concerned with “cloud lock in” and you completely ignore the other 200+ services that the average enterprise is using. Why are you so concerned with the cloud, but not Salesforce, ServiceNow, Sharepoint, Okta, Azure AD, etc?

It makes no technical sense to spend developer time and add complexity to create an ETL job to do what a simple SQL statement can do.

None of this is “making the beer taste better”.

I’ve shared by credentials up thread - 2 years heading a migration and integration when a private equity owned health care company was acquiring companies to get big and go public, 3 years leading the application modernization effort for another company that was acquired at 10x revenue and three years working at AWS in the Professional Services department and now building out a professional services practice for an MSP for applications modernization.

And before that over 20 years as a professional developer

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

#117

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…

Oh we are posting emails. Here is one from google I have been ignoring because updating the app is so far down my todo list it will just never happen.

========

This is your final reminder: By November 1, 2023 version 4 will be deprecated and any updates to existing apps will first require you to migrate to PBL version 5 or newer. We are sending you this reminder as one or more of your apps is still using Play Billing Library (PBL) version 4. Important notes: If your app is targeting Android 14 or higher, you must update to PBL 5.2.1 or PBL 6.0.1 or higher. In May we launched Play Billing Library 6.0 with updates to subscription features, in-app purchase logging, and new API insights. We highly recommend upgrading directly to version 6.0 to future-proof your integration for the next two years and take advantage of the latest tools and features our commerce platform has to offer.

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

#118

Earlier quoted context omitted.

That question depends on their priorities as a company: how do they value developer time vs lock-in vs complexity? Which contrary to your repeated personal attacks is the sort of conversation I have with corporate leaders: they determine the strategy; I make it work technically. But yes — there are clients who insist on avoiding those services (and generally would, if they’re migrating out of S3). And in this particu…

You absolutely do have to use Lambda to integrate your call center with Salesforce. Your call center agents use their familiar Salesforce screen when a customer calls in. But you’re so concerned with “cloud lock in” and you completely ignore the other 200+ services that the average enterprise is using. Why are you so concerned with the cloud, but not Salesforce, ServiceNow, Sharepoint, Okta, Azure AD, etc? It makes n…

There is no technical requirement to use a Lambda to integrate Salesforce — feel free to cite contrary information.

https://help.salesforce.com/s/articleView?id=sf.integrate_wh...

> But you’re so concerned with “cloud lock in” and you completely ignore the other 200+ services that the average enterprise is using. Why are you so concerned with the cloud, but not Salesforce, ServiceNow, Sharepoint, Okta, Azure AD, etc?

This is a fantasy you invented about me because you cannot respond to my actual point — a strawman.

My original advice was to use the cloud — and I was addressing someone else’s concern about lock-in, while giving advice that would aid their initial migration to using cloud services.

I think that it’s very telling you can’t be honest about what I said.

> It makes no technical sense to spend developer time and add complexity to create an ETL job to do what a simple SQL statement can do.

As is this — another strawman you invented.

- - - -

Why do you have two strawmen, but haven’t in several posts actually addressed my specific example?

Are you unable to?

- - - -

What you’ve said is that you spent two years migrating just a hundred VMs, which sounds like a migration delayed by self-induced complexity.

I appreciate arrogantly incompetent developers like yourself — who can’t address technical points and instead resort to fallacious thinking:

Your work gets me paid.

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

#119

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…

Oh we are posting emails. Here is one from google I have been ignoring because updating the app is so far down my todo list it will just never happen. ======== This is your final reminder: By November 1, 2023 version 4 will be deprecated and any updates to existing apps will first require you to migrate to PBL version 5 or newer. We are sending you this reminder as one or more of your apps is still using Play Billing…

Working for two years is "future-proof".

Says as much in a few words as the original article.

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

#120

Earlier quoted context omitted.

You absolutely do have to use Lambda to integrate your call center with Salesforce. Your call center agents use their familiar Salesforce screen when a customer calls in. But you’re so concerned with “cloud lock in” and you completely ignore the other 200+ services that the average enterprise is using. Why are you so concerned with the cloud, but not Salesforce, ServiceNow, Sharepoint, Okta, Azure AD, etc? It makes n…

There is no technical requirement to use a Lambda to integrate Salesforce — feel free to cite contrary information. https://help.salesforce.com/s/articleView?id=sf.integrate_wh... > But you’re so concerned with “cloud lock in” and you completely ignore the other 200+ services that the average enterprise is using. Why are you so concerned with the cloud, but not Salesforce, ServiceNow, Sharepoint, Okta, Azure AD, etc?…

You did see the part about integrating Salesforce with a Connect call center didn’t you?

So I’m an “incompetent developer” who someone managed to get hired at AWS Professional Services not a third party partner - you to consult the largest organizations on the planet?

I’m sure an AbstractFactoryRepositoryFacade is going to prevent cloud lock-in while you advise people to create a complicated workflow when a simple SQL statement using an AWS extension would be faster to develop, more performant and less maintenance?

It’s not a straw man it goes to the core of the efficiency gains you get by taking advantage of your vendors functionality and integrating into it tightly instead of trying to maintain a leaky abstraction.

Post reply on HN