From Silos to Services: Cloud Computing for the Enterprise

Feb 28 2015   11:34AM GMT

Container Frameworks – Tools, Products or Solutions?

Brian Gracely Brian Gracely Profile: Brian Gracely

Tags:
DevOps
Docker
Linux
Unix

Screen Shot 2015-02-28 at 10.25.33 AMEarlier, I covered some of the basics of the container technologies that are quickly evolving .within web-scale clouds and will eventually be migrating into Enterprise and Mid-Market data centers. Once you begin to understand the basics and have played with the technology, you’ll probably start asking yourself a few basic questions:

  1. How should I manage a growing number of containers?
  2. What tools are available to coordinate containers within my datacenter or on public cloud environments?
  3. Are all of these different container technologies compatible?
  4.  If I want an alternative to pure open source consumption, are their commercial alternatives for containers that I could use?

We talked about some of these things on a recent podcast with Nick Weaver (@lynxbat), from Intel’s Software-Defined Infrastructure group. Matt Asay also dove into this a little bit recently, looking at Docker + Mesos.

What it boils down to is the common tradeoff between using a set of “interchangeable” tools (the UNIX/Linux philosophy), or using a more complex system/solution. The discussion has centered around a phrase that Docker’s Solomon Hykes (@solomonstre) uses, “batteries included but removable“.

Some companies, such as Docker, CoreOS, Hashicorp, Mesosphere and the PaaS vendors (and others), are building frameworks of tools around containers. These include the container format, description files, and runtime. But as we all know, managing any system requires more than those basics. It needs tools to deploy. It needs tools to describe and orchestrate complex environments. It needs tools to schedule and coordinate resources. It needs to be able to network resources together. It needs to manage data; implement security, etc.

So the question becomes, does a company pull together the pieces themselves, or acquire/consume an entire stack from a specific company or group? This architectural decision is at the core of the debate between Docker and CoreOS (and here, and here) It has the attention of container ecosystems as they try and determine where to build extensions into existing frameworks vs. building their own technologies. Or does a company look to abstract some of that lower level stuff and try and solve application level challenges at a higher level and let things like PaaS work out the underlying container challenges?

And now we’re also starting to see the IaaS platforms that were previously VM-centric – both VMware and OpenStack – begin to look at how containers will be integrated in the future. VMware’s approach is to embed containers within VMs. OpenStack is looking at ways to integrate CoreOS and Kubernetes, as well as having a Containers Team that’s leading Project Magnum.

As I mentioned earlier, the container space is evolving and innovating at an incredible rapid pace. And it’s a mix of large and small companies, open source and commercial and public cloud offerings. It’s a space that I truly believe everyone in IT, whether you work in Apps, Ops or Infrastructure needs to begin getting hands on experience with. It’s a complex space, but it’s never been easier to start learning.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: