Retour sur la conférence Cloud Nord 2023

Écrit par Martin

Dans mon article sur la fusion de state terraform, je vous avais laissé sur votre faim en vous promettant un article sur la Cloud Nord 2023.

Cloud Nord 2023

Le nom de la conférence pose le tableau, cette 3ème édition se déroulait à Euratechnologies avec au programme tout un tas de conférences couvrant des sujets variés : infrastructure as code, packaging d’applications, IA, Kubernetes, API.

Un agenda alléchant et pour lequel nous avions des attentes élevées, en espérant notamment avoir droit à des sujets bien techniques.

Avec Jonathan et Nicolas, nous nous sommes donc répartis les conférences pour en couvrir un maximum de sujets.

Ouverture

Après quelques aléas techniques, Sébastien Blanc, nous a retracé quelques étapes clés de l’informatique en s’appuyant sur un vieux livre « Silicon Valley ».

Il était amusant de découvrir les opinions de l’époque au travers de ce livre publié aux balbutiements de la tech. À cette époque les GAFAM n’en étaient pas encore, Cisco était une petite boite en devenir et on parlait déjà d’IA !

L’occasion de nous rappeler que les tendances dont on entend parler tous les jours prennent vie après des années ou des dizaines d’années de travail et ne sortent pas de nulle part.

La transformation en commodité de l’intelligence artificielle se fait par contre à un rythme infernal et Sébastien a pu le prouver en déployant dans le cloud une application embarquant un moteur d’IA capable de répondre à cette question fatidique : « Le welsh vient-il de Lille ?». On ne polémiquera pas sur la réponse apportée, l’IA a encore du chemin à parcourir 😊.

Refactoring Terraform

Terraform étant un nos couteaux suisses du quotidien Devops, j’étais curieux d’entendre ce retour d’expérience.

Je n’ai pas été déçu, la présentation d’Arthur était très bien maitrisée, vivante. Mention spéciale aux slides, avec un support très lisible.

Cette présentation était un condensé de retour d’expérience pour maintenir un code Terraform propre et bien organisé.

Cela passe par l’étape fatidique du refactoring et du déplacement de ressources associées. Une des solutions proposée par Terraform est l’usage de directive moved. Toutefois, sur des states un peu volumineux, leur écriture manuelle peut vite s’avérer fastidieuse.

Arthur a donc introduit son propre outil tfautomv dont l’objectif est de générer automatiquement ces directives. Il fonctionne en comparant les ressources 2 à 2 pour définir une correspondance entre source et destination. À coup sûr un outil à tester dès que l’occasion se présentera.

La présentation ne s’attardait pas que sur cet outil mais également sur des bonnes pratiques et des conventions mise en place par le présentateur et son équipe.

Entre autre, une directive à laquelle j’adhère consiste à garder ses modules racines légers en évitant de repasser l’intégralité des variables en top down.

Une astuce proposée consiste à utiliser des modules « purs » utilisant les outputs pour ré-import en tant que constante dans d’autre modules.

Un très bon talk, technique et concret, comme on les aime.

Continuous Container Checkup

Cette présentation était organisée comme un jeu de rôle entre d’une part un développeur peu consciencieux (en mode je déploie mon app et je ne m’en soucie plus) et un autre développeur orienté run.

Les deux intervenants d’Ubisoft voulaient nous présenter leurs tableaux de bord maisons conçus avec Grafana et remontant des métriques sur l’état de sécurité des applicatifs tournant dans leur cluster.

En agrégeant les résultats de tout un tas d’outils (syft, endoflife.date, ecosystems, grype, openvex…), ils ont pu collecter les informations nécessaires pour donner des indicateurs de santé sur chacune des images tournant dans leur cluster.

Couplé à la puissance de Grafana, on obtient une information très lisible (car graphique) avec des possibilités de filtrage puissantes.

L’outil est très intéressant de par sa portée globale, on collecte l’information dans la zone d’exécution, ici Kubernetes, ce qui permet d’analyser n’importe quel projet qu’on viendrait déployer, quelle que soit sa topologie.

Les équipes ont prévu de l’open sourcer sans toutefois donner de date, on attend ça avec impatience.

Composants internes de Kubernetes

Après la pause déjeuner, on rattaquait avec la présentation de Denis Germain sur les composants internes de Kubernetes.

Très didactique, la présentation déroulait une installation de Kubernetes (en 1.27 alpha s’il vous plait 😊), composant par composant : etc, scheduler, controller-manager.

Le fait que le déroulé de la démo soit assez simple (la plupart du temps exécuter les binaires), montre à quel point l’architecture de Kubernetes est bien pensée et orientée composants ; chacun ayant son propre périmètre de responsabilité mais pour autant indispensable au fonctionnement de l’ensemble de la chaine.

Au passage, c’était l’occasion de reparler de Cilium (utilisé en tant que CNI) et d’eBPF (sur lequel s’appuie Cilium) dont on aura l’occasion de reparler sur le blog.

Un mot a également été dit sur les objets de type Gateway API (à ne pas confondre avec API Gateway), qui devrait à terme prendre le pas sur ceux de type Ingress.

L’intelligence artificelle expliquée en 20 minutes

Sans transition, me voilà dans une salle bondée pour assister un speed talk sur l’IA.

Stéphane, développeur, nous a présenté l’IA sous l’angle de ce qu’il en a compris au gré de ses investigations et tests.

