
Dans les coulisses
Clac ! Notre tech-stack
par Nicolas Lefebvre
Ils sont redoutés dans tout le développement logiciel de Digitec Galaxus et se nomment Team Q. Il s'agit de nos cinq architectes seniors. Mais leur quotidien n'est pas seulement marqué par les analogies avec James Bond, mais aussi par l'air chaud, le beurre et Kafka. Et ils cherchent un autre membre d'équipage.
Q, une lettre souvent utilisée actuellement. Mais chez Digitec Galaxus, ce n'est pas à cause du douteux employé du gouvernement américain. L'équipe Q doit son nom au spécialiste de l'informatique compétent qui a le sens de l'humour dans les derniers films de Bond. Q, c'est l'association des cinq Senior Architects de Digitec Galaxus, également appelés Domain Architects en interne. Le nom le suggère : L'équipe travaille selon les principes du Domain-Driven Design, afin de diviser notre système logiciel en contextes. Il y a par exemple le contexte responsable de l'achat de notre assortiment ou un autre pour la sortie des marchandises dans la logistique. L'avantage : si un développeur travaille dans le contexte de la sortie des marchandises, il peut être relativement sûr qu'il ne modifiera pas la logique dans les autres contextes. Si des modifications sont apportées aux interfaces, la prudence est de mise. En cas de modifications globales, les interfaces permettent d'évaluer quels autres contextes seront affectés.
La migration de notre ancien système monolithique fonctionnant dans Azure, avec un peu plus de 2 millions de lignes de code C#.Net Core et une base de données SQL de 1700 tables, vers un système distribué que nous hébergeons sur Kubernetes, a marqué le quotidien de l'équipe Q depuis plusieurs années. Nous appelons ce processus la modularisation. Dans l'image cible actuelle, le système est divisé en environ 40 unités verticalement intégrées, qui s'inspirent des modèles de microservices. Une équipe de développeurs est responsable de chaque unité, qui contient un ou plusieurs contextes.
L'équipe Q est physiquement répartie dans l'ensemble du département de développement logiciel. Le "sit-down" hebdomadaire (qui contraste avec le "stand-up" (ou daily) des équipes de développement) est cependant un point fixe du programme. L'équipe Q est encore un peu mystérieuse. Nous allons changer cela : nous allons vous montrer qui se cache derrière Q et quels sont les domaines d'activité des architectes seniors.
Notre architecte le plus expérimenté, Andreas, nous a rejoints quelques semaines avant le lockdown et a toujours une bonne réplique en réserve. De l'air chaud, mais quand même beaucoup derrière : Il s'est déjà attelé à plusieurs choses en si peu de temps, notamment à la création de la Guilde de la modularisation dans le domaine des boutiques en ligne (OSA). Cette guilde vise à promouvoir l'échange d'expériences entre les équipes. Il a également joué un rôle important dans la création de nos nouveaux rôles d'"architecte logiciel" au sein des équipes de développeurs et d'"ingénieur principal".
La pile technologique de l'OSA se compose principalement de C# .NET Core pour le backend et de ReactJs avec GraphQL entre les deux pour le frontend. Actuellement, Andreas s'occupe de développer notre propre framework UI et de rendre la boutique fonctionnelle indépendamment du reste du monolithe afin de simplifier le travail des développeurs. Les équipes sont responsables à la fois du back-end et du frontend de leur contexte.
Boško est à la fois le plus ancien et le plus jeune architecte de domaine. Il a commencé chez nous en tant que développeur de logiciels et est maintenant architecte responsable des opérations. Ces derniers mois, nous avons mis de côté la plupart des projets prévus à long terme (que nous appelons initiatives) afin d'adapter rapidement les processus à l'augmentation massive du volume des commandes due à la pandémie Corona. Boško est en contact étroit avec les équipes de développement afin d'éviter une dette technique excessive. Il assiste régulièrement à des meet-ups ; depuis des années, il participe aux SoCraTes Days. De plus, il a fait avancer l'idée de l'open source chez nous et a publié notre ProjectsRuler sur Github. Afin d'être bien positionnés sur le plan organisationnel pour la croissance prévue, nous divisons le domaine des opérations en deux secteurs. Nous recherchons un architecte de domaine pour l'une des deux divisions.
L'agenda de Mark est toujours très bien rempli : Il attache une grande importance aux échanges verbaux avec les équipes et à l'encadrement direct de leurs architectes de solutions. Une grande partie de son travail consiste à modéliser nos processus métier dans le domaine de la gestion des catégories et de la finance. Ceux-ci sont encore en grande partie implémentés dans le monolithe et doivent être répartis dans des contextes qui communiquent entre eux de manière synchrone ou asynchrone pour représenter les processus. Avant la pandémie, l'équipe Q se réunissait régulièrement pour des sessions de tableau blanc afin de travailler sur l'interaction des contextes dans de tels processus métier. À distance, c'est un peu plus compliqué, mais nous y travaillons. Un thème qui nous occupe particulièrement en ce moment dans ce contexte est celui des Sagas.
Olivier est chez nous depuis deux ans et demi. Au cours des trois premiers mois, il a consolidé les idées existantes et formulé la vision de notre architecture système distribuée. Il a ensuite pris en charge le développement de DataTransformer. Il s'agit d'une bibliothèque permettant d'envoyer les modifications de données du serveur SQL vers le bus de services Azure avec un délai de quelques millisecondes. Il a également écrit le Domain Modeler, dans lequel nous gérons notre Context Map. Olivier est architecte de domaine dans le domaine Platform et SysOps. Ce domaine est composé d'équipes de plateforme qui aident les équipes de développement des autres domaines à travailler de manière autonome avec la plateforme cloud. Nous nous préparons ainsi à une organisation DevOps flexible. Par exemple, l'équipe BlackJack gère nos clusters SQL Server et MongoDb. Team Bender ! est responsable du cluster Kubernetes et propose des outils tels que le "module de référence" comme modèle pour un microservice .NET Core standard avec connexion à AppInsights, Azure Service Bus, DB, etc. Grâce à ce modèle, nous pouvons déployer un nouveau microservice très facilement. L'automatisation des pipelines CI/CD dans Azure DevOPs soutient également ce processus. Nous renforçons également le bootstrapping et les fonctionnalités de base de nos microservices grâce à des packages partagés.
La plupart des services sont construits selon une conception inspirée de la Clean Architecture. Cependant, les feature teams peuvent définir elles-mêmes la conception de leurs services. Voici une représentation schématique:
En ce moment, Olivier s'intéresse beaucoup à Kafka. Nous souhaitons migrer une grande partie de notre pipeline de données vers Kafka, notamment pour mieux gérer les backfills. Parallèlement, il est fan de RavenDb et cherche toujours à l'utiliser. En vain jusqu'à présent : sur le Tech-Radar régulièrement mis à jour par Team Q, vous verrez avec quelles technologies nous travaillons.
Ces défis vous attirent et vous voulez construire l'avenir du e-commerce avec nous ? Vous trouverez ici notre poste ouvert.
En tant que premier développeur à plein temps de Digitec Galaxus, j'ai été chef d'équipe de Goldfinger et Bender! et chef de la guilde d'architecture (l'équipe A).
Actuellement mon quotidien consiste à développer, avec nos architectes de domaine, en permanence l'architecture système cible. Nous travaillons en étroite collaboration avec les équipes de développement pendant la mise en œuvre et formons le Conseil de révision de l'architecture.
À cause de mes ruptures d'élaboration de logiciel inimaginables et de déploiements de requins de piratage le vendredi après-midi, ils m'appellent aussi 🅷🅰🅲🅺🅴🆁🅼🅰🅽.