Live data from Hacker News

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

steve-yegge.medium.com

11–20 of 126 posts

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

#11
post #7
post #6

Earlier quoted context omitted.

how do y'all look at systems like AWS Aurora, GCP Spanner, etc which offer big speedups and cost savings, but lock you into the platform in practice? this isn't academic for me - I've got a service that's on vanilla RDS PostgreSQL but growing fast, and I'll soon need to decide whether to move to something cheaper/faster but proprietary or blow my budget trying to stay generic...

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 of the work.

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

#12

This story resonates with me so much. An avid cloud platforms user in the past, now I just use Dockerfile + fly.io combo. Dockerfile gives you a total freedom without vendor lock-ins and forceful deprecations. I have never been calmer and happier before that switch. Now, only I decide when to upgrade - and usually it is as easy as editing a text file pointing to a new package version. IMHO, the only thing cloud provi…

Yes, I’m sure major corporations are going to trust their entire enterprise to fly.io and all they need is Docker and storage.

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

#14

This story resonates with me so much. An avid cloud platforms user in the past, now I just use Dockerfile + fly.io combo. Dockerfile gives you a total freedom without vendor lock-ins and forceful deprecations. I have never been calmer and happier before that switch. Now, only I decide when to upgrade - and usually it is as easy as editing a text file pointing to a new package version. IMHO, the only thing cloud provi…

Yes, I’m sure major corporations are going to trust their entire enterprise to fly.io and all they need is Docker and storage.

While you are being sarcastic, all corps, big and small, will be there one day. The situation is like using UTF-8 when everybody still rely on ASCII.

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

#15
> Successful long-lived open systems owe their success to building decades-long micro-communities around extensions/plugins, also known as a marketplace. I’ve ranted about Platforms before, and how important they are, and how Google has never once in their entire corporate history ever really understood what goes into making a successful open Platform, not counting Android or Chrome.

That one statement deserves its own essay in the context of Chrome and Firefox. It'll be interesting for anyone around in 30 years to look back and see how both those browsers are doing against the Emacs web browsers just to score the thinking.

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

#16

This story resonates with me so much. An avid cloud platforms user in the past, now I just use Dockerfile + fly.io combo. Dockerfile gives you a total freedom without vendor lock-ins and forceful deprecations. I have never been calmer and happier before that switch. Now, only I decide when to upgrade - and usually it is as easy as editing a text file pointing to a new package version. IMHO, the only thing cloud provi…

Yes, I’m sure major corporations are going to trust their entire enterprise to fly.io and all they need is Docker and storage.

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.

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

#17
post #6

Earlier quoted context omitted.

how do y'all look at systems like AWS Aurora, GCP Spanner, etc which offer big speedups and cost savings, but lock you into the platform in practice? this isn't academic for me - I've got a service that's on vanilla RDS PostgreSQL but growing fast, and I'll soon need to decide whether to move to something cheaper/faster but proprietary or blow my budget trying to stay generic...

Please tell how Aurora - which is just MySql and Postgres with a better underlying storage engine - “locks you in”?

I agree with you, but I think the idea is that the underlying storage engine affords you functionality that you can't mimic yourself / elsewhere and therefore your capabilities to leave are limited.

You're always "locked in" to some degree and it's an almost worthless thing to invest into if you never actually need to actually migrate off.

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

#18

This story resonates with me so much. An avid cloud platforms user in the past, now I just use Dockerfile + fly.io combo. Dockerfile gives you a total freedom without vendor lock-ins and forceful deprecations. I have never been calmer and happier before that switch. Now, only I decide when to upgrade - and usually it is as easy as editing a text file pointing to a new package version. IMHO, the only thing cloud provi…

Yes, I’m sure major corporations are going to trust their entire enterprise to fly.io and all they need is Docker and storage.

I take the “H” in IMHO (“in my humble opinion”) to mean “this is true to my situation, which does not mean it’s true for everyone”

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

#19

Earlier quoted context omitted.

Yes, I’m sure major corporations are going to trust their entire enterprise to fly.io and all they need is Docker and storage.

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 average enterprise uses 254 SaaS services. I have never in 5 years heard any CTO of any company of any size worry about “lock in” when considering their cloud choices.

Source: 2 years as an architect responsible for integrating acquired companies before a private equity owned company went public, two years leading the “application modernization” effort at a startup that exited 10x revenue, 3 years working at AWS in the Professional Services department and now working at a smaller consulting shop.

And I got Amazoned a couple of months ago. I have no particular loyalty toward Amazon

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

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

Also: keeping your product in beta for a decade is cute but unconvincing.

Post reply on HN