It has been a week since our production team returned from the 2013 DjangoCon US. Though technically we didn't return since it was in Chicago where we are located! Nevertheless, it was, wholeheartedly, an uplifting and enlightening experience.

Russell Keith-Magee's keynote really demonstrated just how far the Django Project and its community have come. The focus on the Django trademark and the DSF's formalization of legal boundries is evidence of a growing maturity and market share. While Django does face some serious challenges in remaining competitive in an unrelentingly evolving ecosystem of Web technologies and techniques, Django is here to stay. That much is clear.

The social opportunity at a conference like DjangoCon US is invaluable. The experience of interacting with engineers using familiar technologies in unfamiliar contexts is immediately enlightening. You could do nothing but listen to other attendees talk to each other all week and still benefit. It is indeed incredible listening to two or more skilled engineers converse about the virtues and shortcommings of various aspects of Django or how it interoperates with other software. There is an intangible contextualization that is gained simply by being surroundedby peers for an extended time.

Of course the talks were great too. This year many of the lectures were very system-ops oriented, not that I'm complaining. System-ops is a technical art of combining interoperating technologies. Unlike Django itself there is no nicely polished set of documentation to teach anyone how to do system-ops correctly. The more quality talks and tutorials on system-ops, the better for everyone. However, there were two technologies that were presented that stood out as particularly interesting to this author.

Salt (docs.saltstack.com) is a configuration management solution of the likes of Puppet and Chef. It provides a declarative way to serialize your provisioning and deployment procedures so they are repeatable and, therefore, testable. Salt, however, is implemented with Python and the code underlying its core components can be extended as such. This makes it attractive for any development team using primarly Python, such as Django shops. While Salt introduces a whole host of new jargon to describe the abstractions in its implementations (states, pillars, grains, high-state, etc.), they all name fairly straightforward features that, when combined, appear to offer an extremely flexible way to handle configuration management.

The other technology presented that caught my attention was Docker (docker.io) from dotCloud. This isn't the easiest technology to explain, but I'll attempt to convey a short teaser. Sometime during the development of the 2.6.x kernel, it grew a set of features referred to as "namespacing" which allows process-level isolation at the operating-system level. This allows a process to run on the localhost except with full filesystem, networking and resource-utilization isolation. The benefit here is that, compared to a full-stack virtual machine, this process-level isolation is achieved with practically no overhead. If the localhost has the resources to run the process unisolated, then it likely has enough resources to run it isolated. These resource savings are immense. The userland exposure of these features is through the LXC project which you can find at lxc.sourceforge.net. 

Docker is a software package written in Go which essentially wraps up the features offered by LXC and combines them with AUFS (a version-control-like filesystem) all under a nifty commandline utility. The addition of AUFS permits copy-on-write for isolated process filesystems. This allows you to commit changes by the isolated process to the environment to a new image which can then be used to spin new process containers. Container images can be transferred over the network and deployed to any other system running Docker. The implications for local development environments, testing and deploying environment changes, twelve-factor development, and replicating and scaling production instances are huge.

At Imaginary, we will be keeping in mind all we have learned at DjangoCon US as we consider how to improve our own internal processes and standards moving forward. From the production team at Imaginary Landscape to the rest of the Django community, we extend a very warm thanks.