I think it’s basically the attitude “customer support is expensive and annoying, and since we’re Google and can do whatever we want, let’s skip it.” This kind of made sense when they had a massive tech advantage such that their products also needed less support.

Now they seem to have lost that edge and are just another competitor offering products that come with poor support.

I’d like to draw parallels to the old cable titans with local monopolies who also had the same customer service tactics as well.

1. Offer a cheap (free) service

2. Gain significant market penetration

3. Provide little to no customer service

4. Raise prices

5. Let the product/services degrade until significant public outcry or regulator involvement

Customers? Them thinking of us as peasants, or even cattle, might better explain these attitudes.

The term of art is "Chattle", as in "Trespass on Chattle". e.g., start by reading section IIa of this:

https://digital.sandiego.edu/cgi/viewcontent.cgi?article=316...

Essentially, Intel employees are 'chattle', and while communicating with them doesn't transfer ownership or control of them away from Intel, it does interfere with Intel's ongoing use of them.

The spirit is the same, but I don't think we're talking about the same thing. It's "chattel", and according to wikipedia, for whatever that's worth, it's "trespass to chattels".

I didn't see any reference there about treating people in a customer relationship as the "chattel" referred to in this law.

It wasn’t originally meant to be applied to employees. That’s a modern interpretation. It seems inevitable that some court will extend the interpretation to customers too.

I don’t think it’s reasonable. I think it’s poor engineering.

Imagine if a hard drive had a limit on the number of files, not just the size. Would that be reasonable.

Or imagine if someone designed a storage protocol and submitted it to IETF with such a limitation saying “it doesn’t affect the vast majority of users so we set this arbitrary limit to make our lives easier.” It would not make it through review.

https://en.wikipedia.org/wiki/Comparison_of_file_systems almost every filesystem has a limit. Some document it, some not. Some limit it per directory rather than globally. There are also path limits which are effectively a file number limits as well. But the limit itself is very normal and would make it through reviews without issues.

NTFS and ext4 have a 2^32 limit according to this table. The Reddit poster mentioned in the article [0] has 2 TB worth of space. I’m not sure if that’s decimal or binary TB, but if we assume binary, you get an average of 512 bytes per file, which is pretty reasonable (and on a real drive, you might be limited by sector size).

But even if you had a 20 TB hard drive, and you wanted a lot of files smaller than 5120 bytes, you can just create multiple partitions. Maybe a little inconvenient, but you can still use your drive to the fullest. Not so much with Google’s 5 million limit (for a 2 TB Google Drive, the minimum average file size is around 430 KB [2])

[0] https://www.reddit.com/r/google/comments/123fjx8/google_has_...

[1] https://www.wolframalpha.com/input?i=%282%2F2%5E32%29+TiB+in...

[2] https://www.wolframalpha.com/input?i=%282%2F5000000%29+TiB+i...

Sure, everything has some limit. But the lowest limit I see on that page is 2^32, which is just a touch higher than 5 million. (/s) And far more importantly, none of those filesystems just decided one day to reduce the limit, which is kind of a big deal. (Although funny, in a horrible way; imagine booting up your machine one day and it tells you that your home filesystem needs to drop a few million files before it can mount. Can you imagine?)

> none of those filesystems just decided one day to reduce the limit

Yes and no. This works differently from one filesystem to another, but search for "running out of inodes" to find many ways this can happen in reality, way below the technical limit of the filesystem itself. You can end up in situations where you can't create a new file and need to remove more than one to solve the situation. (Or even where removing many files doesn't seem to make a difference)

The thing about running out of inodes is that the format command scales them with the size of the drive, and the default is 1 inode per 16KB. So for a standard google account at 2TB or maybe 5TB you'd have 125 million or 312 million inodes.

They've basically gone and set it up like "largefile" mode, 1 inode per 1MB, forced upon all users. That's a bad default and an even worse mandate.

File systems do have a limit on number of files, though as far as I know they're all quite a bit higher than anything in the millions.

Of course, with a physical disk there are also things you can do to get around those limitations, like switch to a different filesystem or use multiple filesystems on one disk.

