Back in September 2016, an event went unnoticed, although it was a fundamental change. Google and RedHat declared the game is over: they decided to fork Docker.

Why did they decide to do that?

Redhat had several reasons:

Container conception: Solomon Hykes from Docker couldn’t agree with Lennart ‘Systemd’ Poettering from RedHat on the container vision,

from couldn’t agree with from on the container vision, Container security: frustration in the RedHat security team was high because of difficulties to integrate patches into the Docker product,

security team was high because of difficulties to integrate patches into the Docker product, Container stability: the Docker company was always adding new features based on new Linux kernels into its product, triggering an insane amount of work to backport all these features into the 3.10 kernel used by most of RedHat products ( RHEL 7 , Atomic , OpenShift , etc),

company was always adding new features based on new kernels into its product, triggering an insane amount of work to backport all these features into the kernel used by most of products ( , , , etc), Container support: the Docker company didn’t consider compatibilities between versions a priority and problems regularly occurred, this didn’t please RedHat that makes a living by supporting customers.

On the Google‘s side, things were even easier to understand. The company has been working on an in-house orchestrator called Kubernetes for years and wanted it to be at the heart of all the container ecosystem. When Google‘s team heard that the Docker company was promoting its own product named Swarm as reference orchestrator, the decision to fork was almost made.

At the end of January 2017 at DevConf.cz, Dan Walsh from RedHat gave a very interesting presentation about Containers in Production (container standardization, read-only container images, CRI-O, COW filesystem problems, etc). At 40 minutes from the beginning, he acknowledged that the Docker replacement was in the testing stage.

At first called OCID, then renamed CRI-O, it already owns its logo. Fully compatible at the format level with Docker, this new Open Source product will bring its own set of tools like skopeo to get an image from a container registry.

If for developers things may continue as usual, in production environments you should see the following change in the coming months:

RedHat people never say that CRI-O is a Docker replacement, they only say they are building an alternative option that will become their reference solution …

Now, you can’t say you didn’t know.