Containers + DevOps: Power Couple

There can be friction between developers and operations when the latter tries to check the "crazy things" that developers want to deploy. As an old, probably bad, truism of mine goes, "Ops would be happy to never change anything, QA likes a few new features to test, developers want bleeding-edge toys every week, and the business wants new stuff now."

DevOps eases this tension by providing another abstraction layer. If developers are responsible for their applications in production (where "application" means the source code and its dependencies above the OS), then operations people are free to focus on making sure that there is appropriate computing power, fail-over, geographic presence, and everything else that symbolize a robust, modern, operational environment. When the people who create an application are the ones supporting it, things tend to run more smoothly: When a developer gets a bug call at two in the morning for a couple of days running, that bug gets fixed pretty quickly. Operations people are happier because they can now focus on automating their environment, not responding to application outages that they often don't have the knowledge or skills to fix.

As part of a DevOps strategy, containers provide a more subtle benefit than just easier deployment. They enable development and operations leadership to "bless" certain application stacks for development use. These template-type stacks include agreed-upon components and provide a guide for junior developers or contractors to follow. Using containers to implement the "blessed" stacks ensures that development teams have a structure to follow but will still be able to easily modify applications, whether to add a critical new feature or to add a module that was missed in the original definition.

Read the rest of this article on Dr. Dobb's.