Some standards have been set for container technology. That's a good thing. Without standards, everybody working on developing a technology goes in separate directions, with no thought about how their implementation will work and play with the work being done by others. Without standards, vendor lock-in is practically unavoidable.
Until July, when the Open Container Initiative (OCI) released version 1.0 of its specification, there were no standards when it came to containers. Products from one vendor didn't necessarily work with the offerings from another. Obviously, this was a problem for DevOps working in diverse environments.
Take Docker and CoreOS, for example, two of the most popular products for container deployment.
"They weren't completely compatible," Brian Gracely, director of product strategy at Red Hat, told ITPro. "They were trying to find some ways, but there were enough nuances between them that there was a little bit of that Betamax versus VHS concept in them. At the end of the day you were still watching a movie, but the thing you needed to run that was going to be different."
Brian Gracely, Directory of product strategy at Red Hat
The good news is that containers are software, and software is much more pliable than physical systems like video tape cartridges. As long as there was a willingness to co-operate, standards could be developed. The willingness was there because all of the players had a vested interest in making containers an attractive option for enterprise use, and many enterprise users haven't been willing to wholeheartedly jump on the container bandwagon because of the lack of standards.
"What ended up happening was that both the CoreOS team, who had made their version of it, the Docker team, and then a bunch of other companies who were in the same space, Red Hat, Google and others, said, 'Instead of you guys fighting about the direction of this, since it's not working out individually let's get this into sort of a common body.' Which is why this Open Container Initiative foundation came around," Gracely said.
Agreeing that standards were necessary was evidently not as difficult as actually developing those standards. Not surprising, since many of the more than 40 members of the project had products on the market, with each probably thinking their way as the best way. The Open Container Initiative was started in June 2015 under the umbrella of the Linux Foundation, and by the time the first version of the specification was released this summer, the members had been wrangling for over two years.
[Container World delivers real-world case studies from the cloud-native ecosystem, hands-on technical education, the best speakers and cutting-edge startups under one roof. Get your ticket.]
"It took a little while," Gracely admitted. "What ended up happening was they took the existing bits they had and they kind of solved the differences they had between them. The scope got a little bigger than it originally was, to include some security elements, and to include not just Linux environments but also Windows environments. But we're now where there is a common standard, and ISVs and developers feel pretty comfortable that the tools they're making investments in now are going to be compatible with what's out there."
OCI 1.0 standardizes runtime as well as the container format. According to Gracely, this not only means that developers should be able to use whatever OCI compliant tools they wish to produce containers that will run across compliant container engines, but the containers will run across different clouds as well -- bringing the old Java adage, "write once, run anywhere," to containers.
The OCI specification is still a work in process, however. Gracely said that next up the initiative will focus on security issues, primarily signing and scanning. A signing standard would allow developers to upload containers to third party repositories as signed trusted containers, or allow corporations to identify containers as developed in-house or from trusted vendors -- in much the same way that software is "trusted" by being signed. Scanning would allow for a standardized method for scanning containers for the presence of malware, known bugs and the like.
"There's a good amount of security built-in to 1.0," he said. "The work going forward is to try to further standardize the way that people will sign, scan and securely manage and trust those containers."
Even that won't be the end of it, as new uses require new standards. For example, containers are finding their way into IoT devices, so there will need to be standards established for embedded use -- especially concerning security issues -- and for edge devices.
