Thanks for the feedback. As the person that named both products, I can say we spent a ton of time debating this but we felt that the fact one is an enterprise file share and the other a document database service focused on mobile and web would mean very little conflict for customers. We will keep an eye on any customer confusion it might cause.
It explains why this is linguistically bad. Basically, a billion people on this planet don't distinguish between the l and r sounds, so for 1/6 of the planet, these names are identical.
Native Chinese speaker here. That post is comically wrong. For one thing, you don't pronounce either "file" or "fire" like "filer" or "firer" -- isn't English amazing ;) -- so there's no L/R sound in the first place for us to supposedly confuse.
I mean all of the following in the best possible way:
Perhaps also worth looking at the screenshot in the blogpost.
You have in there:
---
Datastore
Storage
Filestore
---
So, datastore is not storage, nor is filestore. What is it storage storing if not data or files? Why are files not data? I have no idea what should go where.
> We know folks need to create, read and write large files with low latency. We also know that film studios and production shops are always looking to render movies and create CGI images faster and more efficiently. So alongside our LA region launch,
So I couldn't create, read or write before without low latency? I thought this was already a feature of your other products
> we’re pleased to enable these creative projects by bringing file storage capabilities to GCP for the first time with Cloud Filestore.
For the first time? I couldn't store files before?
I'm not trying to be an arse, but I really don't get from this what the key difference is from everything else you offer.
> What is it storage storing if not data or files?
Objects. Cloud Storage is the S3 competitor.
> Why are files not data?
“Data” as in rows in a database. Like Dynamo.
Everything on a computer is data. The thing you’ve got to understand is that the terms we use, “objects”, “files”, “data” — these don’t refer to types of data, but rather to access paradigms for data. The semantics of their storage, indexing, mutability, etc.
An object is a blob of data named by a key, that you can retrieve entirely, or overwrite entirely, and where usually you automatically get a version history of old versions that have been overwritten that you can retrieve, with a cutoff for automatic GC.
“Data” is a structured tuple that a database knows how to index into, and sort by the columns of. You insert rows, update columns of rows by a key, or delete rows by a key.
“Files” are seekable streams where you can index anywhere into a file by position and then read(2) or write(2) data at that position, and where other clients can see those updates as soon as you sync(2), without needing to close(2) the file first.
All could be used to implement the other (S3 is implemented in terms of Dynamo rows holding chunks of object data, for example.) But each access semantics has use-cases for which it is an impedance match or mismatch.
Thanks for the explanation, the file/object/data difference makes sense.
> An object is a blob of data named by a key, that you can retrieve entirely, or overwrite entirely, and where usually you automatically get a version history of old versions that have been overwritten that you can retrieve, with a cutoff for automatic GC.
And yet they refer to the objects inside as "Files" and support seeking
I know this is just bikeshedding about names and terms but it feels confused.
I think some of the confusion in the list is because of the mix of generic and product naming.
Data can be stored in datastore. But also in "spanner" or "bigtable", which are not parts of "datastore", or in "SQL" which is a language. Object can be stored in the object store called "storage" which is also within an entire category itself called "storage". So there's "Storage" which is a group of all these kinds of stores, and "Storage" which is a very specific type of store.
I think its worth adding some additional phonetic context around this remark (I made a similar remark and my coworkers thought I was making a racist joke).
The reason native Japanese speakers struggle with "R" and "L" sounds is because they just have one phoneme to work with, which sounds (to a native English speaker) like a combination of "R", "L", and "D". If you aren't exposed to phonemes at a young age, it is difficult to expand your set later in life.
An analogous difficulty might exist for English speakers if a Chinese company came up with two product names which used the exact same sequence of syllables, but had "tonal" differences in pronunciation.
Similarly for Japanese, "file" is pronounced/written as "fairu" and "fire" as "faiyaa". If the service docs are translated, then they would look like (and sound as) difference names.
Not only is it confusingly similar to other storage products, but the abbreviations collide among all of them. GCF means how many different things now? (I always considered it to mean Google Cloud Functions - kind of an important product.) Don't underestimate the importance of these things. I can't even talk to my colleagues about your products without us all misunderstanding each other.
> I can say we spent a ton of time debating this but we felt that the fact one is an enterprise file share and the other a document database service focused on mobile and web would mean very little conflict for customers.
How about naming one as Cloud FileStore and other as Cloud DbStore?
Oh oh, it's already causing a lot of confusion. Just check the 70+ comments in this thread alone hating on the naming and professing their confusion and it's been out less than 12 hours... and that is from a self selecting very tech savvy audience. I think you've got a problem.
To be fair, I think “Filestore” in itself is a pretty descriptive name, and the real problem is the name “Firestore”. I can imagine the internal discussion when a bit like that as well, and here we have the result.
It's a clear blunt suggestion to get out of their bubble.
No one outside Google would hear that explanation and say "Yeah totally makes sense one of them is an enterprise file share and the other a document database service focused on mobile and web, crystal clear and very little confusion.".
What more do you want out of my comment for it to not be low effort? Write a 3 page essay about it carefully making a case based on peer reviewed scientific evidence?
Thanks for the feedback. As the person that named both products, I can say we spent a ton of time debating this but we felt that the fact one is an enterprise file share and the other a document database service focused on mobile and web would mean very little conflict for customers. We will keep an eye on any customer confusion it might cause.