Using the cloud leaves you exposed to the whims of the cloud provider. They select and switch technologies based on their needs instead of yours, and can arbitrarily change the restrictions.

If you manage to hit five billion files (which seems to be the standard limit), you might be in the market for object storage rather than new frontiers in file systems.

> five billion files (which seems to be the standard limit),

Article says 5 million? Still a big number, but smaller than 5 billion.

We're talking about file systems.

Then where are we getting 5 billion? The most common filesystem limits listed seem to be 2^32, which is a touch over 4 billion, and 2^64, which is Big.

(i.e. I can see now what I think you meant, but "5 billion" is a much closer match to "5 million" than 2^32)

My brain doesn't do numbers so good, so 4,294,967,295 became 4,924,967,295 and I rounded up instead of down.

Ah, that makes sense. Completely understandable:)

> Of course, with a physical disk there are also things you can do to get around those limitations, like switch to a different filesystem or use multiple filesystems on one disk.

So, use another Google account? If someone's workflow depends on one Google account, sounds like they need to understand the concept of sharding.

Of course they have limits, but the limits should be based on the design. And cloud should have a phenomenally high level.

It's poor engineering to not understand that everything has limits.

Everything has limits. The limits should be based on hardware limitations, not arbitrary limits. The limits should increase over time.

Said like someone who has never run out of inodes! There's a reason `df -i` exists.

Without a limit, you could design a storage system using empty files on google drive with limitless storage potential.

Why couldn't Google just count the file name length and perhaps a small constant metadata size against your quota?

That is a limit. It’s a different one but it tacitly accepts that some check is needed.

They already had a total size limit. The complaint is that they introduced a new one without really telling anyone.

Not a limit as small as Google set, and not a limit added overnight without any previous announcement or grace period. If you want to limit storing data in names of blank files, you could say “blank files, files smaller than 1024 bytes, and folders are counted as 1024 bytes for quota purposes”. A minimum billable size seems fair to me, and there is prior art (e.g. AWS S3 has minimum sizes for some storage classes).

on real filesystems, directories are effectively files and take up space. I see no reason for them not to have zero byte files take from the storage limits due to metadata.

> Imagine if a hard drive had a limit on the number of files

NPM developer?

<ducks>

pnpm helped me a lot with this.

For the record, Google does run a full communications channel for cross-Google support for subscribers of Google One.

Google could have (and many expected them to) eat Amazon's lunch for cloud compute back when it was new. However, Amazon actually had infrastructure around customer support while Google famously really doesn't. From what I gather Google cloud is technologically better, but no one wants to use a cloud from someone who doesn't do customer support as well.

I interviewed with Google Cloud a few years back and they straight up told me they were behind both AWS & Azure as a product and were lacking in user support. They said they were trying to build out an org to address it.

I've got a tale of two clouds. I complained about an issue with AWS on Twitter and two hours later was on a call with the EKS product manager who connected me with someone on their team who documented the issue, gave me a workaround, and then pushed out a fix to everyone a few days later. It was super impressive!

I complained about a separate issue with GCP. The product manager found my tweet and told me it was my fault for using a service marked as "preview". He then told me I should have used a different service, which was also marked as "preview". They were rude and defensive and made no attempt to resolve my issue. We decided to just not use GCP for the project as a result.

Neither of these are isolated stories. I have multiple examples of GCP staff just being super rude for no real reason, while AWS regularly goes above and beyond with customer service.

This matches my experience. GCP was like IBM a decade earlier: they assumed the name alone would close the deal and we didn’t feel like paying more for the privilege of doing their jobs for them.

I've experienced both:

One time two very competent guys shows up on site and let me reproduce the issue, agrees it is a serious bug and promises to take care of it.

Next time I get connected with what seems to be two part time students or something who doesn't seem to have a clue about the product.

Then in a third case some technical architect or something looks into my stack overflow question, verifies there is a known bug and it will be fixed in next monthly rollout, but I never saw a fix.

