Si le format d’images de container Docker est incontestable, l’administration de ces images en production pose encore problème, compte tenu de ce que le produit « maison » Swarm », n’a pas convaincu le marché.

On ne le dira jamais assez, mais Docker Inc, malgré ses indéniables qualités de découvreur et de développeur, reste une petite structure de moins de 300 personnes, perdue au milieu des géants du TI et souffre évidemment, quand elle est comparée aux GAFA et à Google en particulier.

Car Google s’est mis en tête de s’insérer dans l’orchestration des images Docker, avec son produit Kubernetes. Non seulement de s’insérer, mais faute de concurrence crédible, de « manger » le marché. Ce qui est bien dans sa nature.

Les juges de paix sont les opérateurs de Cloud, qui avancent le besoin impératif qu’ils ont d’intégrer une solution industrielle, qui ne subisse pas les aléas éventuels d’une petite structure. Ceci sans connotation négative particulière pour Docker, mais les chiffres parlent d’eux-mêmes. D’autant que Docker a pour vocation d’être racheté. Ce n’est qu’une question de temps.

Kubernetes en pole position

Après s’être focalisé sur les images des containers, en termes de développement, de livraison, adaptation et exécution, Docker a mis au point Swarm, une API qui fait le lien entre les images et l’administration, une sorte de contrat entre ces deux niveaux.

C’est dans cette même voie que s’est orienté Google avec Kubernetes, si ce n’est qu’il s’agit d’une API et d’un formalisme de contrats différents.

On a donc le choix entre deux architectures distinctes, si l’on estime que Mesos et quelques autres, ne sont plus aujourd’hui que des comparses. Entre l’énorme Google avec Kubernetes et le minuscule, mais brillant Docker, qui a su parfaitement intégrer Swarm à son architecture Docker Enterprise Edition.

Le rôle clé de la CNCF

CNCF (Cloud Native Computing Foundation), une structure de la « Linux Foundation », joue un rôle clé dans cet affrontement, car elle accueille les projets Open Source innovants, susceptibles d’être exploités dans le Cloud et parmi eux, Kubernetes apparaît comme l’un des plus importants.

Tout ce qui « entre » dans le giron de la CNCF acquiert une certaine légitimité sur le marché, pour Linux bien entendu, mais aussi par contrecoup, sur les autres plates-formes d’exécution.

L’un des axes de préoccupation de la CNCF est actuellement de fédérer les outils pour construire des architectures de micro-services, chaque micro-service étant placé dans un container Docker.

C’est dans ce contexte que Kubernetes s’est imposé. IBM et Microsoft se sont engagés, par exemple, à la fin 2017 à garantir la portabilité de leurs applications et pourront donc passer d’un cluster Kubernetes à une autre plate-forme, sans adaptation particulière pour les usagers. Ce qui porte à une trentaine environ (selon Google), le nombre d’acteurs dont les charges applicatives pourront ainsi migrer d’un environnement à l’autre, avec Kubernetes en toile de fond.

C’est un grand pas en avant pour les utilisateurs, une épine du pied en moins, dans un cheminement de plus en plus évident vers les Clouds hybrides interopérables.

Il faut bien voir cependant que Kubernetes est une API, qui va donc servir de fondation à tous les éditeurs qui expriment un besoin d’orchestration. Mais chacun de ces éditeurs, Alibaba, Red Hat, etc, qui ont de signé la « Conformance » Kubernetes, pourra construire sa propre solution au-dessus de Kubernetes, la « Conformance » garantissant en théorie aux usagers de pouvoir déplacer des charges de travail d’un environnement à l’autre, sans restriction fonctionnelle. Mais le fait de construire des couches au-dessus de Kubernetes ne voudra cependant pas dire qu’elles seront identiques et exposeront les mêmes services. C’est sur ce point qu’il faudra être très vigilant.

L’approche de Docker

Docker n’a pas totalement renoncé à Swarm. Mais il a ouvert grandes les portes à Kubernetes, dans la mesure où si vous installez Swarm, qui on le répète est parfaitement intégré à Docker EE, vous disposerez d’une option qui vous permettra d’installer également Kubernetes, celui-ci récupérant par héritage, le paramétrage et l’organisation de Swarm. De sorte que vous disposerez nativement de deux plates-formes. Si une charge a été conçue pour Kubernetes, elle communiquera avec l’instance Kubernetes et si une autre, a été imaginée pour Swarm, elle interagira avec l’outil Docker.

Sur le papier, c’est bien.

Mais sur le terrain, nous n’y croyons pas. Car dès que vous associez ou fédérez deux couches distinctes, faisant peu ou prou le même travail, vous créez des incompatibilités et des points de friction, qui se traduisent par des plantages et des pertes de performances.

Pour un client, la seule solution sera de choisir l’une ou l’autre des plates-formes, mais pas les deux.

Ce que le CNCF et Docker vont bien sûr nier, mais nous leur donnons rendez-vous dans un an…

La pile Docker intègre désormais l’API Kubernetes pour l’administration des charges de travail réparties dans un cluster. Kubernetes apparaissant pour l’instant sous forme d’option dans l’installation de Swarm. C’est un début, mais ce n’est pas suffisant.

 

Le paysage s’éclaircit

Avec le ralliement des éditeurs à Kubernetes, le paysage du Cloud s’est fortement simplifié, fondé sur une image exécutable Docker et une fondation commune d’administration. Il subsiste cependant quelques nuages, celui de l’intégration avec OpenStack, entre autres.

Il ne pourra y avoir, de notre point de vue, qu’une seule pile d’usage et d’administration des containers, avec d’un côté des Clouds privés OpenStack et de l’autre Kubernetes et ses affiliés. OpenStack n’a jamais été réputé pour ses capacités d’intégration. Il a longtemps cheminé seul, sans vraiment se préoccuper de ce qui se passait ailleurs, ce qui lui a d’ailleurs coûté cher, la communauté n’ayant plus vraiment confiance dans une structure, qui à force de vouloir couvrir unilatéralement, tous les aspects du Cloud, a fini par agacer tout le monde.

En termes de containers, OpenStack n’a plus aucune échappatoire. Il lui faudra être compatible Kubernetes, sans quoi il perdra définitivement la confiance des peu d’utilisateurs qui lui restent et donnera raison à ses détracteurs, BT entre autres, qui a claqué la porte de la communauté avec fracas.

En 2018, le paysage va donc forcément s’éclaircir et les dernières incertitudes balayées. Docker a bien compris que le vent avait tourné et que s’il voulait finir la course honorablement, il avait intérêt à hisser le Spi. Qui pour lui s’appelle Kubernetes. Pas un mix avec Swarm. Kubernetes seul. Comme pour OpenStack.