Let’s address a couple of specific questions today: should you use containers for your existing Django app - or VMs - and if so, how?
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.
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. 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?).
This is a quick, caveat-free list for when you _definitely should _start using containers or replicable VMs for dev and/or deployment.
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)
 We’ve heard rumors about Windows deployments!
 Vagrant’s multi-machine setup works for this
 Docker Compose works nicely, and there are even https://docs.docker.com/compose/django/https://docs.docker.com/compose/django/
 We’ll cover how to add this to an existing production app in a later newsletter
Learn from more articles like this how to make the most out of your existing Django site.