Now Reading
L’écosystème Cloud computing – 3 : Cloud management
0

L’écosystème Cloud computing – 3 : Cloud management

by Cloud Guru30 avril 2013

Nous avons exploré dans les articles précédents 2 catégories de services de l’écosystème Cloud :

  • Partie 1: Les Fournisseurs de Ressources (FR)
  • Partie 2: Les Automatisations de Services Métiers (ASM)

Dans ce troisième article, nous allons conclure par le composant sans doute le moins mature, mais dont l’importance va être primordiale au fur et à mesure de l’adoption des technologies du Cloud par les Entreprises.

Gouvernance Cloud

Continuons à explorer l’écosystème. A ce stade, notre modèle comprend un ensemble d’ASM qui vont générer une demande forte vers un ensemble de FR. Bien entendu, si les processus qui vont permettre de manager, coordonner, réaliser et mesurer  ces interactions ne sont pas automatisés, l’entreprise va perdre une grande partie des bénéfices escomptés. De plus, on peut raisonnablement envisager qu’une grande Entreprise qui s’appuie sur plusieurs milliers d’applications va engendrer plusieurs centaines (et très vite plusieurs milliers) de requêtes de nouvelles ressources d’infrastructure par jour (par exemple de machines virtuelles).

Il est donc nécessaire d’introduire un autre composant dans notre modèle que j’appellerai Cloud Management Service (CMS). Il faut souligner ici un problème de terminologie car il ne faut pas confondre le CMS avec un logiciel ‘d’automatisation de FR’. Pour fixer les idées, les composants actuels d’OpenStack tels que Nova (Serveurs), Cinder et Swift (Stockage) et Quantum (Réseau) sont des moteurs de FR et ne sont pas des CMS au sens qui va être décrit ci-dessous.

Le CMS est à un autre niveau. Comme il y a un rapport de cardinalité de 1 à N entre le CMS et les FR, et que les FR auront des cycles de vie indépendants des usages, il est nécessaire de dissocier le CMS du moteur de FR. De plus, cette relation de 1 à N dicte de façon très claire le placement des fonctionnalités nécessaires à la gouvernance des FR. Par exemple :

  • L’administration de l’accès (AAA, rôles, droits, limites, etc…) est clairement une fonction du CMS car il est irréaliste de répliquer toutes les métadonnées associes sur les différents FR.
  • La stratégie de placement des machines virtuelles dans le pool des ressources physiques incombe à chaque FR car c’est l’opérateur du FR qui va gérer son service défini par un SLA et un prix. Et c’est bien une des particularités d’OpenStack d’offrir des stratégies de placement configurables.
  • Par contre les règles d’aiguillage des requêtes des systèmes clients vers le FR est clairement une fonction du CMS.

Point focal

Ce CMS va devenir un point charnière pour l’entreprise et va prendre de plus en plus d’importance au fur et à mesure que le nombre de FR et le nombre de ASM va augmenter. Ce CMS va cristalliser la manière dont l’entreprise souhaite opérer son écosystème IT en stockant l’ensemble des métadonnées liés à :

  • L’organisation (Entités métier, équipes, projets, utilisateurs, …)
  • La gouvernance (priorités, droits, limites, processus d’approbation, partitions logiques, …)
  • Les règles d’entreprises pour aiguiller les requêtes (basées sur les prix, la disponibilité, la géographie, la sécurité, les législations, la technologie, …)
  • Les données financières qui permettent les prévisions de capacités
  • Les patrons d’architectures communes et réutilisables de de résilience, de montée en charge, de backup des données, de reprise après sinistre.
  • Un catalogue fédéré d’images, un outil de gestion de ces images et un management des licences
  • Des fonctions fédérées de surveillance
  • Une abstraction globale du réseau qui permet de déployer des systèmes sur plusieurs FR

Ce CMS va être déclinée en un composant logiciel pour les entreprises qui auront des zones privées, ou en un service offert à des entreprises qui ne souhaitent pas gérer cette complexité.

CMS Privé et CMS Public

Dans sa déclinaison ‘privée’, certaines acquisitions récentes (DynamicOps par VMware, Cloupia par Cisco et Nimbula par Oracle) montrent bien que ce composant devient stratégique. On sait aujourd’hui que les Clouds privés ne seront pas mono-technologiques, que le Cloud en entreprise sera hybride, et que les Entreprises souhaitent de l’interopérabilité pour associer des solutions de vendeurs différents. Ce qui signifie que tout acteur qui souhaite jouer un rôle important en tant que fournisseur de composant de Cloud doit avoir un CMS à son catalogue. Celui qui introduit un CMS dans un grand compte aura à terme une position dominante. Il pourra y associer ses services de conseil, ses propres solutions de FR privé et ses propres solutions d’ASM tout en étant capable de manager les FR et ASM concurrents.

