Explication du Cloud (focus IAAS et un peu SAAS) pour un DSI/décideur :)

Comme décrit dans mon dernier blog-post, j’ai pu récemment rencontrer pas mal d’acteurs sur la notion très “market” de Cloud et préparer une présentation sur le sujet pour l’occasion.
C’est pourquoi quand je lis que des DSI/Décideurs demandent à leurs équipes d’étudier une solution “Cloud” … par conditionnement, ou encore considèrent qu’avoir une machine virtuelle ce n’est pas un serveur dédié … il faut un peu expliquer les choses.

Sans écrire exhaustivement les paroles qui accompagnent mes slides “Le Libre, Le SysAdmin et les Clouds” (il faudra venir me voir !), voici quelques réponses en mode FAQ :

– C’est quoi le Cloud ?
Selon le NIST (National Institute of Standards et Technology), le Cloud Computing doit posséder 5 caractéristiques essentielles :

• libre service à la demande
• accessible sur l’ensemble d’un réseau
• avec une mutualisation des ressources
• rapidement « élastique »
• mesurable

En d’autres termes en parlant de la sous catégorie IAAS (Infrastructure As A Service), c’est la mise à disposition par Internet d’une ou plusieurs machines virtuelles aux ressources “facilement” modifiables (à la hausse ou baisse).
L’autre principale catégorie de Cloud est le SAAS (Software As A Service), qui est la mise à disposition par internet d’un logiciel en mode locatif (souvent un prix par utilisateur et par mois intégrant : licence, hébergement, maintenance, sauvegarde)

Enfin il faut différencier Cloud Privé (“cloud” monté pour une utilisation dédié à un unique client.) de Cloud Public (Cloud “mutualisé” ouvert à tous, type ceux d’Amazon, Microsoft, etc.)

– C’est quoi les avantages et inconvénients du Cloud ?

Avantages :

• pas d’investissement dans le matériel
• externalisation de la maintenance matérielle
• diminution du risque de panne matérielle
• outils facilitant les snapshots / la création de master
• Pour les sites/applications avec des besoins de ressources non constants ou linéaires, des économies de coût et d’énergie :
  • lors de pointes d’activité, possibilité d’évolution rapide et temporaire… si l’application est bien scalable !
  • lors des périodes creuses, possibilité de réduction rapide et temporaire

Inconvénients :

• moins de contrôle sur les données (confidentialité, fiabilité)
• moins de performances (principalement en I/O)
• latence réseau entre serveurs souvent dégradée sur un Cloud public
• augmentation des pannes à cause de la couche de virtualisation
• fiabilité non adaptée à des besoins critiques, nécessitant de “compenser” au niveau ingénierie système / logiciels
• Coût + élevé pour sites/applications avec des besoins de ressources constants ou linéaires
• risques juridiques liés à la localisation
• peu ou pas de proximité avec l’hébergeur
• outils spécifiques, avec des problèmes intéropérabilité / réversibilité

– J’ai un unique serveur dédié (physique), il vaut mieux que je passe sur le Cloud ?
Difficile de répondre de façon binaire catégorique. Si vous avez un serveur dédié (sous entendu classique = physique), il est probable que la comparaison se fera avec un serveur dédié … virtuel. À savoir une machine virtuelle. On peut dire les choses suivantes (en prenant une moyenne en terme de qualité/marque à la fois du serveur physique et de la VM comparée) :

• Une machine virtuelle à même ressources (dimensionnement RAM, CPU, disque) qu’un serveur physique (non virtuel) sera plus chère.
• Une machine virtuelle sur un Cloud public aura des performances d’accès disque moins bonne qu’un serveur dédié classique
• Le taux de panne moyen d’un Cloud public est de 7.5h/an (taux de disponibilité de 99,9%)
• Une plateforme “Cloud” (privé ou public) peut avoir une panne du fait de la défaillance (souvent partielle empêchant les Plan de Continuité d’Activité [PCA] de fonctionner) matérielle d’un équipement (exemple un dysfonctionnement du filer par exemple a créé plusieurs indisponibilités partielles sur le Cloud Gandi), ou un bug logiciel sur la couche hyperviseur (couche logicielle sous les machines virtuelles) ou encore un soucis type électrique côté datacenter, etc. Soit au final un risque et POF (Point Of Failure) supplémentaire à un serveur dédié physique [la couche de virtualisation].

En conclusion, passer d’une machine dédiée physique à une machine virtuelle dédiée sur un Cloud (privé ou public) ne doit pas remplacer la mise en place d’un Plan de Reprise d’Activité (PRA) si ce que vous souhaitez héberger est critique. Elle se justifie surtout si des modulations du dimensionnement serveur peuvent être nécessaire sur des périodes courtes ou fréquentes. Dans le cas de Cloud public et certain Cloud privé, cela nécessite aussi d’héberger des applicatifs qui n’ont pas besoin de performances trop grandes côté accès disque.

– Peut-on tout héberger dans le Cloud ?
Dans le Cloud Public la réponse est non -comme en partie évoqué plus haut (service de base de données fortement sollicités, etc.)-.
Dans le Cloud Privé, tout dépend de l’architecture et qualité du matériel pour la partie performance :). Outre ce blocage lié aux performances, le Cloud trouve vraiment son intérêt à pouvoir allumer et éteindre plusieurs machines très réactivement, il est donc particulièrement adapté (en terme de budget notamment) dans le cas d’applications scalables. Typiquement une application structurellement monolithique aura peu d’intérêt à être mise dans le Cloud car la taille maximum d’une unique VM est souvent plus restreinte que sur un serveur dédié physique.

– Quelle est l’utilisation idéale du Cloud ?
Nous avons pu faire gagner en souplesse et faire économiser un budget important en passant un client à une infrastructure hybride (noeud sur serveurs physiques et noeud séparé sur serveurs virtuelles) pour gérer un fort trafic (pic à plusieurs millions de visiteurs unique/jour).
Plus globalement, les exemples type d’utilisation (cas IAAS) :

• frontaux web d’une infrastructure web scalable
• serveurs de dev ou de pre-prod ponctuels

Petit récapitulatif en forme de tableau :

	Souplesse (scalabilité)	Performances	Coût	Nécessité PRA
Serveur physique	x	xxxx	xx	xxx
VM Cloud Public	xxxx	xx	x	xxxx
VM Cloud Privé	xxx	xxx	xxx	xxx