Cloud privé Partie 3/4

Dans le premier article de cette série, j’ai présenté la notion de cloud privé, puis dans un second article un premier type d’offre – un espace dédié chez un fournisseur de cloud computing – qui peut répondre à ce besoin. Face à l’innovation que représente le cloud computing, le cloud privé vise à mitiger les risques liés à cette innovation (verrouillage technologique, sécurité, confidentialité, pérennité des partenaires). Nous allons aujourd’hui nous intéresser à un autre type d’offre de cloud privé – une infrastructure de cloud en interne – avant de comparer ces deux types d’offres. Je rependrai dans cet article la représentation des avantages et des inconvénients des différentes offres par rapport aux gênes du cloud computing utilisés dans les articles précédents.

Une infrastructure de cloud en interne

Il existe désormais des possibilités pour créer sur une infrastructure interne des solutions proches d’EC2. Je place dans cette catégorie :

  • VMWare VSphere
  • Eucalyptus, un projet open source offrant la même interface qu’EC2
  • Enomaly, une plateforme de cloud computing destinée aux fournisseurs et aux entreprises clientes
  • Du côté de Google App Engine, des solutions techniques apparaissent pour faire fonctionner Google App Engine localement

Même si l’infrastructure mise en oeuvre n’aura pas la taille des datacenters de Google ou d’Amazon, cela permet de reprendre quelques principes du cloud computing dans nos SI.

VmWare vSphere

VSphere est l’un des derniers produits de VMWare, le leader de la virtualisation sur architecture x86. Il offre comme un système d’exploitation – pour reprendre la description qu’en fait l’éditeur – constitué d’un ensemble de services de virtualisation : virtualisation du calcul, du stockage, des communications réseau. Il ajoute des fonctionnalités de reprise à chaud, la définition de zones de sécurité, et la possibilité de migrer des machines à chaud. En ce sens vSphere offre des fonctionnalités tout à fait comparables à une offre IaaS comme Amazon. Une telle offre permet de déployer en interne une offre dite de cloud mais limitée à la couche IaaS c’est à dire à des machines virtuelles de type EC2. Je reste volontairement prudent sur le terme cloud, car pour pouvoir offrir l’élasticité et le paiement à des conditions tarifaires comparables à Amazon, le service informatique qui déploiera ce type de produit devra adresser une problématique de gestion de capacité complexe (quel niveau de consolidation? comment absorber les pics de charge sans avoir des investissements sous-utilisés donc impossible à amortir?) bien plus délicate à gérer que le problème technique de mise en oeuvre. En somme ce type d’offre constitue le prolongement des technologies de virtualisation. Les gains apportés seront d’autant plus importants que l’uniformisation des ressources et l’effet d’échelle seront importants, mais il sera probablement difficile d’atteindre le même niveau de rentabilité qu’un prestataire tel Amazon.

Ce type d’offre met en oeuvre des technologies de virtualisation assez proches de celles mises en oeuvre par les fournisseurs de cloud computing. Aujourd’hui cependant, les formats de machine virtuelle (« Xen like » pour Amazon, VMWare pour vSphere) et les interfaces d’administration ne sont pas encore compatibles. Déployer une même machine virtuelle en interne ou sur EC2 au choix, est techniquement faisable avec des outils adaptés mais encore peu répandu. Aujourd’hui quelques forums font état de hacks pour réaliser une partie de l’exercice. Ce type d’offre permet ainsi deux avancées. D’une part elle permet de reprendre en interne le concept de consolidation des machines pour augmenter leur utilisation et donc leur rentabilité. D’autre part, dans les cas d’applications qui peuvent être déployées entièrement sur des machines virtuelles en production – ce qui présente certaines limitations comme nous l’avons vu sur le premier article – cela rend possible la réversibilité du passage au cloud computing. Disposer de deux plateformes très similaires sur le cloud et en interne diminue le risque d’investissement dans le cloud.

Eucalyptus

Eucalyptus est un projet open source qui offre un service proche de VmWare vSphere tout en apportant un solution plus complète à l’exécution d’une même machine virtuelle sur le cloud et sur une plateforme interne équipée d’Eucalyptus.

Plateforme de Cloud Computing Open Source Eucalyptus

Plateforme de Cloud Computing Open Source Eucalyptus

