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

• Comparisons To Other Cloud Tools
  • Differences From App Engine
  • Differences From Heroku
  • Differences From Media Temple
  • Differences from App Scale
  • Differences from Typhoonae
  • Differences from Moonshine
  • Differences from Rubber
  • Bitnami

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 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 and PostGIS 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 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 looks similar, but I haven’t looked at it yet.

Differences from App Scale

AppScale 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, like AppScale, is an open source adaptation of the App Engine API.

Typhoonae uses supervisord 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 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 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 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.