What's better is when their community forum "expert" redirects you to the first Stackoverflow link on Google - even though it is a band-aid solution that doesn't even solve your problem.

I had a similar experience, though it was years ago. Found a minor bug in Elastic Beanstalk and opened a ticket. They confirmed the bug and rolled out a fix in the afternoon. I was very impressed.

I've had very similar experiences with Google products. Their "support" for many products tends to be primarily community forums. And on those forums, "if you don't like it then don't use it" seems to be the standard type of answer.

> From what I gather Google cloud is technologically better, but no one wants to use a cloud from someone who doesn't do customer support as well

I have a hard time using any of google's stuff - cloud, whatever. Have had to deal with 'google search console' recently. "Give us your sitemap!". OK... "Could not fetch". The explanation for "could not fetch" might be "couldn't fetch" or "hasn't fetched yet" or "read but not processed" or "error reading" or.. anything else. On March 9, I had a sitemap entry listed as "couldn't fetch" updated to "last fetched date" of March 10 (9am UTC-4, so not even close to march 10 UTC time). It's just.... buggy. Colleagues currently moving stuff to google cloud (by edict of cto) are encountering bug after bug after slowness after flakiness. Google "support", to the extent they answer, says "we don't know".

Might it have been 'technically better' on day one? perhaps. But if it's buggy/flaky to deal with, and they have no support, not sure how you'd even verify the "technically better" part. How would you trust any numbers you see reported in their own tools?

Had to use GCP stuff about 6 years ago. It was flaky/slow and relatively unsupported then. Watching colleagues go through stuff today, in 2023, it seems no better.

I use both in my day to day work. My takes right now:

Roles/Permissions in GCP is just done better. The whole system of having to switch roles to be able to see stuff across multiple accounts in AWS is opaque and confusing. TrustPolicies are powerful but feel unnecessarily complex for almost every use case. Google has its own warts around permissioning (doing things often requires an opaque role that you have to look up, the error message is often unhelpful). However, it’s better than unraveling the series of permissions needed to, for instance, have an app pull from an S3 bucket in AWS.

AWS sucks at naming things. Everything is some nonsensical acronym that only makes sense to salespeople at Amazon. When you wonder what Google’s load balancer product is called, you look it up and it’s perhaps unsurprisingly called Elastic Load Balancer.

Another plus for Google: Having IAP as a first class citizen is a nice way to avoid having to set up bastions etc when prototyping.

On the other hand, we just spun up a Karpenter instance in EKS, and according to my colleague it’s much better than Google’s Autopilot product.

Also there is a whole industry around getting support from Google, lol. We use DoIT at my place of work, which is a company whose entire business is to pool together customer accounts for volume pricing and white glove support from Google. Interestingly, the cost savings from volume pricing are so significant there’s no cost to end users for using DoIT.

Elastic Load Balancer is in fact an AWS product. I believe GCP's equivalent is called Cloud Load Balancing.

Your point is valid and something I've felt many times as well (Route 53 means DNS somehow???), you just happened to choose literally the only AWS product that is well named.

DNS servers listen on port 53 :)

True. But if you asked me what Route 53 does I wouldn’t be able to tell you without checking. Cloud DNS, OTOH, is a pretty descriptive product name. I’m not saying you disagree, just reiterating the point that AWS naming is just a little too silly and clever for its own good ;)

Google doesn't dogfood its own cloud. None of the popular services like Search, Gmail, or Drive actually use GCP.

Of course they don’t use layer upon any of their own services.

Otherwise what would they do when they inevitably get discontinued?

This is true and false. Google services, including GCP, run on its internal cloud. GCP is just a product on top.

Not so long ago (a few years), Amazon retail was not using AWS either (I think they do, at least partially, now).

Well, the problem with Google is that AFAIK they have no plans to onboard their important services like Search onto GCP. I believe a few years ago they have tried but found the GCP tools too lackluster for internal use.

> From what I gather Google cloud is technologically better

It's a shitshow. Their design is ridiculous, overcomplicated and opinionated. It's clear they are run by engineers because no sane human would choose to use GCP knowing how bizarre and painful it is.