Cette plateforme permet de déployer sur diverses infrastructures de virtualisation (Xen, KVM, VMware pour la version commerciale) des services comparables à Amazon EC2, S3 et EBS avec les mêmes interfaces (signatures de web services identiques et mêmes outils en ligne de commande). Cette offre va donc plus loin que vSphere en permettant d’une part de mutualiser les compétences et les outils (par exemple l’extension de Firefox ElasticFox est utilisable pour Amazon et pour Eucalyptus) et d’autre part de pouvoir convertir des images EC2 (Eucalyptus fournit un outil de conversion dans sa version commerciale). Cette solution est très bien intégrée à la version 9.10 d’Ubuntu qui propose même un assistant d’installation. Cependant il s’agit d’un système distribué assez complexe nécessitant des compétences d’administration linux assez avancées pour être capable d’administrer et de dépanner le système au delà de l’assistant d’installation (configuration réseau, accès ssh distants, etc.). Il s’agit également d’un outil jeune mais dans déjà fortement intégré à certaines distributions linux comme Ubuntu et avec une offre de support. Il ne reste plus qu’à attendre des retours d’expérience concrets.

Autres sociétés

Aujourd’hui un écosystème se met en place avec des propositions de services de ce type même si les offres restent encore limitées. Enomaly est une entreprise qui fournit de façon similaire une « plateforme de cloud computing » à destination des providers et des entreprises. Cela assurerait de fait la compatibilité entre les deux approches à condition que des providers de taille utilisent cette solution. On citera également rPath dont la solution permet de créer des installations déployables sur un serveur physique, une image VMWare ou chez différents fournisseurs. Des sociétés comme CohesiveFT ou RightScale cherchent également à faciliter le portage fournissant des interfaces communes pour gérer en interne comme en externe la sécurité, l’administration, etc.

En synthèse les avantages de ces différentes offres peuvent se résumer ainsi :

Avantages du cloud computing Inconvénients du cloud computing
Le paiement à la demande L’optimisation de certains coûts de gestion La nécessité de gérer différemment la sécurité L’absence de localisation pour les données sensibles Le risque sur les investissements
L’abstraction sur la localisation Dégradé : la haute disponibilité (deux sites) doit être gérée dans le cas interne Amélioré : les données sensibles peuvent rester en interne
Le paiement à la demande Dégradé : il n’est valable que pour les ressources externalisées
Le self-service (accès via internet) Dégradé : l’offre est limitée par rapport au cloud public (uniquement IaaS : location de machines virtuelles) Pas de changement : gestion applicative de la sécurité
L’utilisation de ressources partagées et d’architectures « multi-tenant » Uniquement pour les ressources externalisées Seules les ressources externalisées sont partagées
L’élasticité qui est la capacité à pouvoir ajouter à la demande des ressources dans le système et la scalabilité qui est la capacité à consommer autant de ressources pour la première requête et la 101ème Dégradée : l’élasticité restera délicate pour les ressources internes (mêmes problématiques de dimensionnement pour que la virtualisation) Principal avantage de ces offres : une élasticité tout en ayant une faible barrière entre interne et externe

En positionnant ces différents types d’offres sur cette grille se pose le dilemme suivant : les ressources externes ont les avantages et inconvénients du cloud computing et les ressources internes l’inverse. Elles permettent donc de protéger les investissements mais perdront certains bénéfices du cloud computing au niveau des ressources internes. Pour ces ressources il s’agira de reprendre en interne les bonnes pratiques – virtualisation, industrialisation de l’administration – mises en place chez les fournisseurs.

Mots-clés: ,

1 commentaire pour “Cloud privé Partie 3/4”

  1. Au sujet de la rentabilité des investissements d’un cloud privé interne, je pense surtout que la gain attendu par les entreprises ne se situe pas là. En effet, comme vous le soulignez, les acquisitions doivent être faites de la même manière qu’un modele virtualisé traditionnel. Les gains sont plus de l’ordre de la rapidité de mise en oeuvre et des gains qui en decoulent :
    - phase de lancement raccourcies pour les projets
    - possibilité d’ajout de puissance plus rapide
    - …

    Pour cela il faut abandonner le mode de gestion traditionnel où quasiment chaque projet gère son approvisionnement en ressources (avec les phases de commandes / livraison / setup associées). Le cloud privé ne peut être rentable que si l’on passe vers un mode d’approvisionnement centralisé et par investissement préalable avec refacturation interne. Certes cela demande de créer littéralement un hébergeur interne, mais les efforts dans ce domaine sont en général porteur d’amélioration :
    - centralisation de la gestion des ressources et meilleure gestion (par lissage)
    - possibilité de négocier avec ses fournisseurs sur des echelles plus importantes

    Certes on est fort éloigné de la rentabilité du cloud qui permettent à amazon ou google d’envisager des modèles économiques rentables. Mais pour les entreprises qui ne peuvent se permettre l’utilisation de cloud public ou privé externalisé, c’est certe une manière de réduire les factures d’achats mais surtout un moyen de réduire les délais de mise en oeuvre et de diminuer le go to market de certaines offres. Il s’agit d’un gain indirect et qui est plus difficile à intégrer dans un calcul de ROI mais il est bel est bien présent.

Laissez un commentaire