Jean-Marc Defaut (Capgemini) : les clients « loins d'avoir automatisé leur release management » (2)

Dans le cadre de ses offres de services d’infrastructure et de transformation numérique, Cap Gemini Sogeti a développé une offre sophistiquée d’automatisation d’infrastructures et de gestion de cloud, la Cloud Management Platform (ou CMP). Conçue pour faciliter l’industrialisation des SI clients. Comme l’explique Jean Marc Defaut, le vice-président cloud de Capgemini, l’infrastructure à un rôle essentiel à jouer dans la transformation des entreprises. Elle constitue en effet le socle sur lequel se déploient les nouvelles applications.

La plate-forme de gestion de cloud de Capgemini permet à une entreprise d’automatiser son infrastructure et de composer l’ensemble des services dont elle a besoin, afin de les mettre à disposition via un portail réutilisant les canons du cloud. Ce portail permet de provisionner des ressources et de déployer automatiquement des services sur l’infrastructure propre de l’entreprise, sur le cloud multitenant de Capgemini ou dans le cloud public (IaaS ou SaaS).

Jean-Marc Defaut s’est récemment entretenu avec LeMagIT pour aborder les enjeux auxquels sont confrontés les grands comptes en matière d’automatisation et de cloud et sur les challenges auxquels ils doivent faire face pour industrialiser leur production, réduire leurs coûts et accélérer le provisioning de leurs services. Ces enjeux ont été évoqués dans un premier article.

Dans cette seconde partie, Jean-Marc Defaut revient plus en détail sur les attributs de la plate-forme de gestion de Cloud de Capgemini Sogeti et discute avec nous de ses implications en matière de livraisons d’applications et de transformation.

LeMagIT : La cloud management platform de Cap Gemini Sogeti embarque des capacités d’automatisation, mais aussi la possibilité de gérer des services opérés aussi bien en interne qu’à l’extérieur de l’entreprise. Cela implique aussi je suppose que les entreprises doivent veiller à bien définir ce qu’elles désirent faire elles-mêmes, ce qu’elles préfèrent opérer à l’extérieur sur un cloud tiers ou ce qu’elles externalisent totalement en mode SaaS ?

Tout à fait. Nous avons une démarche systèmatique et structurée autour de ces objectifs. Il est essentiel pour l’IT des clients de délivrer des offres qui ont des caractéristiques et une valeur indiscutable pour les métiers. Je rappelle que l’objectif des clients avec ces approches est avant tout de diminuer leurs coûts et d’augmenter la qualité de leur SI.

Nous définissons donc avec eux la liste des services automatisables et ce qu’il est vraiment pertinent d’automatiser. Cela peut être un service de VM, un service de boite mail, de file sync and share… mais il faut définir clairement ce qui a de la valeur en interne et ce qui sera opéré à l’extérieur.

LeMagIT : Concrètement, que livrez-vous aux clients et qu’est ce qu’apporte la solution ? 

Jean-Marc Defaut, Vice-President Cloud, Cap Gemini

L’objectif pour nous est de proposer un portail clé en main et un jeu d’API qui permettent de traiter l’infrastructure comme du code. Il y a deux abstractions qui permettent de piloter cela : un designer de services avec lequel un architecte ou un administrateur peut composer et décrire un service (éléments d’infrastructure, éléments de middleware et élements de « run » — comme le backup, le monitoring, le reporting ITSM, la gestion des tickets…). Le second étage de la fusée est une couche de « release management » qui permet de modéliser et d’automatiser les étapes du processus de mise en production des applications.

Quand on abstrait l’infrastructure avec la CMP et que l’on met en œuvre du release management (ce qui n’est ni plus ni moins qu’une forme de CI/CD), on résoud déjà une bonne partie des problème chez nos clients. Ces derniers veulent avant tout diminuer leurs coûts et augmenter la qualité de leur SI.

