Technozaure Lille 2021 : récapitulatif des conférences

C’est l’automne, et à la saison où les feuilles tombent, Zenika Lille fait sa Technozaure.

Cette fois-ci, neuf présentations de nos talentueux collègues sont venues nous réchauffer comme une bonne soupe de potirons. Récapitulatif :

Deno?

C’est un nouveau runtime JS et TS, basé sur node, mais sans la gestion de packages, avec plus de sécurité et de compatibilité web, ainsi que le support de Typescript. En effet, pour les auteurs de deno, quelques choix de Node étaient discutables : l’absence de promises, la mauvaise gestion de la sécurité, le fichier package.json, les node_modules et le require(“module”) sans “.js”. Dans Deno, on quitte l’univers NPM. On peut donc exécuter du code depuis n’importe quel serveur. L’importation d’URL directement dans le code peut être vu comme une faiblesse mais npm connaît aussi son lot de pb ( par ex New NPM library hijacks (coa and rc) ). Par ailleurs, les fonctionnalités dangereuses de sécurité (comme par exemple l’accès à une URL quelconque) sont en opt-in, grâce aux flags –allow-* de la ligne de commande ou en demandant la permission pendant l’exécution. La ligne de commande permet, en plus de la création de bundle, de créer des exécutables compatibles avec Windows, par exemple. Et en plus le logo de Deno est un joli petit dinosaure, alors comment résister !

De 0 à 100 avec Accelerate

Comme Accelerate est le résultat d’une étude scientifique (basée sur l’enquête annuelle State of DevOps), les résultats ne sont pas forcément très lisibles (même si le livre fait déjà un bel effort de vulgarisation). Sébastien et Nicolas ont donc décidé de filer la métaphore des compétitions cyclistes dans cette présentation.

Accelerate est donc le résultat d’une étude scientifique basée sur le State of DevOps qui analyse les facteurs permettant de distinguer les organisations capables de bonnes (ou de mauvaises) performances dans la livraison logicielle, afin de segmenter les niveaux de performance.

En parlant de performance, comment distingue-t-on le cycliste qui se paye le bon matériel, la bonne tenue, de celui qui est vraiment bon ? C’est la compétition qui va permettre ça : en se mesurant à d’autres dans des courses de plus en plus difficiles (les critériums, les classiques comme le Paris-Roubaix, les grands tours), le cycliste pourra évaluer son niveau de performance.

Pour les organisations, il y a des tonnes d’indicateurs de performance. Concentrons-nous sur la production de logiciels. On a historiquement utilisé des indicateurs assez médiocres :

• Le nombre de lignes de code produites ( que l’on considère de plus en plus comme une dette)
• La vélocité (pas terrible, parce que basé sur des estimations … aléatoires et soumises à des biais de vérification)
• Les KPIs sur l’utilisation d’une fonctionnalité (là aussi soumis aux biais liés aux performances intrinsèques de la fonctionnalité)

Accelerate propose, en lieu et place de ces indicateurs, 4 indicateurs “globaux” fortement corrélés : 

