Django + EC2 + Google App Engine

Working on Uncensor project has allowed me to dig a little deeper into three interesting technologies: Django, Amazon Web Services (EC2, S3 and Simple DB) and Google App Engine.

Over the jump I talk a little about each and how they can provide benefits to an organisation’s web development efforts.


Having a coding background, I’ve learnt a few different programming languages and environments in my time. Recently I’ve been getting my head into Django (and by extension Python) to develop new functionality for the Uncensor site.

I’ve seen Python mentioned quite a bit over the past year or two – it seems to be a very popular scripting language, esp. on Mac OS X (Python now ships with Mac OS X). I appreciate some of the benefits of the language – the clean code (as there are no brackets or semi-colons to separate code) – but it is taking a little while to get used to. I’m sure I’ll be fine in a few weeks time having worked with it for a while.

But the real star so far has been Django – it has been a fantastic environment to work in. The Models functionality (which makes it super-easy to both create database access classes and related web-based administration panels) is brilliant. I’m really enjoying being able to focus on the application logic rather than coding tedious SQL statements and administration pages.

I’m actually starting at the pointy-end of things, implementing a JSON web-service and consuming an XML web-service, and I can see some small issues with application development in an environment that is aimed at building content management systems (CMS). That said, I’ve been able to do most things that I need with a minimum of fuss.

In terms of productivity, I’ve spent about 1 day working in Django, and I’ve already built what would have taken 2-3 times that amount of time in PHP (even though I know PHP better than Python or Django). In that sense, I’m very impressed.

But why mention it here? I actually think Django (and probably similar frameworks such as Ruby on Rails) are a really good fit for organisations wanting to build CMSs themselves. Although to build a site requires “building from scratch” to a large extent, there are many, many features that support the process, making it much faster and easier than traditional coding exercises.

And there is a growing number of third-party applications already appearing that implement comment systems and more, potentially further reducing development time.

Traditionally I would have steered towards an existing CMS such as Drupal when advising clients on their CMS requirements, but I now consider a bespoke solution, built in a framework such as Django as a real option for systems that have basic, but tailored, requirements.

I would also hint that Django be considered over Ruby on Rails due to it’s lighter memory requirements, and it’s inclusion in Google’s App Engine release (more on that shortly).

Amazon EC2


The other technology that I’ve been looking into is Amazon’s “Elastic Compute Cloud” service (EC2).

Although this service has been around for some time, this project has given me an opportunity to dig a bit deeper into it. Essentially EC2 allows you to create your own server (or servers) hosted in Amazon’s data centers.

The cost is very competitive – for a small server (which is still pretty significant) costing around USD$900 per year (plus some nominal data charges – maybe adding up to a couple of hundred dollars for many organisations). Given that hosting for a dedicated server in Australia can cost hundreds of dollars a month, this is a very affordable option for a dedicated server.

The biggest downside of the EC2 service is that any data on the server is not saved – meaning that you have to put systems in place to:

  1. Store data on a different server (Amazon offer the S3 and Simple DB services to support this requirement)
  2. Setup systems that allow you to “rebuild” your platform in case of failure

Both of these requirements mean that an EC2 setup requires a bit of technical know-how. But once setup, the service can be very cost-effective.

Another benefit of the service is that it’s very easy to launch new “instances” (effectively, additional servers) to handle increased traffic loads. To take advantage of this, however, requires deep understanding of the operating system and server systems – any scaling has to be handled by you.

(EC2 also only supports Linux-based servers at this point in time. However, for most non-profits who are likely using open source frameworks and CMSs anyway, this shouldn’t be an issue.)

Google App Engine


Google recently announced the launch of their App Engine service.

At first blush the App Engine service seems very similar to Amazon EC2, and in some respects it is. In fact, some enterprising folks have already “ported” App Engine to EC2. (This isn’t really a true “port”, but it does demonstrate that it should be possible to move applications from App Engine to EC2 or some other grid-based system in the future.)

The biggest difference is that if you use the Google App Engine framework and supporting database system (Big Table), the application can automatically scale to handle increased loads. This is a big improvement over the EC2 system, which requires the manager of the server (you) to implement such a regime.

App Engine supports Linux + Python and Django out of the box. Yet another reason to consider Django for projects.

Both EC2 and App Engine are very exciting developments, providing scalable, low-cost infrastructure for organisations. Combined with the rapid development afforded by Django, this can mean significantly reduced web development and hosting costs, which is especially important for non-profits (or any organisation) that wants to maximise their “bang-for-buck” when it comes to their web activities.