Whether CoreOS's Rocket successfully challenges Docker's lead in cloud containers will come down to which gets DevOps right.

Charles Babcock, Editor at Large, Cloud

December 4, 2014

7 Min Read

InformationWeek Chiefs Of The Year: Where Are They Now?

InformationWeek Chiefs Of The Year: Where Are They Now?


InformationWeek Chiefs Of The Year: Where Are They Now? (Click image for larger view and slideshow.)

Docker has been flying high throughout 2014. It's racked up a series of notable firsts and accomplishments, but recently, the cloud container system has encountered turbulence. While cruising through space as contested as the Ukraine, CoreOS has launched a Rocket at it. And it will face continued sniping in 2015.

"CoreOS essentially declared war on Docker with the announcement of Rocket, their own rival system," declared Bryan Cantrill, CEO of cloud supplier Joyent, in a blog posting Tuesday responding to CoreOS's new Rocket container system.

Joyent says it supports running Docker on the Joyent public cloud and on its SmartDataCenter software for the private cloud. Having recently discovered that native containers on its SmartOS in-house operating system aren't going anywhere, it's embraced Docker and views dimly anyone who seeks to muddy its strategic vision.

Joyent's SmartOS is a variant of Solaris, and that fits in with Docker Inc.'s plan to be a pan-operating system platform. With Docker, you'll one day be able to build containers that run in Linux, SmartOS, or Windows environments, using the same formatting tool and orchestration platform. Until Thursday, Docker was something you composed a container with. Now it's something that you compose and orchestrate containers with, a platform of multiple tools and processes leading to container deployments.

[How bad is it when a security exposure creeps into container operation? It's bad. See Docker Security Flaw Found.]

Many powerful parties are happy with the enthusiasm around Docker and want to share in it. At Amazon Web Services' Re:Invent conference in November, Amazon announced an EC2 Container Service to launch Docker containerized workloads. As noted above, Microsoft wants .Net and Windows developers to become Docker users.

Thursday, IBM announced that the Docker platform will be the basis for an IBM Container Service in Bluemix. The service will allow developers to put a new application in a Docker container and launch it directly to a bare-metal server in the SoftLayer cloud, via Bluemix. That's another strong endorsement.

Even VMware, which believes the only good container is a container inside a virtual machine, has been forced to come out with support for Docker in its vSphere and vCloud management systems. All of this says a lot about how far Docker has come in a remarkably short amount of time. And yet, when CoreOS CEO Alex Polvi talked about the reasons for CoreOS's creation of Rocket and a container specification, strains of common sense showed through the buzz, the enthusiasm, the sheer momentum of Docker and its adherents.

CoreOS developers have been contributors to Docker, but they thought they were helping build a modular unit of a future container building and deployment process. They was surprised to find that Docker is both the building and deployment process. Docker Inc. "changed the whole charter of the project that we thought we were joining," Polvi said in a phone interview with InformationWeek Tuesday.

"Rocket is built to be a standalone, command line tool," a modular unit that fits in with other things that either developers or IT operations may be doing that require use of containers. Docker, on the other hand, "has evolved to become a platform, a set of integrated tools and processes" that take over steps in the container creation and deployment process. In one sense, it standardizes them, which makes them less prone to developer or IT error; in another, it requires users to do things its way.

I have noted Amazon, IBM, Microsoft, and VMware support for Docker, but the container support I'm most interested in is Red Hat's. On the face of it, Red Hat has plenty of reason to greet Rocket and its App Container specification with less than open arms. CoreOS has emerged as a competitor in providing a host system to run Docker containers, a more lightweight, quick-on-its-feet version of Linux that helps maximize container efficiencies. Red Hat now has its own container host system, Atomic Host, so the two can be viewed as competitors.

But Red Hat has gotten to where it is by keeping some sense of what developers want. It's viewed as stodgy, set in its ways, and slow to respond to new challenges, particularly by developers keen to take advantage of the latest technologies. But at the same time, it knows how to fend off interlopers and disrupters of its ability to produce a bulletproof version of production Linux.

Unlike everyone else I talked to, Lars Hermann, senior director of strategy at Red Hat, didn't have an instant position on Rocket or what's best for the Linux container community. "Many of the concepts that CoreOS brought up in Polvi's blog make a lot of sense," said Hermann.

Red Hat is closely allied with Docker and a frequent code contributor. "Docker has made it very easy for developers to use Linux containers," he noted. But containers as a cog in an extended, integrated platform of tools and processes may not fit every phase of container use, he observed.

In addition, Rocket and its accompanying spec are too new to be effectively evaluated. Nevertheless, Hermann said if developers find Rocket useful, Red Hat would consider support their use on Atomic Host.

Container security remains a concern at Red Hat. Indeed, Hermann and his container-team associates recently said plainly, containers don't contain. They can't be relied upon in their present state of development to guard against malicious code in the container running next to them, nor can the container host protect itself from intrusion by an effective agent buried in one of its guest containers.

It's not in Red Hat's interest to support Docker versus Rocket or vice versa. Rather, it will evaluate both entrants, watch their pickup and usefulness to developers, and decide with a larger community where the interests of Linux users lie. In listening to Hermann, it struck me that Docker, with its large ecosystem and built up catalogue of Dockerized code, may be favored by developers, but on the operations side of DevOps, something like Rocket may play a significant role.

Operations may decide one workload must run in a more secure fashion than the standard Docker container allows. Assigning it to an SE Linux host will help, but it may require other special measures that a revamped container approach via Rocket and App Container may permit. Parts of an application, each in its own container, may be distributed onto different servers, each with a local development team. Frequent updates may be needed, but some impose stiffer security policies than others and still the parts have to be deployed and function as a whole.

Forbes contributor Ben Kepes sided with Docker versus Rocket and said CoreOS was commercially motivated in launching Rocket. I have to differ with my InformationWeek Radio colleague on that point. Last I knew, the value of an open source project lay in the merit of its code, not the purity of motive with which the code was contributed or whether it passed muster as timely by outside critics. CoreOS has advanced sound principles advocating keeping containers lightweight and modular, loosely coupled to the surrounding tools and deployment processes. Docker wants to hardwire more things together into a platform.

As Hermann said, it's too early to declare one container approach as the only one needed. This is a rapidly evolving field, rich in the promise of new efficiencies if best practices can be established for containers in production operations -- or, make that containers in mixed ownership and multitenant production operations.

If the world weren't changing, we might continue to view IT purely as a service organization, and ITSM might be the most important focus for IT leaders. But it's not, it isn't, and it won't be -- at least not in its present form. Get the Research: Beyond IT Service Management report today. (Free registration required.)

About the Author(s)

Charles Babcock

Editor at Large, Cloud

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 Week. He is a graduate of Syracuse University where he obtained a bachelor's degree in journalism. He joined the publication in 2003.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights