Thierry Carrez, directeur ingénierie d'OpenStack: « On travaille sur l'intégration

Le Monde Informatique. Vous avez annoncé une hausse des déploiements OpenStack de 95% sur un an. C'est un chiffre impressionnant, comment l'expliquez-vous ?

Thierry Carrez. Il y a eu deux fois plus de déploiements rapportés en septembre 2017 par rapport à l'année dernière. En termes de nombre de cores, on est à 6 millions aujourd'hui contre 5 millions il y a 6 mois. En 2016, on était à 42% d'augmentation en nombre de déploiements OpenStack d'avril à avril sur la précédente enquête, là le chiffre de 95% nous a surpris, on se demandait si c'était parce que des anciens déploiements sortaient du bois ou bien s'il s'agissait de croissance réelle. Mais vous avez vu, selon un chiffre présenté par Red Hat, que cette augmentation est en deçà de leurs estimations et que ce sont plutôt des nouveaux venus qui déploient OpenStack. Les dernières tendances semblent confirmer cette croissance, des gens qui testaient et se lancent, avec énormément de déploiements en Chine.

La croissance d'OpenStack est-elle plus à chercher en Chine qu'ailleurs en Europe où l'on a atteint un certain plafond de verre ?

Je pense qu'en Europe il y a encore un grand potentiel de croissance. Aux Etats-Unis, il y a clairement une bataille à donner sur le cloud public, notamment sur la notoriété. Car Amazon, Google, Microsoft occupent l'ensemble de l'espace marketing, alors qu'en Europe ce n'est pas du tout le cas avec énormément de déploiements dans le cloud public. OVH se lance aux Etats-Unis en essayant d'attaquer ce triumvirat parce que techniquement leurs solutions ne sont pas meilleures, elles sont plutôt plus chères. Aux US, cela stagne, la forte croissance est à chercher chez OVH et City Cloud qui sont des acteurs européens. En termes de cloud privé, les US sont encore en croissance, beaucoup de croissance en Chine avec surtout des gros déploiements, pas forcément en nombre mais en taille de déploiements. China United SME, un monstre de la finance, China Railways, State Grid l'EDF chinois avec 1 milliard d'abonnés, le moindre de ces déploiements, des centaines de milliers de machines.

Ces volumes en Chine sont-ils les plus gros, jamais vus ailleurs ?

Les plus gros déploiements sont eBay-PayPal, le Cern. L'ensemble de leur infrastructure est sous OpenStack. On s'aperçoit en Chine qu'il y a toujours les mêmes acteurs, Tencent, Huawei en tête. On bénéfice de ces gros utilisateurs.

Comment allez-vous faire pour capitaliser sur les contributions de la communauté OpenStack chinoise ?

Il y a des contributeurs chinois aujourd'hui. Huawei est le plus actif. Le problème, c'est de les orienter vers des contributions plus utiles que financières. Ce qu'a fait Huawei, c'est de recruter des Américains pour amorcer la pompe des contributeurs chinois. On espère que cela va faire fructifier les contributions en Chine. Ce n'est pas toujours facile de collaborer avec le reste du monde, il faut être assez attentif. Avec les Chinois, on essaie de supprimer les réunions hebdomadaires contraignantes, surtout qu'ils ne sont pas très voix, ils préfèrent prendre leur temps pour répondre par mail. On est plutôt présents sur leur créneau horaire pour répondre à leurs demandes en fonction de leurs besoins.

L'année dernière Mirantis et HPE ont éliminé de grandes ressources Openstack. La Chine ne vient-elle pas compenser le retrait de Mirantis et d'HPE ?

Le challenge, c'est de remplacer les gros fournisseurs de services qui n'ont pas réussi à dégager un gros business model autour d'OpenStack comme Mirantis, HPE, IBM qui ont réduit massivement leurs investissements upstream. Avant, certains étaient énormes. Aujourd'hui, on a Red Hat, SuSE, Intel qui ont un business model plus exposé autour de l'open source, ou de la fourniture de matériel un peu plus solide. Entre août et décembre, il y a eu ce retrait important. Le challenge pour nous, c'est de réussir à remplacer la structure de contributeurs de ces gros fournisseurs de services avec des investissements plus directs des utilisateurs. Comment on arrive à les capter ? Sur le dernier renouvellement, on voit beaucoup plus d'utilisateurs, une nouvelle génération qu'il faut accompagner. Auparavant, les gros fournisseurs de services arrivaient avec des équipes de 50 personnes, et quand ces personnes se sont retirées, on s'est retrouvé sur les domaines de documentation, d’infrastructure avec un manque qu'on cherche à combler.

Parce que ce manque n'est pas comblé aujourd'hui ?

