7 ms·

> In my opinion the one thing that makes it hard for sandstorm to grow is the requirement that apps have to specifically be modified to work on the platform Th

> In my opinion the one thing that makes it hard for sandstorm to grow is the requirement that apps have to specifically be modified to work on the platform This is true, though of course without that requirement, Sandstorm wouldn't be able to do what it does. More broadly, I think the challenge we have today is that we've settled into a local maximum way of doing things that we call "Cloud Architecture" and "Software as a Service". The industry has spent many billions of dollars exploring and optimizing this approach. Even open source developers are designing their little apps using hyper-scalable techniques because they think that's what they're "supposed" to do -- never mind that such architecture is actively hostile towards small-scale self-hosting. I think the Sandstorm approach -- which is essentially "distribute apps to people's personal servers the same way you distribute apps to phones today" -- would be vastly preferable (both to users and developers), if it had the same level of development and investment. We can't just invest $100B upfront to build the new world, so instead we need to find an incremental strategy to get there. That's the hard part. Sandstorm tried to harness the investment already being made by "indie" / open source developers. We got a long way with not very much money! But the indie motif didn't exactly give us enterprise credibility, or any other way to sustain the company. My new hope is that "mainstream" cloud infrastructure will push towards being incrementally more and more decentralized on a technical level, because of the technical advantages that brings... If your software is designed to run as a million little servers rather than one huge one, then a company like Cloudflare (my current employer) can go deploy it to literally hundreds of locations around the world for huge savings in latency and long-haul bandwidth, better reliability, etc. Then once apps are designed that way, maybe, just maybe, it'll be easier to flip control of code execution and data away from the vendor towards the consumer? But obviously there's a long way to go to get there.

chuhnk 7y ago
We're broadly working towards a lot of what you're saying here at https://micro.mu https://micro.mu. It's an incremental process which I fundamentally believe needs to begin with giving developers a new method of development guided by a framework. We're leaning more towards the android model of managing a complex runtime and providing the framework for developing in that environment. We'll probably leverage cloud, edge, personal servers, mobile and any other device in the long term to move services to the user. I share a lot of your ideas and philosophy. Shame it didn't come to fruition with sandstorm.
mwcampbell 7y ago
One thing I appreciated about the Sandstorm architecture, and I wonder if you now consider this a mistake, is that each grain holds its own state, using ordinary files and possibly in memory (since IIUC, there's one instance of a grain running at any given time). But I would have liked to use an architecture like this in a SaaS application. We may wish that applications were self-hosted, but SaaS is what people are used to, and there's a lot of money in it. An architecture for SaaS applications based on many small, stateful units, like Sandstorm grains, would be a refreshing alternative to the current norm of trying to make everything stateless and web-scale. And I think it's something you could have sold. I remember proposing something like this to you on an HN comment thread a few years ago, but maybe I didn't articulate it well. The reason I wonder if you now see the statefulness of grains as a mistake is that Cloudflare Workers are going even further in the other direction. Whereas Sandstorm grains can be long-running, Cloudflare Workers are very short-lived. Of course, I realize that you aren't explicitly developing Cloudflare Workers as the successor to Sandstorm; it's a new product with its own requirements. Still, I wonder if your thinking on that part of Sandstorm has changed.
- kentonv 7y ago
  I still very much believe in the fine-grained instances model. Cloudflare Workers is a long, long way from done. Stay tuned... ;)
- solipsism 7y ago
  An architecture for SaaS applications based on many small, stateful units, like Sandstorm grains, would be a refreshing alternative to the current norm itof trying to make everything stateless and web-scale Can you expand on this? The way I see things, the more of my stack that's stateless the better. That goes equally at the application level and at the distributed system level. There are so many advantages to designing things that way that it's hard to imagine going back to the stateful "bad old days". So I'm curious to read a treatise about this alternative small, stateful units model you describe.
  - mwcampbell 7y ago
    For starters, I'll refer you to Sandstorm's own "how it works" page [1], which explains it quite well IMO. Basically, the Sandstorm modl works well for applications that consist of many small things -- documents, chat rooms, project boards, etc. -- each of which can easily run in a single process. Each grain can run in a self-contained process, with its live state being stored in memory, and using the filesystem for durability. When things happen within the grain, it can easily send out notifications to all connected clients, e.g. through WebSockets, because all clients are communicating with that one process (indirectly through a proxy, of course). Consider how much easier it is to implement real-time things, like chat and collaborative document editing, this way, compared to using message brokers, distributed pubsub systems, etc. As for scaling and high availability, as the page I linked explains, the platform takes care of that. [1]: https://sandstorm.io/how-it-works https://sandstorm.io/how-it-works
