Le contexte : nous avons démarré il y a bientôt deux ans la conception d’un produit, inwink, avec une équipe dédiée. C’est une évolution de notre métier parsemée de remises en question, de difficultés, d’erreurs et donc d’apprentissages, autant sur les aspects techniques que méthodologiques.

Je vais essayer de prendre le temps de partager quelques retours d’expériences différents sujets.

Pour le 1^er sujet, j’ai envie de partager notre évolution, en douceur, vers les micro-services. A savoir, pourquoi et comment nous avons mis en place ce type d’architecture.

La 1ère version de notre architecture était basée sur un modèle n tier traditionnel, appelé également « ca fait très bien le job » : front / api / BDD.

Dans notre produit, nous disposons de connecteurs pour synchroniser les données que nous collectons sur les évènements avec des outils de Marketing Automation et/ou de CRM. Est donc rapidement arrivé le moment où il fallut faire des traitements de fond, ou batch, pour faire de la synchro descendante.

Nous avons donc commencé à développer un ensemble de batch, qui, à intervalles régulières, requêtent nos différentes bases de données pour écrire dans des systèmes tiers.

Avantages :

• Rapide à mettre en place
• Facile à scheduler (avec des Azure Function dans notre cas)

Inconvénients :

• Pas facile à maintenir
• Couplage fort avec notre modèle de données
• Consommateur au niveau de la BDD
• Gaspillage de ressources : quand il n’y a plus besoin de synchroniser les données, les connecteurs continuent à pooler.

Notre besoin de créer de nouveaux connecteurs est exponentiel. Nous avons donc décidé de faire évoluer ce point d’architecture.

Notre objectif a été de bannir complètement la notion de pooling, ou de scheduling. Dans notre approche micro-service, un évènement est déclenché, consommé par ou un plusieurs services, qui peuvent potentiellement décider de se re-planifier plus tard.

Un exemple concret, une synchronisation CRM, avant :

1°) Notre API modifie de la data

2°) Un batch tourne à intervalle régulièrement pour vérifier s’il y’a de la donnée à publier

Après :

1°) Notre API modifie la data et transfère à un micro service la donnée qu’elle a modifiée. Elle transfère l’ensemble de la donnée pour permettre à chaque service d’être indépendant de la base et de la logique métier dans le traitement de la donnée.

2°) Ce micro service (appelé updatetracker chez nous), est configuré avec un pattern publish/suscribe pour notifier les autres services intéressés, qui s’activent dans le cas où la donnée est intéressée. Chez nous, il est maintenant appelé de manière asynchrone à chaque modification d’entité, afin de nous permettre de pouvoir câbler des services sur n’importe quelle action sur un objet.

3°) Si des micro-services sont intéressés par cette donnée, ils sont à leur tour notifiés et vont la traiter, ou la retransférer à d’autres services

Avantages :

• Ajout ou évolution de micro services, sans couplage fort
• Moins de sollicitation de la base de données et perte de la dépendance
• Pas de service qui s’exécute quand il n’y en a pas besoin
• Gain de productivité pour créer de nouveaux connecteurs (une fois la montée en compétences faite).

Inconvénients :

• Coup de setup et de montée en compétences sur l’ensemble de l’équipe (4 semaines pour une personne pour créer les templates de projet de micro-service, 1 semaine pour la montée en compétence individuelle avant d’être productif).
• Difficulté à monitorer en production

Je reviendrai sur ce dernier point dans un post plus technique 😊 Mes camarades se feront également sans doute un plaisir de compléter ce sujet.

A titre d’indication, aujourd’hui, environ 30% de notre base de code tourne dans des micro-services, pour la quasi-totalité avec un fonctionnement asynchrone : synchros outils tiers, distribution de mail, algorithmes de recommandations.