Si. On a remplacé la plupart de ces contributeurs. Le challenge, c'est de capter les gens qui peuvent passer plus de 20% de leurs temps sur OpenStack. En 2013, on a mis en place des structures qui font que si on ne passe pas 100% de son temps sur OpenStack, c'est très compliqué. Par exemple, pour devenir leader sur un projet, il faut faire énormément de revue de code et si on a qu'une journée dans la semaine à passer sur OpenStack, on ne peut pas devenir un code reviewer. Il faut peut-être que l'on change ça, que les gens se spécialisent sur un fichier, pas sur l'ensemble du code - c'est plus pénible que cela ne devrait être - et faire en sorte qu'ils deviennent des contributeurs plus importants. Sur des projets comme Nova, le renouvellement s'est fait moins facilement que sur d'autres projets de déploiements plus proches des besoins des utilisateurs.

Quels moyens comptez-vous pousser pour lutter contre le forking OpenStack qui représente une vraie menace pour la contribution générale et la philosphie de votre framework ?

Je ne parlerais pas de menace, je pense que c'est un modèle qui est très inefficace. Je pense surtout que cela ne marche pas bien pour les gens qui suivent ce modèle là. Quand Nick Barcet [directeur senior des produits OpenStack de Red Hat, NDLR] dit que ces structures-là ont essayé de se différencier en faisant un « OpenStack ++ » comme HP et Mirantis qui ont essayé de se différencier sur le produit et pas sur le service. Or, sur un projet open source, il y a un moment où la version « ++ » fabriquée à partir d'une vieille version d'OpenStack marche moins bien que la version d'OpenStack que tout le monde a. Et au moment où ils doivent réconcilier les deux, c'est impossible. C'est un pari à court terme.

Le forking n'est donc pas viable d'après vous ?

Ce n'est pas viable pour les gens qui le font. Pour OpenStack, que les gens le fassent, c'est un peu une perte de ressources, de temps, mais au final ce n'est pas une menace. A chaque fois que cela a été fait, ça n'a pas fonctionné. Je dirai que c'est plus une validation d'un modèle de collaboration ouverte vers lequel des structures comme Orange se dirigent. La plus grosse difficulté à surmonter, c'est plutôt qu'on se heurte à la culture interne de l'entreprise, surtout en France, où les DSI sont prêtes à se refondre et devenir un fournisseur d'infrastructure.

Pensez-vous faire suffisamment d'efforts pour répondre aux besoins des aficionadaos de l'infrastrucutre as a code ?

Je pense que l’infrastructure programmable est aujourd'hui bien couverte par OpenStack et les projets qu'on produit. Aujourd'hui, c'est plus l'adoption dans les entreprises qui est en retrait comme a pu le montrer Thierry Souche, DSI d'Orange, qui avait réussi à faire suffisamment de management pour transformer l'entreprise pour leur cloud privé OpenStack. C'est un gros investissement, gros challenge de passer d'une logique où l'IT est gérée par un seul service qui a le contrôle sur l'ensemble du développement logiciel vers une logique d'utility où l'informatique est une ressource consommée par tous. Les PDG sont intéressés pour passer à ce modèle d'infrastructure en tant que code alors que ce sont plutôt les modèles intermédiaires de management qui résistent, car ces derniers sont rendus obsolètes. La barrière de l'adoption n'est pas technique. C'est plus un gros changement culturel pour les entreprises qu'elles ne sont pas prêtes à faire.

Il semble que vous tentez de minimiser les reproches sur la capacité d'OpenStack d'orchestrer des containers qui s'avère dans la réalité plutôt compliquée ?

Il faut bien comprendre que tout ce qui est cloud natif a besoin d'un cloud. Kubernetes, Docker ou autre vont fonctionner très bien sur un cloud Amazon, Google, Microsoft et devraient le faire très bien sur la partie cloud privé d'OpenStack. On a différents moyens de provisionner du cluster Kubernetes sur OpenStack. Ce dont on s'aperçoit, c'est que les gens qui viennent du monde OpenStack pour aller vers les containers trouvent très bien leurs marques, comme le Cern et son projet Magnum de delivery d'une partie de leur infrastructure avec des clusters Kubernetes provisionnés autour d'OpenStack ; ça marche très bien. Mais on s'aperçoit que les gens qui viennent du monde Kubernetes et qui cherchent une solution d’infrastructure ne trouvent pas forcément chaussure à leur pied. Quand l'environnement est exclusivement Kubernetes, la connexion vers OpenStack n'est pas forcément naturelle. Donc, soit ils vont directement vers un cloud public existant comme Amazon ou bien ils vont vers du Kubernetes déployé directement sur du bare metal. C'est pour ça que l'on doit s'adresser à cette glu manquante entre Kubernetes et OpenStack. C'est une de nos orientations stratégiques. Mais, tout à fait, vous avez raison, c'est identifié comme un élément sur lequel on doit travailler.

En quoi consiste cette glu au juste ?