EGreg 7y ago
Any Sandstorm developers reading this... I would like to invite you to reach out to me. We’re trying to build this decentralized future and we’re making revenues — would be great to explore collaboration. Username: greg Domain: qbix.com See https://qbix.com/QBUX/whitepaper.html https://qbix.com/QBUX/whitepaper.html for the economics of it
sitkack 7y ago
There are a bunch of us out there that still believe in the vision. You were just too early. This needs some sort of WRT54G kinda moment, synology or ???, you needed to have a last mile partner or a host (vpn in to services). I thought containers were going to take over cloud in a pervasive way and it hasn't happened yet. I can't say thank you enough for what you have done. None of this was a failure.
- anderspitman 7y ago
  We'll get there. I don't believe for a minute that kentonv doesn't still plan on being a part of that future. > This needs some sort of WRT54G kinda moment, synology or ???, you needed to have a last mile partner or a host (vpn in to services) While I love the idea of everyone running their own hardware, I've been thinking recently that physical separateness might be the least important aspect of decentralization. I think alignment of incentives is more important. What I mean is that having your apps/data on google's servers isn't necessarily a problem, but being locked into their platform and unable to easily change is. When it's simple and convenient for customers to change providers, companies are incentivized to maintain high quality products and features such as privacy guarantees.
  - kentonv 7y ago
    I agree, but I add one thing that I've seen a lot of decentralization efforts ignore: If I decide to move servers, I need to be able to take with me not just my data, but my software (apps). Otherwise, self-hosting tends to mean accepting second-rate software, and choosing the best software means also choosing the servers provided by the same company. These should be separate decisions.
    - oscargrouch 7y ago
      Im creating something that take this into account; you should have a embeddable/movable entity where you keep your data, api´s and apps. And i tell you its a lot of work.. Was following Sandstorm closely, and despite the fact that im going with different choices compared with Sandstorm, your project was one that i instantly recognized to be tackling in the same domain. I mean, i think your meditation and problem solving are in the right place, we just need a couple more iterations , research and efforts to get there. I will try to give it a shot too, been working on this on a couple of years over the chromium codebase, with a design that was not quite right in the beggining, that needed couple more of iteration and tought, but that in the current incarnation, i think i might have something to show. I hope i can count with your comments and criticism when i launch it, which i believe, its only a couple of months from now, as i have a great respect for your work and your vision. You helped to move the needle forward in a domain we need desperately of a solution or else all of our data and freedoms are at stake (not to mention it can even be a better technology than the current cloud-corporate centric vision that are designed to maximize corporations profit and data centralization, where we dont actually own anything, anymore). So thanks for all of your work, it was really inspiring.
anderspitman 7y ago
Thanks for the thoughts. > My new hope is that "mainstream" cloud infrastructure will push towards being incrementally more and more decentralized on a technical level That sounds pretty close to what I'm doing with my current project. Start with a centralized platform that is instanced per-user under the hood, provide tangible benefits vs the big guys, and eventually open source it for self-hosting. That's the dream anyway.
canadaduane 7y ago
Loved your work & was an early supporter. If you haven't already, I think you should take a look at some really cool new possibilities in the app development space like automerge/hypermerge, braid.id, and gun.eco. These offer a new path forward where a home server is just one possible topology, but the data is freed from servers. See also https://github.com/SmithSamuelM/Papers/blob/master/presentations/DID_Everything_OpenWest2019.pdf https://github.com/SmithSamuelM/Papers/blob/master/presentat... (I particularly like how Sam has coined the term "autonomic data", meaning data that embeds its own authorization through encryption--once you separate authorization from distribution, you can do some amazing things).
indigochill 7y ago
>never mind that such architecture is actively hostile towards small-scale self-hosting Can you provide some information about why this is? Are you talking about vendor lock-in with certain cloud providers? Because Kubernetes, for instance, provides a layer that lets you move applications around (even locally with Minikube) with no fuss. So I suspect I'm misunderstanding what you're referring to.
- kentonv 7y ago
  1) Maintaining a personal server should be no more difficult than maintaining your phone, something that non-technical people can do. No command lines, no config files. Kubernetes obviously isn't that. 2) Kubernetes and other popular cloud infrastructure are designed to scale up to massive traffic, but they are not designed to scale down. For a personal server, you want to be able to install hundreds of apps on a single, modest machine, and only have apps consuming resources when the user is actively using them.

