Novell Cloud Manager : « apporter l’IT comme un service aux utilisateurs »  

LeMagIT : Concrètement, quels sont vos objectifs pour Cloud Manager ?

Ken Muir : Revenons à ce que doit être un Cloud : il s’agit une infrastructure qui doit être flexible et extensible, avec une dimension de self-service, tant pour les utilisateurs de la DSI que pour les utilisateurs métier; elle doit proposer un catalogue d’applications et de services mis à disposition. Le tout assorti d’un système comptable assis sur l’utilisation : les utilisateurs doivent pouvoir payer pour leurs systèmes IT selon leur consommation. Le défi du cloud, c’est donc de pouvoir apporter l’IT comme un service aux utilisateurs métiers qui pourront commander des services et applications packagés via une simple interface publique Web 2.0. 

Mais, concrètement, à quoi doit s’apparenter Cloud Manager ? à un portail de self-service, un moteur d’orchestration et de provisioning ?

Il intègre clairement ce portail de self-service, ce catalogue de services avec lequel l’utilisateur peut interagir. Mais, là, il s’agit d’une interface unique pour tous les types d’utilisateurs - métiers ou IT. Et qui permet, en plus, de supporter les workflows associés à la commande de services IT : lorsque vous demandez à disposer d’un service - qui peut, derrière, sur un plan technique, reposer sur plusieurs applications - vous pouvez choisir parmi différents niveaux de service. Puis votre demande est automatiquement transmise au responsable financier compétent pour approbation. Une fois approuvée, la commande est transmise automatiquement à la DSI où sont comparées les capacités requises et disponibles. Et si, là encore, la commande est approuvée, Cloud Manager intègre les mécanismes d’orchestration nécessaires au provisionning du service dans l’environnement de production.

Ce mécanisme de gestion des workflows rappelle celui d’Identity Manager 4.0. A quel point l’intégration entre ces deux solutions est-elle étroite ?

Cloud Manager intègre son propre moteur de gestion des workflows basé sur les rôles. Mais il peut s’intégrer avec nos outils de gestion des processus métiers, et ceux d’éditeurs tiers, grâce à des connecteurs bus de services d’entreprise (ESB). Nous supportons par exemple les solutions de Remedy. 

Et, de l’autre côté, celui de l’infrastructure, Cloud Manager s’appuie sur PlateSpin Orchestrate. Mais celui-ci sera-t-il requis ?

En fait, les capacités de PlateSpin Orchestrate sont intégrées à Cloud Manager : c’est le moteur de provisionning de l’outil. Et, grâce à des extensions - les adapters - il est capable de communiquer avec ESX de VMware, ou encore XenServer de Citrix. Et même avec vCenter, en profitant des API rendues publiques dans le cadre de l’initiative vCloud. Il saura également communiquer avec Hyper-V et avec System Center VMM. L’intérêt, là, c’est qu’il est possible de déployer ces hyperviseurs - et KVM - l’un à côté de l’autre, au sein de la même infrastructure, et de traiter l’ensemble comme un seul et unique Cloud. Selon les niveaux de service choisis, vous pouvez choisir spécifiquement un environnement ou l’autre. Mais tout cela est caché de l’utilisateur : il s’agit de proposer des services aux métiers sans qu’ils aient à se préoccuper de l’infrastructure sous-jacente. 

Mais, justement, Cloud Manager permettra-t-il de faire migrer à la volée une machine virtuelle d’un hyperviseur à l’autre - d’éditeurs différents, s’entend ?

Clairement, non mais presque. La question est : est-ce vraiment nécessaire ? Dans la pratique, les outils de PlateSpin Migrate permettent de faire passer une machine virtuelle d’un hyperviseur à l’autre avec une indisponibilité quasi nulle. Ce n’est pas du «live» mais cela s’en approche. ServerSync assure, dans une premier temps, une migration «live» mais ne désactive pas la machine virtuelle originale. Après vérification du fonctionnement de la réplique - et une ultime synchronisation des états - la réplique est lancée en remplacement de la machine virtuelle originale. Au final, l’indisponibilité se mesure généralement là en minutes et non pas en heures. Et cela fonctionne aussi entre centres de calcul distants. 

Comment prévoyez-vous de commercialiser Cloud Manager ?

Nous visons, dans un premier temps, les grandes entreprises qui utilisent nos produits, mais aussi celles qui cherchent à avancer vers l’utilisation d’un cloud public. Mais, ces dernières sont confrontées à de nombreuses contraintes, notamment réglementaires. Elles commenceront donc probablement par le cloud privé qui leur permettra, au passage, d’acquérir les compétences et les technologies qui leur serviront pour ensuite assurer la migration transparente d’applications entre cloud privé et cloud public. Et vice-versa. Ce qui est, justement, critique. Dans ce contexte là, nous nous voyons comme ceux qui permettent précisément cette souplesse, sans dépendance vis-à-vis d’un hyperviseur ou d’un autre. 

Sur un plan économique, nous prévoyons de commercialiser Cloud Manager non pas au socket mais à la machine virtuelle.