Full Spectrum developer, une étude de cas

Il y a un terme qui me taraude aujourd’hui dans le monde du développement : full stack programmers. Ce terme me chiffonne, car il porte une forte connotation technique, et sa traduction littérale se résume trop souvent à savoir écrire une API Crud avec ExpressJS, et faire un front (web, mobile) devant. Il manque à mes yeux bien entendu tout ce qui n’est pas du code :

• le recul sur les technologies,
• l’analyse du métier,
• l’analyse du business ,
• la proposition de solutions ne nécessitant pas de code,
• les questions de déploiement,
• …

Heureusement, il y a toujours quelqu’un de beaucoup plus intelligent que moi pour donner un nom au concept : le full spectrum developers. Je vous invite à regarder la vidéo de Michael Feathers sur la question. C’est fait ? Bon.

Je ne prétends pas encore être au niveau de ce qu’il décrit, mais j’avais envie de décrire notre approche pendant notre collaboration avec Sud-Ouest sur sa nouvelle application mobile, pour donner un exemple plus concret.

Du full spectrum dans le cloud™

La mission

Pour bien démarrer, notre travail avec Sud-Ouest n’a pas commencé par répondre à une annonce classique du type «recherche dev expérimenté pour rejoindre une équipe», mais par un brown bag lunch, puis un restaurant, qui ont mené à cette lettre de mission :

Ne plus pousser le même Sud-Ouest pour tous les lecteurs, mais un Sud-Ouest par lecteur.

J’aime ce genre de définition : il n’y a pas de notion de solution, il n’y a pas de trace de technologie, juste un but.

Quelques contraintes

L’étape 2 est de définir tout de même certaines contraintes pour ne pas partir dans toutes les directions :

• seule l’application mobile devait adopter cette philosophie dans un premier temps,
• Sud-Ouest ne veut pas devenir info-gérant,
• l’application doit tendre vers du changement en temps réel, et des capacités offline
• étant donné que c’est une nouvelle manière de faire pour Sud-Ouest, il faut prendre en compte les impacts sur la manière de faire actuelle
• fluidifier autant que faire se peut les relations entre le développement et le reste de Sud-Ouest (journalistes, marketing, publicité)

Première preuve de concept

Comme d’habitude, il est difficile de prendre des décisions en début de produit, vu que c’est le moment où l’on en sait le moins. Étant donné ces contraintes, nous voulions monter rapidement une preuve pour découvrir un maximum de «unknown unknowns». Ce «poc», en revanche, avait pour vocation, s’il était validé, d’être notre base de travail future, donc hors de question de fermer des options ou de coder en mode quick and dirty.

Pour aligner tout le monde, toutes les personnes nécessaires à la réussite du projet ont été réunies dans la même pièce (UX, Développeurs, Journaliste, POs).

Bounded context

Mon premier réflexe, quel que soit le projet, est de tenter de dessiner la carte des bounded contexts (BC). Cela permet à la fois de ne pas mélanger tout son code métier dans un seul gros package qui ne pourrait que se dégrader avec le temps, étant donné qu’il mélange des responsabilités, mais également de choisir les bonnes approches et technologies pour chacun.

Mieux vaut un dessin qu’un long discours, voici cette carte :

Pour donner un peu de contexte : l’application va, in fine, recevoir des Cards à afficher sur l’accueil de l’utilisateur. La gestion des cards, leur contenu, et leurs options, est donc gérée dans le BC… Cards. Le contenu des cards étant très hétérogène (articles, météo, publicité, etc.), la gestion du contenu et de sa mise à jour est déléguée à un BC par source, s’appuyant bien sûr sur une bibliothèque commune. Pour faire une comparaison, ces Cards font plus à penser à Google Now (un raccourci pour accéder au contenu), plutôt qu’à Twitter (un flux infini d’articles).

Pour savoir quoi afficher, nous rentrons dans le domaine du Reader : son but est de capturer les intérêts d’un lecteur, de les pondérer, de les fusionner avec un certain nombre de cards par défaut.

Ce flux, ou stream de cards, est ensuite géré par Stream, qui va éventuellement y insérer d’autres éléments (publicité, card d’onboarding en fonction du parcours utilisateur, etc.).

Enfin, le BC Articles a pour charge de permettre de récupérer tout le contenu éditorial dont nous pourrions avoir besoin, et les notifications servent à prévenir les BC intéressés qu’il y a du changement dans Sud-Ouest qui mérite une mise à jour (nouvel article, nouveau commentaire, etc).

Pour doter chaque BC d’un langage métier correct, il faut ensuite enchaîner avec un certain nombre d’interviews et réflexions pour faire émerger tout ça.

Technologies

L’avantage d’avoir sa carte des bounded context, c’est qu’il est possible ensuite de choisir le style d’implémentation et les technologies pour chaque contexte. Petite note avant d’aller plus loin : encore une fois, en tant qu’adepte du Domain Driven Design, il faut résister à l’envie de se laisser piloter par des technologies qui brillent, s’appuyer au maximum sur des technologies plutôt stables et éprouvées, et ne choisir la nouveauté qui si vraiment, elle apporte un net avantage.

Le BC Article, en tant que BC de lecture seule, manipulant le MongoDB Sud-Ouest, a été implémenté avec NodeJS. Ceci dit, étant donné les transformations que nous voulions appliquer aux sources brutes, tcomb et une batterie de tests générés depuis des cas réels nous ont bien sauvé la mise.

