Chef est un outil opérationnel puissant. Sa flexibilité et sa capacité d'automatisation le rendent extrêmement populaire dans les organisations qui déploient des services de grande envergure. Notre propre Ranjib Dey a été invité à prendre la parole lors de la conférence annuelle de Chef, ChefConf, qui a eu lieu en avril. Voici quelques-uns des points saillants de la conférence de Ranjib, « How To Mock a Mockingbird » (Comment se moquer d'un oiseau moqueur) (du nom d'un livre sur la philosophie mathématique).

Supposons que les choses vont se briser

« Concevoir pour l’échec » pourrait être une manière plus concise d’exprimer ce point. Il s'agit d'un élément fondamental de l'histoire de PagerDuty – PagerDuty a été créé autour du principe selon lequel les crises sont inévitables pour toutes les équipes opérationnelles. Notre rôle est de rendre la gestion de ces crises un peu plus agréable.

Ranjib suggère aux développeurs d’accepter l’échec comme une évidence. Pour atténuer les échecs, les équipes DevOps peuvent s’efforcer de les rendre aussi « peu coûteux et isolés » que possible, poursuit Ranjib.

Le design est important

Si la planification des échecs est le « pourquoi » de la discussion de Ranjib (comme dans « Pourquoi devrais-je prendre Ranjib au sérieux ? »), la conception du code est le « comment ». Dans un environnement où les choses se cassent, l'atténuation par la conception est la meilleure défense contre les temps d'arrêt.

En pratique, cela signifie, explique Ranjib, qu'il faut minimiser le code que vous déployez. Non seulement une plus grande complexité du code rend les tests plus difficiles, mais un code plus léger peut être remplacé plus rapidement si des bugs se présentent (ce qui, encore une fois, est inévitable).

« Tout ce qui est complexe en théorie sera difficile à tester. »

Tester intelligemment

La façon dont vous validez votre base de code est étroitement liée à l'apparence réelle du code. En d'autres termes, vos processus de test dépendront de la solidité de la conception du code.

Votre code doit par exemple bien fonctionner dans des scénarios de tests de type Happy Path. Les scénarios de type Happy Path, également appelés tests d'acceptation, mesurent les performances du code dans des cas d'utilisation ordinaires.

La conception du code est véritablement validée lorsque vos services sont soumis à des contraintes – et le meilleur moyen d’y parvenir est de procéder à des tests unitaires. Non seulement les tests unitaires sont très rapides, note Ranjib, mais ils peuvent détecter 80 à 90 % des erreurs (dans un scénario idéal). Cela en fait une stratégie de validation particulièrement intelligente par rapport aux tests d’acceptation, qui, bien que complets, sont lents (et s’accompagnent d’une courbe d’apprentissage abrupte).

Ranjib ajoute que les tests unitaires jouent un rôle supplémentaire dans le renforcement de la cohérence de la base de code. Les tests unitaires rapides contribuent à maintenir la conventionnalité dans la conception du code. C'est pourquoi les tests unitaires doivent être considérés comme une méthodologie de test fondamentale.

« Les tests unitaires sont d'une valeur inestimable pour la maintenabilité à long terme. »

Communiquez pour de meilleurs résultats

Nous sommes des évangélistes des tests unitaires, car ils permettent aux développeurs de gérer leur code de bout en bout (avec le soutien des opérations). Dans un environnement où les développeurs et les opérations travaillent vers des objectifs communs, la collaboration est extrêmement importante – et pour que la collaboration prospère, tout le monde doit communiquer.

La communication étant un élément essentiel de la culture DevOps, Ranjib affirme que l'élimination des silos de connaissances doit être une priorité. Une bonne conception est l'élément principal d'une base de code saine (comme indiqué dans le premier point de Ranjib), et la conception ne peut pas s'épanouir si les équipes ne partagent pas entre elles ce qu'elles savent.

« La communication influencera le design. »

Soyez à l'aise avec la complexité

Ranjib a illustré l'importance de la communication avec deux diapositives : l'une représentant une topologie de code de référence typique et la suivante montrant une image d'une assiette de spaghetti. Selon Ranjib, les topologies de référence ne parviennent pas à capturer toutes les dépendances et tous les services opérationnels contenus dans les déploiements. Les topologies réelles, poursuit-il, ressemblent beaucoup plus à cette masse de spaghetti.

En termes simples, les bases de code modernes seront trop complexes pour communiquer de manière simpliste. Et les topologies les plus tolérantes aux pannes seront sans évolutivité, c'est-à-dire qu'elles contiendront une pluralité de nœuds et de rayons de sorte qu'aucun élément ne soit « lié » de manière dépendante à un autre.

L'idée de ne pas savoir comment tout ce qui est connecté dans votre base de code est connecté (et d'être d'accord avec cela) a été avancée par Corey Bertram, ingénieur en fiabilité du site Netflix, lors de son arrêt au siège de PagerDuty en mars. Le discours de Corey a illustré la nature des déploiements, suggérant que Adopter une attitude zen est la seule réponse logique à leur complexité sauvage.

« Personne ne sait exactement à quoi devrait ressembler une architecture réseau tolérante aux pannes. »