Le Chaos Gorilla est une des pratiques appliquée dans l’approche du Chaos engineering. Cette pratique extrême permet de s’imposer d’avoir des offres de qualité.
Le Chaos Gorilla
Le chaos gorilla est très proche de son grand frère le chaos monkey.
Revenons aux origines du terme de Chaos Monkey. Voici l’explication d’Antonio Garcia Martinez dans son livre qui explique pourquoi la solution s’est appelée Chaos Monkey :
« Imaginez un singe s’introduisant dans un data center, ces « fermes » de serveurs qui hébergent toutes les fonctions critiques de nos activités en ligne. Le singe arrache au hasard des câbles, détruit des appareils et retourne tout ce qui lui passe par la main. Le défi pour les responsables informatiques est de concevoir le système d’information dont ils ont la charge pour qu’il puisse fonctionner malgré ces singes, dont personne ne sait jamais quand ils arrivent et ce qu’ils vont détruire. »
Voici le raison très simple de cette appellation ; elle pourrait surprendre quand on ne connait pas les raisons de son existence. Je vous laisse imaginer l’image en remplaçant le singe par un gorille.
En effet, le terme de gorille est exactement la représentation métaphorique que veut donner cette autre solution pour tester la résilience en cas de panne.
le chaos gorilla, c’est la solution XXL
En effet, cette solution contrairement au chaos monkey qui va tester des pannes d’instances ou de serveurs, va tester la résilience en cas de panne sur une zone complète d’AWS.
Si cette solution peut paraitre être la chaos monkey XXL, elle n’impliquera pas les mêmes nécessités pour y faire face. Mais si votre système sait faire face à la mise en place d’une telle solution, vous commencez à avoir des solutions solides capables de faire face à beaucoup de problèmes.
Les zones et régions sur AWS
Voici le schéma proposé par Amazon pour que vous comprenez bien la notion de zones :
Avec un système fonctionnant en plusieurs zones voire en plusieurs régions (on parle bien de régions dans le monde), votre système devrait être assez résistant. Cependant, cela implique une bonne capacité de scalabilité car lorsqu’une zone tombe, les autres zones doivent faire face à une éventuelle surcharge de travail.
Mais ce n’est pas couteux ?
Les clouds d’aujourd’hui permettent de limiter les frais si on compare aux années 90 ; cependant, la mise en place de services capables de faire face aux solutions du chaos engineering a un coût.
Cependant, ce coût permettra d’avoir des systèmes beaucoup plus résiliants ; cela permettra :
- d’éviter la déception des clients (en cas de panne)
- de limiter les coûts de maintenances futures
- de ne pas être surpris d’avoir des pannes en cascade
Est-ce que le coût n’est pas un investissement gagnant au final ?
conclusion chaos gorilla
Utilisez-vous le chaos gorilla dans vos entreprises ? Pensez-vous que le chaos gorilla est un extrême ou devrait devenir une norme pour s’assurer de la qualité de service ?
Lien utile lié au chaos gorilla : outil à télécharger
Soyez le premier à commenter