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

51–60 of 126 posts

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

#51

Post by atomicfiredoll »

unicornmama wrote: post #13

We noped-out or Google cloud because of this. It wasn’t hard to drive home the argument after they rug pulled Google Domains.

While my team and I were already getting progressively more skeptical of Google products for all the often retread reasons, the Google Domains issue in particular solidified my team's feelings as well into a single example as well.

I know there are SLAs, that Domains wasn't necessarily targeted at the same audience, etc. But, I'm guessing lots of folks got burned by it and I don't know how to justify trusting Google at this point. Given their struggles with their reputation and cloud offering, that situation and how they handled it still blows my mind.

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

#52

Post by garganzol »

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

> You’re now so far removed from simple Unix-like principles, tools and platforms that migration will be harder by an order of magnitude

Exactly my experience. Some services I manage are still entrenched in Big Co. Cloud, and it's a hell. This lock-in costs us additional money (thousands per year), but that amount is less than it would cost us to migrate those apps immediately.

Unix is cool not because it's a Unix, but because it's simple, aka Unix Philosophy.

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

#53

Post by dielll »

recently Youtube shows you a pop up that says they banned adblockers and even suggest that you pay for Youtube Premium. However, in my country if you click the Youtube Premium link, it says YouTube Premium is not available in your country"

I don't think Google takes their non ad products seriously. They only launch their products in few countries, the teams use them for promotion then abandon the products

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

#54

Post by miroljub »

garganzol wrote: post #46
djha-skin wrote: post #40

Earlier quoted context omitted.

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

The TCP connection limits are in place only when a central HTTP/HTTPS routing/termination is used. But you can turn that off by a config parameter in fly.toml file and by allocating static IPv4/IPv6 addresses for your app. By doing so, your app will be then fully responsible for handling all HTTP/HTTPS traffic by itself without external caps.

It's funny how people spend a lot of time and, in the end, choose a worse (unfavourable?) product just because of their inability to find a config switch that would solve all their issues and enable them to use their tool of choice.

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

#55

Post by vrosas »

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 confusing name and called it firestore.

Rather than maintain 2 different nosql databases google quietly broke datastore free from appengine and migrated everyone’s data to firestore. But to maintain compatibility they kept both sets of APIs so now you have Firestore native (to get people to move off firebase) and firestore in datastore mode (for anyone who was using the og datastore). The 2 APIs still have specific features and access patterns hence the differences in billing.

You can access and manage firebase both from the GCP console and the Firebase console but it’s the same db, same as how firebase storeage is really just GCS. So that adds another layer of confusion.

Hope this helps.

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

#56

Post by noirscape »

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

It does depend on the managed services you're using. Most SaaS companies do offer the "conventional" services managed; if all you need is a database, a cache and some sort of place to dump a docker container for your backend/frontend and not deal with the wires of manually setting up, connecting and securing all of it against the outside world, their offer makes sense. (And like... this describes the majority of internet tech stacks).

The hairy stuff is when you get into the highly specific offerings for each SaaS platform. They all offer a ton of them and they can certainly be attractive for some cases (ie. Filehosting) or useless in others (there's a lot of stuff that amounts to "our version of cache/database" and little else) but that's where the lock-in issues tend to play up.

GCP is uniquely terrible though from what I've heard in terms of support lifespan and utter unhelpfulness in terms of communicating to their customers when some SaaS offering of theirs are on the chopping block.

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

#57

Post by UncleMeat »

renegade-otter wrote: post #47
bradleyjg wrote: post #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 br…

Google culture in general seems to be "this is not fun or a very profitable, so we are just going to, like, not do it anymore". Fundamentally it comes from the fact that they don't have to do any of it anyway . Anyone using AdWords knows that it's a money-printing machine. Google is thousands of fresh CS graduates who want to do "cool green-field stuff" but not really the day-to-day grind we are all part of and what…

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

My experience is that people really do become proud of the systems that they build and that deleting them is something they avoid. This isn't coming from junior engineers wanting to do green field stuff. This is coming from VPs who swoop in and say "what I care about is this metric and if you aren't pushing on this metric then you are fired."

There are aggravating factors. Regulation sometimes means that core infrastructure needs to change out from under you, so the "it is stable and just needs a small amount of ongoing maintenance" doesn't always persist. I think that Google's monorepo also contributes to this. It has a lot of huge benefits but it also means that "keep the old version of library X around" isn't really possible.

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

#58

Post by crote »

f33d5173 wrote: post #41
bloppe wrote: post #23

I think python would've been in more trouble if it never made the transition to version 3. You probably shouldn't be building massive apps in Python in the first place.

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.

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

#59

Post by icedchai »

scarface_74 wrote: post #37
secondcoming wrote: post #30

Earlier quoted context omitted.

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.

Totally. Migrating anything is a PITA, even if it's simple. If it's complex and involves tons of code changes to eliminate "lock in", or more likely, move from one flavor of lock-in to another, you better think seriously whether it's even worth bothering.

Developer time is very, very expensive, and any time you spend "migrating" is time not spent building features that add value. Except in rare cases, the end customer probably doesn't care if your stuff runs on AWS, GCP, or Azure.

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

#60

Post by bitcharmer »

renegade-otter wrote: post #47
bradleyjg wrote: post #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 br…

Google culture in general seems to be "this is not fun or a very profitable, so we are just going to, like, not do it anymore". Fundamentally it comes from the fact that they don't have to do any of it anyway . Anyone using AdWords knows that it's a money-printing machine. Google is thousands of fresh CS graduates who want to do "cool green-field stuff" but not really the day-to-day grind we are all part of and what…

> Google is thousands of fresh CS graduates

This is exactly my impression judging by the quality of their products and Google's interviewing process.

Post reply on HN