• Batch size (Fréquence de déploiement – élite : plusieurs fois par jour
• Lead time to delivery (Durée entre le début du travail sur une story et sa livraison en production – élite : moins d’une heure)
• Time to restore service (Durée nécessaire pour rétablir une situation stable en production, après une avarie – élite : mois d’une heure)
• Change failure rate (Taux de déploiement ratés – élite: entre 10 et 15%)

Accelerate segmente les organisations selon leur capacité à maintenir des valeurs élevées pour ces indicateurs. Toutefois, comme il n’est pas utile de motiver les cyclistes en leur ordonnant de gagner des courses, il ne faut pas viser à améliorer directement ces indicateurs, mais plutôt à permettre leur amélioration par des actions connexes sur des leviers ( que l’on appelle capabilities) variés.

On distingue plusieurs catégories de levier

• Continuous delivery capabilities (délivrer de la valeur rapidement)
• Product and process capabilities (expérimenter, répondre aux besoins)
• Lean management capabilities  (optimiser la chaîne de fabrication)
• Cultural capabilities (culture d’entreprise)

Travailler sur ces leviers va améliorer les performances, encore faut-il avoir un bon niveau de base pour chacun. Détaillons les prérequis pour chacun de ces leviers

La performance dans la livraison logicielle n’est possible que si ces différents leviers sont actionnés, avec des effets bonus : la culture organisationnelle, la satisfaction au travail, la performance organisationnelle, la diminution des burn outs, la fierté des équipes, et la réputation de l’organisation.

Spirale dynamique, le modèle darwinien de la conscience

Laetitia nous parle des concepts théoriques sous-tendant une formation d’Alignance qu’elle a reçu récemment sur la spirale dynamique.

L’objectif de ce parcours de formation est de mieux s’accepter et comprendre les relations humaines en comprenant mieux les valeurs guidant les décisions des individus.

Il s’agit d’une évolution faisant dialoguer le personnel et le collectif. Cette représentation est pertinente que l’on considère l’individu, ou une collectivité, une entreprise. On peut voir cette spirale comme une évolution dans le temps (dont la vitesse dépend évidemment de la maturité des personnes, des collectivités).

Cette spirale permet de mieux comprendre les personnes et où elles en sont. Elle permet aussi de mieux dialoguer et de se comprendre. On constate notamment que les entreprises se situent souvent au niveau de l’ordre (d’où une certaine difficulté pour les agilistes).

Archi hexa : adaptez-vous, ne soyez plus un port

À quelles problématiques doit répondre une architecture moderne ?

• ne pas dépendre d’un framework
• séparer la technique du métier
• tester le métier (pas les dépendances)
• l’UI change indépendamment du métier
• changement de techno indépendamment du métier

Le modèle classique Controller > Service > Repo (chaque couche appelle la suivante) n’est pas adapté car le code métier se retrouve dépendant du repository, qui est une implémentation technique (et dépendant de l’implémentation du stockage). L’architecture hexagonale vise à inverser cette dépendance pour rendre le code métier central tout  en l’isolant des implémentations de stockage.

Le code métier expose donc des ports pour l’extérieur (sous forme d’interfaces Java). Ca a plein d’avantages : limitation du couplage, capacité à changer d’infrastructure, et test, tout ça simplement en changeant les dépendances des modules

Chez leur client, Roman et Sébastien ont dû travailler sur une appli avec plusieurs partenaires pour le paiement (1 par moyen de paiement – paypal etc). L’archi hexa a permis la multiplicité des adaptateurs sans avoir de contrainte technique côté paiement, car le même code méditer est réutilisé. Ça permet par exemple de rajouter un provider de paiement sans toucher au code métier et de découper les US en tâches client / métier / infra, mais aussi de se focaliser sur les tests du domaine.

Les points à retenir :

• Isoler le code métier est une bonne idée
• C’est une bonne idée quelle que soit la taille de l’appli
• Il faut avoir du code métier, c’est-à-dire que ça ne s’applique qu’aux applications où changer la technologie d’appli ne change pas la raison d’être

Qu’es aquo Keda

Dans Kubernetes, habituellement, on déploie une charge de travail afin de mettre un service à dispo des users. Et faire du scaling c’est simple, dans les cas simples. Alors pourquoi ne pas passer à du scaling intelligent ? 

Dans le reste de la présentation, Logan va utiliser l’exemple d’un restaurant ouvert le midi  pour 200 couverts avec 3 postes de travail en salle:

• accueil
• commande / service
• payment

Combien faut-il d’employés en salle ?

On démarre avec une première démonstration, qui montre que se baser uniquement sur le CPU du pod n’est pas suffisant (on réagit trop longtemps après l’arrivée des requêtes). Se baser sur le nombre de requêtes entrantes c’est mieux, mais ce n’est pas encore optimal. Dans les deux cas, on constate que la scalabilité est réactive, et pas anticipée. Alors comment anticiper ?

Avec Keda (Kubernetes Event Driven Autoscaling) qui se base évidemment sur un opérateur k8s. Avec ça, on peut scaler en utilisant les données d’utilisation.

Pour ça, on utilise un connecteur postgres avec Keda où la requête SELECT COUNT FROM CUSTOMER_ARRIVAL WHERE arrivaltime >= now – 30 sec AND arrivaltime <= now – 20 sec permettra de scaler les conteneurs. Avec ça, on obtient une satisfaction client à 100 % commandes et paiement… Mais on reste clairement mauvais sur l’accueil, certains clients font même demi-tour. Pour anticiper leur arrivée, on peut se baser sur l’historique du service précédent, donc une requête sur la fréquentation d’hier (SELECT COUNT FROM CUSTOMER ARRIVAL WHERE arrivaltime >= now -15 min – 30 sec AND arrivaltime <= now -15 min + 30 sec) maintient le même niveau de satisfaction en permettant plus d’entrées dans le restaurant.

Et avec Keda, on peut aussi rendre des pods dormants (comme avec kidle) pour faire des économies lorsqu’il n’y a pas d’activité.

Et en fait, le mieux, c’est de combiner les 2 (anticipatif + réactif) pour avoir un scaling :

• Simple
• Optimisé
• Anticipatif
• Tolérant
• Économique

L’art de donner du feedback

Antoine nous présente un outil pour faire des bons feedbacks utiles et efficaces. Qu’est-ce qu’un feedback ?

• Il nourrit en retour
• Il permet à celui qui le reçoit, de se construire et progresser
• Il doit être rapide et structuré

Ça implique deux dimensions 

• Dimension Humaine : respect et reconnaissance
• Outil de régulation : savoir si on avance dans la bonne direction

Antoine nous rappelle que dans un bon feedback, on utilise le “Je”, et on bannit le “mais” (car tout ce qui est avant est omis par le destinataire)
Antoine nous propose d’adopter le perfection game, une formule qui se révèle efficace et facile à utiliser :

Games of nodes ou comment fonctionnent les systèmes distribués

Dans une application classique, il y a une base Oracle, donc un seul serveur. Mais quand elle grossit, on est obligé de passer à un mode répliqué, qui marche moins bien.

C’est pour ça que le NoSQL a été créé (pour rappel, ça veut plutôt dire Not Only SQL). Généralement, les produits NoSQL couvrent 20% des features SQL classiques, mais y ajoutent une killer feature.

Et c’est le moment de parler du théorème CAP qui dit que des trois propriétés

• consistency : on a toujours la dernière info partout
• availability : toutes les requêtes ont une réponse
• partition tolerance : aucune panne n’empêche de répondre

On ne peut en avoir que deux en même temps.

Une base SQL va fournir availability et consistency – mais pas de partition (tout ou rien sur un serveur)

Cassandra ou le dns fournissent availability et partition tolerance – mais pas toujours la dernière info

MongoDB fournit consistency et partition tolerance – toujours la dernière donnée sur tous les noeuds, on peut perdre des noeuds mais pas forcément de réponse (revient plus tard)

Autrement dit

CA = d’accord avec soi même

AP = dire n’importe quoi à tout le monde

CP = mettre tout le monde d’accord

RAFT est un protocole qui respecte les deux contraintes CP que Delphin et Alexandre ré-implémentent dans la suite de la présentation (et c’est vraiment impossible à retranscrire).

Utiliser WASI pour déployer du code pendant le runtime

Rémi nous présente une expérience réalisée dans son projet. Le but est d’aider les clients quand ils ont des idées de travaux. On essaye dans ce cas de budgéter l’idée. 

Il y a déjà eu 2 versions majeures de leur code, avec 12 estimateurs différents et beaucoup de règles métiers. Comme il s’agit d’un projet monorepo (incluant front, back, déploiement), le déploiement du code métier est parfois limité par les refontes techniques. On est donc dans un cycle de vie inadapté aux évolutions métier. L’équipe a donc testé le déploiement de modules WASI implémentés avec TinyGo. Dans cette implémentation, ils ont rencontré des difficultés (comme par exemple la sérialisation) sans pour autant avoir d’impact positif sur les performances (ce qui n’était en fait pas un objectif). Finalement, l’idée a été mise de côté car bien que ça fonctionne comme attendu, la mise en œuvre en Go était trop lourde, et les gros points positifs de Wasm ne servaient en fait pas. Dans d’autres écosystèmes/d’autres projets, l’idée reste intéressante à tester.

TZ Wasi

Créer un opérateur Kubernetes en Golang

Dans Kubernetes, il y a des contrôleurs et des opérateurs. Un opérateur, c’est un contrôleur avec du savoir humain. Étant donné que nous allons en créer un, il nous faut un peu d’outillage : en l’occurrence, kubebuilder basé sur controller-runtime / controller-tools (il existe une alternative, operator-sdk).

Il faut d’abord installer kubebuilder, puis faire un scaffold. Chaque objet est référencé via un triptyque Group, Version, Kind (présent dans les fichiers .yaml).

Une API a une partie metadata avec le GVK, une section spec, et une section status.

La commande kubebuilder create api crée un fichier go dans lequel on définit les types.

La CRD (custom resource definition) est générée automatiquement (grâce au make manifests).

k8s gère ses ressources via une boucle de réconciliation : 

• Read
• Reconcile
• Repeat

Il faut implémenter l’interface Reconcile pour y ajouter cette logique.

Il reste à coder la gestion des ressources associées à notre nouveau type. Le finalizer permet d’effectuer des actions de nettoyage quand la ressource est supprimée. Le manager est responsable de déclencher la réconciliation en écoutant les événements sur la ressource, sur les childs resources créés (owns) et sur d’autres resources (watch). Il est possible de tester en BDD avec Ginko et Gomega.

Lors du déploiement, il faut gérer finement les RBACs de cet opérateur.