Le BC des notifications est également un petit programme Node qui se contente de transformer les évènements Sud-Ouest pour les déposer dans Google Pub/Sub.

Les sources elles, ne sont souvent que de simples adaptateurs pour transformer un signal en un autre, intelligible par Cards.

Reader, Card, et Stream, étant donné que c’est là que se cache une bonne part de logique métier, ont été implémentés avec une architecture de type DDD/CQRS, mais sans event sourcing, qui n’avait pas l’air d’apporter grand-chose en terme business dans ce contexte. Java a été notre choix de langage également. Si on prend la peine de ne pas utiliser une once de JEE, Java est un langage mature, performant, stable, et massivement bien outillé (refactorings FTW).

Cards et Stream devant réagir à pas mal de sollicitations externes pour faire leur travail, nous sommes partis sur RxJava pour coller au mieux à cette philosophie. Pour appeler ça avec le terme à la mode, on peut parler d’architecture réactive : le système réagit à des stimulus externes plutôt que d’être interrogé à intervalle de temps régulier.

La volonté d’avoir les changements en temps réel dans l’application nous a très vite fait regarder du côté de Firebase real time database. Il fallait donc valider qu’il allait tenir ses promesses, tout en testant son intégration avec un autre choix : react-native. L’astuce, pour ne pas se laisser manger par firebase, était de le considérer comme une simple base de projection, et non pas comme le cœur des BC Reader, Stream et Cards. Il n’est donc qu’un détail d’implémentation.

Enfin, pour persister nos modèles d’écriture, nous avons fait également un choix assez conservateur, et utilisé du SQL classique, via Google Cloud SQL, manipulé via un modèle de persistance manipulé par Ebean.

Déploiement/Exploitation

Comme dit plus haut, une volonté très forte de Sud-Ouest est d’avoir à administrer le moins de machines possible, à juste titre. Naturellement, tout le monde pense à utiliser un fournisseur de cloud dans ce cas, mais la question suivante est PaaS ou IaaS ou… CaaS (container as a service). Le choix d’aller plutôt du côté de Google Cloud avait été plus ou moins fait avant mon arrivée. Restait à départager AppEngine et Google Container Engine (et donc Kubernetes). Pour faire court, et pour donner un avis très personnel : je trouve AppEngine Flex pas encore très pertinent, donc c’était plutôt Kubernetes + AppEngine Classic. À l’époque, classic ne supportait pas encore Java8, et encore moins Node, donc nous sommes partis vers GKE pour la flexibilité qu’il nous offre, surtout que nous avions déjà une expérience de la bête via feu jameshake.

Par extension, nous allions utiliser StackDriver, et Google Docker Registry.

Restait la question épineuse de déploiement continu, qui est hélas encore parfois problématique dans ce monde là je trouve, mais nous l’avons gardé pour plus tard, le temps de savoir comment Sud-Ouest voudrait étendre ses expériences dans le monde de Kubernetes si celle ci était un succès. Nous avons juste installé Drone avec un plugin K8S pour aller très vite dans un premier temps.

Et donc…

Cela peut paraître beaucoup de mots et de complexité d’avoir pris en compte tous ces aspects pour le premier prototype, mais nous avions une première version en à peu près un mois… Là plupart des hypothèses ont bien tenu, restait ensuite “juste” à construire le produit…

La suite de l’histoire

La suite de l’intervention a donc été de faire avancer tous ces composants, sans jamais hésiter à changer des éléments à la lumière de certaines informations :

• les BC Reader et Stream ont finalement été intégrés dans le même livrable, car il devenait douteux de penser que c’était deux BC séparés. Pour faciliter l’exploration, nous les avons donc fusionnés
• Nous avons confié de moins en moins de responsabilités à PUB/SUB (au début toutes les communications passaient par lui), pour s’appuyer tout simplement au maximum sur… des requêtes http entre services
• Nous avions expérimenté GraphQL pour le BC Article, pour finalement l’abandonner
• Nous avons remplacé Drone par un combo Jenkins (qui ne fait que le build des images, + test bien sûr), et Spinnaker pour gérer le déploiement continu
• Introduire redux-saga dans l’application mobile pour modéliser plus facilement, via ses channels, toutes nos IOs, dont tous les push de firebase.
• La liste pourrait être bien plus longue, on va s’arrêter là :)

Conclusion (temporaire)

Cet article est, je pense, clairement indigeste. J’espère juste avoir montré un aspect de cette approche de tendre vers le full spectrum : en ne nous cantonnant pas à un seul domaine de connaissance, nous pouvons tendre vers des décisions s’intégrant dans un tout un peu plus grand que notre bout de code, dont nous avons choisi la technologie souvent seulement pour nous faire plaisir, ou par habitude.

Si vous vous posez la question, oui l’application mobile Sud-Ouest que vous pouvez télécharger aujourd’hui s’appuie sur tout ça, et sert allègrement plusieurs milliers de lecteurs sans broncher. Elle n’exploite pas encore la totalité de ces capacités, mais c’est pour bientôt :)

P.S:

Cet article ne serait pas complet bien sûr si je ne remerciais pas la team UFO, anciens et nouveaux : Julien, Julien, Paul, Nicolas, Cédric, Renaud, Mathieu, Audrey, Arnaud.