La communauté d̶e̶ ̶l̶’̶a̶n̶n̶e̶a̶u eskerienne à Devoxx 2022 — épisode 1

Esker était présent pour la dixième édition de Devoxx à Paris. Pour cette édition spéciale, les organisateurs ont mis les petits plats dans les grands et ont assuré une logistique et un planning sans faille !
Nous étions 5 Eskerien⸱ne⸱s à aller de conférence en conférence, mais ce n’était pas suffisant pour pouvoir suivre les 8 présentations qui avaient parfois lieu en même temps ! Voici donc nos impressions sur ce qui nous a le plus marqué.

Cet article sera divisé en deux parties. Dans la première, nous laissons le clavier à Naima et Simon. Naima travaille dans une équipe DevOps dont le rôle est d’assurer la scalabilité et la performance de notre infrastructure Cloud tout en industrialisant sa gestion. Simon fait partie d’une équipe fonctionnelle en charge de nos solutions SaaS.

Les conférences que nous avons préférées

Naima : Micro Frontends REX — Diviser pour mieux régner !

Hugo Chiavenuto — Solution Architect chez Lombard Odier

Le système d’information de Lombard Odier a connu une refonte des plus belles. Partant d’un système legacy avec une stack technique qui inclut entre autres du Delphi, ils ont mis en place une architecture micro-frontend en se basant sur la fonctionnalité de fédération de modules de webpack et le framework Angular.
On retrouve dans cette architecture deux applications (bundles): une application Host (Shell ou Container), qui va déterminer à quel moment les composants de la page web vont être chargés (lazy loading) et une application Remote, une librairie de composants, qui contient et expose les différents widgets core et design qui vont être consommés par l’application Host. Tout ceci est rendu possible grâce au “Module federation” de webpack. Un “global store” est partagé par les composants / widgets, et leur permet de communiquer entre eux. Ainsi, il n’ont pas à connaitre l’existence des autres composants et seuls les changements que ceux-ci apportent au store sont utilisés.
Finalement, après s’être aperçu que l’application Host ne faisait que spécifier la position d’un composant sur une vue de l’application, l’approche déclarative a semblé plus adaptée. Une page est découpée en cellules et un fichier Json suffit ainsi à décrire le layout d’une vue.

L’architecture de Lombard Odier présente beaucoup d’avantages et leur a permis, entre autres, de rendre leurs applications personnalisables. Nous avons choisi une approche similaire pour notre framework développé chez Esker. Un client peut ainsi créer la vue qui lui convient en sélectionnant et positionnant les composants à l’aide d’un simple drag and drop depuis la bibliothèque.
La modernisation de nos applications chez Esker commence aussi à prendre le chemin d’une architecture micro-frontend. En effet, à côté de notre framework front développé en interne, qui contient un ensemble de composants écrits en vanilla JS, nous avons commencé à créer des micro-frontends séparés pour certaines parties de nos applications, tels que des dashboards en React.
Le chemin est long, mais ce REX a été très inspirant dans le cadre de nos réflexions autour de la modernisation progressive et continue de nos outils et de notre stack technique.

Simon : Et si les micro-services n’avaient rien à voir avec la technique ?

Yves Brissaud, Senior Software Engineer chez Docker Inc.

Chez Docker, ils sont experts sur les micro-services depuis un bon moment. Alors, ils commencent à remarquer que ce ne sont pas seulement les aspects techniques comme le nombre de lignes de codes, ou la taille du micro-service qui comptent, mais aussi bien l’organisation des équipes, et la manière dont elles communiquent.
En effet, selon la loi de Conway : « les organisations qui conçoivent des systèmes […] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. ». Ainsi, les micro-services seront bien architecturés et feront la bonne taille, si et seulement si les équipes qui les développent sont elles aussi bien définies, comprennent le bon nombre de personnes, et ont des interactions logiques avec les autres.
Il existe des boîtes à outils qui tiennent compte de cela pour mettre en place une organisation performante et des interactions constructives. En les appliquant, on peut donc obtenir une couche logicielle efficace. Le site https://teamtopologies.com/ présente ces outils via des schémas d’organisations typiques qui sont en cours d’implémentation chez Docker. On peut par exemple définir les équipes qui vont plutôt délivrer les fonctionnalités, ou celles qui vont aider les autres, en leur donnant accès à la plateforme, à des APIs, ou à des calculs complexes ou du machine learning pour les aider dans leur besoin. Les équipes vont donc pouvoir créer un logiciel correspondant à leur structure.
Chez Docker, redéfinir la structure des équipes en utilisant ces outils a permis deux choses importantes.

• La première est de baisser la charge cognitive de chacun dans l’équipe. Cela a été rendu possible par la dynamique d’équipe créée, qui lui permet d’assumer la propriété de tâches complexes. Par exemple, dans la chaîne d’intégration continue (CI), qui va se charger de la build quand elle est rouge ? Cette question n’est actuellement pas élucidée dans toutes les entreprises.
• La deuxième chose est donc de créer un logiciel qui va correspondre à leur structure, et il est maintenant plus simple de trouver l’équipe à contacter en cas de bug sur l’un des micro-services. Contrairement à avant, les équipes avaient des noms de code qui ne disaient pas ce qu’elles faisaient. Pour une question sur un sujet en particulier, il était difficile de savoir à qui s’adresser, avec de nombreux rebonds et perte de temps possibles.

