Forwords

I’ve worked with docker since version 0.9 and also worked in some internal projects with a lot of buzzwords: fullstack microstuff, immutable things, continuous blabla, and devops. We have been able to make an average of 3 deployments per day for all 365 days of last year.

Some months ago, I had to formulate an opinion on Kubernetes, Rancher, Mesos, and the Docker family…. and I had a (very) few days to learn a bit about those things.

As I discussed on twitter, Brandon Philips asked me to explain what I wrote in 69 characters. Ok. Challenge accepted!

The usecase

In my company, we create software (let’s say websites) in projects that the customer or we will host. The time frame of the projects varies from 2 months to sometimes many years. The hosting platform, the maintenance team, and the dev team may change during the project. Of course we have also very nice issues like lack of resource, lack of brain time, silo thinking, …

Globally, we have applications (java, php, perl, …) running on linux (debian, redhat,…) in a (virtual) machine. Of course we have some optimizations of our work: we have some internal standards about the structure of the apps, the monitoring, the deployments, and the changes between stages (dev, test, pre-prod, prod). Maintaining this level of organization, reflex, and know-how in the team is kind of ok. Everything is nice but slow, prone to human errors, and can’t be delegated.

The target

So the goal is to have something better for the ops team. I could say my target was something like: minimizing the work to realize, breaking the silos, and hopefully delegating to another persons. The idea behind this is: if you build good tools, those can become natural to others and you are not needed anymore.

What we have to do if we want to achieve this:

• From the dev host until production: everything has to be the same.
• Production has to run on a dev host: scaling, domain names, …
• People we don’t know have to be able to test without us to validate if something is ready for production.

Docker enters in a bar…

The goal is not to use docker. In fact, docker 1.0 arrived just in time, otherwise we would have used VMs with vagrant and some other part that has been done before as proof-of-concept. For example, we have test environments ignoring those are test and behave like production. We added an adaptive layer made of fake DNS (with response policy zone), proxys, and firewalls. We unified our environments: there’s no difference between test and production in a configuration or software (shall I say deliverable?) point of view.

That’s good, but not enough because if something fails on test, it’s already too late. The dev has already validated his code, and he has to discover what’s wrong in an environment which is not the one he worked on. This adds an overhead of work. So production has to be on the dev’s host too, and whatever additional constraints found in production have to be identical on the dev host.

In fact, dev and prod stages have to be close to each other for a second reason: if you are able to deploy future changes to the dev stages, then the devs will test your platform for you.

It happened before…

This is not the first time a platform is created. It has happened before and it will happen again. Here as we are switching from one platform to another, it’s really expensive as we must optimize this new platform. We will also need to optimize all the following ones even if we have no idea of what they will be. So on a more meta-level, we have to build a platform which is easy to go out. We have to judge each optimization as a potential debt for the future platform.

So. Kubernetes?

Of course there’s no absolute response and I started this post with a long description just because the context is very important. Having said, I have to go back to the beginning and say why, in my context, kubernetes is not good enough:

It’s complex, and there are business models on this: Stackpointcloud. (I couldn’t find on-line the video of keynote of Zachary-Smith where it is announced just after a joke, that as a matter of fact, installing kubernetes is more complex than it should be).

It is consuming more and more dependent resources. In Germany, an enterprise had to renew all the computers for its devs because kubernetes with Minikube is not discrete.

Using pods is a must with kubernetes. I find it a very good idea. But how many other platforms support them? I haven’t experienced a lot, but MESOS doesn’t and neither does docker compose. Am I then contracting some dept for all my apps if I choose to use them?

Kubernetes was created by Google to tempt customers to buy their cloud solution. It’s very good to benefit from the vast experience of this company, but we have to be careful google doesn’t change its mind like it did with some other products.

Lastly, Kubernetes is exclusive. Something which is nice with RancherOS and docker swarm (the old one at least) is that you can start them on an infra and they immediately enable the user to see what is already working.

In my mind kubernetes was made from an ops point of view as much as docker was with a dev point of view. The challenge is to find something in between.

Edit: Many thanks to Carmen Andoh for making this post readable.