Les entreprises prennent un virage important dans la façon dont elles créent et mettent en œuvre leurs ressources de TI. Ce virage promet des économies grâce à la facturation à l’utilisation et une capacité d’évolution. Tout changement majeur dans les technologies de l’information pousse les professionnels à revoir leur stratégie applicative — voyez par exemple les systèmes clients/serveurs, le Web ou autres appareils mobiles. Aujourd’hui, l’infonuagique incite à faire une révision semblable des stratégies de TI. Mais les nuages en sont encore à leurs débuts. Nombre d’entreprises restent sceptiques face à l’informatique à la demande, car elles sont contraintes de reléguer leur contrôle des réseaux et des architectures sous-jacents sur lesquels fonctionnent leurs applications.
Vers la fin de l’année 2009, Webmetrics, une entreprise de mesure et de contrôle de la performance, nous a demandé d’écrire une étude sur la performance du nuage. Nous avons donc décidé d’évaluer plusieurs plates-formes infonuagiques, sous différentes dimensions, en utilisant les services de Webmetrics pour la collecte des données de performance. Sur une période de plusieurs mois, nous avons créé des agents d’essai pour mesurer les réseaux, les UCT, et les contraintes E/S des cinq plus importants fournisseurs d’infonuagique. Nous avons aussi analysé les sites de cinq sociétés en les faisant fonctionner sur chacun des cinq nuages. Comme vous vous l’imaginez, cela a produit une quantité considérable de données. Nous les avons traitées pour ensuite les parcourir afin de découvrir des tendances qui nous permettraient de comprendre la performance et les capacités de ces plates-formes. Ce compte-rendu rapporte les résultats de nos efforts.
Les évaluations sous plusieurs plates-formes sont, par leur nature, imprécises. Les différents nuages requièrent différentes techniques de programmation donc, tous les agents d’essais sont uniques. Certains nuages utilisent le stockage de données à grande échelle pour extraction rapide et d’autres misent sur des bases de données plus traditionnelles. Donc, les données dans ce compte-rendu ne doivent servir que de lignes directrices pour de plus amples essais; vos résultats varieront grandement.
D’abord et avant tout : Il y a beaucoup à surveiller. Les nuages peuvent défaillir de plusieurs façons imprévues; voici quelques-unes des leçons que nous avons apprises.
Surveillez vos voisins. Nous avons recueilli des preuves que nombre d’applications infonuagiques ralentissent tout d’un coup, vous serez donc certainement affecté par les autres qui utilisent le même nuage que vous.
Ayez connaissance du profil de votre nuage. L’histogramme ci-joint démontre que chacun des nuages est bon pour différentes tâches. Vous allez devoir choisir la taille de votre machine virtuelle — au niveau de l’UCT de la mémoire, etc. — afin de fournir une bonne performance.
Vous aurez besoin d’un agent à l’interne. Lors de la planification de votre stratégie, munissez-vous d’un code sur mesure exerçant les fonctions secondaires; vous pourrez ainsi repérer le problème rapidement.
Choisissez PaaS ou IaaS. Si vous êtes prêt à reprogrammer votre application pour tirer profit de systèmes de données massives tels que Bigtable, vous bénéficierez d’une grande évolutivité en choisissant un nuage PaaS. D’un autre côté, si vous avez besoin de machines individuelles, vous aurez à intégrer de la souplesse à votre configuration IaaS.
Les données massives ne sont pas données. Le fait d’utiliser de grandes bases de données communes peut sembler une bonne idée. Cependant, l’entrée des données est coûteuse en temps, ce qui n’est peut-être pas approprié aux tendances d’utilisation de votre application.
Surveillez l’utilisation et les régulateurs. Dans un système PaaS, si vous dépassez vos limites de taux, vos utilisateurs recevront des messages d’erreurs.
Le diagnostic de panne devient plus difficile. Vous aurez besoin des données sur Internet dans leur ensemble, de votre fournisseur de nuage dans son ensemble ainsi que des différents tiers qui composent votre application afin de repérer le problème convenablement. Lorsque vous fonctionniez sur une infrastructure réservée, vous n’aviez pas à passer votre temps à éliminer les problèmes de tierces parties (comme les conflits issus d’une bande passante partagée ou du blocage E/S).
PaaS signifie : tout le monde dans le même panier. Nous avons remarqué que lors de l’utilisation d’un PaaS, si le nuage ralentit, tout le monde ralentit aussi. Avec le laaS, il y a une plus grande marge entre l’UCT et le temps de réponse du serveur — mais vous rivalisez toujours pour de l’espace de stockage partagé et pour la bande passante du réseau.
Surveillez plusieurs zones. Si vous misez sur les zones disponibles pour répartir les risques de pannes, vous devrez accroître la surveillance afin de comparer les zones les unes aux autres.
