3 ms·

cool, but what does sandstorm have to do with cloudflare? then again i don't quite get what it is... some kind of file/app sharing thing.

yebyen 10y ago
Sandstorm takes apps that normally would need someone to run a server, breaks them down into the smallest shareable unit (a "grain"), and lets you host them all centrally, on the Sandstorm server. Whether that's the Oasis service, your own machines, or something in between. So instead of running a whole Gitlab server, you'd run a Sandstorm server that hosts Gitlab grains, each consisting of a single repository. Gitlab itself is no longer responsible for sharing and authentication, the Gitlab grain lets Sandstorm handle that. Apps need to be rewired to fit into this paradigm, but once they do, it feels like one coherent platform rather than a bunch of separate individually hosted apps that maybe you glue together somehow. For Etherpad, instead of running an Etherpad server that hosts many notepads, you create an Etherpad grain that has just one shared pad. For a drawing app, the grain would be just one drawing. For a photo gallery app, maybe it would be just one gallery. (These are all real examples, these grains all exist and work as I'm describing.)
- derefr 10y ago
  > Whether that's the Oasis service, your own machines, or something in between. To clarify: does a "grain" just run in one place, or is each "grain" a cluster of containers that can be spread-scheduled between disparate regions (i.e. "the Oasis service" and "your own machines" at the same time)? And, if the latter, do the cluster nodes have awareness of their locations, and can take advantage of that?
  - yebyen 10y ago
    I have honestly no idea, other than I know that the grains are not permanent resident processes. IOW when they are not in use, they spin down and do not actively consume resources other than disk. I think the grain runs in one place, I think to use the container analog it would be one container, but as a point of clarification I believe that it is not using one of the container runtimes like docker or rkt that you will be familiar with, but uses its own sandboxing instead. I have not tried running the newly opened up Oasis backend so I can't really speak toward how it works. My experience with a single server running Sandstorm has been good, painless automatic upgrades, I would expect from what I know about this team, that since it's their dogfood they made it taste good.

yebyen 10y ago

Sandstorm takes apps that normally would need someone to run a server, breaks them down into the smallest shareable unit (a "grain"), and lets you host them all centrally, on the Sandstorm server. Whether that's the Oasis service, your own machines, or something in between. So instead of running a whole Gitlab server, you'd run a Sandstorm server that hosts Gitlab grains, each consisting of a single repository. Gitlab itself is no longer responsible for sharing and authentication, the Gitlab grain lets Sandstorm handle that. Apps need to be rewired to fit into this paradigm, but once they do, it feels like one coherent platform rather than a bunch of separate individually hosted apps that maybe you glue together somehow. For Etherpad, instead of running an Etherpad server that hosts many notepads, you create an Etherpad grain that has just one shared pad. For a drawing app, the grain would be just one drawing. For a photo gallery app, maybe it would be just one gallery. (These are all real examples, these grains all exist and work as I'm describing.)

derefr 10y ago
> Whether that's the Oasis service, your own machines, or something in between. To clarify: does a "grain" just run in one place, or is each "grain" a cluster of containers that can be spread-scheduled between disparate regions (i.e. "the Oasis service" and "your own machines" at the same time)? And, if the latter, do the cluster nodes have awareness of their locations, and can take advantage of that?
- yebyen 10y ago
  I have honestly no idea, other than I know that the grains are not permanent resident processes. IOW when they are not in use, they spin down and do not actively consume resources other than disk. I think the grain runs in one place, I think to use the container analog it would be one container, but as a point of clarification I believe that it is not using one of the container runtimes like docker or rkt that you will be familiar with, but uses its own sandboxing instead. I have not tried running the newly opened up Oasis backend so I can't really speak toward how it works. My experience with a single server running Sandstorm has been good, painless automatic upgrades, I would expect from what I know about this team, that since it's their dogfood they made it taste good.