La présentation situait les différents types d’intelligence artificielle (ANI : artificial narrow intelligence, AGI : artificial general intelligence, ASI : artificial super intelligence).

L’occasion également de rappeler que l’intelligence artificielle ne peut pas partir de rien et que la qualité des données en entrée est l’un des éléments clés. Sauf que ces données sont souvent qualifiées par des … humains.

L’IA est d’ailleurs capable de fonctionner en mode supervisé et non supervisé. Dans le premier cas, elle sera guidée par l’humain pour confirmer ou infirmer ses « choix ». C’est notamment ce qui permet l’apprentissage par renforcement.

En non supervisé, l’IA va tenter de découvrir des patterns (les objets qui ressemblent à des voitures sont sûrement également des voitures). Ce mode est intéressant pour pré-qualifier et segmenter des gros volumes de données existants.

Sur les aspects de type « Comment ça marche ? », on se rend compte que l’IA se base principalement sur des approches probabilistes en convertissant les données d’entrée en vecteur mathématiques.

C’est aussi ce qui explique que les calculs soient bien plus performants avec des GPU, conçus pour traiter ce type d’information, qu’avec des CPU.

Créer des règles d’autoscaling efficace avec Kubernetes

Pour cette présentation en forme de REX on retrouve Henrik Rexed, déjà croisé lors de sa présentation « L’art de l’observabilité avec Open Telemetry ».

Cette fois, il s’agissait d’un retour d’expérience d’une approche FinOps. Au-delà de présenter des outils d’optimisation il s’agissait avant tout d’analyser des problématiques de performance dans le cadre d’une réduction de coûts.

Opencost a bien sûr été un des points d’entrée dans l’analyse des ressources mais finalement pas le centre de cette présentation.

Il s’agissait avant tout de comprendre comment optimiser l’usage des ressources. Lors de la livraison d’un projet, un réflexe naturel est de surdimensionner les ressources pour garantir un fonctionnement optimal et d’optimiser ensuite (quand on n’oublie pas de le faire !).

Pour maximiser son taux d’usage dans un contexte Kubernetes, il s’agit d’avoir un nombre de pod adapté à la charge et capable de scaler automatiquement.

Kubernetes dispose évidemment d’une API pour la partie HPA (horizontal pod autoscaling) mais avec un nombre de métriques assez restreint : CPU et mémoire.

Henrik nous démontre avec un exemple concret que ces métriques peuvent s’avérer insuffisantes, notamment lorsqu’on a posé des limites sur ses ressources. Dans son cas, le CPU des nodes sur lesquelles tournait l’application était la plupart du temps idle. L’occasion de relancer le débat sur l’intérêt des limites de CPU.

Il s’avère également que même lorsqu’elles sont intéressantes, ces métriques peuvent arriver trop tard.

L’autoscaling n’étant pas instantané, on veut idéalement que le dimensionnement s’anticipe autant que possible. C’est à ce moment que l’outil Keptn a été introduit. Celui-ci permet de disposer davantage de métriques en entrée pour prendre les bonnes décisions de scaling.

En l’occurrence, il s’agissait ici de s’appuyer sur le nombre de requêtes entrantes pour déterminer le dimensionnement à mettre en face.

Finalement une présentation très dense et bien rythmée avec un cas concret, on a adoré.

Documenter et standardiser ses API avec AsyncAPI

Lors de cette dernière présentation de la journée, Ludovic nous a parlé de son parcours avec Async API. Un projet qu’il utilise au quotidien dans le cadre professionnel et auquel il a directement contribué.

Async API est un standard très proche de OpenAPI, dans sa conception et sa documentation, à tel point que passer de l’un à l’autre n’est pas vraiment dépaysant.

Avec des API asynchrones on sort de la logique requête / réponse et on bascule dans une logique client / serveur avec des connexions qui peuvent rester ouvertes et des flux qui ne sont pas bloqués dans l’attente de la réponse.

On va donc plutôt utiliser des websocket ou du gRPC. AsyncAPI a l’ambition de devenir le standard de facto, en lieu et place de OpenAPI (tout un programme !). Ils ont récemment monté un partenariat avec Postman qui dédie un certain nombre de ses employés pour travailler sur le standard et son intégration dans Postman.

Lorsqu’on travaille avec des outils tels que OpenAPI ou AsyncAPI, il est préférable d’opter pour une logique « contract first » (vs code first).

En clair, on va prendre le temps en amont de définir le format de son API, les paramètres d’entrée, les formats de retour avant de travailler sur l’implémentation.

L’immense avantage de ce type d’approche est de faciliter la mise en place de mock et potentiellement parallèliser le développement de l’API et de son ou ses clients (qu’on en maitrise le développement ou non).

AsyncAPI permet l’exposition de schémas sous différents formats : le bien connu JSON schema mais également RAML ou Avro.

À noter que la version 3 de AsyncAPI est en cours de construction. Difficile de dire si on est proche ou non d’une finalisation, le dernier article annonçant une arrivée datant de mars 2022.

Au final, un sujet très intéressant et parfaitement maitrisé. Utilisateurs de longue date d’OpenAPI, nous allons nous pencher plus sérieusement sur AsyncAPI.

Conclusion

On en retiendra une journée enrichissante, des conférences très intéressantes et des présentations bien maitrisées.

Le superbe cadre d’Euratechnologies aura compensé le seul bémol de la journée : le manque de café !

On a hâte d’assister à la prochaine édition.