PageRenderTime 30ms CodeModel.GetById 16ms RepoModel.GetById 0ms app.codeStats 0ms

Plain Text | 246 lines | 194 code | 52 blank | 0 comment | 0 complexity | 0bd50305fa91ab24578671bd5e882b75 MD5 | raw file
Possible License(s): GPL-2.0
  1. Comparisons To Other Cloud Tools
  2. ================================
  3. There are a bunch of tools or hosted applications for managing cloud
  4. applications. As I come upon these, I'm trying to add at least a
  5. casual comparison...
  6. .. contents::
  7. Differences From App Engine
  8. ---------------------------
  9. App Engine is in many ways the basis for Silver Lining; at least, all
  10. the choices I made when starting Silver Lining were in reaction to App
  11. Engine: either deliberately copying App Engine, or deliberately *not*
  12. copying it.
  13. So, some specific differences:
  14. * This doesn't do security isolation between apps on a server.
  15. Individual servers aren't that expensive, so untrusted applications
  16. just shouldn't comingle with Silver Lining.
  17. * This doesn't have a scalable backend. It would be possible to set
  18. up a scalable backend service, and do the associated configuration,
  19. but I don't know much about those tools anyway. Scalability isn't
  20. the first goal; ease and reliability of deployment is more the goal.
  21. Not that this should *exclude* scalability, but it's not automatic.
  22. With work and when using scalable backends, this might become easy
  23. with Silver Lining in the future. But it's going to be a lot of
  24. steps, and in total a great deal of work.
  25. * You can write files.
  26. * App Engine allocates server time dynamically, and this does not in
  27. any way, though at least it makes your deployments scriptable so you
  28. might be able to deploy new servers in an automated fashion.
  29. * There's no authentication built in, and there won't be; this can be
  30. handled by per-application libraries.
  31. * There's no limits (like, for example, the 1000-now-2000 file limit).
  32. As a result support for skipping files on upload is not such a big
  33. deal. Cloud disk space is fairly cheap, so optimizing tihs isn't a
  34. big deal.
  35. * Dynamic support for multiple runners or static file locations isn't
  36. supported (like in ``app.yaml``), because it doesn't seem very
  37. important to me. If you don't want process isolation, something
  38. like `Paste's urlmap <>`_
  39. can handle dispatch (implemented in your application's runner). At
  40. some point it should be possible to upload entirely separate
  41. applications into different paths, but that will be more isolated
  42. than what App Engine provides through ``app.yaml``.
  43. * Of course, you can run any library or service. For me `lxml
  44. <>`_ and `PostGIS
  45. <>`_ are important, and the lack of
  46. those libraries really kept and keeps me from using App Engine.
  47. * No pure-Python libraries are included, because they aren't needed
  48. (including, for example, Django and WebOb). Silver Lining keeps the
  49. runtime quite clean (except for libraries installed system-wide,
  50. which would be the case for something like lxml).
  51. Differences From Heroku
  52. -----------------------
  53. `Heroku <>`_ is an App Engine-like service for Ruby
  54. applications. But it works differently from App Engine, and has some
  55. novel ideas:
  56. * Heroku uses git to deploy. I don't see any particular reason to
  57. integrate with a version control system. This system uses rsync.
  58. * Configuration seems to be done somewhat magically with Heroku, and
  59. just with environmental variables in this system. Magic is
  60. annoying. You need to glue together the environmental variables
  61. with your configuration manually, though you only need to do it
  62. *once*. (If you aren't using a framework that includes
  63. "configuration" then you can probably just hardcode the
  64. environmental variables in your code.)
  65. * Stuff like migration is built-in. I want to do that stuff too.
  66. * Apps seem to be more chroot'd than in this system. I'm not that
  67. concerned about this, as I expect people to just do that isolation
  68. by using multiple servers.
  69. * There's a bunch of nice add-ons for Heroku. These will map to
  70. Silver Lining services. While not yet implemented, in the future
  71. enabling Solr will be a matter of writing ``service.solr =`` in your
  72. ``app.ini``.
  73. * Heroku uses Ruby. I believe Ruby is very supportable by this
  74. system, but it isn't supported now, and I'm unlikely to add it
  75. myself (mostly because I don't know quite how it should work).
  76. * Heroku has more support for dynamically scaling up your application.
  77. You can give Silver Lining apps a bigger server (up to the limits of
  78. your service provider), and if you deploy an application on multiple
  79. servers/nodes you can be reasonably assured they are identical, but
  80. scaling of the persistence is not handled, and so adding new nodes
  81. isn't really handled.
  82. Generally Heroku seems like a faster-moving target than App Engine,
  83. with lots of interesting ideas; I hope to get more ideas from it going
  84. forward.
  85. Of course, the primary difference of Silver Lining is: it's open
  86. source, you can adapt the system as you find necessary, and it's a
  87. **lot** cheaper (since you are paying only for the actual cloud
  88. service, which is reasonably priced).
  89. Differences From Media Temple
  90. -----------------------------
  91. `This
  92. <>`_
  93. looks similar, but I haven't looked at it yet.
  94. Differences from App Scale
  95. --------------------------
  96. `AppScale <>`_ is an open source
  97. implementation of the Google App Engine API. It features a bunch of
  98. database backends, and can do a lot of the management of scaling
  99. nodes.
  100. While Silver Lining takes ideas from App Engine, the priorities are
  101. really quite different. Silver Lining is focused on simple, reliable,
  102. repeatable deployment of applications. The deployments really aren't
  103. that different from how software might traditionally be deployed, it
  104. just formalizes those pieces and factors the problem in a way that
  105. makes the actual deployment as simple and reliable as possible.
  106. AppScale (at least from what I can tell) is more focused on scaling,
  107. and App Engine-like infrastructure. It provides the App Engine API;
  108. Silver Lining was written because I liked *parts* of the App Engine
  109. toolset, but I couldn't embrace the constraints of the platform.
  110. Silver Lining also I believe scales *down* further than AppScale. You
  111. can run as many sites on one server/node as you care to. So it is
  112. quite suitable for deploying several small applications cheaply. I
  113. believe Silver Lining will make the life of the average web developer
  114. easier and simpler very quickly.
  115. Silver Lining is meant to be usable with existing applications. You
  116. can use pretty much any database (some support code needs to be
  117. written to manage each kind of database, but it's quite simple). You
  118. can write files. Traditional "configuration" is actually kind of
  119. pushed *into* the application, but it just means you should do things
  120. like (in Django)::
  121. DATABASE_ENGINE = 'postgresql_psycopg2'
  122. DATABASE_NAME = os.environ['CONFIG_PG_DBNAME']
  123. DATABASE_USER = os.environ['CONFIG_PG_DBUSER']
  125. DATABASE_HOST = os.environ['CONFIG_PG_DBHOST']
  126. DATABASE_PORT = os.environ['CONFIG_PG_DBPORT']
  127. Everything you can do in a traditional deployment system, you can do
  128. with Silver Lining (at least, potentially; extra support code may be
  129. necessary). I don't think AppScale provides this nor do I think this
  130. is a goal of AppScale.
  131. Differences from Typhoonae
  132. --------------------------
  133. `Typhoonae <>`_, like AppScale, is
  134. an open source adaptation of the App Engine API.
  135. Typhoonae uses `supervisord <>`_ for monitoring
  136. the processes, while Silver Lining uses mod_wsgi. They both have a
  137. similar function, but because mod_wsgi is integrated with the web
  138. server it is not just aware of the process dying, but also of the
  139. process becoming unresponsive. Supervisor, because it is a
  140. general-purpose process monitor, cannot determine when a process is
  141. serving its function.
  142. People have asked about how Silver Lining can be used with something
  143. more closely related to App Engine. I'm not that optimistic about
  144. AppScale, because I think it overlaps in the wrong ways with Silver
  145. Lining -- they are more like direct competitors than complementary
  146. tools. Typhoonae on the other hand might work better.
  147. The pieces of Typhoonae that would be useful would be its
  148. implementations of the App Engine APIs, backed with MongoDB (data
  149. store), RabbitMQ (well... not quite sure what this is for), and
  150. ejabberd (for chat integration), and possibly other APIs that they've
  151. implemented with a better backend than what the App Engine SDK itself
  152. contains. These would each be services. Possibly something like the
  153. Data Store API would just be a library you install, plus
  154. ``service.mongodb``, but they could be presented as first-class
  155. services (e.g. ``service.typhoonae_datastore``). I'd probably prefer
  156. they not be first-class services, because that means Typhoonae
  157. releases would have to be tied one-to-one to Silver Lining releases.
  158. I'd rather see something like a ``silverlining_typhoonae``
  159. distribution that you could install into your app.
  160. Differences from Moonshine
  161. --------------------------
  162. So far, `Moonshine <>`_ sounds
  163. like the closest thing to Silver Lining in functionality, with even
  164. many of the same choices, except Ruby instead of Python. It uses
  165. Ubuntu, Apache, and Passenger (where Passenger is the closest thing to
  166. a Ruby equivalent of mod_wsgi). It also uses Ruby Enterprise Edition
  167. (?) and MySQL, where Silver Lining does not have a single persistence
  168. backend.
  169. ``config/moonshine.yml`` is a lot like ``app.ini``, ``cap
  170. deploy:setup`` is like ``silver setup-node`` and ``cap deploy`` is
  171. like ``silver update``.
  172. It's built on Capistrano, not using its own native constructs. In
  173. this sense it is glue, but it's kind of a matter of perspective. If
  174. Capistrano worked a little differently then it might look like
  175. Moonshine was the application and Capistrano the library.
  176. It has a notion of "shared config", which is configuration not in your
  177. source tree, but which is needed for deployment. Silver Lining needs
  178. something like this.
  179. Differences from Rubber
  180. -----------------------
  181. `Rubber <>`_ is a tool based on
  182. Ruby/Rails and Capistrano.
  183. I'll have to look into it some. It, like Moonshine, is based on
  184. Capistrano. It is a more general configuration management tool. It
  185. also has more features for scaling.
  186. Bitnami
  187. -------
  188. `Bitnamo <>`_ is kind of a package for pre-built
  189. open source applications. For instance, you grab a Joomla image and
  190. you get Joomla. From what I can tell, Bitnami itself is actually
  191. proprietary. The supported applications seem to be PHP.
  192. Bitnami also creates virtual images you can use to develop. It has
  193. inspired me to at least add a `todo item
  194. <todo.html#create-virtual-machine-images>`_.