Manage Learn to apply best practices and optimize your operations.

Container technology's role in storage

Containers are somewhat limited in scope and scale so the next logical step for the technology is dealing with storage.

This article can also be found in the Premium Editorial Download: Modern Infrastructure: Collaboration moves beyond email:

Could containers dethrone virtual machines as the next generation compute architecture? I've heard many industry folks say that containers are moving faster into real deployments than almost any previous technology, driven by application developers, DevOps and business-side folks looking for agility as much as IT needs efficiency and scale.

Containers were one of the hottest topics at VMworld 2015. VMware clearly sees a near-term mash-up of virtual machines and containers coming quickly to corporate data centers. And IT organizations still need to uphold security and data management requirements -- even with containerized applications. VMware has done a bang-up job of delivering that on the VM side, and now it's weighed in with designs that extend its virtualization and cloud management solutions to support (and, we think, ultimately assimilate) enterprise containerization projects.

VMware's new vSphere Integrated Containers (VICs) make managing and securing containers, which in this case are running nested in virtual machines (called "virtual container hosts"), pretty much the same as managing and securing traditional VMs. The VICs show up in VMware management tools as first-class IT managed objects equivalent to VMs, and inherit much of what of vSphere offers to virtual machine management, including robust security. This makes container adoption something every VMware customer can simply slide into.

However, here at Taneja Group we think the real turning point for container adoption will be when containers move beyond being simply stateless compute engines and deal directly with persistent data. Until that happens, containers will be necessarily limited in scope and scale.

What's in a container?

Briefly, a container encapsulates and isolates application code inside a container process that makes the code believe it has a machine all to itself, translating any system service calls out to the container host. Since containers are really just processes, many (possibly thousands of) containers can easily share a single server, be it physical or virtual.

The contained application bits think they have a whole running operating system to themselves (like they would if hosted in a virtual machine), but they are actually sharing the host OS. This is less isolation between applications than virtual machines provide, but also more efficient (because each container is not running its own OS).

There are other advantages. Containers run in user space and thus are less likely to corrupt, block or crash anything at the kernel level. Containers are quickly copied, often cached, and can be readily spun up and down. By design, containers can be fully built almost anywhere (like on all those developer MacBooks) and then run anywhere else consistently (like on Amazon Web Services). But all this means that containers were originally designed to be stateless, containing no data that needed protection or persistence.

Containers were originally designed for building microservices. A microservices architecture is great for apps architected to be hosted in a cloud. These new apps have containerized bits that are stateless in that they persist no internal data and can come and go (outside of atomic micro-transactions) dynamically as operational needs dictate.

Containerized application storage, however, is still big thorn. Apps running inside a container can access the local OS storage, but if the container is moved (or cloned, replicated, etc.) to another container host, it doesn't take any current host data with it. As such, stateless containers are not suitable for a wide variety of applications that need a reliable and persistent data service. Microservices that persist data at a micro-transaction level into cloud storage, such as AWS S3, work well, but most applications need more than that.

Solving for storage

Does that mean that containers will have a small part to play in tomorrow's data center, limited to developers' playgrounds or new cloud-hosted microservices applications? We think the benefits of containers are too attractive to the enterprise data center to ignore, and as you might have guessed, container data management products are emerging.

ClusterHQ's Flocker, for example, adds the ability for a container to mount a unique Flocker dataset that moves with it, even across container hosts. This dataset is partitioned under the covers by the Flocker controller out of shared block storage that is mounted to all the container hosts. With this solution, containers become "stateful" and can now readily host almost anything, even databases like MongoDB and MySQL. 

As of version 1.3, Flocker supports OpenStack Cinder block storage and direct custom drivers from the likes of EMC, NetApp, Hedvig and Nexenta, with more coming soon. At VMworld, VMware announced Flocker support through a vSphere driver so any vSphere-mounted storage will be available to containers. This also includes both Virtual SAN and third-party storage that supports its Virtual Volumes. Both scenarios are interesting, as they add explicit storage services, such as QoS to each container's storage, just as they do to VMs.

In their limited stateless form, containers and VMs each have a defined role to play. Now that containers support virtualized storage directly, hypervisor vendors will need to act quickly to offer high value-add capabilities. Since the future data center will likely be a mixed VM/container environment with plenty of nesting of containers within VMs (and support hybrid, DevOps-centric cloud operations) there will be plenty of opportunities for them to provide cohesive management solutions.

Containers are helping us build a more fluid, agile, but ultimately convoluted environment. That means everyone will need even better security tools, more dynamic networking and, of course, more adaptable storage. Be sure to let us know how your IT organization is adapting and adopting container products, and what challenges you see to broader containerization.

This was last published in October 2015

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

The complete rundown on Docker data storage and containers

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

It's hard for me to see that containers will achieve real penetration until they have sufficient security and data management tools. At the same time, it's hard to see how the tools will come along until there's a critical mass of containers out there. Maybe a container vendor needs to buy a security vendor.
Cancel
Hi Sharon,
I agree management tooling is critical. I think a big challenge on the management side will be assuring application performance at scale. I'm not sure that the web2.0-ish approach of simply load balancing hosts is going to cut it with complex webs of interconnected micro-services all contributing to the end performance experience.
For security and some other key management see that VMware already fully supports containers in their mature enterprise management solutions as first class equivalents to VMs. That with the fact that containers themselves are immutable objects should go a long way to meeting security requirements at that level.
Data management may not be more complicated than with VM's, as most data "container connecting" solutions connect to the same storage services we already have, and as a bonus in more explicit "blueprinted" ways that can be "meta" analyzed.
But again I agree that demonstrated mature management will provide the predicted "change in watershed" moment.
Cancel
so how do we get that?
Cancel

-ADS BY GOOGLE

SearchDataCenter

SearchAWS

SearchServerVirtualization

SearchCloudApplications

SearchCloudComputing

Close