LeMagIT : Chaque fois que l’on voit émerger l’idée de couche intermédiaire comme ce que vous proposez avec la cloud management platform se pose la question de leur intégration avec l’existant et la question de leur évolution. Car non seulement les couches basses di'nfrastructures évoluent, mais les technologies applicatives aussi. Ils faut donc en parallèle maintenir l’évolution d’API vers le bas et vers le haut pour que ces plates-formes continuent à jouer leur rôle.

Vous avez parfaitement raison. Il faut un couplage lâche via des connecteurs. Et on crée aujourd’hui ces connecteurs très simplement et très rapidement et on les propose sur étagère à nos clients.

LeMagIT : Des acteurs comme VMware avec vRealize Automation et vCloud sont suffisamment puissants pour que ce soit les fournisseurs d’infrastructure qui créent ces connecteurs pour eux…

Je suis complètement d’accord, mais le problème que j’ai est que cela ne traite pas le problème d’hétérogénéité que l’on rencontre chez nos clients. Cela n’enlève rien au mérite de vRealize Automation. vRA est une excellente plate-forme. Mais mon problème est d’automatiser de l’Unix, du Windows, du VMware. Dans la Cloud Management Platform, on utilise beaucoup HPE Cloud Service Automation, car cela nous permet de traiter tous les cas, même les plus tordus chez des clients qui ont souvent un historique très complexe. 

LeMagIT : On a évoqué les fonctions de « release management » de la CMP de Cap Gemini. Comment ces fonctions s’intègrent-elles avec les processus modernes de développement de type CI/CD ?

En fait, dans les processus de CI/CD il y a les mêmes types de processus et les mêmes types d’intégration de tests automatisés. Les objets sont potentiellement différents, de même que les tests, et la fréquence. Mais conceptuellement, c’est la même chose.

L’idée avec la CMP est de dire : je veux un processus de management identique, quelle que soit la nature des applications. Pourquoi cela ? Parce que je peux aussi bien produire des applications de type microservices sur un PaaS qui va préempter des ressources infrastructure de façon automatisée, que des applications traditionnelles qui vont consommer des ressources d’infrastructure de façon plus standard.

Et dans tous les cas, je veux que la chaîne qui va de la production de code jusqu’au test avant mise en production soit identique. Pour une raison simple : beaucoup d’entreprises vont faire des applications cloud natives, mais vont aussi scalper les front-ends d’applications traditionnelles pour les remplacer par des front-end cloud natifs connectés à des applications traditionnelles. Le même processus de release management doit alors pouvoir invoquer la cloud management platform pour déployer l’infra traditionnelle et invoquer le PaaS pour déployer le code cloud natif dessus.

LeMagIT : On a des infrastructures qui exposent aujourd’hui de plus en plus des API sophistiquées pour le provisioning de ressources - c'est le cas de certaines plates-formes hyperconvergées ou d'architectures composables comme celles d'HPE -, des PaaS qui ont aussi leurs propres API et à l'inverse des infrastructures traditionnelles relativement pauvres en API. Cela veut sans doute dire que selon les cas, la Cloud Management Platform doit être plus ou moins « épaisse » et qu'elle doit même parfois quasiment s’effacer en n’étant qu’une couche d’encapsulation d’API tierces.

Exactement. pour faire simple il faut envisager trois modèles d’applications majeurs : les applications de type micro-services, où l’on met en production des composants éminemment « scalables » sur un PaaS, les applications JEEE ou .Net traditionnelles et les applications hybrides. Et effectivement, selon les cas, il faudra automatiser un grand nombre d’opérations et dans d’autres cas très peu de choses. Dans Cloud Foundry, cela peut par exemple se limiter à un CF Push [la commande Cloud Foundry qui permet de déployer automatiquement une application sur le PaaS].

Ce qui est intéressant pour nous est que la plupart des clients sont encore loin d’avoir automatisé leur release management et c’est un bénéfice important apporté par notre cloud Management Platform.