Dossier Comparatif : qui va gagner la guerre des orchestrateurs de containers ?
En fusionnant son orchestrateur à son moteur d'exécution, Docker a lancé la guerre des orchestrateurs de containers. Face à lui, on trouve Kubernetes de Google ou Mesos soutenu par la fondation Apache. Etat des lieux des forces en présence.
En l'espace de trois ans, Docker a bouleversé le monde du container logiciel. Pour mémoire, cette technologie permet d'encapsuler une application afin de pourvoir l'exécuter de façon native sur n'importe quel serveur. N'embarquant pas de système d'exploitation, le container est à la fois plus léger et plus rapide à s'exécuter qu'une machine virtuelle. En revanche, il sera dépendant du type de serveur sous-jacent. Un container Docker sur un serveur Linux ne pourra pas être porté sur un serveur Windows, et réciproquement.
Si Docker n'a pas inventé le concept de container - Google l'utilise depuis une quinzaine d'année -, la société créée par le franco-américain Solomon Hykes a réussi à imposer le concept en simplifiant son usage. Depuis, les grands noms du cloud dont AWS et Microsoft Azure l'ont adopté.
Le container devenant une "commodité", l'enjeu se situe désormais au niveau au-dessus. Comment gérer le déploiement et le cycle de vie de dizaines ou de centaines de containers ? "La technologie initiale proposée par Docker est très unitaire et locale", observe Arnaud Mazin, manager référent chez Octo Technology. "Le moteur d'exécution montre ses limites quand on passe à l'échelle. Il faut un système plus large qui gère la distribution, la résilience, la scalabilité, la répartition de charge."
Orchestrateur universel versus orchestrateur dédié
C'est le rôle dévolu aux orchestrateurs. Un orchestrateur fonctionne sur le mode esclave-maître. Le maître gère l'état et le provisionnement des containers sur une grappe de serveurs. Et ce, depuis un agent placé sur tous les nœuds du cluster. On trouve deux familles d'orchestrateurs. D'abord, Fleet et Mesos, avec une approche multi technologies, gèrent des processus et donc, le cas échéant, des containers. En face, on trouve des orchestrateurs dédiés à la containerisation comme Kubernetes, proposé par Google, Rancher ou Nomad.
La guerre des containers s'est déplacée sur le terrain des orchestrateurs
La guerre des containers se déplaçant sur le terrain des orchestrateurs, Docker ne pouvait ne pas en être. En février 2015, la start-up lançait en version bêta son propre outil d'orchestration, Swarm, avec la légitimité naturelle du leader de la containerisation.
"Se pose également un enjeu de rentabilité pour Docker, les activités de support et de formation ne suffisant pas pour arriver à un business model viable", note Édouard Devouge, consultant senior, architecte cloud et évangéliste DevOps chez Octo Technology. S'appuyant sur Swarm, le projet Orca donnera naissance à Docker Datacenter, une offre on-premise de containerisation pour les grandes entreprises.
Docker intègre son orchestrateur à son moteur de container
Tous ces orchestrateurs étant open source, Docker a toutefois commis un impair pour une partie de la communauté. Dans la version 1.12 de sa solution, sortie en juin dernier, l'éditeur a fusionné le moteur d'exécution de Docker (Docker Engine) et Swarm. Pas très open source dans l'esprit pour certains esprits qui reprochaient déjà à Docker de fermer les contributions sur son GitHub. Une passe d'armes s'en est suivie sur Twitter, accompagnée de menaces de "forker" Docker pour en proposer une version expurgée de Swarm. A priori sans passage à l'acte jusqu'alors.
Quelques années plus tôt, CoreOS avait proposé un moteur d'exécution, Rocket, une alternative à Docker visant à contrebalancer le pouvoir de ce dernier. Voire le court-circuiter puisque Kubernetes peut communiquer avec Rocket et se passer ainsi de Docker. Ce projet est soutenu, entre autres, par Google et Red Hat. Des acteurs que l'on retrouve au sein de l'Open containers initiative. Quel sera le prochain épisode ?
