Setup, updates, maintenance, tech support, and uptime guarantees, just to name a few reasons that "the cloud" is better. A service like Wordpress.com or Wix beats the self-hosted Pi on all of these counts.
I interact with a lot of non-technical small business owners and am "that tech guy" in their minds. A question I'm hearing more and more frequently is _why even bother with a website when a Facebook page is much easier and they can see people interacting with it._
Their reasons are not all that different from why many tech savvy HN readers are using a Mac instead of Linux: convenience; less shit to worry about.
Hosting anything on a Pi plugged into the wall goes in the exact opposite direction from what these people want. The centralized services are winning because they pay attention to what the market wants, they build it, and they make it easy to sign up.
If my roommate can plug a Roku into the TV, and knows how to use Ableton Live and Squarespace, there's absolutely no reason he couldn't use something like that.
And there's no reason that those non-technical people couldn't continue to pay you for helping them use stuff like that.
And there's no reason that people can't continue to use stuff like Facebook. But I have a feeling that people are going to be over that way of doing things by the time the next two decades are over.
If their home network is down, hopefully their office network isn't, or their business partners' networks aren't.
Also, these kinds of applications are practically begging for mesh networks. So what it means for a home network to be "down" could change a lot in the coming years.
The Internet is breaking all the time anyway. Every day at least one of the bigger / more important sites I visit has a temporary problem with something. Three days a week HN keeps returning CloudFlare errors to me. Even Facebook has some issues that break it every other week. The world isn't ending because of this, and it isn't going to end because the site I co-host with my other friend is down for the night.
As you grow to the point where close-to-perfect reliability matters, you'll be able to afford to get someone do handle the hosting for you, just like you do today.
For the price of hardware we're talking about, it'd just get replaced.
The bottleneck I see is bandwidth and government regulation of the electromagnetic spectrum. If Amit Pai gets his way then what you are talking about will be much more difficult.
I abandoned my Facebook account many years ago and refuse to set up a new one. As a result, it is difficult for my children to interact with me. They post their lives on Facebook, but they don't open that up to the public. So only specific Facebook accounts get to see what they share. That excludes me.
I have to open myself to Facebook to see their content. Alternatively, they could set up non-Facebook websites and "blog" their lives there. But that is harder than just using Facebook, and gets really hard if you want to keep it viewable only by select people. And then I would have to set up an account on their server to be able to see their content. Multiply that by all the people I would have to set up an account with and it's obviously unworkable pretty quickly.
I still hate Facebook, and refuse to set up an account with them. But I recognize that the alternatives are not pretty.
Edit: typos
The solution needs to allow identities which are "register once, use anywhere" across the web, and portable so that you can migrate to a different identity host/provider/implementation without losing all your accounts. Ideally these identities would also allow you to reveal as much or as little information about yourself as you want, and not force you to reveal some unique property which is correlatable between colluding sites.
Obviously that's not an easy thing to create, and may actually be harder than creating a viable rival to Facebook, but if we don't solve the web ID problem, then governments and corporations are going to "solve" it force us, and we'll all be the worse as a result.
It's a fascinating idea to have some means of identity authentication where the party seeking to authenticate your identity doesn't have enough identity information to connect the dots, and the party providing authentication doesn't even know about the party seeking authentication.
Setup, updates, maintenance, and tech support is however a thing, but there is always the fine print. The cloud generally do not maintain and update a website, and attacks generally succeed today by targeting poorly updated websites rather than servers. That leaves setup and teach support, two things which the website developer will often provide while they create and maintain the website.
Seems like the future to me, it's just not in any big tech company's best interest right now as they fight over data centers.
What if publishing to your blog was as easy as installing a Chrome web extension that now travels with you? Suddenly every computer you have that runs the extension can pin a local copy of the site, and your visitors help out by virtue of the protocol. This doesn't exist of course, but thanks to ipfs-js, it could, very easily. There are obvious drawbacks to this approach of course, but my point is that the "Hello World" of this kind of app could easily be much lower bar than setting up a Raspberry Pi.
Applications like Tox or Matrix (which uses servers, but not necessarily "centralized" servers) are great examples of dynamic p2p applications.
Or for example applications that use statically distributed javascript to facilitate dynamic p2p communications. Stuff like together.js, gun.js, freedom.js, etc.
Syncthing and Resilio Sync are also wonderful examples, and Resilio Sync has amazing encryption features: you can give out seed-only links to your data. People who use these links won't have permission to decrypt the content. They will only have permission to echo it. That's a "raspberry pi plugged into the wall at the coffee shop" solution to private, mutable content distribution.
As for the shopping cart example, this is something that could be conducive to a more centralized approach, especially if your physical distribution model is centralized and your payment system is centralized (traditional banks). In that of case, you'd want to have a more direct connection with the physical distributor. If you want a direct, instantaneous connection with the shopping cart company's servers, then that's what you need.
But it's possible to have a situation where your product is not physical (like music or video), and you are using a decentralized currency (like bitcoin). There's absolutely no reason you couldn't facilitate that in a completely distributed way.
By the way, Bitcoin is a banking app... Have you ever used a browser based cryptocurrency wallet? Imagine a browser based cryptocurrency wallet that's hosted on IPFS. That's a pretty distributed banking app. If you want privacy too, use zcash or monero.
To provide an argument that might fill this gap:
Most systems don't actually have a huge amount of data. Look at the data size and data growth of CRMs, special-purpose wikis, and so on: These are mostly smaller than 500 MB (excluding static content like images), and grow by less than 1MB even on a busy day. And that's the uncompressed size.
Also, most systems, despite being mutable, actually want (or need) an audit trail. So these are really append-only systems which merely have a "mutable look and feel" to the user.
I'm not following the logic of the argument here though, jumping from "X is good for Y" to "...don't actually have huge amount of data", perhaps you can elaborate?
With a merkelized append-only log (immutable DAG), there's always an audit trail. I agree with your point about "mutable look and feel", in a lot of use cases there's only a limited set of "writers" and updates happen infrequently.
Perhaps I should rephrase my previous comment, then, as "immutable systems are good for building mutable systems on top". Does that help to provide a better counter argument?
You can build mutable systems on top of immutable (append-only) systems. But is that a good idea? Yes, it is, for systems which don't have huge amounts of (non-static) data, and/or system which need an audit-trail anyway. And these are more systems than one may initially think.
I disagree that immutability is a negatively defining factor here re. data size or capabilities of the database.
If you look how many Big Data systems process data, you'll find that at the core of many, is an append-only log. For example: Kafka is a log (https://engineering.linkedin.com/distributed-systems/log-wha...), and looking at Apache Samza's architecture, we can see how a log is at the core of it (https://www.confluent.io/blog/turning-the-database-inside-ou...). In less Big Data orientated databases, there's always a log of operations (sometimes also called a transaction log or replication log) to keep the track of changes.
As with git, even if a version (commit) is immutable, it doesn't mean it's worth saving. Lots of times, you might make a temporary branch locally to do some work. Then you'll merge it and push the merged version upstream. Later you might check out a new copy from upstream, not caring that your temporary working branch isn't there.
User friendly versioning is a major challenge for dynamic, distributed applications. How do we gracefully bridge the gap between long term (distributed) memory and short term (local) memory? Each specific application has its own needs and tradeoffs.
And how do applications communicate about which versions are compatible with the applications' needs? About which versions are worth holding onto?
Why would something like a chat or email app need to hang onto that much history?
Imagine a distributed "email" app that uses networks of mutually trusted peers to deliver encrypted messages ("emails") asynchronously. My device doesn't need to hang onto your emails indefinitely. It only needs to hang onto them until they've been received. This could be done via explicitly sending receipts, or probably in most cases by giving stuff simple expiration dates. The sender would have the most incentive to hang onto the original message until its been delivered.
How this scales in terms of MB and GB is hugely dependent on how your application is configured, how frequently new data is emerging, the limits set by peers for how much they're willing to share, etc. But text is pretty cheap. I can't imagine storing 3 GB of yours or someone else's text emails on your phone, short term or long term. The raspberry pi plugged into the wall at your house can has much more storage anyway ;)
There are examples of the use cases you mention being built with decentralized technologies. [1][2]
[1] The various cryptocurrency wallets and exchanges
That assumes that all users are morons. If they want to pay anything to use else's hardware and energy then they only need to pick up their wallet and offer real cash. Offering another Dogecoin competitor to convince people to give away their energy bill and hardware is just a fancy way to officially assert that the people who fall for these gimmicks are complete morons who give away their resources in exchange for glorified arcade tokens.
Distributed computing certainly has it's role, but the added complexity of cache invalidation, versioning, and content synchronization are undeniable.
I hear you on the added complexity of it all, and I think that's why its taken so long for this stuff to be developed. It's been stewing for a long time. LANs have been around since before the internet, but a lot of stuff that's relatively easy on the internet is much, much harder in distributed and mesh networks. I think we're currently witnessing an epiphany.
Having the ability to recognize the same resource, and to request it, from multiple, disparate devices in just about any network setting is a totally different level.
And on a human level, I believe it could foster healthier social interactions around the sharing of digital content. When content is in its infancy, these kinds of applications create incentives, however slight they may be, to share it in closer physical proximity to people. It gives us back the awesome joy of the LAN party. Facebook says "you need to share your content via ISP and it must be stored on our servers at all times." Whereas distributed network applications invite us to imagine more humane, local, trusted environments for sharing digital content. If you want to share old family videos, get together for dinner, watch them on the TV and then share them privately over the WIFI. If you're in a band, make arrangements with local cafes to host your album. People who come for coffee will have the best bandwidth on it. If you're an artist, host your portfolio on your phone. Share it with people like you'd share a business card. If they like it, they may choose to help seed it, even without your asking. We're talking about the internet for LANs.
This stuff has the potential to refresh the art of digital collection and curation, something that's been co-opted by centralized content providers.
But the Android interface kinda stinks, so when I wanted to use it with "non-tech" people, I decided to just use Resilio instead. It's quite a bit more refined. I wish it was open source, but you can't have everything.
That's, flatly, a lie. There's a whole passage in the middle about how needing servers is a weakness of HTTP that this gets beyond.
Instead, we could put Raspberry Pis in our walls? We can do that now.
In a distributed web you need seeds. Whether they are called "servers", "peers", "devices", or "clients" is dependent on implementation and semantics. For the purpose of my comments I chose to call dedicated seeds "servers", because it made sense to me.
And yeah, we can do that now! I've even used an old cell phone with a busted touchscreen as a low power syncthing device. Mostly it was meant to relay notes between my phone and laptop if one or the other was sleeping or dead. It worked great. Eventually, I stopped depending on it, because I have a headless machine running now (a "server") that does the same thing.
All I had to do to migrate was share my syncthing directories with the server. It was a breeze. I didn't have to worry about configuring addresses or anything.
Also, the server is useful as a relay, but if my phone and laptop are both on, say if I'm working at the library or something, they just communicate directly. So I don't depend on the server in the same way.
Imagine that you and some friends want to launch a small local business and need to host a website. Instead of paying to host it "up in the cloud", why not plug a few raspberry pi's into the walls at each of your houses? Between that and also seeding it from your laptops, the site should have decent coverage. Maybe you could also offer some discounts for loyal customers who choose to seed it. This site will be redundantly hosted in the location where it's most likely to be accessed.
If you're doing something more permanent, then you will want to make sure you have more stable hosts, and not just some peoples cell phones. Just like you do now. It's the same thing as now. If you want to host something, make sure there is at least one computer that is serving it on a decent internet connection.
The difference is that with distributed web technologies, there is a smooth continuum for scaling. You don't even need to assume there is an ISP to seed! All you need is LANs. But if you want to do big things, you can harness the power of thousands of peers all streaming something that they're into.
I use syncthing and resilio sync all the time, and it works great with just 3 devices.