Retour sur le BreizhCamp 2019

Une fois n’est pas coutume, nous étions au BreizhCamp 2019 qui s’est tenu à Rennes. Le thème de cette année Ghostbuster a envahi les stands.
Je vous propose ici une retranscription d’une sélection de présentations de la journée du jeudi.

Micro Frontend: le casse-tête des microservices étendu au FrontEnd !

par Audrey Neuveu
Le constat posé par l’oratrice est que l’approche des microservices est, aujourd’hui, surtout dédiée aux développements backend. Alliées des microservices, les équipes sont constituées de peu de personnes et sont autonomes sur le choix des technos et le rythme des releases. Cela induit une coordination forte entre les services consommateurs et les producteurs ce qui n’est pas toujours aisé. L’idée est alors de passer du microservice backend au microservice backend + frontend : ainsi une équipe est en charge d’un périmètre fonctionnel cohérent intégrant aussi bien les services REST que l’UX et l’UI afin de gagner en autonomie et cohérence fonctionnelle.

Ce type de modèle est déjà présent sur les gros acteurs du net : Amazon et Ikea, par exemple, intègrent sur leur site plusieurs fonctionnalités principales comme le listing des produits et le checkout. Ces fonctionnalités sont réalisées par des équipes distinctes et s’intègrent dans la même application finale. C’est sur ce dernier point que la suite de la présentation porte : quelle stratégie utiliser pour intégrer des composants dans un front unique ?

Plusieurs pistes ont été explorées : webcomponent, agrégation de fragments React, intégration des composants sous forme de lib JS (Layout as Lib). Chacune de ces approches apporte son lot d’avantages et d’inconvénients : la problématique de bouchonnage des appels de service sur les postes de développeur est, par exemple, beaucoup plus simple à réaliser en Layout as Lib. Par contre, la cohérence visuelle est plus facile à réaliser avec les webcomponents, mais la gestion du routeur d’autant plus aisée avec les fragments React…
Au final, aucune bonne réponse, mais plutôt des recommandations en découlent : d’abord, penser aux use-cases puis à la technique, ne pas sous-estimer le design final de l’application et finalement bien partager les ressources et services.

Quand performance, scalabilité et robustesse bousculent vos habitudes de développement

par : Céline Gilet / Slides
Le projet décrit par l’oratrice est un nouveau système de comptabilité. Il doit répondre à une très forte volumétrie d’intégration et d’export de centaines de millions de données par jour. La présentation s’est orientée autour des enjeux de robustesse de la plateforme, réponse à la montée en charge et stratégie d’optimisation de performance. Le pipeline de traitement complet doit être capable de détecter une erreur d’un composant et relancer le traitement là où il a planté.
Parmi tous les sujets abordés, voici les 2 que j’ai retenus :
2 bases de données sont utilisées pour assurer d’un côté le suivi des traitements (base relationnelle) et l’intégration des données (base nosql, Cassandra). Cette 2ème base nécessite de penser les requêtes d’abord en lecture afin qu’une seule partition sur un unique noeud soit ciblée pour maximiser les performances. Le pattern “clean architecture” a été mis en oeuvre afin limiter les adhérences à la plateforme, aux bases de données, etc. Cette approche permet de changer la base nosql si les performances ne sont pas adéquates en réécrivant uniquement les mappers du domaine métier vers le modèle physique.
Les travaux d’optimisation de performances ne sont pas simples à illustrer lors des démos de sprint, néanmoins, l’oratrice insiste sur la nécessité d’impliquer le métier dans ces phases afin de bien leur faire mesurer les impacts. Pour mener à bien ces travaux, l’équipe n’a pas tout de suite automatisé les tests de performance, mais a itéré de nombreuses fois afin de maîtriser le périmètre, la plateforme, les jeux de données, etc. Pour le côté dev, l’approche choisie par le projet consiste non pas à valider les temps de traitement sur une volumétrie très importante, mais sur un échantillon stable. Le temps d’exécution est alors de quelques minutes ce qui permet de visualiser rapidement les gains ou pertes des évolutions réalisées.