chuhnk 7y ago

We're broadly working towards a lot of what you're saying here at https://micro.mu https://micro.mu. It's an incremental process which I fundamentally believe needs to begin with giving developers a new method of development guided by a framework. We're leaning more towards the android model of managing a complex runtime and providing the framework for developing in that environment. We'll probably leverage cloud, edge, personal servers, mobile and any other device in the long term to move services to the user. I share a lot of your ideas and philosophy. Shame it didn't come to fruition with sandstorm.

mwcampbell 7y ago

One thing I appreciated about the Sandstorm architecture, and I wonder if you now consider this a mistake, is that each grain holds its own state, using ordinary files and possibly in memory (since IIUC, there's one instance of a grain running at any given time). But I would have liked to use an architecture like this in a SaaS application. We may wish that applications were self-hosted, but SaaS is what people are used to, and there's a lot of money in it. An architecture for SaaS applications based on many small, stateful units, like Sandstorm grains, would be a refreshing alternative to the current norm of trying to make everything stateless and web-scale. And I think it's something you could have sold. I remember proposing something like this to you on an HN comment thread a few years ago, but maybe I didn't articulate it well. The reason I wonder if you now see the statefulness of grains as a mistake is that Cloudflare Workers are going even further in the other direction. Whereas Sandstorm grains can be long-running, Cloudflare Workers are very short-lived. Of course, I realize that you aren't explicitly developing Cloudflare Workers as the successor to Sandstorm; it's a new product with its own requirements. Still, I wonder if your thinking on that part of Sandstorm has changed.

kentonv 7y ago
I still very much believe in the fine-grained instances model. Cloudflare Workers is a long, long way from done. Stay tuned... ;)
solipsism 7y ago
An architecture for SaaS applications based on many small, stateful units, like Sandstorm grains, would be a refreshing alternative to the current norm itof trying to make everything stateless and web-scale Can you expand on this? The way I see things, the more of my stack that's stateless the better. That goes equally at the application level and at the distributed system level. There are so many advantages to designing things that way that it's hard to imagine going back to the stateful "bad old days". So I'm curious to read a treatise about this alternative small, stateful units model you describe.
- mwcampbell 7y ago
  For starters, I'll refer you to Sandstorm's own "how it works" page [1], which explains it quite well IMO. Basically, the Sandstorm modl works well for applications that consist of many small things -- documents, chat rooms, project boards, etc. -- each of which can easily run in a single process. Each grain can run in a self-contained process, with its live state being stored in memory, and using the filesystem for durability. When things happen within the grain, it can easily send out notifications to all connected clients, e.g. through WebSockets, because all clients are communicating with that one process (indirectly through a proxy, of course). Consider how much easier it is to implement real-time things, like chat and collaborative document editing, this way, compared to using message brokers, distributed pubsub systems, etc. As for scaling and high availability, as the page I linked explains, the platform takes care of that. [1]: https://sandstorm.io/how-it-works https://sandstorm.io/how-it-works

EGreg 7y ago

Any Sandstorm developers reading this... I would like to invite you to reach out to me. We’re trying to build this decentralized future and we’re making revenues — would be great to explore collaboration. Username: greg Domain: qbix.com See https://qbix.com/QBUX/whitepaper.html https://qbix.com/QBUX/whitepaper.html for the economics of it

