7 ms·

Sandstorm is one of the coolest pieces of tech I've come across in the last few years. Not just on a philosophical self-hosting level, but also a technical leve

Sandstorm is one of the coolest pieces of tech I've come across in the last few years. Not just on a philosophical self-hosting level, but also a technical level (capnproto is awesome). I'm working on a product right now that is heavily inspired by Sandstorm. 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, and it never reached critical mass of developers building in sandstorm support to their apps. So it's essentially a chicken-and-egg problem. I'm not sure what the solution to that is. I would love to read a pseudo-postmortem (I refuse to believe this heralds the death of sandstorm) by @kentonv about what he thinks the main challenges of getting to a truly decentralized world are, how sandstorm plays in, and where we go from here.

kentonv 7y ago
> 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.
snowe2010 7y ago
I investigated capnproto for a while, how do you feel about them compared to the alternatives?
- anderspitman 7y ago
  Disclaimer: I've only looked fairly close at capnproto, RSocket, and gRPC, never used them myself. It depends on what you need to do. What's your use case? My primary constraint is that I need web browser compatibility, ie websockets currently. If capnproto had a solid browser JS implementation I would said use it hands down if it has the features you need. There's some work being done to shoehorn gRPC into the browser[0], but it seems very complicated to me (requires a proxy server IIRC). If you need a robust browser solution today, take a look at RSocket[1]. I think the reason rsocket isn't talked about more is that it comes across as very "enterprisey", but on a technical level it looks very good to me. You may also be interested in my minimalist approach, omnistreams[2]. It basically adds backpressure and multiplexing on top of websockets. We're running that in production at iobio.io, but the API isn't stable yet (would love external input). One big caveat of capnproto vs gRPC is that capnproto doesn't really have built-in "stream" mechanics, ie the concept of making a request that you expect to return an unbounded list of elements. I've mentioned this before and kentonv explained a way it could be mimicked though[3]. [0] https://grpc.io/blog/state-of-grpc-web/ https://grpc.io/blog/state-of-grpc-web/ [1] http://rsocket.io/ http://rsocket.io/ [2] https://github.com/omnistreams/omnistreams-spec https://github.com/omnistreams/omnistreams-spec [3] https://news.ycombinator.com/item?id=20041250 https://news.ycombinator.com/item?id=20041250
mnutt 7y ago
I always thought one of the big barriers was porting existing apps: you need to disable/rip out their auth and user management, and you need to pare them down to operate on only a single unit of whatever thing they manage (a grain). These changes are often hard to upstream, so you’ll be applying upstream updates over and over. I was hoping we’d see a bunch of small purpose-built apps that were perhaps companions to a standalone app that just needed a small internet-accessible component, such as IoT devices or even mobile apps that need a way to host shareable links.

kentonv 7y ago

> 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.

snowe2010 7y ago

I investigated capnproto for a while, how do you feel about them compared to the alternatives?

anderspitman 7y ago
Disclaimer: I've only looked fairly close at capnproto, RSocket, and gRPC, never used them myself. It depends on what you need to do. What's your use case? My primary constraint is that I need web browser compatibility, ie websockets currently. If capnproto had a solid browser JS implementation I would said use it hands down if it has the features you need. There's some work being done to shoehorn gRPC into the browser[0], but it seems very complicated to me (requires a proxy server IIRC). If you need a robust browser solution today, take a look at RSocket[1]. I think the reason rsocket isn't talked about more is that it comes across as very "enterprisey", but on a technical level it looks very good to me. You may also be interested in my minimalist approach, omnistreams[2]. It basically adds backpressure and multiplexing on top of websockets. We're running that in production at iobio.io, but the API isn't stable yet (would love external input). One big caveat of capnproto vs gRPC is that capnproto doesn't really have built-in "stream" mechanics, ie the concept of making a request that you expect to return an unbounded list of elements. I've mentioned this before and kentonv explained a way it could be mimicked though[3]. [0] https://grpc.io/blog/state-of-grpc-web/ https://grpc.io/blog/state-of-grpc-web/ [1] http://rsocket.io/ http://rsocket.io/ [2] https://github.com/omnistreams/omnistreams-spec https://github.com/omnistreams/omnistreams-spec [3] https://news.ycombinator.com/item?id=20041250 https://news.ycombinator.com/item?id=20041250

mnutt 7y ago

I always thought one of the big barriers was porting existing apps: you need to disable/rip out their auth and user management, and you need to pare them down to operate on only a single unit of whatever thing they manage (a grain). These changes are often hard to upstream, so you’ll be applying upstream updates over and over. I was hoping we’d see a bunch of small purpose-built apps that were perhaps companions to a standalone app that just needed a small internet-accessible component, such as IoT devices or even mobile apps that need a way to host shareable links.