/docs/comparisons.txt

Comparisons To Other Cloud Tools
================================

There are a bunch of tools or hosted applications for managing cloud
applications.  As I come upon these, I'm trying to add at least a
casual comparison...

.. contents::

Differences From App Engine
---------------------------

App Engine is in many ways the basis for Silver Lining; at least, all
the choices I made when starting Silver Lining were in reaction to App
Engine: either deliberately copying App Engine, or deliberately *not*
copying it.

So, some specific differences:

* This doesn't do security isolation between apps on a server.
  Individual servers aren't that expensive, so untrusted applications
  just shouldn't comingle with Silver Lining.

* This doesn't have a scalable backend.  It would be possible to set
  up a scalable backend service, and do the associated configuration,
  but I don't know much about those tools anyway.  Scalability isn't
  the first goal; ease and reliability of deployment is more the goal.
  Not that this should *exclude* scalability, but it's not automatic.
  With work and when using scalable backends, this might become easy
  with Silver Lining in the future.  But it's going to be a lot of
  steps, and in total a great deal of work.

* You can write files.

* App Engine allocates server time dynamically, and this does not in
  any way, though at least it makes your deployments scriptable so you
  might be able to deploy new servers in an automated fashion.

* There's no authentication built in, and there won't be; this can be
  handled by per-application libraries.

* There's no limits (like, for example, the 1000-now-2000 file limit).
  As a result support for skipping files on upload is not such a big
  deal.  Cloud disk space is fairly cheap, so optimizing tihs isn't a
  big deal.  

