4 ms·

I'd be interested in some concrete examples of things GCP have depreciated. I'm an (admittedly fairly light) user of GCP and haven't come across any myself.

by remus 6y ago

gostsamo 6y ago
Personal experience: I have to support an internal tool for a company in app engine. The contract is part time and I have to prioritize what issues to fix. The answer is usually "those caused by Google deprecating something". The nosql db some hyped individual has chosen years ago - "deprecated, we don't bother with solving bugs there". Email service: "it is in python2, but not in python3, look for management approval to use external service". File storage: "this library is deprecated, use whatever service is fancy now". Task queues: "nope, we are changing the api and calling it cloud tasks now, so please refactor all of your files to use the new semantics". The list goes on and on.
- dmitriid 6y ago
  Dataflow SDK libraries have updated their minor version from 2.4 to something like 2.16 in just two years. Guess what, everything below 2.14 is deprecated and not supported. And yes. Despite these being minor version updates, stuff will break if you go from, say, version 2.9 to version 2.11.
larrymcp 6y ago
I saw that he mentioned a few of them in the article. He writes: I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to... I dunno, _everything_, has forced me to rewrite it all after at most 2–3 years.
- habosa 6y ago
  I work on Firebase. His characterization of Firestore is incorrect and lazy. It did not replace Realtime Database (which is the product he’s calling Firebase) they are two products which live side by side and both are being actively improved. People assumed that because we made a new database we were killing the older one, but that was never true.
  - lclarkmichalek 6y ago
    Well, that’s a novel take on the customer is always right
    - joshuamorton 6y ago
      "the customer is always right" doesn't mean every individual customer is always correct and you should never disagree with any of them, it means the customer, in aggregate, is correct and you need to react to customer opinions. But also idk what else you'd want them to say "the thing you're taking shit isn't deprecated" seems like an important response to "you mishandled this deprecation".
  - zwily 6y ago
    I haven’t been totally happy with Google’s stewardship of Firebase, but that line in the article bugged me too. I didn’t think RTDB was ever deprecated.
- remus 6y ago
  Thanks for taking the time to list them out, didn't spot those in the article. Personally, I think most of them seem quite sensible. Having a 'support everything forever' approach is obviously going to impose a huge burden on the teams who maintain this stuff which is then going to limit the ability to make anything better. The depreciation notices generally seem pretty good (12-15 months notice by the looks of it, sometimes followed by degraded functionality rather than complete removal of the feature).
  - jto1218 6y ago
    that’s the whole point of the article though. Why should the “huge burden on the teams who maintain the stuff” be shifted to the customer who has less resources than Google to manage that burden. 12-15 months is not a long time. If you have to rebuild things that already work every year, you’re wasting a lot of time that could be spent building value for your customers.
  - calcifer 6y ago
    > Having a 'support everything forever' approach is obviously going to impose a huge burden on the teams who maintain this stuff which is then going to limit the ability to make anything better And yet AWS is doing just that while innovating at the same time.
    - remus 6y ago
      AWS depreciate things too, though. For example https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/ https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-...
      - calcifer 6y ago
        Deprecate [1] doesn't mean remove though. While the old style paths are officially deprecated, they will be supported indefinitely. GCP's problem is that they deprecate and remove features. [1] "Depreciate" is something else.
- tejohnso 6y ago
  I wonder what the complaints are regarding App Engine. I've been using it for over five years without any issue. Come to think of it, the Channels API shut down was a bit of a nuisance. But it never worked all that well, and deprecation seemed like a reasonable move to me. Here's a detailed list[1]. [1]: https://cloud.google.com/appengine/docs/deprecations https://cloud.google.com/appengine/docs/deprecations
- StopHammoTime 6y ago
  In relation to this, you then have AWS who basically support everything forever until their customers stop using it. They _still_ support people on EC2-Classic even though they would rather not. Every TAM I've come into contact with brags about how they won't deprecate until the customer deprecates. There's a reason that people trust Amazon with their compute, and that's because in regards to their technology they're trustworthy.
