Show HN: Sandstorm Personal Cloud Platform Demo
sandstorm.io
sandstorm.io
While at Google, he initiated the Jeff Dean Facts prank [2], and in his spare time part-designed his own LAN-party-optimized house. [3]
So, you know, if he thinks he can provide a differentiating hosting platform, I'd have a glance.
[1] http://kentonv.github.io/capnproto/ [2] https://plus.google.com/+KentonVarda/posts/TSDhe5CvaFe [3] http://kentonsprojects.blogspot.com/2011/12/lan-party-optimi...
Just need to correct one thing: I didn't invent Protobufs (Jeff Dean and his colleague Sanjay Ghemawat did), but I did write most of version 2 and was responsible for open sourcing it.
That said, my googler friends say they much prefer ProtoBufs v2 ;)
[1] https://www.indiegogo.com/projects/sandstorm-io-personal-clo...
We still need your help to get this into production. Please check out the crowdfunding campaign: http://igg.me/at/sandstorm
Over the course of yesterday we had 747 demo users launch 952 app instances.
Currently we're on GCE for price reasons, though we're looking for good non-Google, non-Amazon options for our eventual release.
Sandstorm tends to be memory-bottlenecked since we're launching separate instances of each app for each user, although we make up a lot of it by shutting down instances when they aren't in active use.
I was super-paranoid about the demo totally breaking under load (having not tried this before), so I upped the server to GCE's largest-memory instance at 104GB of RAM.
That turned out to be completely unnecessary. It never used more than 6GB (and CPU was mostly negligible). Doh. Oh well, better to have spent too much than too little.
We also have a separate front-end server which does our SSL, so that our private keys don't reside on the same server as apps, just as an extra precaution. That machine is just a regular n1-standard-1 instance. CPU usage was in the single digit percentages there as well.
You can indeed run your own Sandstorm instance. There are installation instructions in our Github readme: https://github.com/sandstorm-io/sandstorm
Feel free to send me questions.
At any rate, sounds like my 4 core gbuplink hetzner box with 16gb ram should have no problem working with this (obviously overkill for a personal playpen, but its good to know I have lots of headroom...).
Are you planning to stay with meteor going forward? The other components seem much less complicated to get up and running, and more sys.adm. friendly. An example being the need (?) for node/npm and meteor's bundled node/npm...
We do plan to stick with Meteor. It's a pretty awesome framework. I find Meteor is incredibly easy to get running, but this is again due to its binary installer script which maybe you don't like. :)
I believe that Meteorite (the "mrt" tool which you had to install separately using npm) is slated to go away before Meteor 1.0 as that functionality will be rolled into Meteor itself. So, that part will get better, at least. For now, you actually can (and arguably should) install it using Meteor's bundled npm rather than the system npm.
I was indeed installing from source, as that is a requisite for contributing to the project (if I can't build it how could I possibly submit patches).
I have no problem with you citing any one distribution/version as supported however -- it would be madness to demand support for "everything" from an alpha source release! And I think aiming for cross-platform-distribution comparability would be wasted effort at this point.
With Vagrant from wheezy-backports, everything came up fine -- just had to(?) increase the vms ram to 512 mb for ipython notebook to work.
Now my only problem is figuring out how to get the hacker cms to publish anything (to users without login). I've understood that the cms should be stuffing files under /var/www (in my vagrant/virtualbox vm) -- so I'll have to check if "publish" pushes anything there -- and if there appear to be an nginx-instance set up to serve files from /var/www...).
As for meteor -- I have a few reservation of their architecture in general -- but my main problem is the complexity of the setup -- especially how hart it seems to be to build everything needed from source. But then again, they're not yet at 1.0, are they?
(Still seeing as how easy nodejs is to build from source, it is a shame meteor manage to somehow mangle that process...)
[edit: That is, I couldn't find any docs on how to publish from hacker cms, but I did find this for devs:
https://github.com/sandstorm-io/sandstorm/wiki/Publishing-to... ]
https://blog.sandstorm.io/news/2014-07-25-sharelatex.html
Most of our existing apps are actually ports of existing open source Linux-based servers. Most were ported by Jason Paryani over the last month, which tells you how easy it is. This includes apps written in PHP, Python, Node, etc.
Note that the dev tools (and all the platform source code) are available to anyone. There are some WIP docs on the wiki:
https://github.com/sandstorm-io/sandstorm/wiki
It's probably actually harder to port _away_ from Sandstorm simply because you have to add a login system and other such features. Adding is a lot harder than removing. :)
Anyway, this is wonderful. One more question - web2py?
It's actually incredibly easy to move your data between Sandstorm hosts. Unlike, say, Google apps, Sandstorm apps are not tied to the hosting, so you can change hosts while still using exactly the same app. You can also run Sandstorm on your own machine if you want (it's open source).
Porting data from a Sandstorm version of an app to a non-Sandstorm version is also relatively easy. If you click the "download a backup" button, it's just a zip file that contains the app's database in whatever format it uses. But, how exactly to set up the app outside of Sandstorm depends entirely on the app.
Regarding web2py: I don't know much about it, but I assume it runs on Linux so it should work fine for writing a Sandstorm app...
Nice implementation.
Not really true. Sandstorm acts as a proxy in front of the apps and adds headers which identify the user. It takes very little code on the app side to read these headers and use them rather than use the app's own authentication.
That said, we do have some changes which we'll have to rebase from time to time. Eventually we hope that app developers will be interested in maintaining these changes themselves and explicitly targeting Sandstorm, but that is probably a ways away still. In the meantime, maintaining the edits doesn't seem to painful.
OT: I always take a closer look when a computer screen appears in a video - in this case I couldn't recognize what you're running there. My guess would be a a tiling window manager? But the other screen shows Windows so I'm curious.
The code on the right window looks like Haskell due to the one liners.
https://dl.dropboxusercontent.com/u/19746944/kv.png
(Also, its kinda surprising/refresing that Sandstorm isn't written in Go or Node... )
That's me running Qt Creator (my personal favorite IDE) on Linux. You may be disappointed to learn that the code is C++. :) Sandstorm's lower layers are all C++ since we interface closely with Linux syscalls, though I think in that shot I'm actually editing Cap'n Proto (which Sandstorm uses).
All of the machines in the video are running Linux, with GNOME 3 as the window manager.
> Camlistore
Yep, I've talked to Bradfitz about Camlistore a few times.
Sandstorm actually gives each app instance its own directory on the filesystem for storage, so that it can use any storage format it wants. So an app could use Camlistore. It may also make sense for Camlistore to act as an independent app which other apps connect to. But in any case, Sandstorm is agnostic to these things.