Silicon

INSIGHTS FOR IT PROFESSIONALS

Cloud Hybride : Reliez vos infrastructures avec une approche Open Source

Les conteneurs et microservices à l’assaut des DSI

Ils sont le fer de lance du mouvement DevOps et une approche de choix pour les applications Cloud natives. Ce sont les microservices, qui effectuent une percée en entreprise. Ils s’accompagnent d’une montée des conteneurs, un mode de déploiement qui leur est particulièrement bien adapté.

Conteneurs, DevOps, microservices. Ces trois termes apparaissent souvent dans les mêmes conversations. Et pour cause : « Les trois sont interdépendants et reliés, mais à des couches conceptuelles différentes », analyse Hervé Lemaitre, business strategist chez Red Hat. « Les microservices sont une approche d’architecture logicielle où les applications sont formées de services autonomes, connectés les uns aux autres. Cela permet de développer plus rapidement et plus efficacement des services applicatifs. »

Marc Gardette, Microsoft« Les microservices, c’est une méthode de design d’applications décomposées en différentes parties autonomes, qui peuvent être versionnées, déployées et gérées indépendamment les unes des autres », détaille Marc Gardette, directeur de la stratégie Cloud de Microsoft France. « Cela permet une grande agilité dans les développements. Ce design attractif est presque évident pour des applications Cloud natives. » Microsoft a d’ailleurs utilisé cette solution pour nombre de ses services Cloud.

Une approche boostée par le mouvement DevOps

À la base, il y a la volonté des équipes informatiques de travailler de façon plus efficace avec les équipes métiers, en proposant des logiciels capables d’évoluer plus rapidement. L’utilisation de méthodes de développement agiles et l’adoption des principes du mouvement DevOps ont nécessité l’apparition de nouvelles approches permettant de faire travailler des équipes fonctionnelles différentes sur un même projet. Le tout avec un cycle de développement court.

Les microservices sont la réponse naturelle à cette tendance. En particulier pour les projets massifs, comme les applications ‘native cloud’, ou ce principe de ‘logiciel composable’ peut se montrer redoutable.

Pascal Rabier, HPEAttention toutefois, car il est encore rare en entreprise qu’une application soit uniquement composée de microservices « stateless » reliés par des API, souligne Pascal Rabier, responsable produits systèmes intégrés et hyperconvergés, HPE France. Un effort d’intégration est souvent nécessaire. Et la migration entre serveurs (hosts) des conteneurs hébergeant des composants applicatifs « stateful » n’est pas encore possible nativement dans les solutions de conteneurs et microservices. Par exemple les bases de données, le stockage en local, etc. Afin de lever une partie de ces limitations, HPE propose des connecteurs Docker pour ses solutions de stockage 3PAR et StoreVirtual.

Les conteneurs éliminent les dépendances

Plus légers que la virtualisation, les conteneurs sont idéaux pour accueillir des microservices (à raison d’un par conteneur), auxquels ils apportent un certain degré d’indépendance. Les conteneurs sont indéniablement un booster, voire un ‘enabler’ pour les microservices, et donc pour le mouvement DevOps.

Pourquoi ? Car les conteneurs peuvent embarquer directement les langages de programmation et frameworks dont le code aura besoin pour fonctionner. Les développeurs n’ont donc plus à se soucier de savoir si l’interpréteur X ou la librairie Y sont présents sur le serveur. Toutes les dépendances nécessaires sont packagées directement dans le conteneur, au côté de l’application.

« Les conteneurs sont avant tout un format de packaging qui facilite la portabilité, explique Marc Gardette. Ils n’intéressent donc pas que les DevOps. Leur réplicatibilité facilitée par la présence des runtimes n’impose pas la nature du mode de développement. »

Oui, mais les microservices ont une arme secrète. Ils sont reliés les uns aux autres via un couplage faible représenté par les API qu’ils proposent. « Cela permet d’assembler des applications à base de services, même s’ils sont conçus par des tiers, illustre Hervé Lemaitre. Ce n’est plus un monde fermé. Nous le voyons dans le domaine de la finance, ou le PSD2 impose d’exposer les services de paiement sous la forme d’API. »

Deux mondes proches, mais pas forcément liés

Toutes les applications en conteneur ne sont pas des microservices et tous les microservices ne sont pas déployés sous la forme de conteneurs. Des offres comme Cloud Foundry, OpenShift, voire JBoss sont ainsi devenues des réceptacles de choix pour les microservices.

