Mieux armé contre VMware, OpenStack balbutie sur les containers

Enfin un vrai challenger commercial de VMware

« Grâce à OpenStack, nous pouvons proposer un prix 6 à 10 fois moins élevé que les 900.000 € que VMware demande à l’un de nos prospects pour transformer ses 150 serveurs en un cluster de machines virtuelles », confie au MagIT Christophe Sauthier, le PDG de l’intégrateur toulousain Objectif Libre. « Les fonctions sont désormais mâtures, on ne se heurte plus à des cas d’usages qui ne sont pas adressés. En particulier, les possibilités d’automatisation sont si puissantes qu’OpenStack permet à l’un de nos clients de provisionner des infrastructures pour les nouveaux projets en 20 minutes, là où sa DSI mettait auparavant trois semaines à le faire manuellement. Pas parce que c’est compliqué, juste parce que la DSI est noyée sous d’autres demandes. OpenStack accélère la mise en production, c’est son second intérêt après son coût très attractif ».

Il illustrait en coulisse les résultats d’une étude menée par le cabinet 451 Research, selon laquelle 72% des clients d’OpenStack auraient choisi ce logiciel pour faire des économies par rapport à d’autres solutions d’infrastructures.

Cette même étude estime qu’OpenStack générera un CA de 1,8 Md$ en 2016, soit 50% de mieux que celui de l’année dernière, et atteindra même près de 6 Md$ d’ici à 2020. De son côté, l’entreprise commerciale VMware a déjà généré un CA de 6,6 Md$ en 2015, mais ses revenus ne semblent plus augmenter que d’environ 10% par an.

« OpenStack est désormais un outil de production pour 7 clients sur 10, quelle que soit leur activité. Le temps où les entreprises déployaient majoritairement OpenStack pour essayer des maquettes technologiques est révolu », se félicite Mark Collier, le COO de la fondation OpenStack.

Christophe Sauthier s'enthousiasme : « OpenStack est une formidable locomotive économique pour son écosystème d’intégrateurs. Quand nous ne faisions que de l’intégration Linux, nous étions invisibles en dehors de nos clients locaux. OpenStack nous a ouvert les portes de très grands comptes, car il permet pour une fraction du prix de VMware de déployer des clouds privés avec toutes les fonctions. Des banques américaines nous ont même approchés pour utiliser CloudKitty, le module de facturation d’OpenStack que nous avons développé ».

Le PDG de l’intégrateur toulousain ajoute qu’en étant plus configurable qu’un VMware, OpenStack permet à des acteurs comme Objectif Libre de vendre du savoir-faire pour, typiquement, développer une automatisation sur-mesure.

L’interopérabilité Cloud privé-Clouds publics en plus

« Le succès d’OpenStack reposera de plus en plus sur son API standard qui fait qu’un cloud privé peut devenir facilement hybride en s’intégrant à une grande variété de clouds tiers. C’est important pour les applications historiques pour résoudre des questions tarifaires ou géographiques. Ca le sera encore plus pour exécuter partout des applications mobiles, des objets connectés et du Big Data. L’interopérabilité d’OpenStack répond en ce sens à la demande de 9 entreprises sur 10 », lance Don Rippert, Directeur Général de la Stratégie Cloud chez IBM.

Il commentait un défi organisé par le constructeur pour démontrer l’interopérabilité des clouds privés et publics basés sur différentes implémentations d’OpenStack.

Sur scène, seize fournisseurs - des hébergeurs de Cloud, des fabricants d’infrastructure, des éditeurs de distributions OpenStack - se passaient l’un l’autre une même application métier, avec son interface, sa base de données et des microservices en containers. Malgré les particularités techniques de chacun (hyperviseurs, consoles d’administrations et systèmes d’infrastructures différents), cet « Interrop Challenge » prouvait qu’il est désormais possible de passer son SI d’un Cloud à l’autre aussi facilement que l’on transfère des fonds entre des banques.

« L’interopérabilité entre OpenStack et Amazon AWS, Microsoft Azure ou Google avait été démontrée à d’autres occasions. Aujourd’hui, avec OVH, IBM SoftLayer, AT&T, Deutsche Telekom, Rackspace, Cisco, HPE, Huawei, Intel, ou encore VMware, nous voulions surtout tordre le cou une bonne fois pour toutes aux rumeurs selon lesquelles les Cloud OpenStack ne seraient même pas interopérables entre eux. Preuve que si. La technologie est mâture », précise Jonathan Bryce qui insiste pour assimiler OpenStack au standard du Cloud.

« La crainte d’être pieds et poings liés à un fournisseur en particulier sans possibilité de migrer ses données simplement vers l’un de ses concurrents a longtemps constitué un frein à l’adoption du cloud par les entreprises. Nous prouvons qu’il est à présent possible de changer de fournisseur pour des raisons tarifaires ou géographiques dès lors qu’ils utilisent tous la plateforme d’orchestration OpenStack et le même langage d’automatisation - Ansible en l’occurrence », ajoute-t-il.

Pour mémoire, l’avantage d’OpenStack est d’offrir une même couche d’orchestration pour une grande variété d’hyperviseurs, dont ESXi de VMware et Hyper-V de Microsoft.

