If you’re like me and spend a lot of time evaluating new technologies with the goal of “doing more faster” with your engineering organization, then you’re certainly aware of the many choices of DevOps tools like Puppet, Chef, Ansible, Salt, etc. In my opinion each of these tools is amazing at one piece of the DevOps puzzle – configuration management, and some are OK at other DevOps tasks. Each of the tools has a slightly different approach to configuration management but after comparing them I find that you’re usually picking a tool based on stylistic reasons like the DSL, existing recipes/playbooks, or existing familiarity. While I have my opinion on which of the above tools is “the best”, each tool only solves the configuration management piece of the puzzle.

If DevOps is truly a culture change and not just the codification of operational tasks then we need tools that help foster that culture and I think Docker goes a long way towards doing that.

Coming from the perspective of a developer looking at development tools, I see the above tools as APIs for DevOps, where Docker is more of a framework for DevOps. This is because Docker is both a runtime environment and a configuration management tool in one. Best of all Docker eliminates many common tasks in your development cycle and creates a tighter feedback loop between your development and operational tasks. I believe creating fast effective feedback loops between development and operations is critical weather development and operations are entire departments or simply tasks in within your organization.

In my experience developing software as a service platforms, one of the most problematic parts of the process is the management of the environments, how many times have you heard “works for me” or “works on our test servers”? Generally issues like this arise from subtle dependency changes between the environments introduced by both developers, QA and operations throughout the deployment lifecycle. To fix this problem I’ve seen, and attempted, several approaches. For example I’ve tried having a base VM and using Vagrant with Puppet or Chef to create local environments that were the same as test and production environments. This seems to work at first but it proved to be cumbersome to manage the differences between development and test environments as time went on. I found that this mostly because the DevOps (configuration management) tools are geared towards maintaining a perfect operational state based on strict server roles defined in the tool. While this approach was better than manual management of development and test environments it was still quite easy to have the configurations between environments drift apart over time and end up with the same issues mentioned above.

So how does Docker help and what makes it better?

• Uses a layered approach to dependency management, making the configuration of environments easier to maintain.
• Provides various runtime options allowing the same image to be run in multiple ways without extra configuration.
• Can use any or no DevOps tools to build up your Docker images reducing the learning curve across engineering.
• Lightweight runtime makes running multiple Docker images on a single machine more feasible than with VMs.
• Decoupled network and storage layers allows a single Docker image to be run on a single system or multiple systems easily.

These features allow developers to run complex multi-service architectures on their laptops and with the same runtime images operations can support any number of load or availability scenarios with as many or as few systems as necessary. This combination of predictable dependency management and runtime flexibility is like having all the ease of a Heroku environment with the flexibility of AWS or Softlayer.

Docker has many other impressive features, and few shortcomings, but in my opinion it’s a great framework to build your DevOps culture around as it makes maintaining a predictable production environment and a flexible development environment easy with one tool. Over my next few posts I’ll cover more specific examples of using Docker in development, test, and production environments. In the mean time visit the links below to read more about Docker and it’s growing ecosystem.

Docker, Deis, Shipyard