De nombreuses entreprises engagées sur le marché de l’écosystème Docker ainsi que des utilisateurs finaux envisagent le fork de la solution de conteneurisation. Ils expriment leur frustration concernant la gestion de Docker Engine et recherchent de nouveaux moyens de répondre aux différents problèmes posés par le déploiement de Docker dans les entreprises.
Plusieurs options sont actuellement à l’étude, incluant donc la possibilité de créer un fork (une branche de développement séparée) de Docker Engine. Selon de multiples sources proches des récentes discussions, les représentants des firmes comme Red Hat, Google, CoreOS, Huawei et deux autres grands utilisateurs finaux sont impliqués dans cette discussion sur l’avenir de Docker, malgré leurs dénégations.
Il semble que le moment soit critique pour l’écosystème de gestion des conteneurs. Bien qu’aucun des experts des compagnies suscitées ne veuille arriver à la mise en place d’un fork, ces derniers ont clairement exprimé leur inquiétude quant au manque de stabilité du code base de Docker. Ce défaut serait particulièrement problématique dans la construction de services additionnels et dans le maintien d’un support efficace pour les clients reposant sur la technologie Docker en production.
De nombreuses sociétés participantes aux discussions utilisent les conteneurs pour construire des systèmes distribués à grande échelle et pourraient voir dans l’addition récente des capacités d’orchestration intégrées une véritable menace pour les propres solutions d’orchestrations, pour la plupart fondées sur Google Kubernetes. L’inquiétude la plus fréquemment observée vient donc de la planification qualifiée d’agressive des livraisons Docker, qui met les fournisseurs de solution de tierce partie en porte à faux vis-à-vis de leurs propres clients.
« Docker casse constamment la compatibilité du backend » déclare Rob Hirschfeld, CEO de RackN, leader de la communauté Kubernetes, qui n’est pas impliqué dans les discussions en cours. Les applications de RackN’s utilisent et provisionnent des composants Docker. Ainsi, chaque changement dans les fondations de l’écosystème occasionne des impacts sur l’activité économique des propres clients de RackN. « Docker utilise Docker Engine comme un produit et non comme un composant que la communauté utilise pour créer ses propres services », ajoute-t-il. Cette approche force l’opérateur à gérer les problèmes de compatibilité quand Docker introduit une innovation ou fusionne des composants comme Swarm dans le Docker Engine.
Depuis la mise en place publique de ces dissensions sur la stratégie mise en place par Docker, les discussions vont aussi bon train sur les forums spécialisés. À cette heure, de nombreuses solutions sont évoquées sans qu’aucune des parties n’ait pris position publiquement sur le sujet.
Source :thenewstack.io