EE84M3i 6y ago
"depreciated"? In what sense do you mean? Taxes?
Mandatum 6y ago
Search each product in docs for the "Deprecate", "Deprecated" or "Deprecations" page (it's not common across product lines), they list every single functionality and date they deprecated stuff.. And yeah, they've done a fair bit. Example: https://cloud.google.com/stackdriver/docs/deprecations https://cloud.google.com/stackdriver/docs/deprecations

I'd be interested in some concrete examples of things GCP have depreciated. I'm an (admittedly fairly light) user of GCP and haven't come across any myself.

by remus 6y ago

I'd be interested in some concrete examples of things GCP have depreciated. I'm an (admittedly fairly light) user of GCP and haven't come across any myself.

gostsamo 6y ago

Personal experience: I have to support an internal tool for a company in app engine. The contract is part time and I have to prioritize what issues to fix. The answer is usually "those caused by Google deprecating something". The nosql db some hyped individual has chosen years ago - "deprecated, we don't bother with solving bugs there". Email service: "it is in python2, but not in python3, look for management approval to use external service". File storage: "this library is deprecated, use whatever service is fancy now". Task queues: "nope, we are changing the api and calling it cloud tasks now, so please refactor all of your files to use the new semantics". The list goes on and on.

dmitriid 6y ago
Dataflow SDK libraries have updated their minor version from 2.4 to something like 2.16 in just two years. Guess what, everything below 2.14 is deprecated and not supported. And yes. Despite these being minor version updates, stuff will break if you go from, say, version 2.9 to version 2.11.

larrymcp 6y ago

I saw that he mentioned a few of them in the article. He writes: I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to... I dunno, _everything_, has forced me to rewrite it all after at most 2–3 years.

habosa 6y ago
I work on Firebase. His characterization of Firestore is incorrect and lazy. It did not replace Realtime Database (which is the product he’s calling Firebase) they are two products which live side by side and both are being actively improved. People assumed that because we made a new database we were killing the older one, but that was never true.
- lclarkmichalek 6y ago
  Well, that’s a novel take on the customer is always right
  - joshuamorton 6y ago
    "the customer is always right" doesn't mean every individual customer is always correct and you should never disagree with any of them, it means the customer, in aggregate, is correct and you need to react to customer opinions. But also idk what else you'd want them to say "the thing you're taking shit isn't deprecated" seems like an important response to "you mishandled this deprecation".
- zwily 6y ago
  I haven’t been totally happy with Google’s stewardship of Firebase, but that line in the article bugged me too. I didn’t think RTDB was ever deprecated.
remus 6y ago
Thanks for taking the time to list them out, didn't spot those in the article. Personally, I think most of them seem quite sensible. Having a 'support everything forever' approach is obviously going to impose a huge burden on the teams who maintain this stuff which is then going to limit the ability to make anything better. The depreciation notices generally seem pretty good (12-15 months notice by the looks of it, sometimes followed by degraded functionality rather than complete removal of the feature).
- jto1218 6y ago
  that’s the whole point of the article though. Why should the “huge burden on the teams who maintain the stuff” be shifted to the customer who has less resources than Google to manage that burden. 12-15 months is not a long time. If you have to rebuild things that already work every year, you’re wasting a lot of time that could be spent building value for your customers.
- calcifer 6y ago
  > Having a 'support everything forever' approach is obviously going to impose a huge burden on the teams who maintain this stuff which is then going to limit the ability to make anything better And yet AWS is doing just that while innovating at the same time.
  - remus 6y ago
    AWS depreciate things too, though. For example https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/ https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-...
    - calcifer 6y ago
      Deprecate [1] doesn't mean remove though. While the old style paths are officially deprecated, they will be supported indefinitely. GCP's problem is that they deprecate and remove features. [1] "Depreciate" is something else.
tejohnso 6y ago
I wonder what the complaints are regarding App Engine. I've been using it for over five years without any issue. Come to think of it, the Channels API shut down was a bit of a nuisance. But it never worked all that well, and deprecation seemed like a reasonable move to me. Here's a detailed list[1]. [1]: https://cloud.google.com/appengine/docs/deprecations https://cloud.google.com/appengine/docs/deprecations
StopHammoTime 6y ago
In relation to this, you then have AWS who basically support everything forever until their customers stop using it. They _still_ support people on EC2-Classic even though they would rather not. Every TAM I've come into contact with brags about how they won't deprecate until the customer deprecates. There's a reason that people trust Amazon with their compute, and that's because in regards to their technology they're trustworthy.

EE84M3i 6y ago

"depreciated"? In what sense do you mean? Taxes?

Mandatum 6y ago

Search each product in docs for the "Deprecate", "Deprecated" or "Deprecations" page (it's not common across product lines), they list every single functionality and date they deprecated stuff.. And yeah, they've done a fair bit. Example: https://cloud.google.com/stackdriver/docs/deprecations https://cloud.google.com/stackdriver/docs/deprecations