That set of people is not that small; it is basically what people in business analyst roles do all day. They know Excel very well and maybe even a bit of python/js, have a good understanding of the business problem at hand, but not technical enough to do full on custom reports from scratch.
Data Studio fits squarely in this market of tools for them, and that space is growing and pretty crowded. There a multiple big businesses built on producing tools just like that, for example Tableau (public company valued at ~10B as of today).
Granted, Data Studio is more basic but it is free and nicely integrates with the rest of Google data product suite (Analytics, Sheets, BigQuery). I don't think it will go away, and I think it is actually the strongest part of google cloud offering (and the biggest gap in AWS cloud product lineup).
Thats a good point. My use is purely in the contest of advertising agencies where that role is very small. Most people are very good at analysing their specific channel, but can't do it in general.
AWS has a similar product, QuickSight[1]. It's not my favorite to use, but integrates with the AWS ecosystem as easily as Data Studio integrates with the Google ecosystem.
Yeah QuickSight is their shot at that market. But (anecdotally) I don't think it getting much traction. The fact that they didn't have any flashy announcements about it at re:Invent this year somewhat corroborates that. There is something in Amazon DNA that prevents them from building great UX-centric products.
Besides, without something like Google Sheets or Excel it is not that useful, inevitably you have a ton of small data across the org that is stored in spreadsheets.
One obvious play for Amazon is to just pay a ton of cash and acquire something like Airtable, but they don't seem to be for sale.
Although I've not tested if only having `s3:PutObject` even allows overwriting in the first place? You might not need versioning.
Also - they dont have `list` or `read` access, so they cant even see what files are there to overwrite in the first place. They might be able to guess depending on your code, but adding some random numbers and you'd be pretty safe.
Any AWS IWS experts able to confirm if `s3:PutObject` allows overwrite?
If you're using AWS anyway, I think using their managed Postgres / RDS could make this a lot easier operationally. No need for custom syncing/backup scripts, easier to scale the storage up.
To the larger point, while I totally agree with the premise -- most apps will never need to scale beyond one large instance, I'm not exactly sure what's the actual tradeoff is. If you're writing a simple CRUD app, it is not really controversial that it shouldn't need any complex distributed stuff anyway, it is just a simple python/Go app and a data store.
Most "fancy" things outside that single process paradigm, such as avoiding using local disk and using S3/RDS/document stores, using containers for deployment, etc. usually have more to do with making the app operationally simpler and easy to recover from instance failures than scaling per se.
> operationally simpler and easy to recover from instance failures than scaling per se.
I'd say architecturally making the app easier to perform this function, rather than rely on infrastructure to do it for you (and hoping doing so will make the app "easier" to code).
For example, use an append only data structure (like event sourcing), with snapshotting. Then your app recovery process is just "restart".
There is a certain amount of clarity or volatility in a system. Volatility will entail cost that will effectively be passed onto the buyer one way or another.
Google can be smart about it and try to do some predictions, but ultimately, the customer should in many cases know much more about what their usage patterns will be. This information reduces volatility and therefore cost ... passed on to the buyer.
If you say "I want to rent 10 cars for a month" vs. "I want the ability to rent from 2 to 20 cars for a month, not sure about what" - what is the intrinsic cost going to be for the provider? Even with demand smoothing over a large client base ... the increased volatility is cost.
I don't think this is related to gambling.
In many ways this is really similar to financial planning and I think the language of this article will make way more sense to financial types than technical types. I might even go so far as saying this is really a problem for financial ops, and not devops.
It's not a bad deal, companies purchase physical servers all the time which are around 3 year investments. Plus you can prorate your reserved instances to larger ones for only the difference in cost.
Between Cloud Storage, Cloud Datastore, Cloud Firestore and now Cloud Filestore the naming of these services is frustratingly confusing. Oh and of course there are also BigQuery and BigTable, which do not really give any clearer picture of the actual service. I've used GCP extensively for more than a year now and I still get confused about the different storage services way too often.
"Google Cloud Storage" could be a product but also the encompassing category of all the things you mentioned?
Also on the Firebase pricing page (https://firebase.google.com/pricing) they have a "Realtime Database", is that related to datastore or cloud storage?
They also have another item there just labeled "Storage". Is that one of the above?
And at the bottom you get "Google Cloud Platform" on the "Blaze Plan". Is that the products you mentioned that all start with "Cloud"?
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?
Between Cloud Storage, Cloud Firestore, and Cloud Filestore, I can't make heads or tails of the situation without diving into the docs.
I was confused when they introduced Cloud Firestore to compete with their Realtime Database (https://firebase.google.com/docs/database/rtdb-vs-firestore). Now it seems like they're doing it again with Storage vs Filestore, not to mention the horrendous choice of names.
Cloud Filestore specifically gives you a multi-host NFS interface (for traditional filesystem applications) like Amazon EFS - for applications you cant easily modify to use other APIs it appears like a normal filesystem.
Cloud Storage is an API-level object store (e.g. S3) that requires specific application support.
Most people can tell the difference between /naʊ/ and /nɑt/. I mean, just look at them... one ends with a consonant, one doesn't, and the vowels are reasonably different.
The difference here is between /faɪl/ and /ˈfaɪəɹ/, which is much more subtle. It comes down to the difference between /l/ and /əɹ/. The [ə] is an uncommon vowel in languages, unstressed, and mostly subsumed by nearby sounds. And worse, more than a billion people on the planet grew up speaking a language which doesn't distinguish the [l] and [ɹ] sounds (they're both approximants with only slight differences in articulation). So when you say "file" or "fire" these people can't distinguish which one you're saying, and when they say it they use something like the tap [ɾ] or retroflex [ɻ] instead, both of which sound ambiguous to native English speakers. Or some non-native speakers will use [l] exclusively, for both /l/ and /ɹ/.
FWIW, while Japanese doesn't distinguish L and R, "fire" is transliterated as ファイア faia while "file" is ファイル fairu. So the difference is reasonably clear.
The parent gave a phonetic explanation that has nothing to do with writing but rather hearing and speaking about it. For a billion people they aren't one letter away from each other, they're ~ the same. That's the point.
I am a bit embarrassed, but I had to read your comment twice to see that you mentioned two different products in your first sentence. So for me at least, GP comment is accurate.
Except "w" and "t" aren't similar in pronunciation. While "r" varies a lot in pronunciation across languages and regional dialects, there are many languages where the two ("r" and "l") require the same tongue position and a few languages where the two are (overly simplified) equivalent.
[1] https://observablehq.com/@oavdeev/parallel-task-latency-calc...