Sandstorm Oasis hosting open beta and App Market
blog.sandstorm.io
blog.sandstorm.io
Edit: Things seem a bit better now. This is our first time getting a load spike on Blackrock (codename for the "enterprise" add-on to Sandstorm which can utilize a whole cluster, which we use to run Oasis); previously, it was always the single-machine demo.
The problem is, ironically, we haven't parallelized our front-end yet. We are seamlessly distributing the apps themselves across way more machines than we actually need, but everyone is connecting to the same instance of the surrounding management UI. Honestly I didn't prioritize this because I thought our reinvented-wheel back-end was going to be the bigger bottleneck -- whoops.
Luckily this shouldn't be too hard to fix as the front-end is mostly stateless. Probably fixed in a week or two.
Nice to know what to focus on, in any case! Thanks for testing!
The personal computer revolution won't be complete until users have personal servers. Desktops, laptops, smartphones -- none of them compare in importance to controlling your own server.
Sandstorm is a great step in that direction. There's something very beautiful in how it "rolls with the blow" of how awful the web is. While Mozilla (sorry to pick on you guys) is just trying to force more JS everywhere, Sandstorm makes one small product and wildly improves what a web app means.
I've just stumbled upon the update (upgrade?) on my self-hosted Sandstorm instance, which I just installed a week ago to try and learn. It feels (and looks, and works!) better.
I'm one of the perfect use cases for Sandstorm -- I use Xubuntu and I've installed it in some friends and relatives' computers, I occasionally help people with "computer problems" and I might dabble with my systems and local network but I'm by no means a net/sysadmin or programmer, and yet I find the whole... ecosystem? (sorry, I can't find the word) fascinating. It's the best sci-fi you can read.
But there is this huge gap that only I seem to see, and I feel Sandstorm could help filling that gap, between those that know how some of this "real sci-fi" works and those that, like me and lots and lots of my fellows, don't.
Let the documentation improve. Hehe, I'm happy about some software thing...
When I explained that we might use this for a project or two, if it turned out to be too much trouble to put our GitLab instance with all its private repos on the public internet, he understood right away.
Up until that point he basically knew what Sandstorm was all about and he was saying "I don't think Sandstorm is for us." I'm still not sure he sees, but the free open beta and the app store will probably work to help convert him. He loves app stores. (Why not add, a shameless plug for Synology DSM OS with its Docker Hub support!)
How does Sandstorm create an update-model for SaaS when developers are deploying hundreds of changes a day?
I like the idea, but I wonder if this idea would have worked better in an era when software wasn't always continuously evolving to the needs of customers
It doesn't! Sandstorm is the anti-SaaS. Sandstorm is all about running fine-grained instances of apps (e.g. a separate Etherpad instance for every document) in a decentralized way rather than huge centralized "scalable" SaaS apps. Supporting SaaS-style apps is explicitly a non-goal for us.
Sandstorm is meant for people hosting personal servers for themselves or for businesses hosting corporate-internal apps for their employees; generally not for external-facing apps.
It turns out that decentralized apps are trivial to scale, without any fancy distributed systems architecture.
> Are you going to require your users to configure lots of API keys and services manually and manage these vendor relationships?
No. "Managing vendor relationships" is not a thing that one needs to do in Sandstorm's usage model.
Sandstorm apps are generally self-contained; they include all their code dependencies directly in the package, including the full stack of front-end, business logic, database, etc.
The only time a Sandstorm app needs to reach out to other apps and services is when the app logically needs to interact with other objects. For example, imagine a chart app which renders charts based on the contents of a spreadsheet (another app). These apps need to be connected, but this kind of connection makes logical sense to an end user. They know what a chart is, they know what a spreadsheet is, and they know they need to connect them. Sandstorm will provide something we call the "powerbox UI" to allow users to create these connections in a user-friendly way.
https://docs.sandstorm.io/en/latest/developing/security-prac...
> How does Sandstorm create an update-model for SaaS when developers are deploying hundreds of changes a day?
It's like mobile. You ship an app to the app market, and then users get updates from there.
It's almost like the SaaS DNA is to move very quickly (break things) and react to customers.
If your developers cannot continuously deploy to their customers and make changes behind the scenes, how will your developers compete with a Slack?
Is your only value proposition data security?
A guy in Turkey and a guy in France working in their free time built Wekan, a Sandstorm app that easily replaces Trello. Two people in their spare time vs. a whole funded company. There is no way that they'd be able to build and run a SaaS service competing with Trello -- and no way I personally would use a service run by two random guys in their spare time -- but building a Sandstorm app was no problem for them, and has been incredibly useful to me.
To me the question is: how will SaaS developers be able to compete against Sandstorm developers that can build apps so much more easily?
He needs to figure out how to create a viable business, and his first order concern is getting to P/M fit by rapidly iterating and delivering product (often making several changes a day).
If they create a viable business, they have enough leverage and margins (given SaaS has very favorable unit economics) to pay for a infra and a dude to manage it,
But it has security problems, privacy problems, and leaves users out of control of the platform they are using. And in many cases it's an excuse to charge a subscription fee for something where a one-time charge will do. Service-oriented infrastructure is a distinctly consumer-unfriendly way to operate.
In an age of poor Internet speeds and insufficient PC processing power, the 'cloud' may have briefly made sense. But I think we're well past the point where it does, and consumers should have better options.
The great part about Sandstorm (to me), is that people happy to have cloud hosting services, can, and people who want to self-host, can, and both can use the same apps and software without a problem. Companies that want to pay for a managed hosting service can, and companies that want (or need) everything on premises can, and they can both use the same apps and software.
Almost all the value creation that's happening in the cloud is about enabling agility, and very fast release models.
Agility is far more valuable then the time/effort it takes to maintain these apps.
Agility is the ability to launch a new product or feature faster than your competitors
When agility is no longer valuable to a business, they already have a dominant position in the market or have been disrupted by something else.
In fact, most people not in Silicon Valley hate it. And something like Sandstorm puts the user in control of whether or not their stuff changes. Someone can have auto-update on, and have the latest everything, and someone else, even on the same server, can choose to keep a stable version that does what they need.
Clearly, there is not enough education about privacy and how your data is being used to extract money from your pockets.
But when it comes to agility, yes, it's more about improving upon (or finding) the value proposition of that product.
If uber could cut down the time it takes to find a car from 5 minutes to 1 minute, wouldn't that be better for everyone?
How does a company on Sandstorm compete with a modern SaaS company that can change an algo behind-the-scenes and instantly improve experience?
Those sorts of mindsets are why my views on Google has heavily soured over the years, the same way my feelings soured about Facebook.
But I definitely agree that consumer education is key. :)
You obviously are not a believer in the Sandstorm platform, and are thinking about things in a way that I would call traditional (at least for the last 10 years). You could very well be correct, but many of us on this thread think you are incorrect. It's as simple as that.
Yes, I realize it can be used for other things. I'm not sure if there is value in those things.
On this point, I completely agree. Where we seem to disagree is how best to make sure developers can iterate quickly.
Give me one example where the distribution or usage of an open-source solution is comparable to it's SaaS competitor People misunderstand what open-source really is. There is a selfish reason to maintain open-source projects. Developers are above fixing their own problems when working on open-source. This is the only reason companies and developers invest in open-source.
Hence, the type of projects that become massively successful are components, frameworks or platforms... things that are re-usable for the solutions or apps these developers are creating for their companies. There is real economic value being unlocked there. Recent examples being Docker, AngularJS, etc that are supporting by lots of companies
Creating an app or solution is a whole different ballgame. They are usually side projects because there is little or no incentive for a company to take away resources from building their own apps/solutions, to save a few bucks.
Also, unlike many Drive apps, where I have to share my information with a third party provider, or "trust" the app, Sandstorm doesn't let my apps betray me. Privacy is inherent in the design.
But the key thing, is if I don't like my host, I CAN LEAVE. I am at the point that I loathe storing my data with Google. I love Gmail, and I wish I could take it with me and put it on a server run by a company I trust. But I can't do that. With Sandstorm, I can. I can run the app I want on the host I want. I have control of my app, my experience, and my data.
Google ruins my experience on a weekly basis. They change things without my permission that breaks my workflow and makes it hard for me to go about my day. I KNOW my Sandstorm hosting will do what I want it to do.
Google can't do any of this for me.
No other company has that kind of volume of data and heuristics
The big issue, is your much talked about data and heuristics are unreliable. Since Google changes their software or algorithms without my permission, I can't rely on any of them.
I would love to be able to work on Open-Source apps and might occasionally build some for free but at the end of the day I still need money to pay my rent and all.
The answer to that is probably central to what kind/quality of application that you will get on the market.
We want to help developers get paid for their work by making it really easy to get paid. Sandstorm Oasis users will already have a credit card on file; we want to make it easy for them to use that card for in-app purchases. In the case of open source apps, we want to make it easy for app developers to solicit "tips", perhaps by implementing this as part of the Sandstorm UI -- if you use an open source app a lot, the UI could (hopefully not overly intrusively) say "Hey, would you consider giving a weekly tip to this developer?"
I've also thought about a "spotify" model where we automatically pass along some portion of subscription fees to apps that get used a lot.
Of course, things are more complicated for personal servers where the user doesn't necessarily have payment methods on file. We're still thinking about how that will work, but we'll come up with something.
I've also speculated in the past that Sandstorm would be something great to have on NASs of the QNAP, Synology variety... any progress in that direction?
I agree it'd be great on NASs. I'm particularly excited about Synology ones since I know they have some x86-64 models. If you're interested in possibly helping out with that stuff, feel free to email community@sandstorm.io and I can see if there's a way we can give you a preview of that sooner rather than later.
I know that Docker-izing it could be more comfortable for people who are already familiar with launching Docker images, and similarly Debian packages would be more comfortable to long-time Debian users, etc. But, these other distribution mechanisms would have significant technical disadvantages compared to what we have (and what we are building), while adding some significant maintenance cost for us. So we've decided not to pursue them for now. That said, it might make more sense when we have a "stable release".
Regarding Synology, they actually sent us a test unit that we plan to play with at some point... so much to do, so little time.
Ok, that's interesting... so hopefully it wouldn't conflict with my Docker install and its containers at all (other than port numbers I suppose).
You could configure your email then perhaps to respond with things like your personal profile, in response to anonymous inbound requests.
To do it securely in Sandstorm would have to wait for our secure inter-app communication system, similar to Android intents, called the Powerbox. But we're working on it.
(It's $6/mo for the standard plan, which is probably enough for most people.)
The general idea is that if an app needs IRC access, it can bother the user once to get it, and if it doesn't need IRC access, then it shouldn't ever have access to IRC (or the network).
This isn't ready yet, but good golly am I excited for us to finish it up so I can tell all my friends that Sandstorm is the easiest way to run an IRC bouncer.
I can't figure out how to make etherpads public by default.
Which rather kills the primary use-case of etherpads for me (frictionless collaborative documents - non-guessable urls are the only authentication)
I'll tell you why I didn't suss this out (and I think this is a geek blind spot more than a true UX flaw).
1. I decided all the options FOR the app would be inside the part of the screen owned by the app (i.e. not the top bar). So I only looked there.
2. I was expecting the url in the browser's address bar to be shareable.
I'll see if there's something we can do to make this essential UI element more discoverable.
To some extent, it's a matter of learning about Sandstorm -- Sandstorm's role in the web app ecosystem is basically to add sharing & access control, so maybe everyone has to learn this. But hopefully we can help people figure it out more easily.
It did take me a while to figure out how to delete "grains" (I would've thought from the list of grains, instead I had to open one and click the delete button).
Also, I don't quite understand why I started out with five wekan grains from the get-go? Maybe a bug.
Also, I think first-time users might need some more hints (like unintrusive first-run popups or something) that the top bar is the Sandstorm stuff, while the rest is the app itself. I don't know what would be the best way, it seems quite challenging to design something like this :-)
What does the key icon do? (No hover text.)
Maybe "Share" should say "Share app"? (So I don't get confused into thinking it means "share this one wekan note" or "share this particular song from groovebasin".)
Yesterday in particular Oasis was under heavy load from HN, if you clicked on New Wekan a bunch of times before it did it, it might have made a bunch. Usually it's near instant so this sort of thing doesn't happen.
paulproteus will love all your feedback. He likes feedback. :D
FWIW, the first version of Sandstorm let you copy/paste the URL from the address bar, and I'm definitely a fan of that model. But, a lot of people are uncomfortable with that. It "feels" insecure. So we're trying to find a happy middle ground, where the people who like URL sharing can use it, and those that don't can avoid it. It will take some experimentation to get right.
Just played around with the new UI, looks great!
Looking forward to setting up an instance soon (or perhaps paying for hosting) :)
The work you all are doing is awesome - keep it up!
Though, depending on what you want to monitor, the ideal drivers to let the app talk to things outside of Sandstorm may not be ready yet.
And Gitweb itself should present you with some basic instructions on setting up a webkey to push code to it.
Yes, but the name of the repo itself has _RENAME_ME as its suffix and AFAICT there's no way to change it. It seems as if gitlab behaves this way too.
EDIT: ok embarassing mistake on my part, it's all clear now.
I hope you don't stay embarrassed. We could improve parts of the interface, and we need feedback like this to know what people think is going on, so that we can decide how to change the interface to show people what is actually going on.
Thanks for leaving the comment and I hope you enjoy using Sandstorm!
I think it took so long because it's so different from what I'm used to. It seems like a powerful idea but challenging to make sure your customers' expectations are managed.
The sidebar/navbar clearly is part of the strategy, well done there. But the gulf that exists between the specific-app content pane and the sandstorm navbar is the tricky bit.
Definitely in for the $6 hosted version, once you guys are out of beta.
Seriously... wonderful work.