Makram Jandar – Consultant Data AI nous parle DevOps dans le prochain Hors-Série du magazine Programmez! qui sortira le 23/10/2020. Voici un résumé de l’article.

En ce qui concerne Azure et l’IaC (Infrastructure as Code), l’éventail des options est plutôt bien bourré, plus exactement trois principales: les modèles ARM, Terraform et le petit dernier Azure CLI (command-line interface).

  • Les modèles ARM, chouettes au demeurant, mais si incommodants à coder et à déboguer — j’en flippe rien qu’à y penser —, enfin, je n’ai rien contre mais le coté Friendly laisse et pas que peu à désirer !!
  • Terraform du haut de son statut de Goldorak de l’infra, bien robuste si cool, avec tout plein de gadgets pas crades du tout : Backend, Idempotence, code Refactoring… sans compter la ribambelle des thin Wrappers genre Terragrunt, Tau (une petite merveille conceptuellement causant),  tfscaffold, etc., pèche cependant par le décalage de ses providers d’autant plus prononcé si on utilise ses mignons susnommés avec les dernières nouveautés d’Azure.
  • Enfin, il y a l’Azure CLI, mon chouchou 😉 et j’assume le parti-pris (les goûts et les couleuvres !!) Faut dire que ses avantages valent la peine à ce qu’on se démène en scryptologie à papie pour combler ses déficiences !! De un, il est très intuitif, l’on a déjà une représentation de l’Infra convoitée au moment même de l’expression du besoin. Certes, pas wysiwyg du tout mais quasi tout comme… Deuzio, déboguer les couacs d’approvisionnement devenait si easy, que c’est presque fun et puis surtout son extrême lisibilité le rend déclarativement looks-like

Pour ainsi dire, en mode « je bazarde tout et je recrée from scratch » allez-y sec, c’est pour le moins spectaculaire. Que ce soit en mode Canary[1] ou Blue Green Deployment[2], c’est comme à la superette, on remplit son caddie et on passe à la caisse… L’on peut ainsi, si tant qu’on soit rompu aux principes DevOps et qu’on ait la bonne Team, faire de l’infra Immutable avec l’assistance d’un packer ou des spin-offs organisationnelles voire de versionning  à la « en voulez-vous, en voilà », et donc vraiment mover fast sans ou avec peu de casses… Inversement, si on veut apporter des changements graduels au fil du temps. Bien que certaines commandes d’Azure CLI soient idempotentes (la plupart des créations le sont), toutes les commandes ne le sont pas complètement, on peut contourner, via des dictionnaires de mapping, à même les templates YAML… Ils se marient bien les lurons et c’est le moins qu’on le puisse dire !

En résumé, le potentiel est extra, faites-en l’expérience dans mon article dédié à l’IaC en mode NoOps de l’hors-série Programmez…


[1] Le nom canary release vient des canaris qui étaient utilisés dans les mines de charbon pour détecter les gaz toxiques comme le monoxyde de carbone : les mineurs transportaient un canari dans une cage, et si la concentration de gaz toxique devenait trop élevée, le pauvre canari tournait de l’œil ; mais comme les canaris sont plus sensibles que les humains, cela arrivait avant que les mineurs ne soient affectés, et leur laissait donc le temps de faire demi-tour pour revenir en sécurité.

Une canary release est une release qui n’est exposée qu’à un petit nombre d’utilisateurs. Au lieu de faire basculer l’intégralité du trafic sur la nouvelle version, on n’en fait passer qu’une partie. Selon les cas, ça peut être une fraction des requêtes, ou bien seulement les requêtes de certains utilisateurs, par exemple. Puis, on observe attentivement ce qui se passe pour ces requêtes (ou ces utilisateurs). Si tout va bien, on peut faire passer tout le trafic sur la nouvelle version (ou même augmenter de manière progressive). Si nos métriques nous indiquent que les taux d’erreur ou la latence sont plus élevés sur la nouvelle version, ou bien que les utilisateurs nous remontent des problèmes, on revient à la version originale — et ce faisant, on n’a impacté qu’une toute petite fraction du trafic (ou des utilisateurs) ; la plupart n’ont même pas vu le problème survenir.

Ces procédés ont été largement décrits par des organisations comme Netflix par exemple, ou encore Facebook. C’est d’ailleurs comme ça que Facebook a pu abandonner le slogan « move fast and break things », et ne garder que la partie « move fast ».

[2] Dans un blue green deployment, lorsqu’on déploie une nouvelle version, on déploie un nouvel ensemble de serveurs (l’ensemble green) pour remplacer l’ancien (le blue) ; puis, on bascule tout le trafic d’une stack à l’autre. Un peu comme si on changeait d’un seul coup le signal d’aiguillage d’une voie ferrée, mais au niveau de nos load balancers. En cas de problème, tout ce qu’il y a à faire, c’est rebasculer vers l’ancienne stack.