Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Sandstorm: a Personal cloud platform (by Kenton Varda)

Sandstorm: a Personal cloud platform (by Kenton Varda)

Kenton Varda, author of Cap'n Proto and the person responsible for open sourcing Protocol Buffers at Google, spoke at Talks at Sourcegraph about Sandstorm, a new project to provide a personal cloud platform for web applications.

Slides: http://sandstorm.io/slides
Video: https://www.youtube.com/watch?v=dlJYlM94fbE
Talks at Sourcegraph: http://www.meetup.com/Sourcegraph-Hacker-Meetup/

Sourcegraph

August 06, 2014
Tweet

More Decks by Sourcegraph

Other Decks in Programming

Transcript

  1. Where does it run? Up to you: • Subscribe to

    shared hosting, or • Set up on your own machine. It’s open source! https://github.com/sandstorm-io
  2. But I can already run a server... Sandstorm is different:

    • No config files. • No command lines. • App store. Like a phone. Ideal for techies and non-techies.
  3. Architecture Front-end Node.js + Meteor App Container proc proc proc

    App Container proc proc proc App Container proc proc proc Storage HTTP Cap’n Proto Users Filesystem
  4. Architecture Sandboxing: • Linux containers (same syscalls as Docker). ◦

    Native code — use any tech stack. • Reduced attack surface: seccomp, etc. • App package mapped read-only at /. • Per-instance storage at /var.
  5. Architecture Fine-grained containers: • Share app code/assets read-only. • Shut

    down when not in use. Allows per-user or even per-document containerization.
  6. Architecture User interface • App rendered in an iframe. •

    Unified login and sharing. • Proxy does authentication. • Shell (parent frame) can display system UI.
  7. Architecture Powerbox: Mediates introductions • App A: “I implement interface

    Foo” • App B: “I need an instance of Foo” • System displays picker.
  8. Why we need this 1. Developer-hosts are too powerful. •

    Spying/data-mining • Unwanted experiments • Privacy violations • Disappearing apps
  9. Why we need this 2. Developer-hosts are walled gardens •

    Federated auth is hard ⇒ temptation to integrate only with first-parties. “if you want a definition of the term ‘walled garden’ as it pertains to technology, ask a man with both an iphone and a chromebook” - @malki
  10. Why we need this 3. Enable open source and indie

    apps • Not all useful apps are monetizable. • Hobby projects don’t want to run servers. • You wouldn’t want to use their servers. • What good is “open source” if you can’t deploy your modified code?
  11. Why we need this 4. Enterprise • Many companies won’t/can’t

    use SaaS. ◦ Privacy laws ◦ Competition • On-prem servers suck. ◦ High IT costs ◦ Poor integration ◦ Security
  12. Why we need this 5. It’s inevitable. • 1990’s: AOL

    vs. WWW • 2010’s: SaaS vs. decentralized hosting We will win. Question is how soon.