olly - Fotolia

Docker fork talk prompts container standardization brawl

The IT industry is abuzz with a debate about whether a Docker fork is imminent or a good idea for container standardization.

Talk of a Docker fork is gaining momentum following the release of Docker Engine 1.12., but whether that's a positive for IT pros remains to be seen.

While Docker Inc. officials say there’s no substantiation for reports that formal talks have taken place to plan a fork for the containerization software, that hasn't stopped the IT industry from asking whether it would at least be a good idea, now that it's been mentioned.

One catalyst for the debate appears to be a recent Medium post by Samsung engineer Bob Wise, who argued, "The Docker approach has been characterized by a rapid pace of feature introduction in Docker Engine versions, along with the fragility caused by code churn."

Wise further stated that the community should be proactive and create a Docker fork that would be "a stable, simple, boring container implementation, with minimal essential characteristics, and [a] community agreement around image creation, naming and publishing."

Wise specifically called out Docker's move to embed Docker Swarm into Docker Engine with version 1.12, describing it as "equal parts poor architecture and brilliant marketing."

At last week's VMworld conference in Las Vegas, Docker officials re-emphasized the Swarm piece of Docker Engine 1.12 is swappable to allow for other orchestration platforms, such as Google Kubernetes or Mesos.

"Docker added Swarm Mode based on overwhelming feedback from the users of Docker -- we also made it optional for those [who] prefer to use third-party orchestrators," said David Messina, senior vice president of marketing and community at Docker, based in San Francisco. "The fact that IT shops have a choice among orchestrators is a good thing for users and ultimately will result in innovation from all parties."

This part of the Docker pitch, however, appears to be falling on deaf ears in the ecosystem.

Docker fork could appease users, partners

In some IT shops, particularly in smaller and midmarket areas, Swarm Mode has caused IT pros to drop consideration of Kubernetes and Mesos.

"If you're massive, tools like Kubernetes make sense," said Dan Elder, senior engineer and Linux services manager for IT consulting and services firm Novacoast Inc., in Santa Barbara, Calif.

Novacoast looked at Mesos and Kubernetes for internal use prior to the release of Docker Engine 1.12, and it felt Mesos and Kubernetes came with a lot of overhead for a relatively small environment.

Having something built in was immediately preferable for Elder's shop -- and for others among Novacoast's clients, Elder said.

Docker has been the container standard for the industry over the last few years, and Elder said he'd hate to see that change. Nevertheless, with a Docker fork, third-party vendors could be assured their Docker-based products won't suddenly become obsolete if the direction of Docker changes, he said.

"It's a very rapidly evolving ecosystem and tough to keep up with at this point," Elder said. "It would certainly be beneficial to have that common core that everyone can work with together."

Standardization upstream is a better move than forking, argued Daniel Riek, senior director of systems design and engineering at Red Hat, one such third-party vendor, in his personal blog. Riek pointed to tensions around a fork originating in "the aggressive way that Docker Inc. is trying to control the Docker open source project."

Will industry politics stymie containerization momentum?

Ultimately, all the behind-the-scenes maneuvering could slow the container movement.

"I think Docker Inc. has been playing politics with a lot of folks in the space and have made no friends on that front," said Aaron Welch, co-founder and senior vice president for Packet, a New York-based bare-metal hosted server provider.

"Some in the community forget that there are other platforms that could leverage Docker, which would need their own runtime implementation, like IoT [internet of things] or embedded devices, and not having a container spec and roadmap that everyone can build against makes it more difficult to do that."

In the end, it may just be the user community that forces either hand and decides the outcome -- whether to pressure Docker to provide a stable core or force the vendors to continually play catch-up.
Chris Rileyfounding partner at HKM Consulting

Docker is also potentially playing with fire if its rapid development has introduced instability into its core product, as Wise's post alleged it does.

"For us, Docker has been very stable with the core engine features, and they have not regressed due to the so-called pollution of the engine with Swarm," said Venkat Thiruvengadam, principal engineer for San Francisco-based startup Zenefits, which offers HR management software as a service. "But if people start noticing issues in their core use case, someone is just going to fork it out."

Docker's Messina noted that Docker offers enterprises long-term support for the whole stack, not just the container format.

Packet, a member of the Cloud Native Computing Foundation founded by Google, would support a "boring spec," according to Welch.

"I know the detractors will point shaky fingers at the lumbering OpenStack zombie and say, 'This is what you'll get,'" he said. "But I would argue that the scope is modest enough such that a properly stewarded process involving the right stakeholders could produce something that everyone is happy with."

Users hold the cards

Several industry observers said Docker forking already happens without affecting Docker's momentum or its use as the de facto container standard. Red Hat has Atomic Host, for example, and CoreOS has pushed its Docker alternative, Rkt, for years without taking over the market. Red Hat's Dan Walsh, who works on security for the Atomic Host project, took issue with the term fork for any versioning, preferring to call Atomic Host a patched version of the Docker-based container runtime.

"That didn't dissuade the community away from Docker, but those were the early days," said Chris Riley, a founding partner at HKM Consulting LLC in Rochester, Mass., adding that he is concerned about fragmentation of Docker's strengths and a splintering of the supporting ecosystem should a Docker fork take place.

"In the end, it may just be the user community that forces either hand and decides the outcome -- whether to pressure Docker to provide a stable core or force the vendors to continually play catch-up because Docker-funded innovation is more important," Riley said.

Another item in the cons column for a Docker fork is it would be done for unusual reasons, observed Zubin Irani, CEO of cPrime Inc., an Agile software development consulting firm in San Francisco.

"Many times, the community wants to fork to accelerate development or move the software in a new direction, but this is the complete opposite," he said.

Still, "Docker is iterating too quickly, and to be quite frank, they're not being very disciplined about it," Irani added. "We've seen that they don't adhere well to semantic versioning, [which] causes all sorts of problems for stability in general and backward compatibility specifically."

That would be bad enough, but the problem is exaggerated because Docker is only one part of a larger technical solution necessary to scale the container approach, Irani said.

But "slowing down is not the answer," argued Mike Kavis, vice president and principal architect for Cloud Technology Partners Inc., a cloud consultancy based in Boston. "That is how industries stall and is a legacy mindset."

Beth Pariseau is senior news writer for TechTarget's Data Center and Virtualization Media Group. Write to her at [email protected] or follow @PariseauTT on Twitter.

While Docker Inc. officials say there’s no substantiation for reports that formal talks have taken place

Next Steps

Docker enhances cloud platform portability

Are IT pros ready for bare-metal containers?

To go mainstream, Docker needs persistence

Dig Deeper on Managing Virtual Containers