Chez Microsoft, c’est Azure Service Fabric qui est au cœur de cette révolution. Ce serveur d’applications dédié aux microservices se charge de mettre en mouvement les solutions adoptant cette approche : gestion des états, des versions, des affinités, optimisation des performances et load balancing automatique sont assurés par Service Fabric.

Mais aux côtés de ces serveurs dédiés aux applications à base de microservices, des solutions de plus bas niveau, comme les conteneurs Docker, montent en puissance. « Les microservices existent depuis longtemps. Mais ce sont les conteneurs qui ont permis de concrétiser plus largement cette approche, explique Viktor Farcic, senior consultant chez CloudBees. De même, les conteneurs existent depuis longtemps, mais se sont réalisés avec l’arrivée de Docker. » Les conteneurs promettent de révolutionner l’IT, en passant les OS au second plan et en permettant une évolution forte des process, assure le représentant de CloudBees.

Face aux conteneurs, les clients de HPE n’ont pas tous le même profil, témoigne Pascal Rabier. « Les early adopters obnt déjà commencé à déployer des conteneurs sur les serveurs HPE. Chez les grands comptes, plus classiques, l’intérêt pour les conteneurs a commencé à se faire sentir l’année dernière. Nous assistons aujourd’hui à des expérimentations grandeur nature, mais pas sur tout le périmètre (utilisation sur seulement quelques applications). Nous pensons toutefois que cette approche va se généraliser, car c’est un enabler du DevOps. Les releases applicatives sont assemblées plus rapidement ; publiées plus rapidement et déployées plus rapidement. »

Les équipes opérationnelles (et l’entreprise) devront s’adapter

« Nos clients constatent les bénéfices de l’approche DevOps sur la productivité des développeurs, poursuit notre interlocuteur HPE. Et ils commencent à déployer des projets grandeur nature. C’est un excellent moyen d’éprouver les bénéfices réels de cette approche. Il n’y a toutefois pas encore de consensus établi au niveau méthodologique. La mise en place d’une culture DevOps n’est pas si simple que cela. »

Au niveau des développeurs, ce mode de fonctionnent donne des résultats tangibles. Mais quid de l’entreprise ? Et du reste de la DSI ? Il faut que les équipes opérationnelles en charge de l’infrastructure soient capables d’adopter le même tempo. « Plus les développeurs deviennent agiles, plus l’infrastructure se doit d’être agile elle aussi, sinon gare au grand écart lors du déploiement », alerte Pascal Rabier.

DevOps, microservices et conteneurs se marient très bien avec les infrastructures composables Synergy de HPE, qui présentent le même degré d’agilité. Ce principe d’infrastructure composable via des pools de ressources (CPU, mémoire, disque, réseau, etc.) librement attribuables permet de créer des infrastructures adaptées aussi bien aux systèmes legacy qu’aux microservices. Car, nous allons le voir, les microservices, et plus encore les conteneurs, changent certains paramètres côté serveurs.

Des conteneurs : dans les VM… pour le moment

Hervé Lemaitre, Red HatVirtualisation et conteneurs ne sont pas forcément opposés. « Les deux ne sont pas placés au même niveau d’abstraction », constate Hervé Lemaitre. La virtualisation apporte une couche d’abstraction entre un serveur physique et un OS invité. Les conteneurs proposent une couche d’abstraction entre l’OS et les applications. « Les deux ne sont donc pas mutuellement exclusifs », poursuit l’expert de Red Hat.

Aujourd’hui, les infrastructures serveur sont en général virtualisées. Le déploiement des conteneurs devrait donc se faire essentiellement sur des machines virtuelles, prophétise Pascal Rabier. « Sur de grosses infrastructures, afin d’aller un cran plus loin en matière d’optimisation des coûts, certaines entreprises pourraient toutefois opter pour un déploiement des conteneurs en bare metal… avec un débat sur la sécurité, » précise-t-il.

Viktor Farcic, CloudBees« Faire tourner Docker en bare metal représente probablement un saut trop important pour les entreprises, estime pour sa part Viktor Farcic. D’autant plus que certaines choses manquent encore dans les conteneurs en matière de gestion des ressources processeur. » Mais aussi sur le terrain de la sécurité. « Tout un questionnement sur la sécurité émerge, confirme Pascal Rabier. Sur la bonne manière de déployer les conteneurs, les systèmes de contrôle à mettre en place, etc. Des acteurs comme Docker ont déjà fait beaucoup pour embarquer la sécurité dans leur technologie, mais ils rencontrent des opposants. »

