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

21–30 of 126 posts

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

#21

Post by zinekeller »

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.

> I find GCP policies pretty reasonable. I was never caught off guard by them.

For some individuals, sure. But other people and especially businesses don't really want change for change's sake (and if possible want to have a more-or-less set-and-forget thing), and the article clearly explains why it is better with AWS if that's the goal.

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

#22

Post by zmgsabst »

scarface_74 wrote: post #11
zmgsabst wrote: post #7

Earlier quoted context omitted.

Drive-by response: I’d ask two questions — how possible is it to isolate the code which is proprietary? …is there a third option which allows not blowing your budget, but remaining generic? Naively, isolating the proprietary interface in a wrapper in your code minimizes changes should you need to move — and blowing your budget isn’t a long term solution. So does it come down to the proprietary option or fail?

This would only come from someone who has never done or managed a migration at scale. There are so many moving pieces doing any migration at scale, your code is the least of the problems. I have seen it take nearly a year to migrate hundreds of generic VMs with VM hosted databases from on prem to cloud. You can’t get more generic than that. Yes, this was with AWS Professional Services (where I use to work) doing much…

Yawn, insulting others experience to make your point is trite.

Perhaps you could justify your point rather than attack other people and appeal to authority?

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

#24

Post by scarface_74 »

zmgsabst wrote: post #22
scarface_74 wrote: post #11

Earlier quoted context omitted.

This would only come from someone who has never done or managed a migration at scale. There are so many moving pieces doing any migration at scale, your code is the least of the problems. I have seen it take nearly a year to migrate hundreds of generic VMs with VM hosted databases from on prem to cloud. You can’t get more generic than that. Yes, this was with AWS Professional Services (where I use to work) doing much…

Yawn, insulting others experience to make your point is trite. Perhaps you could justify your point rather than attack other people and appeal to authority?

There is so much involved with any migration at scale - data migration, regression testing, network changes even where a company many have a physical connection to their cloud provider, security, compliance , training, and the list goes on.

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

#25

Post by zmgsabst »

scarface_74 wrote: post #24
zmgsabst wrote: post #22

Earlier quoted context omitted.

Yawn, insulting others experience to make your point is trite. Perhaps you could justify your point rather than attack other people and appeal to authority?

There is so much involved with any migration at scale - data migration, regression testing, network changes even where a company many have a physical connection to their cloud provider, security, compliance , training, and the list goes on.

Okay — and?

How is any of that relevant to what I said?

You’re ignoring that maintaining your code without modifying your data access (changing only the wrapper) significantly simplifies virtually everything you listed - with the exception of network topology changes.

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

#26

Post by fidotron »

The Android team did need to be told. There was a lot of internal dev pressure to abandon backwards compat (by which I actually mean reproducing bugs) even between immediate revisions.

At one point their (at the time brilliant) dev relations baited me into telling them “if the targetSdk setting isn’t for this exact problem then what is it for?” and never heard of them thinking of making such changes again.

The backstory was one product I had become responsible for was reliant on a bug in the inheritance implementation of the earlier VMs. I was stunned to say the least. That product happened to be FIFA which made my case somewhat easier.

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

#28

Post by gorjusborg »

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.

I am guessing that you either aren't using it for business, or if you are, you are very small.

The author's take is brutal, but totally on-point. The cloud business is about asking businesses to use your system as a foundation. Google doesn't take that seriously enough.

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

#29

Post by scarface_74 »

zmgsabst wrote: post #25
scarface_74 wrote: post #24

Earlier quoted context omitted.

There is so much involved with any migration at scale - data migration, regression testing, network changes even where a company many have a physical connection to their cloud provider, security, compliance , training, and the list goes on.

Okay — and? How is any of that relevant to what I said? You’re ignoring that maintaining your code without modifying your data access (changing only the wrapper) significantly simplifies virtually everything you listed - with the exception of network topology changes.

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?

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

#30

Post by secondcoming »

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…

Maybe they don't worry about it because they don't think there's anything to worry about it. The most expensive part of switching cloud providers is data transfer.

That's where the lock-in is, Kubernetes vs VMs isn't that big a deal at all; annoying sure. For the record, my employer uses both Kubernetes and VM. The deployment is pretty much the same.

Post reply on HN