Creating an IAM role isn't strongly consistent. You have to build your own polling logic to wait for it to be done to attach a policy to it. Even using their own Terraform provider. If I worked there I'd be embarrassed.

As someone now in a position to make such decisions on a larger scale, GCP isn't even on my radar for this reason. I've had enough experiences with Google's lack of support when needed that it would take years of turnaround to undo that black mark.

AWS and Amazon as a whole has always had stellar support. And they'll continue to receive my business in both as long as that holds true, even though we rarely use it.

It is not reasonable at all if you sell the service by N gigabytes per month. They materially changed the service without telling anyone.

Google does this all the time, anyone who uses GCP, particularly BigQuery, knows all too well about stealth changes that break things.

What BigQuery changes have affected you? I haven't noticed any in years of regular use.

I believe it's related to the price changes they announced this week, it could double some use cases cost.

How about just not using google? There are viable alternatives to almost everything they offer. I haven't been using them for anything for a year now.

I find that my most often downvoted comments here.are those that shed negative light on Google. Curious.

> Leadership at Google ought to recognize this

It’s not a recognition problem, there’s no “aha” moment that will come from the right person just explaining it to them.

They simply don’t care, and have no incentive to ever change.

The common practice among other companies is this:

- Give old users approaching or exceeding limit with an additional 10% or 20% buffer.

- Ensure to notify all users about the change

- Update relevant support documentation.

Clear communication is crucial in addressing new storage limitation. For example, organizations might be archiving all their emails in a single Google Drive for legal discovery, AI training, or similar purposes. These companies may quickly reach the 5 million limit, but the situation can be resolved by dividing the content across multiple Google Drives or utilizing alternative storage solutions like Amazon S3 or Dropbox. No big deal.

The crux of the matter lies in maintaining clear communication.

> Having a limit of 5 million files is perfectly reasonable.

Is it? On this desktop I have 1.5 million files, "df -i" says I've used 1.1 million inodes and I have 61 million inodes free.

The 5 million file limit on Google Drive seems to be excessively low.

Note to Google, consider re-imagining your PhD's and MBA's as food service personnel.

Agreed, it's absurdly low. My rootfs is ~1 million files, with ~61 million free too; I only reinstalled Gentoo a couple of months ago, so I'm only using 180GB / 1TB.

> On this desktop I have 1.5 million files, "df -i" says I've used 1.1 million inodes

You have 400,000 files with 2 hard links? Or 100,000 files with 5 hard links each?

How? Why?

I'm not sure what you're asking? I'm happy to try and oblige, do you have a command I can run to answer your questions?

>Having a limit of 5 million files is perfectly reasonable

For ordinary users, this would pretty much equate to an unlimited account. Much like ATT's old unlimited bandwidth accounts. It's not until power users start hitting these ceilings to realize unlimited doesn't mean what they think it means. I don't know if Googs every used that kind of phrasing or not, but you can see where some dev never thought that limit would be achievable so there's no reason to really mention it.

Weird they don't consider how that sort of bad behavior impacts their other business.

I started a company in 2019 -> didn't choose G Suite, because I don't trust Google. Same for GCP.

I wonder if this message is getting through to Google, because the evidence suggests not. Any corp considering Google services has to seriously evaluate the risk that one day google will just decide to whack the service. Even in GCP, things that you might have thought would be solid for the long term, like IoT, can go away. Once you lose that trust, it's very hard to get it back. Azure and AWS I'm sure do their share of dumb things, but it really sticks to Google because everyone knows that they are infamous for killing products.

> Leadership at Google ought to recognize this

They're fully aware of how bad it is. They do not care. The Ad gravy train is still here, and they'll milk it until they can't anymore and then retire to their multiple homes (or go off and do it again to some other company).

I don't know why people expect leadership to do anything about a shitty company. They have literally no incentive to change. They'll always be hired somewhere else. Business as usual.

Even my bog cheap hosting lists storage limits and, "inode" limits on its dashboard. We're doing fine on both but way worse on the number of files.