A l’inverse, la couche d’orchestration de VMware ne fonctionne qu’avec l’hyperviseur de la même marque, ce qui réduit les possibilités d’interopérabilité entre un Cloud interne VMware et le cloud d’hebergeurs tiers qui reposent la plupart du temps sur l’hyperviseur Open source KVM.

Le problème des containers

Il y a cependant une ombre au tableau : comme le suggère l’étude de 451 Research, le succès soudain d’OpenStack pourrait bientôt s’arrêter subitement au profit des plateformes d’orchestration des containers.

« Pour faire simple, les entreprises veulent de l’Infrastructure as Code, c’est-à-dire laisser les développeurs provisionner automatiquement depuis leurs applications les ressources dont ils ont besoin, sans devoir passer par la DSI. OpenStack est très bien pour déployer des machines virtuelles, du stockage et du réseau automatiquement, mais les entreprises entendent plutôt déployer des containers. Et le plus simple pour le faire aujourd’hui n’est pas de passer par OpenStack, mais de passer par une plateforme d’orchestration de containers, comme Kubernetes, Apache Mesos ou Docker Swarm », explique David Alles, architecte senior des infrastructures Cloud chez Orange Labs.

Dans le détail, OpenStack dispose de toutes les API nécessaires pour piloter des containers et, qui plus est, au format Docker que tout le monde utilise. Sauf que les développeurs ne vont a priori pas utiliser les API - qui non seulement ajoutent une couche de complexité, mais en plus posent le risque qu’une application ne fonctionne plus lorsque l’API évoluera.

Les développeurs vont plutôt décrire les besoins de leurs applications dans un fichier « template », lequel sera interprété par le module Heat d’OpenStack qui, lui, se chargera de faire appel à toutes les API pour déployer les ressources. Problème, Heat n’est pas encore en mesure de déployer des containers sans passer par des VM.

L’autre solution est de donner ce fichier template à Kubernetes et consort. Problème derechef, les logiciels qui orchestrent le format Docker ne savent déployer que des containers ; ils ne sont pas adaptés pour déployer du réseau et du stockage aussi précisément que sait le faire OpenStack.

« On se retrouve dans une situation où aucune des deux solutions n’est pour l’instant satisfaisante. Soit vous devez forcément déployer des containers par-dessus des VM en sachant pertinemment que cela gâchera énormément de ressources et provoquera de nombreux problèmes de performances - en containers, en effet, une application ne correspond plus à 3 VM (front-office, back-office, base de données), elle correspond à 25 micro-services ! - soit vous déployez directement des containers et vous n’avez plus aucune possibilité de sécuriser votre réseau - ce qui posera de nombreux problèmes en production pour les objets connectés, le Big Data, les applications mobiles, mais aussi les applications historiques dont personne ne veut voir la sécurité dégradée en passant par le cloud », décrit David Alles.

Selon lui, il s’agit maintenant de savoir qui, d’OpenStack ou de Kubernetes et consort, proposera le premier une solution. « Il y a à mon sens une échéance de deux ans. Dans deux ans, il se peut que plus aucune entreprise ne déploie de VM, puisque les cloud publics eux-mêmes propose de déployer directement des containers », assène-t-il.

OpenStack Newton, un début de réponse

S’attaquer aux containers est justement le propos de la dernière version Newton d’OpenStack - en particulier via l’orchestrateur de containers Magnum qui sait envoyer des ordres à Kubernetes, Mesos et Swarm - mais aussi grâce au module Ironic qui sait déployer du Bare Metal (serveurs physiques, non virtualisés, l’idéal pour les containers) ou encore le module Kuryr qui sert pilote pour le stockage et le réseau OpenStack en passant par les containers.

Sauf que tous ces modules ne fonctionnent pas encore bien ensemble et que Kuryr n’est même exploitable pour l’heure que par des informaticiens qui bidouillent des scripts Ansible pour programmer directement les API.

« D’accord, ce n’est pas encore prêt. Mais il ne faudrait pas commettre l’erreur de penser que les entreprises vont aussi vite que l’évolution d’OpenStack. Kuryr sera opérationnel lorsque les entreprises en auront besoin », affirme Mark Collier.

« Par ailleurs, nous observons que les entreprises qui adoptent le plus rapidement les containers sont celles qui le font via OpenStack, car OpenStack leur apporte la possibilité de les exécuter sur tout type d’infrastructures, des VM comme du Bare Metal, ce qui ne ferme aucune possibilité pour déployer à l’avenir des ressources dans n’importe quel cloud », enchérit Jonathan Bryce.

En attendant que le fonctionnement des containers se peaufine dans la tuyauterie OpenStack, la dernière version Newton amène un module Vitrage censé aider à confectionner les meilleures configurations. Encore en pré-version, Vitrage inspecte les problèmes entre chaque couche, apprends à les reconnaître et remonte des alertes. « Ce n’est pas encore aussi évolué que ce que sait faire Splunk, par exemple. En revanche, Vitrage sert déjà  à détecter, justement, les problèmes de sécurité et de performances », indique Jonathan Bryce.