sitkack 7y ago

There are a bunch of us out there that still believe in the vision. You were just too early. This needs some sort of WRT54G kinda moment, synology or ???, you needed to have a last mile partner or a host (vpn in to services). I thought containers were going to take over cloud in a pervasive way and it hasn't happened yet. I can't say thank you enough for what you have done. None of this was a failure.

anderspitman 7y ago
We'll get there. I don't believe for a minute that kentonv doesn't still plan on being a part of that future. > This needs some sort of WRT54G kinda moment, synology or ???, you needed to have a last mile partner or a host (vpn in to services) While I love the idea of everyone running their own hardware, I've been thinking recently that physical separateness might be the least important aspect of decentralization. I think alignment of incentives is more important. What I mean is that having your apps/data on google's servers isn't necessarily a problem, but being locked into their platform and unable to easily change is. When it's simple and convenient for customers to change providers, companies are incentivized to maintain high quality products and features such as privacy guarantees.
- kentonv 7y ago
  I agree, but I add one thing that I've seen a lot of decentralization efforts ignore: If I decide to move servers, I need to be able to take with me not just my data, but my software (apps). Otherwise, self-hosting tends to mean accepting second-rate software, and choosing the best software means also choosing the servers provided by the same company. These should be separate decisions.
  - oscargrouch 7y ago
    Im creating something that take this into account; you should have a embeddable/movable entity where you keep your data, api´s and apps. And i tell you its a lot of work.. Was following Sandstorm closely, and despite the fact that im going with different choices compared with Sandstorm, your project was one that i instantly recognized to be tackling in the same domain. I mean, i think your meditation and problem solving are in the right place, we just need a couple more iterations , research and efforts to get there. I will try to give it a shot too, been working on this on a couple of years over the chromium codebase, with a design that was not quite right in the beggining, that needed couple more of iteration and tought, but that in the current incarnation, i think i might have something to show. I hope i can count with your comments and criticism when i launch it, which i believe, its only a couple of months from now, as i have a great respect for your work and your vision. You helped to move the needle forward in a domain we need desperately of a solution or else all of our data and freedoms are at stake (not to mention it can even be a better technology than the current cloud-corporate centric vision that are designed to maximize corporations profit and data centralization, where we dont actually own anything, anymore). So thanks for all of your work, it was really inspiring.

anderspitman 7y ago

Thanks for the thoughts. > My new hope is that "mainstream" cloud infrastructure will push towards being incrementally more and more decentralized on a technical level That sounds pretty close to what I'm doing with my current project. Start with a centralized platform that is instanced per-user under the hood, provide tangible benefits vs the big guys, and eventually open source it for self-hosting. That's the dream anyway.

canadaduane 7y ago

Loved your work & was an early supporter. If you haven't already, I think you should take a look at some really cool new possibilities in the app development space like automerge/hypermerge, braid.id, and gun.eco. These offer a new path forward where a home server is just one possible topology, but the data is freed from servers. See also https://github.com/SmithSamuelM/Papers/blob/master/presentations/DID_Everything_OpenWest2019.pdf https://github.com/SmithSamuelM/Papers/blob/master/presentat... (I particularly like how Sam has coined the term "autonomic data", meaning data that embeds its own authorization through encryption--once you separate authorization from distribution, you can do some amazing things).

indigochill 7y ago

>never mind that such architecture is actively hostile towards small-scale self-hosting Can you provide some information about why this is? Are you talking about vendor lock-in with certain cloud providers? Because Kubernetes, for instance, provides a layer that lets you move applications around (even locally with Minikube) with no fuss. So I suspect I'm misunderstanding what you're referring to.

kentonv 7y ago
1) Maintaining a personal server should be no more difficult than maintaining your phone, something that non-technical people can do. No command lines, no config files. Kubernetes obviously isn't that. 2) Kubernetes and other popular cloud infrastructure are designed to scale up to massive traffic, but they are not designed to scale down. For a personal server, you want to be able to install hundreds of apps on a single, modest machine, and only have apps consuming resources when the user is actively using them.