4 ms·

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 n

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.

zinekeller 3y ago
> 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.
- tight-ship 3y ago
  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).
gorjusborg 3y ago
I am guessing that you either aren't using it for business, or if you are, you are very small. The author's take is brutal, but totally on-point. The cloud business is about asking businesses to use your system as a foundation. Google doesn't take that seriously enough.
busterarm 3y ago
When you have 30 engineering teams all using different parts of the platform and your Product team is crushing your whole org with their aggressive roadmap, you will no longer feel like GCP policies are reasonable. When everything takes 20% longer to ship than you planned because every other week some random team(s) is forced to do unplanned, immediate rewrites by a vendor, that vendor starts to look like a dick and also a huge liability to your business. Also Google's own documentation is full of grenades. Just yesterday I found in their GKE docs something they tell you is the default and you must use it...except it doesn't apply to clusters created a few versions ago, even if they're updated, because they didn't roll their change out to existing clusters -- just new ones created after their change. Also google's docs reflect their deprecation policy -- there is no document versioning. You can always and only see latest.
- kuchenbecker 3y ago
  That backwards compatibility strategy to update defaults on new versions while leaving existing the same is to avoid the scenario you're complaining about by not changing behavior for existing customers.
  - busterarm 3y ago
    But then they don't have versioned documentation, so you only know how to properly operate the newest version of things and for the existing stuff you have to figure it out on your own.
- gtirloni 3y ago
  > When everything takes 20% longer to ship than you planned because every other week some random team(s) is forced to do unplanned, immediate rewrites by a vendor This vendor is certainly not GCP in this case. Every other week? Immediate rewrites? Is this even based on reality?
  - busterarm 3y ago
    GCP is the best of Google's offerings and they still manage to do this. If you're using Google APIs like Places, AdWords, Geocoder, etc, they frequently make breaking changes with no announcement. I've had many, many days in my career of having to drop everything to patch mission-critical glue code to keep up with Google APIs. Also keep in mind that the documentation for their SDKs is frequently outdated and incorrect, especially around authentication and to the point that I often just deferred to reading the source code over reading their docs. And that's even if their SDK was in a working state, because often their own SDKs would lag behind their own API changes and you'd have to try out ruby, python or php to find one that worked properly (although golang always works, because that's what Googlers actually give a shit about). Maybe its gotten better in the last few years, but that was solidly my experience from 2010-2018 and those were a lot closer to "Peak Google" than now. Now I write less code against their APIs, but I also have about 10M/yr in GCP infrastructure that I manage and it's also a treadmill even though we stick to the basics (VMs, GCS, Cloud SQL, GKE).

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.

zinekeller 3y ago

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

tight-ship 3y ago
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).

gorjusborg 3y ago

I am guessing that you either aren't using it for business, or if you are, you are very small. The author's take is brutal, but totally on-point. The cloud business is about asking businesses to use your system as a foundation. Google doesn't take that seriously enough.

busterarm 3y ago

When you have 30 engineering teams all using different parts of the platform and your Product team is crushing your whole org with their aggressive roadmap, you will no longer feel like GCP policies are reasonable. When everything takes 20% longer to ship than you planned because every other week some random team(s) is forced to do unplanned, immediate rewrites by a vendor, that vendor starts to look like a dick and also a huge liability to your business. Also Google's own documentation is full of grenades. Just yesterday I found in their GKE docs something they tell you is the default and you must use it...except it doesn't apply to clusters created a few versions ago, even if they're updated, because they didn't roll their change out to existing clusters -- just new ones created after their change. Also google's docs reflect their deprecation policy -- there is no document versioning. You can always and only see latest.

kuchenbecker 3y ago
That backwards compatibility strategy to update defaults on new versions while leaving existing the same is to avoid the scenario you're complaining about by not changing behavior for existing customers.
- busterarm 3y ago
  But then they don't have versioned documentation, so you only know how to properly operate the newest version of things and for the existing stuff you have to figure it out on your own.
gtirloni 3y ago
> When everything takes 20% longer to ship than you planned because every other week some random team(s) is forced to do unplanned, immediate rewrites by a vendor This vendor is certainly not GCP in this case. Every other week? Immediate rewrites? Is this even based on reality?
- busterarm 3y ago
  GCP is the best of Google's offerings and they still manage to do this. If you're using Google APIs like Places, AdWords, Geocoder, etc, they frequently make breaking changes with no announcement. I've had many, many days in my career of having to drop everything to patch mission-critical glue code to keep up with Google APIs. Also keep in mind that the documentation for their SDKs is frequently outdated and incorrect, especially around authentication and to the point that I often just deferred to reading the source code over reading their docs. And that's even if their SDK was in a working state, because often their own SDKs would lag behind their own API changes and you'd have to try out ruby, python or php to find one that worked properly (although golang always works, because that's what Googlers actually give a shit about). Maybe its gotten better in the last few years, but that was solidly my experience from 2010-2018 and those were a lot closer to "Peak Google" than now. Now I write less code against their APIs, but I also have about 10M/yr in GCP infrastructure that I manage and it's also a treadmill even though we stick to the basics (VMs, GCS, Cloud SQL, GKE).