Ymmv. I found a bug in their CA/PKI service, sent an example in and got a callback and feedback from a knowledgeable engineer who wrote me a workaround and put in a change request. I think the bug was fixed in a few weeks.

My team works with lots of companies, Google is one of the better ones in our experience. AWS is also excellent. I’m told Azure is good, but most of my experience with Microsoft is with enterprise product support, which is awful.

Which Support level do you have with GCP?

I haven’t used GCP support at work yet only as a hobbyist, sounds like maybe you had their enterprise support tier?

I've created several tickets against both AWS and GCP and had good and bad experiences with each. I actually used to have mostly bad experiences (a lot of useless back and forth, wrong answers, etc) with GCP but the last few years it's actually gotten significantly better. For example, we found a bug with autoscaling specific instance types (it's now posted as a known issue) and it was acknowledged and workarounds suggested without much hassle.

I find the self-serve UI and overall experience with GCP to be superior, so to me it’s a bit like the premium you pay for a Mac over a PC. Granted I never needed or wanted to speak to a human, but their infamy in that respect deserves a special nod of acknowledgment.

That's sort of the flip side of the coin. Google firmly believes that technology can solve everything and humans shouldn't need to be involved out of principle. So they build a great UI, great tools for devs and engineers to use, and then provide absolutely zero humans to support that.

I have a hilarious situation at the moment where they decided to shut down my Workspace account because they retracted the grandfathered-in free tier. This has 15+years of history of a small business I ran in it. I tried to move it to a paid account, but because the account was created in a different country to my current billing country, the form doesn't work (can't enter address for credit card). And there's just literally NO way to do it. No avenue to any way to contact a human to quite literally give them money. So in the end I gave up : downloaded the emails and resigned myself to losing all the other history associated with the account.

But what's really hilarious is they can't seem to shut it down either, perhaps for the same reason. Every time they set a new billing deadline it warns me with another spate of emails and then the date goes by and its still there. I suspect their software doesn't know how to shut down a hybrid multi-country account either, and there are no humans so they are stuck.

Sounds like you have the rarest of rare problems, being an immortal Google account that just won't die. ;)

I had this exact type issue for a charity account. A bit higher impact given team size but NO WAY to talk to a human!! Or if we did they couldn’t do anything. I imagine this has since changed, but it does leave a sour taste

This medium article seems silly, just add custom metrics to your app for what was fetched from cache vs DB. And label the metric by route/query/pattern. To control costs, don't tick the metric for every single request, instead accumulate locally and post to metrics API every X minutes.

That didn't exist back then. Adding logging all over the application would increase costs while losing a significant amount of money.

The problem is that Google had no problem billing for a metric that they didn't expose to the user and didn't provide tools to debug properly.

1. No it would not be expensive. Writing metrics is literally free: https://cloud.google.com/stackdriver/pricing . If metrics didn't exist yet then log 1/1000 requests to control the log volume and find the pattern from the averages.

2. It isn't up to google to tell you if you are querying against the cache or the DB. It's your code. You should know. Just tick something when you use the Redis/BQ/GCS/SQL client.

This task is so easy I would assign it to a junior engineer and expect code changes done in one day!

1. Logs are not free. Stackdriver was not an option back then.

2. If the phone company charges me extra they tell me which numbers I called. Here a cache miss started happening. Only in production with no tooling available (at the time) to determine why this was happening. A single number of "data read" was all the information given. Not even the table name... That means you end up looking for a needle in a haystack.

I'm guessing you work for Google because your attitude seems similar. No they don't *have* to provide that service which is exactly why they suck. A service oriented company would make the *effort* to provide a user with this information. Especially a paying user at gold level.

> accumulate locally

Is that an option in AppEngine? The memcache docs seem to indicate the free tier has undocumented eviction policies.

You have to implement that with your own code but it isn't much more than a dict/map and a timestamp for last update.

Same-ish problem, though. You wouldn't know for sure the instance will run again...your dict/map data can be dropped. I don't see any sort of instance timeout callback where you could guard against that.

I think it's negligible. The only metrics you lose are on rare scaledowns and they are averaged out anyways. GCP likes to keep instances idle for a long time.

I'm only considering them because of GKE autopilot and cloud run which both seem like completely painless ways to deploy containers (I've setup prototypes with both).