It's hard to look back on 2014 and not conclude that containers will play some significant future role in the cloud. Right now everybody -- apparently including Red Hat and Google -- agrees that containers in the cloud should be run in a virtual machine.
But with containers, we're nearly where we need to be for the ideal, streamlined cloud workload vehicle. The container isolates one application from another on a host, has its own API access through which it may be commissioned and decommissioned without affecting other apps, and makes highly efficient use of a shared operating system kernel. It scales up and down quickly and easily, provided the resource is available. What's not to like?
Virtual machines have many of the same attributes, but they are more cumbersome to both commission and scale. Instead of sharing the host's kernel, each virtual machine needs its own operating system, which means significant overhead. Each is more secure than today's container, but that may not always be true in the future, despite VMware's dictum that the only good container is a virtualized container. "This approach has become an unnecessarily heavyweight solution to the underlying question of how to best run applications in the cloud," David Strauss wrote in the Linux Journal.
If virtual machines are heavyweights, why haven't containers replaced them? Container isolation works. The problem lies not in the containerized application's boundaries, but in the available safeguards against unpredictable code breaking out, intentionally or otherwise, into another container's memory space. Even worse would be a breakout into the host system's space, where an intruder could peer into each container and the host operating system.
[Want to learn more about how the Rocket alternative was launched? Read Rocket Challenges Docker On Cloud Containers.]
The problem isn't so much about flaws in container design than flaws in container operational implementation. Hence, I predict that 2015 will see revised methods of implementing container operations that start to address security issues, pushing containers toward the center of cloud operations.
Docker has so far dominated the discussion of Linux containers, so when observers discuss container security, they're talking about Docker operations. One example of an existing security issue is the Docker pull feature. When directed, Docker will retrieve a container image and load it on a host. It performs the fetch and unpack actions as one function, with no validation of the image, even though it's come across the Internet before installation.
In the Red Hat security blog on Dec. 18, Trevor Jay noted that unpacking consists of following a preloaded file path, meaning the unloaded code could be set loose at nearly any point in the file system. "Docker brings with it an entirely new attack surface," Jay wrote. And that's after everyone knew we already had a container security problem.
At the beginning of 2014, there was Docker and little else. But now there is a split in the open source projects developing container formatting systems. There's Docker, which is sponsored by what is now Docker, Inc. (formerly DotCloud). Docker containers are generally considered complementary to Google's Kubernetes container provisioning project. Now there's also CoreOS' Rocket, whose appearance on Dec. 1 shook up the container world.
Nearly overlooked in the hoopla over Rocket was Docker's Dec. 4 announcement that it was adding a container orchestration system to its platform. Successfully building what had been a formatting system into one that made a lot of future deployment decisions -- such as what operating system would be needed -- would put Docker in the driver's seat. Such a platform might have the power to determine which vendor's operating system would be most frequently used -- or even produce its own stripped-down container Linux to supplant those vendors.
Doubters of the need for one broad container platform, including Pivotal and Red Hat, greeted the Rocket announcement enthusiastically almost as soon as it was announced.
But Docker was leading an emerging wave. "The big message here," Ben Golub, CEO of Docker, said in an interview prior to the Dec. 4 announcement, "is that as the world moves from a small number of 'Docker-ized' applications on a few hosts to many containers on multiple hosts, the need for an orchestration system is writ large."
More than one participant in the container community saw the handwriting on the wall. CoreOS, as a contributor to Docker, had never agreed to produce a container platform so dominant that it might end up eliminating its own role. In its own announcement, CoreOS harkened back to an earlier Docker project that was smaller and lighter, which incidentally left orchestration open to a number of possible decision points.
Asked whether everyone in the community supported Docker as a broad platform, Golub had heard the critics in the background, but he was not concerned enough to deflect Docker from its path. "Docker is being used in more mature enterprises [as well as Web companies]," he said. "It's more painful than it needs to be to deploy it on a large scale."
By becoming a platform that can orchestrate deployments, Golub continued, Docker "can release the productivity of developers, regardless of what tools they use." That remark was significant because Docker is working with Microsoft to allow Windows Studio and .net tools to put code into the Docker format and run it as a Windows container.
Expansion across operating systems was as natural as expansion across more workload configuration functions. "That's how Docker grows -- by being extended and by being open [to additional developer groups]," Golub said in a Nov.26 interview.
Docker can -- and should -- grow in this direction, but the rumblings that accompanied the embrace of Windows as another Docker-izable system sparked something of an identity crisis among some core Docker contributors. They thought of themselves as Linux developers, and of Docker as a Linux technology. They envisioned it rapidly advancing the state of the art of running Linux applications in the cloud. Much of Docker's development -- Docker, Inc. comprises 70 people; the Docker project 700 contributors -- has come from developers who envisioned a light and flexible technology for their own purposes, not a universal and dominant, Windows- embracing platform.
The back-to-basics claim that accompanied the Rocket announcement Dec. 1 may be overstated. CoreOS may have its own interests to defend against Docker, as may Red Hat (despite it's being an early backer of Docker). Nevertheless, what's most likely to emerge is a flexible alternative way to implement a Linux container in the cloud. And if it's a standard and lightweight container with a new security infrastructure, all bets are off on the question of whether the future cloud will run workloads primarily as virtual machines or as containers.
Our latest survey shows growing demand, fixed budgets, and good reason why resellers and vendors must fight to remain relevant. One thing's for sure: The data center is poised for a wild ride, and no one wants to be left behind. Get the Research: 2014 State Of The Data Center report today. (Free registration required.)Charles Babcock is an editor-at-large for InformationWeek and author of Management Strategies for the Cloud Revolution, a McGraw-Hill book. He is the former editor-in-chief of Digital News, former software editor of Computerworld and former technology editor of Interactive ... View Full Bio