Pour donner quelques exemples de topologies proposées dans la méthode “Team Topologies”, voici quatre équipes types :

• Stream-aligned teams : elles sont dédiées aux features à délivrer rapidement aux clients et se concentrent sur un segment métier en particulier.
• Enabling teams : elles apportent leur support aux autres équipes, les aident à implémenter les nouvelles technologies par exemple.
• Complicated sub-system teams : elles sont là où une expertise spécifique est requise. Elles ne font pas de livraison de feature client, mais fournissent aux stream-aligned les calculs mathématiques complexes (ex : trajectoires drones, base de données spéciale), pour qu’elles développent leur application.
• Platform teams : elles fournissent en interne les services pour que les stream-aligned teams puissent continuer à livrer leurs fonctionnalités avec un bon niveau de service. Cela passe souvent par la mise en place d’APIs qui peuvent être utilisées en toute confiance afin de réduire la charge cognitive des autres équipes.

Les schémas ci-dessus illustrent les différents types d’équipes et les interactions qu’elles peuvent avoir dans le cadre du développement logiciel.

Finalement, la taille et la communication entre les micro-services ne doivent pas répondre à une règle technique arbitraire, mais plutôt refléter l’organisation entre les équipes. Ici nous avons vu des patterns d’équipes types qui peuvent s’appliquer dans n’importe quelle entreprise éditant un logiciel en mode Agile. Bien sûr, ces méthodes nécessitent d’être mises en place progressivement, et d’être adaptées au fur et à mesure. Globalement, cela permet de casser les silos entre les équipes, de faire primer le collectif sur les individus et de réduire la charge cognitive de chacun, pour une meilleure collaboration afin d’atteindre l’objectif commun.

Naima : Ciel ! Mon Kubernetes mine des bitcoins !

Denis Germain — Lead tech SRE chez Deezer

Kubernetes est devenu un indispensable du déploiement de services et d’applications. Utilisé par de plus en plus de monde, Denis Germain, nous a présenté quelques pièges à éviter pour assurer la sécurité de nos clusters, avec des exemples de cas réels constatés dans le monde tech. En voici quelque uns :

• Prendre garde aux interfaces graphiques de management : ne pas déployer la console Kubernetes si on n’en a pas besoin et si elle est déployée, ne surtout pas l’exposer sur internet.
• Ne pas exécuter un container avec un compte administrateur
• Remplacer Pod Security Policy (Déprécié) par Open Policy Agent ou Kyverno
• Analyser les images Docker, car les images de base sont remplies de failles
• Ne pas inclure dans les images des outils utiles aux attaquants (même pas de shell !)
• Faire des audits, des scans de vulnérabilité…

En résumé :

Une check-list que nous sommes ravis d’avoir pour nos débuts dans le monde de Kubernetes. La sécurité est primordiale pour toutes les entreprises, qui plus est chez Esker, puisque notre plateforme SaaS héberge des millions de documents stratégiques.

Simon : Doctolib a besoin d’une base de données plus puissante. Ok, mais laquelle?

Bertrand Paquet, Senior SRE & David Gageot, Chief Architect chez Doctolib

Chez Doctolib, la “boring architecture” est au cœur du design de l’application. Il s’agit de garder la simplicité maximale pour toutes les couches logicielles. Ainsi, le système fonctionne depuis plusieurs années avec une unique base Postgres, mais qui atteint les limites des serveurs disponibles sur AWS. Elle utilise en effet de l’ordre de 1300 CPUs virtuels et 10 000 gigas de mémoire.
Etant donné le caractère très privé des données gérées par Doctolib, la base de données au début sur Heroku a dû être migrée sur AWS EC2, puis sur Aurora. Mais aujourd’hui, les tests mensuels qui visent à voir à quel horizon la base de production ne tiendra plus tirent la sonnette d’alarme. En particulier avec la prise de RDV pour la vaccination Covid-19 en France, la plateforme a vu son usage décuplé et ses performances mises en danger. Deux options étaient alors possibles : augmenter la taille de la base de données par 10, ou découper la base. Malheureusement, Doctolib utilise déjà la plus grosse instance possible d’Aurora. Ils ont donc pensé à utiliser d’autres déploiements de bases de données proches de Postgres comme Spanner, Yugabyte, Citus MX et Vitess. Ces options n’ont pas été satisfaisantes pour couvrir les besoins de Doctolib. Ils ont donc décidé de splitter la base de données, avec des astuces techniques.
C’était intéressant de voir le processus de choix bien défini, avec la validation à chaque étape, comme les tests unitaires, la validation des schémas ou les tests de charges par exemple…. La méthodologie avec laquelle ils ont basé leur étude était bien construite et a permis de ne pas partir sur un candidat alternatif à Postgres les yeux fermés, ou sur des promesses marketing, et de constater plus tard que l’outil choisi ne suffisait pas.
De même chez Esker, le choix des bases de données est un élément crucial. Il en va de la performance globale de la plateforme, car il s’agit souvent du facteur limitant lorsque de nombreux clients y sont connectés, ou en début de mois quand de nombreux documents sont traités. Nous avons fait le choix d’une architecture mixte entre Postgres et Elasticsearch pour répondre aux différentes requêtes de manière optimisée. Nous avons aussi déplacé des groupes de clients dans des shards différents pour répartir la charge sur plusieurs serveurs de bases de données.

La suite !

La suite arrive bientôt, restez à l’affût !