Sur le Cloud Azure de Microsoft, les conteneurs (Docker pour le moment) peuvent être déployés dans des machines virtuelles via Azure Container Service. « Le déploiement bare metal est rarement choisi par les acteurs hyperscales, dont fait partie Microsoft », analyse Marc Gardette. Pour ces sociétés, la multiplicité des services et la volumétrie supposent du tout virtualisé ; du tout Cloud.

Azure Container Service se veut agnostique, avec une gestion qui pourra être assurée par DC/OS, Docker Swarm, et peut-être plus tard Kubernetes (Microsoft y réfléchit). Ces modes de gestion et de déploiement des conteneurs s’inviteront dans la solution de Cloud privé Azure Stack, qui verra le jour mi-2017 sur des appliances de grands constructeurs… dont HPE.

La problématique de la sécurité, Microsoft y a aussi pensé. La firme compte proposer une solution intéressante pour répondre à ce défi : les conteneurs Hyper-V. En intégrant un kernel virtualisé spécifique au cœur du conteneur, ils offriront un meilleur niveau de sécurité. « La densité sera un peu moins importante, mais la logique propre aux conteneurs sera préservée », explique notre intervenant Microsoft.

Le casse-tête de l’orchestration et de la sécurité des conteneurs

« Orchestrer des conteneurs et des machines virtuelles, ce n’est pas le même ordre d’échelle et cela peut s’avérer problématique », souligne Hervé Lemaitre. Entre machines virtuelles et conteneurs, le nombre d’instances est en général multiplié par 10, nous expliquent à la fois Red Hat et HPE. Si les outils de gestion restent globalement les mêmes, la volumétrie change du tout au tout.

Plus légers, les conteneurs sont présents en plus grand nombre sur chaque serveur. « Cela permet une meilleure utilisation des ressources matérielles », analyse Pascal Rabier. Processeur et mémoire seront donc mieux exploités… et rentabilisés. Du côté du stockage, la tendance full flash devrait aider à passer ce cap. « Le chemin vers plus de performance a déjà été fait dans le secteur du stockage. Cela aurait pu être un problème, mais il a été devancé. » Côté réseau, par contre, la tension pourrait être forte. Pascal Rabier prédit une évolution rapide vers des architectures réseau à grande bande-passant et faible latence. Un élément heureusement pris en compte par les infrastructures composables HPE Synergy.

Concernant la gestion des conteneurs, l’offre OneView de HPE propose d’ores et déjà le déploiement de Docker Engine. Pour des solutions comme Windows Server 2016, qui va lui aussi proposer le support des conteneurs Docker, des plug-ins sont fournis par HPE afin que les outils de gestion de haut niveau (par exemple System Center) aient une vue complète sur les serveurs du constructeur.

« Côté gestion, si fusion il doit y avoir, ce ne sera pas pour tout de suite, car c’est un monde très hétérogène, en particulier avec le Cloud hybride », estime Red Hat. Le Graal de l’outil de gestion universel, à la fois infrastructure, plate-forme et applicatif n’est donc pas pour demain. VM et conteneurs sont différents, mais la logique de gestion des ressources reste relativement similaire, tempère pour sa part Microsoft.

Vers du full software-defined ?

Et demain ? L’une des grandes révolutions dans la gestion du cycle de vie des applications est représentée par Jenkins, qui permet d’automatiser l’ensemble de ce processus. De l’autre côté, nous assistons également à la montée d’outils de gestion automatisée des infrastructures. Les deux vont-ils se rejoindre ? Forcément, estime le consultant de CloudBees, même si Jenkins n’aura pas pour vocation à aller de la définition de l’infrastructure au déploiement des applications.

HPE se propulse pour sa part déjà dans le tout software-defined, avec des templates réutilisables, qui permettent de définir le profil d’un serveur. Ces templates sont créés par les équipes opérationnelles et mis à la disposition des développeurs au travers d’API. Ainsi, l’écriture d’un logiciel est en mesure de définir directement l’infrastructure nécessaire à son fonctionnement. Un rapprochement s’opère entre Devs et Ops… « Le personnel opérationnel peut alors se concentrer sur le suivi de la stabilité et des performances de l’infrastructure », conclut Pascal Rabier.

Les intervenants du dossier

Pascal Rabier, responsable produits systèmes intégrés et hyperconvergés, HPE France.
Marc Gardette, directeur de la stratégie Cloud, Microsoft France.
Hervé Lemaitre, business strategist chez Red Hat.< – Viktor Farcic, senior consultant, CloudBees.