* Dynamic support for multiple runners or static file locations isn't
  supported (like in ``app.yaml``), because it doesn't seem very
  important to me.  If you don't want process isolation, something
  like `Paste's urlmap <http://pythonpaste.org/modules/urlmap.html>`_
  can handle dispatch (implemented in your application's runner).  At
  some point it should be possible to upload entirely separate
  applications into different paths, but that will be more isolated
  than what App Engine provides through ``app.yaml``.

* Of course, you can run any library or service.  For me `lxml
  <http://codespeak.net/lxml/>`_ and `PostGIS
  <http://postgis.refractions.net/>`_ are important, and the lack of
  those libraries really kept and keeps me from using App Engine.

* No pure-Python libraries are included, because they aren't needed
  (including, for example, Django and WebOb).  Silver Lining keeps the
  runtime quite clean (except for libraries installed system-wide,
  which would be the case for something like lxml).

Differences From Heroku
-----------------------

`Heroku <http://heroku.com/>`_ is an App Engine-like service for Ruby
applications.  But it works differently from App Engine, and has some
novel ideas:

* Heroku uses git to deploy.  I don't see any particular reason to
  integrate with a version control system.  This system uses rsync.

* Configuration seems to be done somewhat magically with Heroku, and
  just with environmental variables in this system.  Magic is
  annoying.  You need to glue together the environmental variables
  with your configuration manually, though you only need to do it
  *once*.  (If you aren't using a framework that includes
  "configuration" then you can probably just hardcode the
  environmental variables in your code.)

* Stuff like migration is built-in.  I want to do that stuff too.

* Apps seem to be more chroot'd than in this system.  I'm not that
  concerned about this, as I expect people to just do that isolation
  by using multiple servers.

* There's a bunch of nice add-ons for Heroku.  These will map to
  Silver Lining services.  While not yet implemented, in the future
  enabling Solr will be a matter of writing ``service.solr =`` in your
  ``app.ini``.

* Heroku uses Ruby.  I believe Ruby is very supportable by this
  system, but it isn't supported now, and I'm unlikely to add it
  myself (mostly because I don't know quite how it should work).

* Heroku has more support for dynamically scaling up your application.
  You can give Silver Lining apps a bigger server (up to the limits of
  your service provider), and if you deploy an application on multiple
  servers/nodes you can be reasonably assured they are identical, but
  scaling of the persistence is not handled, and so adding new nodes
  isn't really handled.

Generally Heroku seems like a faster-moving target than App Engine,
with lots of interesting ideas; I hope to get more ideas from it going
forward.

Of course, the primary difference of Silver Lining is: it's open
source, you can adapt the system as you find necessary, and it's a
**lot** cheaper (since you are paying only for the actual cloud
service, which is reasonably priced).

Differences From Media Temple
-----------------------------

`This
<http://mediatemple.net/webhosting/gs/features/containers.php#django>`_
looks similar, but I haven't looked at it yet.

Differences from App Scale
--------------------------

`AppScale <http://appscale.cs.ucsb.edu/>`_ is an open source
implementation of the Google App Engine API.  It features a bunch of
database backends, and can do a lot of the management of scaling
nodes.

While Silver Lining takes ideas from App Engine, the priorities are
really quite different.  Silver Lining is focused on simple, reliable,
repeatable deployment of applications.  The deployments really aren't
that different from how software might traditionally be deployed, it
just formalizes those pieces and factors the problem in a way that
makes the actual deployment as simple and reliable as possible.

AppScale (at least from what I can tell) is more focused on scaling,
and App Engine-like infrastructure.  It provides the App Engine API;
Silver Lining was written because I liked *parts* of the App Engine
toolset, but I couldn't embrace the constraints of the platform.

Silver Lining also I believe scales *down* further than AppScale.  You
can run as many sites on one server/node as you care to.  So it is
quite suitable for deploying several small applications cheaply.  I
believe Silver Lining will make the life of the average web developer
easier and simpler very quickly.

Silver Lining is meant to be usable with existing applications.  You
can use pretty much any database (some support code needs to be
written to manage each kind of database, but it's quite simple).  You
can write files.  Traditional "configuration" is actually kind of
pushed *into* the application, but it just means you should do things
like (in Django)::

    DATABASE_ENGINE = 'postgresql_psycopg2'
    DATABASE_NAME = os.environ['CONFIG_PG_DBNAME']
    DATABASE_USER = os.environ['CONFIG_PG_DBUSER']
    DATABASE_PASSWORD = os.environ['CONFIG_PG_DBPASSWORD']
    DATABASE_HOST = os.environ['CONFIG_PG_DBHOST']
    DATABASE_PORT = os.environ['CONFIG_PG_DBPORT']

Everything you can do in a traditional deployment system, you can do
with Silver Lining (at least, potentially; extra support code may be
necessary).  I don't think AppScale provides this nor do I think this
is a goal of AppScale.

Differences from Typhoonae
--------------------------

`Typhoonae <http://code.google.com/p/typhoonae/>`_, like AppScale, is
an open source adaptation of the App Engine API.

Typhoonae uses `supervisord <http://supervisord.org/>`_ for monitoring
the processes, while Silver Lining uses mod_wsgi.  They both have a
similar function, but because mod_wsgi is integrated with the web
server it is not just aware of the process dying, but also of the
process becoming unresponsive.  Supervisor, because it is a
general-purpose process monitor, cannot determine when a process is
serving its function.

People have asked about how Silver Lining can be used with something
more closely related to App Engine.  I'm not that optimistic about
AppScale, because I think it overlaps in the wrong ways with Silver
Lining -- they are more like direct competitors than complementary
tools.  Typhoonae on the other hand might work better.

The pieces of Typhoonae that would be useful would be its
implementations of the App Engine APIs, backed with MongoDB (data
store), RabbitMQ (well... not quite sure what this is for), and
ejabberd (for chat integration), and possibly other APIs that they've
implemented with a better backend than what the App Engine SDK itself
contains.  These would each be services.  Possibly something like the
Data Store API would just be a library you install, plus
``service.mongodb``, but they could be presented as first-class
services (e.g. ``service.typhoonae_datastore``).  I'd probably prefer
they not be first-class services, because that means Typhoonae
releases would have to be tied one-to-one to Silver Lining releases.
I'd rather see something like a ``silverlining_typhoonae``
distribution that you could install into your app.

Differences from Moonshine
--------------------------

So far, `Moonshine <http://github.com/railsmachine/moonshine>`_ sounds
like the closest thing to Silver Lining in functionality, with even
many of the same choices, except Ruby instead of Python.  It uses
Ubuntu, Apache, and Passenger (where Passenger is the closest thing to
a Ruby equivalent of mod_wsgi).  It also uses Ruby Enterprise Edition
(?) and MySQL, where Silver Lining does not have a single persistence
backend.

``config/moonshine.yml`` is a lot like ``app.ini``, ``cap
deploy:setup`` is like ``silver setup-node`` and ``cap deploy`` is
like ``silver update``.

It's built on Capistrano, not using its own native constructs.  In
this sense it is glue, but it's kind of a matter of perspective.  If
Capistrano worked a little differently then it might look like
Moonshine was the application and Capistrano the library.

It has a notion of "shared config", which is configuration not in your
source tree, but which is needed for deployment.  Silver Lining needs
something like this.

Differences from Rubber
-----------------------

`Rubber <http://github.com/wr0ngway/rubber/wikis>`_ is a tool based on
Ruby/Rails and Capistrano.

I'll have to look into it some.  It, like Moonshine, is based on
Capistrano.  It is a more general configuration management tool.  It
also has more features for scaling.

Bitnami
-------

`Bitnamo <http://bitnami.org/>`_ is kind of a package for pre-built
open source applications.  For instance, you grab a Joomla image and
you get Joomla.  From what I can tell, Bitnami itself is actually
proprietary.  The supported applications seem to be PHP.

Bitnami also creates virtual images you can use to develop.  It has
inspired me to at least add a `todo item
<todo.html#create-virtual-machine-images>`_.