Let’s address a couple of specific questions today: should you use containers for your existing Django app - or VMs - and if so, how?
 

The problem

A [very]_ _common problem faced by application owners of all kinds is the divergence between environments. Environment replicability failure leads to “works for me”, surprise bugs, and developers working on manually reproducing environments (aka snow flakes). 

We’re looking at lost time at best, and long lived bugs at worst.

This can be a special issue with legacy applications where you need to capture an app _where in the state its in _in order to reliably make changes to.
 

Containers and VMs

Using a consistent replicable environment is the solution; when and how are the next questions.

The solutions available center on virtual machines and containers, respectively. 

But first, what are we talking about? 

A virtual machine consists of the entire stack, a full operating system, usually a Linux or BSD variant[0]. A container, on the other hand, is an isolated process in a partitioned space that must be run in the context of a separate operating system.

In theory running apps in containers is a no brainer, what with the isolated process and the ability to carry over dependencies from environment to environment without the baggage of a full OS.

In practice there are a few other considerations (and isn’t this always the case?).

 

When to pick which, in brief

This is a quick, caveat-free list for when you _definitely should _start using containers or replicable VMs for dev and/or deployment.

• Do you have an N-tier deployment which you need to replicate in full in dev? Use VMs [1]
• Is your main concern the app itself (which may have non-trivial dependencies or several supporting services? Use containers [2]
• Does your app have a basic setup with 1 or 2 easily managed backing services and _a common build environment? Use containers if you want, but don’t feel _obliged If you already have a production deployment, let’s say in a self-managed cloud hosting platform, e.g. EC2, Digital Ocean, etc, then to maintain parity you’ll want to use the same configuration and OS versions in dev and production. The most optimal way to do this is to use a configuration management tool (e.g. Ansible) apply the same basic configuration to production and to dev. The most straight forward way to do this is with VMs managed by Vagrant, relying on the same provisioning modules you use for production[3].

On the other hand if those services, or at least the exact configuration thereof, are not critical, then using containers, e.g. with Docker, are going to be much lighter weight. We’re talking 100’s of MBs rather than GBs, and seconds dev startup time rather than waiting for an entire VM and OS to load. This works _best _when you’re deploying with these containers of course. 

Lastly, if the installation steps are few, with minimal configuration decisions, and no special dependencies, you can probably get by fine without these changes. That doesn’t mean you can’t or shouldn’t look at standardizing at least your development platform on containers, but it does mean it needn’t be a priority. Once you start adding multiple processes and backing services beyond the database, as well as installation procedures that go beyond a single build command, it might be time to take a look at containers and configuration management.

---

This was brief and to the point, perhaps too short. If there’s something you’d like explained in more depth or motivated better hit reply and hit me with your questions. (And for our US readers have a happy Thanksgiving this week)

Virtually yours,
Ben

[0] We’ve heard rumors about Windows deployments!
[1] Vagrant’s multi-machine setup works for this
[2] Docker Compose works nicely, and there are even https://docs.docker.com/compose/django/https://docs.docker.com/compose/django/
[3] We’ll cover how to add this to an existing production app in a later newsletter

More like this

• Making an app webscale, or, app schemas vs. DB schemas (This Old Pony #25)
• I heard you liked logging from your app so I put logging in your app! (This Old Pony #23)