Comme vous l’avez peut-être vu, la presse plus ou moins spécialisée s’est empressée de mettre « le cloud » sur la sellette suite à la panne de Amazon Web Services (AWS).
Le Cloud (« nuage » en français), est une architecture informatique qui consiste à ne plus raisonner en termes de « serveurs » mais en termes d’« unités de traitement » (calcul, stockage, transfert de données).
Autrement dit, la promesse du Cloud, c’est que les programmeurs d’un site web n’ont plus à s’occuper de la gestion des éléments physiques (serveurs, disques durs, réseaux) : il leur suffit de louer un service d’accès à des « unités de traitement ». Ainsi, le prestataire du service a la charge de s’assurer que les éléments physiques sont opérationnels en permanence pour garantir le fonctionnement de ces « unités de traitement ».
Outre l’accès facilité à des services dits de « haute disponibilité », le Cloud permet également de réduire les coûts et la consommation énergétique globale : là où un site web avait besoin de 2 serveurs pour obtenir une redondance (et donc résister à une panne d’un serveur), il n’a plus besoin que d’une portion de serveurs, partagé avec d’autres clients du Cloud.
Pour en revenir à la fameuse panne d’AWS, et comme le fait justement remarquer PingDom, spécialiste de la surveillance (monitoring) de services web, il y a certes de nombreux enseignements à tirer de cette panne majeure, mais sûrement pas lieu de bannir le Cloud.
Le premier à blâmer, si l’on en croit les analyses postées par les clients du Cloud Amazon, sont… les programmeurs/utilisateurs du Cloud eux-mêmes, qui d’ailleurs assument très bien leur responsabilité.
Quant à ceux qui, comme smugmug.com, n’ont pas été touchés (ou presque) par la panne, ils donnent quelques recommandations :
- Ne pas localiser ses ressources dans un seul datacenter (appelés AZ dans le vocabulaire AWS), mais dans autant de lieux différents que possible: 4, voir 5 («ne pas mettre tous ses œufs dans le même panier…» en bref).
- Ne pas utiliser un seul prestataire de Cloud, mais plusieurs. Facile à dire, mais moins à faire: chaque fournisseur de Cloud a ses spécificités, et en utiliser plusieurs nivèle par le bas les fonctionnalités utilisées.
- Programmer son logiciel pour qu’il résiste à une panne. Les logiciels web sont éminemment complexes, un petit dysfonctionnement ne doit pas arrêter tout le système. Pour y parvenir, il est souhaitable de concevoir son logiciel sous forme de modules ou «briques» autonomes, pour que le dysfonctionnement d’un module n’empêche les autres de fonctionner.
- Tester en permanence la résistance du logiciel à des pannes. Jeff Atwood va plus loin et explique pourquoi l’on devrait générer volontairement des pannes aléatoires dans son logiciel, en «tuant» des tâches (comme on peut le faire sur son ordinateur Windows).
Pour autant, toutes ces bonnes résolutions à prendre pour l’avenir, ne doivent pas faire oublier trop vite les erreurs qui viennent d’être commises par Amazon Web Services : aussi bien au niveau de l’architecture de leur système de stockage, qui est resté en panne plusieurs jours, qu’au niveau de leur communication de crise, quasi absente.
Il reste à chacun la charge mettre en pratique ces recommandations, que l’on soit client du Cloud ou pas, d’ailleurs…
Werner KLINGER
Ingénieur conseil NTIC.