Sashkin - Fotolia
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.
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.
