4 ms·

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 storag

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.

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.