Dans sa déclinaison ‘public’ certains Service Provider ciblent les petites et moyennes entreprises et offrent cette gouvernance en tant que service pour gérer leurs déploiements chez des FR (par exemple Rightscale). Par ailleurs, toutes les Entreprises qui utilisent à ce jour des services d’infogérance auprès des dizaines de milliers d’hébergeurs qui existe dans le monde voudront continuer à bénéficier des services managés typiques de l’infogérance (management de l’OS, sécurité, monitoring applicatif, backup des données, etc…) et ne pourront donc pas interfacer directement des FR. Il est donc évident que cette demande forte sera satisfaite soit par les hébergeurs qui vont étendre leurs services d’infogérance soit en étant eux-mêmes FR, soit en assurant des services au-dessus de FR tiers (par exemple eNovance qui propose de l’infogérance sur Amazon). L’offre SmartCloud Enterprise +   d’IBM s’insère dans ce créneau, et offre la flexibilité d’un FR (ou presque) avec les services d’infogérance requis par les grands comptes.

Modèle de Cloud Computing

Voici donc le modèle complet (simplifié) :

article3_1

Traditionnellement, l’adoption du Cloud en entreprise est décrite comme un parcours (initiatique ?) avec différents stades de maturité tels que : data center virtualisé, data center consolidé et dynamique, Cloud privé, Cloud hybride. Dans cette optique, on envisage typiquement une progression qui démarre d’un data center traditionnel et qui aboutit à un ‘Cloud’ (sans bien savoir ce que cela comprenait) petit à petit.

Et si le modèle décrit ci-dessus nous suggérait une autre approche qui inverse la flèche ? Dans cette logique, on partirait d’un besoin business qui nécessite un ASM sur lequel on enregistre un FR (comme on mettrait une pile dans un appareil) ou sur lequel on enregistre un CMS (une multiprise programmable) dès lors que les ASM sont plus nombreux.

Conclusion

Pour tester – et illustrer- ce modèle, j’ai superposé un certain nombre d’acteurs du Cloud sur la figure de base. Cela donne le graphique suivant :

article3_2

On constate que ce modèle permet de placer de façon précise tous les acteurs. Il permet de comparer les différentes offres, de les placer dans un contexte et de comprendre les différents points d’intégration possibles.

Il permet donc de décrire les différents composants (ou services) qui constituent l’ADN de l’écosystème Cloud, tel qu’il se présente aujourd’hui. J’utilise ce modèle depuis quelques temps lorsque nous recevons des clients au Business Center de La Gaude. Très souvent nos interlocuteurs ont des besoins spécifiques et de temps en temps ils souhaitent connaitre la vision Cloud d’IBM de façon plus générale. Mais dans la majorité des cas, ils  sont demandeurs d’une vision à plus long terme car leur business l’exige (81% des entreprises considèrent que disposer d’une stratégie Cloud précise est de la plus haute priorité – Source : Forrester, 2012).

Ce modèle permet de présenter cette vision, permet de visualiser les produits actuels dans ce contexte, et permet d’imaginer une progression. Le flou – et la désagréable sensation de risque – s’amenuise lorsque les propos sont plus précis et cohérents.

J’utilise aussi ce modèle pour analyser la compétition et identifier les stratégies et priorités des différentes catégories de compétiteurs. On peut ainsi comparer ce qui est comparable et définir les points potentiels d’intégrations, car il est bien évident qu’un même acteur de l’IT peut être concurrent sur certains aspects tout en étant partenaire sur d’autres.

J’attends vos commentaires avec impatience.

Gérard Richter
Gérard est un ‘Consultant Cloud’ dans l’entité ‘Cloud Center for Industries’ au Business Center de La Gaude. Dans ce rôle, il intervient lors de visites de clients et lors de sessions d’éducation des forces de vente. Une des particularités du ‘ Cloud Center for Industries ‘ est d’identifier les particularités du Cloud par type d’industrie et de proposer à nos clients des démonstrations qui illustrent des cas d’usage métier.
Précédemment, Gérard a dirigé un service de R&D chez Lucent Technologies puis travaillé en tant que consultant Cloud pour BT.

{lang: 'fr'}
About The Author
Cloud Guru

Vous souhaitez réagir sur cet article ?