Django deployment using Platform-as-a-Service (PaaS)
UPDATE: I’ve published a PaaS bakeoff summary comparing four different PaaS providers: Heroku, Dotcloud, Stackato and OpenShift.
Django developers have had to wrestle with deployment for so long, that just about everyone by now has either resorted to writing their own custom Fabric script or embraced Chef or Puppet as their swiss army knife provisioning and deployment tool. Google App Engine has had Django support for a few years now, but no Django developer took it seriously because your only data storage option was to use Google’s Bigtable NoSQL datastore rather than a more common RDBMS such as MySQL or PostgreSQL. (Note: Google has since announced SQL support for App Engine, so you no longer need to use django-nonrel.)
But within the last year, there has emerged a wave of PaaS providers that offer seamless deployment without having to manage servers, a luxury that Rails developers have enjoyed for several years with Heroku. Some of these Python-only providers have come and gone (Djangy, ep.io and my own DjangoZoom), but the providers who are still standing are getting more mature and broadening their offerings. While Dotcloud has been polyglot from the start, Heroku only recently added their Cedar stack to support other runtimes besides Ruby, including Python. We also saw two goliaths release open source PaaS solutions, VMWare’s CloudFoundry and Redhat’s OpenShift. Amazon even recently announced support for Python on their Elastic Beanstalk PaaS.
So the market is heating up and it’s getting quite competitive, which likely means falling prices but also carries the risk for consolidation as bigger PaaS players buy out or crush smaller players. We’ve already seen EngineYard buy Orchestra (to beef up their PHP offering) and AppFog buy Nodester (to beef up their Node.js offering). AppFog switched from their homegrown PaaS to building on top of CloudFoundry, and ActiveState took a similar route with their Stackato PaaS, which also has its origins in CloudFoundry, but has since diverged quite significantly from CloudFoundry.
With all of these PaaS offerings, how does one know which one to use and trust? How do you know if it has the features you need for your app, and how do you know if it will scale, and how much is it going to cost? In a recent Venturebeat article entitled An ugly duckling no more: why Platform-as-a-service is poised for huge growth, the author says that unfamiliarity with PaaS among developers is a barrier to adoption:
Not enough people know what PaaS can help their company accomplish. Heroku’s Teich said when he talks to developers and enterprises about PaaS, they don’t do much evaluation of their options or even know what the options are. Basically, they are woefully uneducated. “Developers have a lot of preconceived notions about which PaaS they should use,” Teich said. “It’s another sign that PaaS is something that has a lot of growth potential.”
I remembered reading Ken Cochrane’s blog series last year in which he reviewed all of the Django-supporting PaaS providers and wrapped it up with a nice summary of the pros/cons of each provider. At the recent DjangoCon, he admitted that they need to be rewritten and updated, but given that he’s now employed by Dotcloud, he’s not exactly in the best position to do this comparison. I, on the other hand don’t have any such allegiance and can therefore write an unbiased comparison of the various PaaS providers from the standpoint of a Django developer.
So inspired by Ken’s posts, this is the first in a series of blog posts exploring how to deploy Django apps on the leading PaaS providers:
- Stackato: How to deploy Django projects to the Stackato PaaS
- OpenShift: Deploying Django to OpenShift
- Dotcloud: article coming soon!
- Heroku: article coming soon!
- Amazon Elastic Beanstalk: article coming soon!
UPDATE: I’ve published a PaaS bakeoff summary comparing four different PaaS providers: Heroku, Dotcloud, Stackato and OpenShift and what changes you need to make to your Django project to deploy it.