Pour terminer, sur un projet de ce type, il ne faut pas tout changer d’un seul coup, mais procéder par étape afin de vérifier les impacts : par exemple, d’abord les optims de performances puis la scalabilité et enfin la robustesse.

De Java 8 à Java 11 sur un gros projet : les pièges à éviter

par Thomas Collignon, Alexis Dmytryk
La présentation illustre les différents points d’attention à prendre en compte lors d’une migration de Java 8 à Java 11, mais la première question est : qu’est-ce que va apporter Java 11 et quelle distribution choisir ? La correction des failles de sécurité est l’argument premier pour faire le saut, mais le choix de la distribution reste plus délicat. Il est encore trop tôt pour bien déterminer si le choix de ‘oracle openjdk’ ou ‘oracle jdk’ ou ‘adoptopenjdk’ est le bon et tout dépend de la stratégie de suivi des versions choisie par le projet…

Remarque : l’équipe a choisi de faire un passage intermédiaire en Java 10 pour limiter la casse.
La question de la formation des équipes de développement s’est posée : les évolutions en Java 11 n’étant pas aussi importantes qu’à l’arrivée de Java 8, il n’a pas été choisi de faire des sessions dédiées.
Pour cette migration, des problèmes ont été rencontrés à tous les niveaux et ont pratiquement tous eu une solution :

• les outils facilitant les impacts sur le code sont jdeps et java-almanac
• toutes les dépendances ont dû être montées de version
• coté outillage de tests, powermock et reflection sont 2 librairies non maintenues qui ont dû être changées
• des soucis importants de performance ont été constatés avec Eclipse notamment la construction de l’index qui est passée de quelques secondes à 45 minutes. Un patch a finalement été trouvé et est en cours de soumission afin d’améliorer la situation
• au niveau des serveurs d’applications, le produit tourne sur Tomcat et Weblogic. Autant la migration en Java 11 sur Tomcat a été triviale, autant sur Weblogic, même à vide, le serveur ne démarre même pas et aucun correctif / évolution n’est disponible pour le moment. Malgré un contact rapproché avec le support idoine, l’équipe a choisi d’abandonner le support de ce serveur d’application.

Jenkins-X : toward a cloud-native Jenkins

par Nicolas De Loof
Jenkins X est un renouveau du projet Jenkins, il ne s’agit pas d’une distribution Jenkins, ni d’un set de plugins ni un produit Cloudbees, mais bien d’une réécriture du moteur pour s’autoriser des breaking changes par rapport au produit actuel et pour prendre en compte des nouveaux paradigmes d’exécutions.
Jenkins et Jenkins X ont rejoint la fondation cd.fondation, issue de la linux foundation, dans un but de fédérer les pratiques CI / CD.
Afin de mieux comprendre la démarche de Jenkins X, l’orateur décrit une roadmap fictive d’évolution sur l’actuel Jenkins : 

• Phase 1 : réduire la dépendance vers le $HOME_JENKINS et ajouter une nouvelle api de persistance des artefacts au lieu de le faire directement dans les plugins avec un “new File(…)”
• Phase 2 : persister les données au niveau des noeuds au lieu de tout remonter sur le master
• Phase 3 : proxifier les appels des hooks pour limiter les appels à Github par exemple et autoriser une mise à jour du master sans perdre les notifications
• Phase 4 : isoler l’exécution des jenkinsfile dans des processus différents pour limiter l’impact de la sandbox (ndlr : adieu les @NonCPS ?)
• Phase 5 : externaliser la webui ou même ne plus l’avoir, car les logs d’exécution peuvent s’intégrer dans Github par exemple.

Le projet Jenkins X reprend ces différents points en s’appuyant sur Kubernetes et Prow pour la partie moteur d’exécution et intègre des descripteurs yaml en guise de Jenkinsfile.
La CLI de JenkinsX se charge de créer un cluster Kubernetes et modifie sa configuration via commits afin d’assurer la traçabilité, le tout dans une approche gitops. Le lancement d’un job, le suivi, etc. sont également réalisés avec cet outil.