Can OCI Specs Protect Against Balkanization of Containers?
TL:DR Not at this point. Not even close
Open Container Initiative, the vendor conglomerate from different platform camps (Docker, CloudFoundry, etc.) with the promise of creating vendor neutral container standards, has announced the release of new image specification for container images. I thought this is a good time to reflect on the balkanization of containers and do a reality check. If you read further, keep in mind that there is an undercurrent of sarcasm in my commentary :-).
Balkanization? What?
As PaaS vendors tried to differentiate themselves from IaaS, they were desperately scrambling for a differentiation with IaaS, especially AWS (Disclaimer: Almost every PaaS vendor has sponsored my conference focussed on PaaS, Deploycon, and I was employed at Red Hat later for 2 1/2 years), they considered Containers as the unit of (both technical and business) value that will distinguish PaaS from IaaS. Containers were promising but it didn’t capture the attention till Docker perfected the art and solved the user experience (developer experience to be specific) of containers. Immediately many vendors jumped on to Docker bandwagon (Disclaimer again: I was responsible for getting Docker Inc and Red Hat to speak on the collaboration and was still employed by OpenShift for two years after that. So read this with a gran of salt on my own biases) claiming portability along with efficiency as the advantage with Docker. However, CloudFoundry Project has already moved far ahead with their own container format (initially Warden and now Garden). Along the way, the friction between Docker and some of the other companies in the open source project lead to the creation of competing container project, mainly spearheaded by CoreOS. Clearly, this is balkanization of containers just like what happened in the hypervisor space.
Then came OCI
Then all the vendors in the container space realized that their biggest selling points against hypervisor based IaaS, PORTABILITY, is lost due to this balkanization and wanted to find a way to keep them relevant. Without going into all the politics that went behind the scenes, this thinking resulted in Open Container Initiative or OCI. It was marketed as an effort to keep portability associated with containers intact and as the only path towards the promised No-Lockin land.
Now OCI has announced the release of spec for Container Images. This is one small step and focussed on getting some standardization around container packaging. It should be a welcome news, especially since vendors from all camps (Docker, Rocket and Garden) are involved. Right?
Now the reality check
Docker Engine 1.11 is the only container to support OCI specifications at this point. Docker based containers have wide adoption in the industry and supported by major orchestration players including k8s, CloudFoundry (with Diego as the orchestration layer), Docker Swarm, Mesosphere DCOS along with other smaller players in the Docker ecosystem. Clearly, their portability argument has some shine but I am not sure how much Docker Inc. is committed to play nice with other players. Especially, with their own orchestration layer, Docker Swarm, and all in one platform, Docker Datacenter, I don’t expect the cooperation with other vendors to continue ad infinitum. Docker, the company, is under the unicorn umbrella with all the investments and soon the business pressure will push them in their own way.
The other larger community around Docker containers is the Kubernetes community and they are already talking about standardization at a layer above containers and are talking about multi-container support in Kubernetes as a solution for container balkanization. Google’s investment in Rocket and their own problems around Google Compute Engine will push Kubernetes community on their own path. Clearly, balkanization of containers is key for the future success of Kubernetes based products.
Apache Mesos has also taken a line similar to Kubernetes community when it comes to balkanization of containers. The support for multiple containers in Apache Mesos ensures that container standards will matter less and there is no room for standardization on the orchestration layer.
The philosophy of Mesos and Kubernetes community on container standards is similar to the stand taken by cloud management players on API standardization in the early days of cloud.
Let us take a look at CloudFoundry project. They went their own way with both containers and orchestration and used opinionated platform as a philosophical differentiation against Docker ecosystem. But they joined OCI and committed to open standards on containers. To their credit, they have embraced RunC to run as the backend for their containers. However, this only solves the portability in one direction. Users will be able to deploy Docker containers on CloudFoundry but their native containers cannot be ported to other platforms in the Docker ecosystem. As long as your container is based on Docker, you can retain certain levels of portability and they are working to make Docker containers a first class citizen on CloudFoundry. But it is nowhere close to the portability nirvana the container standard is supposed to bring in.
In short
If you are an enterprise buyer dreaming about container standard and the associated portability as the magical path towards no-lockin nirvana, go do a mindfulness course and try to get the delusions out of the way. As you embark on your container journey, assume that you will be locked-in and plan your strategy wisely. Yes, the lock-in with containers is not as bad as the proprietary software of the past but it is no nirvana either.
As someone who has been advocating openness for a long time, I want to be proven wrong by these vendors. If you are a vendor and want to share an alternative point of view or brief me about your efforts towards No-Lockin nirvana, feel free to set up a briefing.
