Object storage is a higher-level abstraction than block-storage. FUSE and similar tech can do the job for basic requirements like read-only access by legacy applications but rarely works well for other scenarios.
A more complex layer like https://objectivefs.com/ (based on the S3 API) would be more useful, although I would've expected the cloud providers to scale their own block-store/SANs backed with object-stores by now.
Dropbox became popular because, from the perspective of 99% of users, it provides an incredibly simple and effective UX for syncing files across devices and locations. And better UX is enough to be a billion-dollar company.
Use Redis. It's an in-memory data structure server, first created to have the same data structures usable and accessible across processes and languages.
Or plenty of other in-memory database products (Apache Ignite) or fast key/value (ScyllaDB) or just use RDBMS (Postgres or SQLite).
What they expect and what they are (currently) legally entitled to can be separate things. Same goes for the rights you were taught that you have in school and how they actually work in the legal system.
Planetscale[1] is MySQL that is automatically sharded and proxied with a system called Vitess to scale horizontally. Because it's real MySQL, most functionality still works without the operations overhead.
Neon[2] is Postgres that has a surgically enhanced data layer that reads from a distributed set of nodes and object storage, but is still a single Postgres instance that's started and stopped on-demand and not automatically sharded. Because it's real Postgres, all functionality works including extensions without dealing with issues from sharded datasets, but also without the horizontally scalability and instant start (so far). However because the data layer is improved, the actual compute node is much more efficient in both startup and processing so it works well in many scenarios.
CockroachDB[3] is a proprietary distributed database built to Postgres wire/data protocol with natively separated storage and compute. Their serverless plan also starts and stops instances as traffic comes in but with fast startup because of their specific architecture. Because it's not real Postgres though, there's a good bit of missing functionality.
There's also TiDB[4] from PingCap which is similar to a MySQL version of CockroachDB, and Yugabyte[5] which is somewhat like Neon but with both distributed compute and data layers also using real Postgres components - however neither has a serverless offering.
Being boring has nothing to do with scale. Some of the biggest applications run on incredibly simple architectures, and often are able to scale so well because of that (boring) simplicity.
Definitely not. I'd much rather scale Postgres manually through layers of sharding and proxies than handle Cassandra.
There is ScyllaDB for a much better reimplementation of Cassandra/Dynamo, but wide-column databases are still best for niche scenarios, especially as RDBMS are rapidly evolving into natively distributed architectures.
Monolithic apps running on big servers talking to databases running on big servers. Very little orchestration overhead or complexity with serverless and the rest.
Everything from StackOverflow to ad serving systems to high-frequency trading exchanges are run this way.
What is your definition of non-boring architecture? I'm curious as to what you consider the exciting architectures necessary for scaling to make sure we're talking about the same thing.
Quora, Pinterest, Twitter, etc are all just big app instances talking to DB instances, with separate systems for background processing, queues, and caching. Are you suggesting that they would scale better with serverless functions instead?
I do not consider any of your examples really that simple or boring.
Boring to me is a load balancer, app server and cache. Once you start talking about background jobs and queues I don’t see how that’s any simpler than the alternative.
You could say Google, running Borg, is basically a database with a bunch of load balancers and background job processors. Obviously the complexity is in the scale and implementation.
Yes. Mobile and desktop apps have much more data leakage because they can store more data for longer and have much more APIs to use. A mobile app provides 100x more detailed data with more persistence than a website ever could.
This is well understood by the adtech industry and is why so many websites push apps in the first place.
Historically I think you are right but I'm not so sure it's still the case.
Do you think an iPhone with the tracking blocker engaged is still a richer source of data than the web app on an iPhone? Facebook claims that Apple's privacy protections cost them $10 billion of revenue the first year.
Most apps can use passwords from Chrome just fine, and you can also quickly open the native passwords window when encountering a password field using the key icon.
For TOTP, use apps like Authy which can be installed and used from multiple devices.
A more complex layer like https://objectivefs.com/ (based on the S3 API) would be more useful, although I would've expected the cloud providers to scale their own block-store/SANs backed with object-stores by now.