Un certain nombre de poids lourds de l’écosystème Docker, parmi lesquels Red Hat, Google, CoreOS, Huawei, ainsi que deux grands clients finaux, reprochent au champion des conteneurs le rythme trop soutenu de ses innovations. C’est ce que rapporte le site spécialisé TheNewStack.io. Les trop fréquentes révisions de Docker Engine entraîneraient des problèmes de stabilité mettant les partenaires de l’écosystème en difficulté vis-à-vis de leur propre base installée. À tel point que la question d’un fork du cœur open source du produit est désormais ouvertement posée, selon TheNewStack.io, afin de ralentir le rythme des montées en versions imposé par Docker et rassurer les clients finaux confrontés à des problèmes de compatibilité.
Ludovic Piot, consultant chez l’infogéreur Devops Oxalide, n’est pas étonné par ces vélléités de fork. « La société Docker a laissé la gouvernance du moteur de conteneurs (containerd) et de l’API de manipulation en CLI (runC) à l’Open Container Initiative et à la Linux Foundation, en novembre 2015, explique-t-il. Mais Docker (la techno) étant un standard de facto, l’initiative libre est obligée de jouer les suiveurs face à la vélocité d’innovation de Docker (la société), qui court-circuite, dans la pratique, les choix opérés par l’OCI. On assiste de plus en plus à une séparation de la communauté en deux camps concurrents très identifiés : le premier regroupe Google, CoreOS et Red Hat autour de Kubernetes (orchestrateur), Rkt (container engine), etcd (référentiel d’auto-discovery) et OpenShift (solution PaaS intégrée). Le second est incarné par Docker avec ses propres outils Swarm et Docker. »
« La fréquence des releases Docker peut être problématique »
Les partenaires que nous avons interrogés rejoignent le point de vue des partisans du schisme concernant le rythme trop rapide des révisions. « Je suis personnellement assez d’accord pour dire que la fréquence des releases Docker peut être problématique, commente Christophe Sauthier, CEO d’Objectif Libre. J’ai déjà vécu des soucis de ce type dans des projets qui utilisent Docker – comme par exemple Kuryr, un projet OpenStack qui vise à utiliser la couche réseau de cette solution de Cloud dans des conteneurs. Un phénomène accentué car le fait que les équipes Docker n’ont pas la réputation de trop partager avec les projets d’à coté… »
Pour Pierre Vacherand, directeur technique du cabinet de conseil annécien Apalia, spécialisé dans les infrastructures cloud, il est impératif de « stabiliser une version en dehors des enjeux de domination du secteur afin de convaincre les clients que la technologie Docker est prête pour les contraintes de la production ».
« La fréquence des mises à jour est typique d’une solution encore jeune. C’est clairement un frein pour des environnements de production », analyse pour sa part Sébastien Lucas, directeur général associé d’Oxalide.
Beaucoup commencent à trouver de l’intérêt à Swarm
Les récriminations du camp Google-Red Hat-CoreOS se cristallisent notamment sur l’intégration récente par Docker de sa propre technologie d’orchestration Swarm au sein de Docker Engine. Une initiative qui menace évidemment la suprématie de l’orchestrateur Google Kubernetes. Autre reproche formulé cette fois par Red Hat : l’utilisation par Docker de ses propres scripts d’initialisation. Une solution incompatible avec systemd sur lequel s’appuie Red Hat.
Mais s’ils admettent que la fréquence des mises à jour de Docker est problématique, les partenaires sont plus sceptiques sur le fait que l’intégration de Swarm à Docker Engine nuise à l’intérêt des clients. Certes, des problèmes de compatibilité sont possibles bien que les fonctionnalités d’orchestration de Docker ne soient pas activées par défaut, selon TheNewStack.io. Mais l’hostilité de Google serait plutôt à rechercher dans la crainte de voir se tarir la manne des clients que Kubernetes draine vers son offre Cloud Platform services for containers.
De fait, beaucoup commencent à trouver de l’intérêt à Swarm : « certains de nos experts trouvent que Swarm est vecteur d’une réelle simplification de l’orchestration de conteneurs par rapport à Kubernetes (même si encore à pas mal parfaire…), souligne Christophe Sauthier. C’est donc un vrai pas en avant dans la bonne direction. Je pense que ce n’est pas l’intégration de Swarm à Docker Engine qui est porteuse de préjudice à Kubernetes mais beaucoup plus ses avantages intrinsèques. » « Si Swarm se montre intéressant par sa simplicité de prise en main, il reste fonctionnellement moins complet et moins robuste dans son usage que Kubernetes », tempère toutefois Ludovic Piot
« Un fork ne laisse souvent qu’un seul vainqueur et fait peur aux clients »
Quant à savoir si un fork serait porteur d’opportunités ou de menace pour leur business, les partenaires sont partagés. « Si un fork pouvait permettre d’avoir plusieurs acteurs capables d’interopérer et de proposer des solutions sans lock-in plutôt qu’un seul acteur qui écarte tous ses rivaux, ce pourrait être une opportunité pour Apalia », explique Pierre Vacherand, qui envisage de proposer du support technique sur le projet issu de ce fork. Pour lui, ce projet de fork est symptomatique des difficultés que « semble avoir Docker à croitre tout en laissant un espace suffisant pour que son écosystème développe un business viable. »
Sébastien Lucas le rejoint sur ce point : « Sur ce sujet, il est amusant de voir que les débats sont les mêmes que pour Linux il y a 15 ans. Les forks sont, je pense, nécessaires. Ils permettent de mettre à disposition des « parfums » adaptés aux différentes contraintes de chaque marché et évitent qu’un seul acteur donne (trop) le « la » ». Mais s’il y voit une opportunité, il nuance immédiatement : « les forks morcellent l’expertise et rendent plus compliqué l’entretien de celle-ci pour les partenaires ».
« Une stabilité peut être intéressante pour ralentir cette course continue aux fonctionnalités et permettre une meilleure prise en main globale par nos clients qui n’ont pas forcément le temps de suivre cette actualités, estime pour sa part Christophe Sauthier. Toutefois, un fork engendre toujours un fort risque d’éclatement et ne laisse souvent qu’un seul vainqueur, comme la fin tragique d’OpenOffice permet de le constater. Il faudra attendre de connaître les soutiens des deux projets concurrents pour voir de quel coté penchera la balance. Ce genre de situation a tendance à faire peur aux clients dans leur phase de décision… Il faudra donc redoubler d’effort pour les rassurer. »