Comme nous l’avons vu dans un post précédent – La qualité dans le cloud – la réduction des coûts reste la motivation principale pour la virtualisation et le cloud, suivi ensuite de l’aptitude á délivrer la capacité.

Lorsqu’il s’agit de dimensionner une infrastructure physique et un budget d’exploitation pour celle-ci, le modèle est le suivant :

• Prévoir la charge maximale nécessaire, y compris pour répondre aux pointes d’activité.
• Estimer l’augmentation prévisionnelle, sur la période, à moyen / long terme.
• Ajouter une marge de sécurité.

Une architecture à base de serveurs physiques est forcément sur-dimensionnée par rapport aux besoins. Demandez à n’importe quel responsable de production ou ingénieur système : 20% à 40% des serveurs physiques hébergent des applications qui utilisent moins de 10% de leur CPU. Vous pouvez mutualiser ces applications dans plusieurs machines virtuelles au sein d’un unique serveur et libérer les autres pour les réaffecter dans votre infrastructure.

Réduction de coûts : faire plus avec moins.

Capacity Management

L’aptitude à délivrer la capacité constitue la seconde raison la plus importante : répondre avec la meilleure réactivité possible aux demandes des utilisateurs. Avant, lorsque vous aviez besoin d’un nouveau serveur, il fallait attendre, souvent plusieurs semaines, le temps de passer la commande et la livraison et l’installation de la machine. Aujourd’hui, il suffit de 3 clicks de souris pour installer une machine virtuelle, et les utilisateurs se sont habitués à voir leurs demandes satisfaites en 24 heures.

Ce qui amène d’ailleurs à ce phénomène bien connu de prolifération des machines virtuelles, avec la conséquence d’annuler les gains réalisés antérieurement par la réduction des coûts d’infrastructure. Car s’il est aisé d’installer de nouvelles VMs, cela représente un coût en termes de ressources, de licences et de charges de personnel pour gérer l’infrastructure virtuelle.

La gestion de la capacité ne consiste pas uniquement à répondre aux demandes des utilisateurs, mais également à faire face sans encombre et avec la réactivité maximale aux pics d’activité. Faire plus mais aussi mieux, avec moins. C’est l’un des avantages de la virtualisation : pouvoir déplacer les ressources disponibles en fonction des besoins. Rien de pire pour l’image d’une entreprise qu’un site web inaccessible, et s’il s’agit d’un site marchand, toute indisponibilité même provisoire équivaut à un accident industriel.

Malgré cela, il n’est pas rare que les patrons de la production, le responsable de l’infrastructure ou le Capacity manager ne soient pas avertis lorsqu’une nouvelle version d’application va générer un surcroît d’activité. De plus, ces pics ne sont pas toujours prévisibles.

Enfin, d’un point de vue développement, cette capacité à répondre aux variations d’activité n’est pas toujours inscrite dans les objectifs de projet. Délivrer une application en temps et en heure, avec les nouvelles fonctionnalités implémentées sans défauts ni bugs, voilà la priorité. Faire en sorte que l’application soit suffisamment ‘élastique’ pour réagir correctement aux variations de charge constitue rarement un objectif identifié, ni une préoccupation réellement intégrée dans le cycle de projet, sauf évènement particulier.

Une seule fois, j’ai vu un client souhaiter un audit de la qualité de son code, afin de vérifier si les programmeurs connaissaient et appliquaient correctement les bonnes pratiques en matière de performance. Il s’agissait d’une application bancaire critique, qui devait voir multipliée par trois son nombre d’utilisateurs, et par la-même la taille des données. Hormis un tel cas où la performance – en fait la scalabilité – était inscrite dans les objectifs du projet, il est bien rare que celle-ci soit considérée comme critique lorsqu’il s’agit d’identifier l’impact de nouvelles fonctionnalités sur l’application.

Bien sûr, vous vous souciez des bonnes pratiques en matière de performance, mais avez-vous intégré l’élasticité de votre application au sein de votre projet ?

Elasticité

Le terme d’élasticité provient du monde du cloud. Il constitue un critère important de la qualité d’une infrastructure virtuelle : l’aptitude à ajouter ou supprimer – on parle de commissionner / décommisionner – bref à déplacer des ressources (CPU, mémoire, espace et performance du disque dur principalement) afin de répondre aux besoins de capacité.
Imaginez que l’infrastructure virtuelle soit un ballon : pouvoir gonfler ou dégonfler un ballon plus ou moins facilement ou rapidement dépend de l’élasticité de celui-ci.

On mesure l’élasticité sur des critères tels que :

• La vitesse pour ‘bouger’ les ressources nécessaires – pour gonfler/dégonfler le ballon,
• La quantité de ces ressources déplacées,
• La possibilité de ne déplacer que certaines ressources – mémoire, CPU, espace disque – uniquement.

L’élasticité est nécessaire pour répondre aux pics d’activité, et aux besoins de scalabilité. Les deux notions ne doivent pas être confondues.

Scalabilité

La scalabilité est l’aptitude à répondre á la montée en charge en ajoutant des ressources. On peut la mesurer sous la forme d’un ratio charge / ressources. Si une application autorise une performance satisfaisante avec n ressources pour x utilisateurs, et si la performance reste égale en multipliant les ressources par 2 lorsque le nombre d’utilisateurs est multiplié par 2, alors cette application a une bonne scalabilité. Si ce ratio reste constant alors que les deux facteurs augmentent, la scalabilité sera linéaire. C’est l’idéal. Mais il est plus probable que certains composants ne soient pas à la hauteur de la scalabilité souhaitée, et donc que la performance se stabilise à partir d’un certain seuil, malgré l’ajout de ressources supplémentaires.

L’élasticité est la capacité à ajouter – ou diminuer – ces ressources dans une infrastructure virtuelle. L’élasticité inclut la scalabilité, mais une application ‘scalable’ n’est pas forcément une application élastique. Par exemple, vous effectuez du load-balancing afin de répartir la charge entre 2 serveurs d’application : ceci vous permet d’assurer un temps de réponse et une performance correcte, quelque soit le nombre d’utilisateurs, même lors de pointes d’activité imprévues.

Mais si vous ne pouvez revenir automatiquement à une architecture avec un unique serveur d’application, sans faire de load-balancing, vous ne pouvez pas dégonfler le ballon, votre application n’est pas élastique.

Comment prendre en compte l’élasticité dans votre projet ? Qu’est ce que l’élasticité d’une application ? Quelles applications sont concernées ? A vrai dire, si l’on commence à voir un certain nombre d’annonces d’éditeurs logiciels sur ce sujet, je n’ai pas encore trouvé beaucoup de réponses concrètes à ces questions, du point de vue du développeur ou de l’architecte. C’est ce que nous tenterons de faire dans notre prochain post.

Dans l’attente, tout commentaire sera le bienvenu.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.