Par exemple, aujourd'hui, il y a un problème de sécurité sur les containers. Si on veut faire tourner des clusters Kubernetes dans un mode purement multitenant avec une isolation correcte entre les workloads permettant de tourner dans un environnement sécurisé sérieux, il y a un élément manquant. Aujourd'hui, ils ne savent pas faire, il manque des pièces technologiques qu'il faut que l'on intègre, qui existent dans le monde open source. C'est pourquoi, on a désigné l'infrastructure de containers comme un des éléments stratégiques sur lequel il faut que l'on travaille. Des choses vont arriver d'ici la fin de l'année.

Est-ce que ce manque d'intégration concernant Kubernetes peut être bloquant ?

Pas vraiment car on s'aperçoit que les plus gros déploiements de Kuberntes tournent sur un substrat OpenStack comme chez eBay-PayPal. Mais cela reste des choses qu'ils sont obligés de faire eux-mêmes. Il y a un manque aujourd’hui. eBay a notamment écrit un produit pour déployer des clusters Kubernetes sur des clouds OpenStack et des clouds publics. Ils n'étaient pas satisfaits avec ce qui existait, que ce soit dans le monde Kubernetes et OpenStack. Il manque des briques aujourd'hui pour rendre cette intégration complète et c'est ce sur quoi nous devons travailler dans l'avenir. Aujourd'hui, ce n'est pas franchement bloquant, mais c'est plus pénible que cela devrait être car chaque client est obligé de réinventer sa solution. Ce n'est pas que ce soit impossible, mais on doit faire en sorte que cela soit plus simple et tester cela de bout en bout. Et l'on va s'assurer que les changements dans Kubernetes et dans OpenStack ne cassent pas la possibilité d'utiliser ces deux outils ensemble. Ce n'est pas le seul sujet, il y a aussi le edge computing sur lequel on doit travailler pour déporter les traitements du datacenter au plus près des ressources clients, des mobiles, des box Internet... Il y a un très gros potentiel pour la fondation, il va falloir développer des briques supplémentaires.

Quels sont les outils que vous proposez pour faciliter la migration multi-clouds ?

Les API sont de moins en moins un élément critique par rapport à l'interopérabilité. Depuis Microsoft et Google ont montré leur capacité à concurrencer Amazon sur ce sujet et les demandes sont plutôt qu'Amazon et Google supportent les interfaces que l'inverse. Aujourd'hui, le débat de l'API est un peu passé mais il faut que les librairies permettent d'adresser les clouds Amazon, OpenStack, Google ou autre de manière unifiée. On produit du code permettant de passer d'un cloud Openstack à un autre mais il y a des librairies multi-clouds qui intègrent cette problématique. Ce sur quoi on a plus de mal, c'est quand Amazon va pousser le serveless ou des choses très poussées qui ne sont pas du tout portables. Il est impossible de passer d'une app qui a été designée en serverless pour Amazon utilisant toutes ses spécificités serveurs, autre part. Cela est fait à dessein par Amazon, car une app faite sur ce modèle-là ne pourra plus bouger de leur cloud. Oui, on ne sait pas comment contrer une « superspécialisation » de ce point de vue là.

Il n'y a pas de plan B là ?

Il n'y a pas de plan B mais je dirai que les gens qui se mettent dans cette situation de lock-in complet en adoptant des produits Amazon très spécifiques se tirent une balle dans le pied au moment où ils s'aperçoivent ce que cela leur coûte. Aujourd'hui, ce que l'on voit ce sont davantage des entreprises qui migrent en dehors d'Amazon quand les responsables financiers s'aperçoivent du coût pour faire tourner. C'est extrêmement coûteux, Amazon fait des marges délirantes, OVH arrive à faire un dizième du prix du stockage et un quart du prix du compute tout en dégageant des chiffres confortables. Ce n'est pas tenable.

Pike, la dernière version du framework OpenStack, est jugée assez complexe et pas forcément très stable. Que répondez-vous à ces critiques ?

Sur Okata, il y a eu assez peu de développements nouveaux, beaucoup plus de bug fix. Je ne pense pas qu'on puisse dire que Pike est significativement plus compliqué. En termes de fonctions on est de plus en plus sur du support d'upgrades plus simples, à chaud. Les plus gros changements que je vois sont le support de plus en plus de projets comme Ironic, et des upgrades des ruptures. Il n'y a pas franchement de raisons que cela augmente la complexité. C'est sûr sinon qu'en termes de projets, cela ne va pas en diminuant. Même si on en a retiré certains, comme Fuel, le système d'installation essentiellement maintenu par Mirantis qui n'a jamais eu d'adoption en dehors de Mirantis. On a un peu cassé les branches mortes, mais en parallèle on a d'autres projets. On a rajouté Matahari, poussé par des Japonais, Nec essentiellement, qui travaille sur la survie de workloads dans des VM pour faire « transitioner » des worlkloads classiques d'entreprises plus que des clouds native en containers. On a Cyborg, un projet pour référencer accélérateurs GPU. On voit une grosse adoption d'Openstack pour le machine learning... Oui, il y a une certaine complexité, mais on travaille pour bien représenter le coeur du projet. Le reste est un écosystème pour traiter des cas particuliers.