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

31–40 of 126 posts

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

#31

Post by diarrhea »

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…

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

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

#32

Post by Havoc »

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 all have different documentation pages and APIs and pricing and honestly wtf google

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

#33

Post by zmgsabst »

scarface_74 wrote: post #29
zmgsabst wrote: post #25

Earlier quoted context omitted.

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?

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 projects I’ve seen attempt it — you’re essentially doing a rewrite while trying to migrate, which introduces bugs in compliance, security, etc.

- - - -

Edit to include a specific example:

Let’s imagine I’m migrating a dataset, A. And my copy is A’.

In the scenario where I have some wrappers, W and W’, I can write my validation test on the data, T, to work against that interface.

So then T(W(A)) = T(W’(A’)) implies that W(A) = W’(A’), since T is a function (and the same code, run both places). My problem in demonstrating my data integrity reduces to ensuring that my wrappers faithfully marshal data — something I’ll get by writing unit tests.

In the scenario where I don’t have those data wrappers, I have to write two tests — T and T’.

But then what does T(A) = T’(A’) prove? Nothing directly — I need to prove that my two integrity tests are actually measuring the same thing.

In this way, isolating the complexity of your data marshaling directly impacts the complexity of downstream tasks, such as verifying the integrity of your data.

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

#34

Post by tight-ship »

zinekeller wrote: post #21
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.

I think this is a good point. Maybe GCP is failing at communicating why things are changing.

As a customer, I'd be fine with GCP doing things to keep their costs down so GCP pricing stays the same or decreases. But I understand this is hard to quantify outside GCP and requires a bit of faith (which I accept as inherent, since full transparency is impossible).

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

#36

Post by scarface_74 »

diarrhea wrote: post #31
scarface_74 wrote: post #19

Earlier quoted context omitted.

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…

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

And what about the 250 other SaaS services that your company uses?

Are you going to suggest that your medical software doesn’t integrate with third party EMH/EMR systems? That your call center and sales team doesn’t integrate with Salesforce?

What about your dependency on Workday? ServiceNow? Your project management software? All of the Microsoft software?

Yes even VMWare. There is a reason that AWS has a VMWare offering.

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

#37

Post by scarface_74 »

secondcoming wrote: post #30
scarface_74 wrote: post #19

Earlier quoted context omitted.

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.

The most expensive part is the staff and man hours.

Everyone here is completely ignoring the organization complexities.

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

#38

Post by rwmj »

ravivyas wrote: post #3

Note: Post is from 2020

The only thing that has changed is more stuff has been deprecated. I got an email from Google only last week that something in Analytics is changing (don't care - I stopped using it ages ago when it broke because of some earlier deprecation).

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

#39

Post by refulgentis »

scarface_74 wrote: post #12
garganzol wrote: post #10

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.

Idk. I don't think every major corporation can do that

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

#40

Post by djha-skin »

garganzol wrote: post #10

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…

One of our engineering teams wanted to use fly.io instead of kubernetes that I was running in AWS for the company. They really liked its ease of use and they really wanted to use it. Unfortunately fly.io only allowed 5,000 concurrent TCP connections, and there's was a chat app that needed to maintain many more web sockets than that for each instance that was running (More like 50,000).

So they ended up switching to kubernetes and AWS.

Fly.io is nice, but as far as scale is concerned, it's entry level.

Post reply on HN