Catégories
Start-up et applications

L'ingénierie du chaos dans les environnements sans serveur est plus utile que vous ne le pensez

L'ingénierie du chaos a gagné beaucoup de terrain au cours des dernières années en quittant son origines chez Netflix à de plus en plus d'entreprises de l'industrie. De nombreuses équipes de développement l'utilisent pour éviter les temps d'arrêt en essayant de briser leurs systèmes volontairement afin de pouvoir améliorer ces systèmes avant qu'ils ne causent des problèmes.

Compte tenu de la nature résiliente de l'informatique sans serveur, basée sur les accords de disponibilité et de disponibilité des fournisseurs de cloud, il peut sembler que l'ingénierie du chaos est une méthode de test qui ne serait pas pratique en mode sans serveur. Mais Emrah Samdan, vice-président des produits pour Thundra, estime que l'informatique sans serveur et l'ingénierie du chaos vont vraiment bien ensemble.

Parce que le fournisseur de cloud garantit la disponibilité et l'évolutivité, lors de l'ingénierie du chaos dans des environnements sans serveur, l'objectif n'est pas nécessairement de faire tomber le système, mais de trouver des pannes au niveau de l'application, telles que celles causées par un manque de mémoire ou de temps. «Le but des expériences sur le chaos n'est pas de détruire tout le logiciel mais d'apprendre des échecs en injectant de petites pannes contrôlables», a déclaré Samdan.

CONTENU CONNEXE: Pour construire des systèmes résilients, embrassez le chaos

Certains des exemples les plus courants d'ingénierie du chaos dans le sans serveur que Samdan voit sont l'injection de latence dans les fonctions sans serveur pour vérifier que les délais d'expiration fonctionnent correctement et l'injection de pannes dans les connexions tierces.

Samdan a noté que l'étape de l'ingénierie du chaos consistant à définir l'état de statut est une première étape importante, mais qui est souvent négligée. «Les gens veulent juste casser des choses, mais la première étape consiste en fait à comprendre comment ils fonctionnent réellement, quels sont les hauts et les bas du système, quelles sont les limites, à quel point votre système est déjà résilient», a-t-il déclaré.

Il pense que la détermination de cette base de référence est encore plus importante dans les environnements sans serveur. En effet, ce qui est considéré comme normal pour le sans serveur peut être très différent de ce qui est considéré comme normal dans d'autres systèmes. Par exemple, en mode sans serveur, la latence et le nombre d’exécutions sont très importants, ce qui n’est pas aussi vrai dans d’autres systèmes.

Pour cette raison, il est important qu'une équipe d'ingénieurs dispose d'une observabilité appropriée. «Les expériences d'ingénierie du chaos consistent à poser des questions pour comprendre ce qui s'est réellement passé pendant l'expérience. Vous ne pouvez pas y parvenir en gardant un œil sur les graphiques métriques, car ils sont conçus pour répondre à des questions connues. Afin de poser des questions sur les inconnues du système distribué, vous devez regrouper et intégrer les trois piliers de l'observabilité – journaux, métriques et traces. Je vois que l'adoption d'une observabilité correcte se poursuit et que de plus en plus d'entreprises utilisent des outils modernes à cette fin. Je crois franchement que nous verrons de plus en plus d’entreprises se lancer dans l’ingénierie du chaos à mesure que l’observabilité moderne se généralisera », a déclaré Samdan.

Pour ceux qui cherchent à commencer à faire des expériences de chaos dans des environnements sans serveur, Samdan recommande de commencer petit et de commencer dans l'environnement de préparation. Plutôt que de limiter toutes les fonctions sans serveur, il conseille de limiter ou d'injecter une latence dans un ou deux services en aval. "Il ne s'agit pas seulement de tester les échecs sur votre système, il s'agit également de tester la réaction de votre équipe à ces échecs. Donc, commencer petit est en fait très encourageant de persévérer pour des expériences plus complètes », a déclaré Samdan.

Comme pour toute nouvelle méthodologie, changer de culture est le plus grand défi. L'ingénierie du chaos doit être une initiative et être parrainée par des personnes de haut niveau dans l'entreprise, estime Samdan. «Les équipes doivent être capables de travailler en harmonie en planifiant, en gérant et en évaluant les jours de match. Nous devons toujours garder à l'esprit que les expériences de chaos ne servent pas à critiquer les collègues pour les faiblesses de leurs modules. Il s'agit davantage de corriger ces faiblesses avant que les clients ne soient touchés et de laisser ces collègues grandir à la suite des expériences », a déclaré Samdan.

Samdan a également conseillé aux développeurs de se rappeler que l'ingénierie du chaos n'est pas une solution miracle pour trouver chaque échec. Il fonctionne mieux lorsqu'il est utilisé pour compléter d'autres méthodologies de test comme les tests unitaires et les tests d'intégration. «Cependant, l'ingénierie du chaos exploite un point très différent des autres tests. Il teste la résilience d'autres parties de votre système lorsqu'une partie rencontre des problèmes dus à une latence ou à tout type de défaillance. Compte tenu du paradigme des systèmes distribués sans serveur, la réalisation d'expériences de chaos devient une évidence pour révéler les pièges cachés avant que les clients ne les révèlent en production », a-t-il déclaré.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *