carloscastilla - Fotolia
Google's Kubernetes incubator may have begun to subtly rock the IT containerization boat with a new effort that builds on the Open Container Initiative's proposals for container standardization.
The effort is in a pre-alpha stage, and was originally named Open Container Initiative Daemon. This month, it has been renamed to Container Runtime Interface using Open Container Initiative runtimes (CRI-O). It uses the container runtime and image format -- originally donated by Docker -- that the Linux Foundation is working on with the Open Container Initiative (OCI), formed in June 2015.
But CRI-O, which also involves engineers from open source IT vendor Red Hat, goes beyond what OCI has done to include a standardized means by which Kubernetes can pull containers from a registry and store them there again. That has some IT experts wondering -- once again -- if there is to be a schism in the container market.
Early adopters of containers in particular are breaking out the popcorn and watching what develops.
"There is a lot of developer focus on Kubernetes right now -- they have the community momentum in my opinion," said Aaron Welch, co-founder and senior vice president of Packet Host Inc., a New York-based bare-metal-hosted server provider. "Red Hat doesn't always bat a thousand, but they do have a lot of deep experience with container technology and have the resources to disrupt [the market] if they can execute and make it as easy to adopt as Docker."
CRI-O is just the next step in what Kubernetes already represents, said Zubin Irani, CEO of cPrime Inc., an Agile software development consulting firm in San Francisco.
Zubin IraniCEO, cPrime Inc.
"Container standards are one thing, and that's a vitally important piece that Docker created," Irani said. "But how you manage the creation and destruction of hundreds and thousands of instances requires some rather robust solutions."
The most important work in the market is being done on container management to make the technology production-ready, said Chris Riley, founding partner at HKM Consulting LLC in Rochester, Mass.
"It appears that Red Hat and Google are maturing Kubernetes to stay ahead of Docker Swarm and insulate it from the container technology," Riley said. "By introducing [CRI-O], they can standardize container execution and how Kubernetes can govern container-based solutions."
Such a nascent project should be on container users' watch lists, Riley added, because standardized APIs can ensure that customers migrate to or integrate with containers without extra work.
Users will be sensitive to the direction of the technology and ensuring that whatever they put in place is maturing and stable, Irani said.
"DevOps, as a technical approach, is still developing and there are literally hundreds of different software solutions out there," Irani said. "The market needs to whittle down to some key players, and the container space is no different."
IT industry watchers are making a mountain out of a molehill, Red Hat executives said, emphasizing that CRI-O uses the same runC lightweight runtime container technology Docker donated to the Open Container Initiative for its container runtime and image format.
"It's just where we're drawing the line on what should be stable and standard, and what should be specific to each vendor solution," said Joe Fernandes, senior director of product management at Red Hat. "Some folks are getting carried away ... [and] looking for stories, but there's not one here."
But IT pros are equally dismissive of this as merely public hand-waving.
"I think everyone is trying to play nice publicly since there is a lot of coopetition going on," Irani said.
Representatives from the Linux Foundation said that CRI-O goes beyond the scope of the Open Container Initiative, but declined to comment on whether the move is meant to be a shot across the bow of Docker in the container management arena. Docker Inc. and Google also declined to comment.
Look inside Docker's configuration management capabilities
Consider the possibility of Ubernetes for Kubernetes
How do stateful applications fit into the containerized future?