Like in the physical world of shipping containers, the OCI container image and runtime formats are critical because they allow for infrastructure and investment to happen among a bunch competing and collaborating entities. Vendors can invest in building an ecosystem of tools, orchestrators, registry servers, etc. Users can extract value from the ecosystem, move containers where they want and get return on investment from infrastructure that they build and buy. Without the OCI, there can’t even be a guide to Buying a Used Linux Container.
Think of the Open Containers Initiative Runtime and Image specifications as the software world’s version of the ISO standards which make shipping containers portable and usable. In the shipping world it takes a set of standards working together – ISO 1161 defines basic sizes and hook placement, ISO 2308 defines hook strength (yes, that was a problem), while ISO 6346 defines codes for tracking different types (yes, there are like 14 common types) and sizes of containers, and many more. In the software world, it takes an image specification to define how resting software containers should be formatted on disk, as well as a runtime specification to define how to turn an image into a running process (Linux or Windows) – fancy files and fancy processes.
The OCI specifications are so critical because it takes a vendor neutral, set of standards to create a healthy ecosystem. In the 1960s, when shipping containers took off, the entire industry would have developed more slowly or perhaps not at all, If only one vendor would have controlled everything. To achieve true portability, we really need a set of open standards. With these open standards in place, we develop an large ecosystem, buyer’s guide, and a market place.
In the software world, we can’t have just one vendor control an open source community – it won’t work. Heck, one vendor, VMWare tried this with Virtual Appliances and it failed – here’s the half broken website still up. Now, we have the OCI 1.0 around the corner, which puts us in a good place. The next two things we need to think about is building standards around application definition (2.0), and then service catalogs (3.0). Once all three of these are defined, we might be on the road to an industry as mature as shipping containers.
One comment on “The Open Containers Initiative: Software Containers vs. Shipping Containers”