Strategic CIO // IT Strategy
News
9/3/2014
09:06 AM
Langdon White
Langdon White
News
Connect Directly
RSS
E-Mail
100%
0%

Containers + DevOps: Power Couple

Containers provide a lightweight alternative to virtual machines. The benefits to your DevOps strategy go beyond easier deployment.

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.

Langdon White is a platform architect for Developer Experience at Red Hat.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
zerox203
100%
0%
zerox203,
User Rank: Ninja
9/8/2014 | 11:15:01 AM
Re: Containers + DevOps
It is true that DevOps is changing the way we look at pretty much everything. In a way, it's like a lot of new methodologies: "agile", BYOD, etc. It's not about adding something new, it's about taking down barriers and letting people do their jobs the way they've always wanted. Seems simple enough, but it took as a while to get there in terms of security policies and business, and as you point out, it comes with some headaches of it's own. There is a reason many businesses are apprehensive about these policies, but I think the benefits are starting to far outweigh any downsides.

Containers seem like a great solution for developers wanting things just how they like them, and it's not something I'm too read up on. Thanks for the primer! It's good to see some disclosure too - the full version of the article on Dr. Dobb's (a good read!) notes that it's not 'all sunshine and rainbows' with containers. That's kind of a rarity in the IT-hype blogosphere. To be honest, this sounds a little heady for my software dev needs, but I'll be sure to pass it on!
Stratustician
100%
0%
Stratustician,
User Rank: Ninja
9/4/2014 | 9:10:38 AM
Re: Why not update an existing container without creating a new one?
From a security perspective, you would need to get security blessing during the app creation stage, which in many cases might work provided you have a security rep on the DevOps team.  For other organizations, I wonder if using containers, and having to create new containers (in a sense) if you are updating/patching the application might mean more frustration from the security team if they have to go ahead and test again that the security policies are in place.  Is there a way to embed security controls in the container as a default as part of the container certification process so that any new containers would carry the same policies?
Charlie Babcock
100%
0%
Charlie Babcock,
User Rank: Author
9/3/2014 | 3:56:06 PM
Why not update an existing container without creating a new one?
Isn't possible, Langdon, for a developer to update an application tier inside Docker, without disturbing the layers around it? That is, a silver bullet update, affecting one layer in a production system and leaving others unchanged? Granted such a change must be tested in staging before going back into production. You appear to recommend generating a new point release of the application in development, then swapping in the new container. Isn't there a way to work with the existing one? 
Transformative CIOs Organize for Success
Transformative CIOs Organize for Success
Trying to meet today’s business technology needs with yesterday’s IT organizational structure is like driving a Model T at the Indy 500. Time for a reset.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Must Reads Oct. 21, 2014
InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A roundup of the top stories and trends on InformationWeek.com
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.