Le parcours de Shoprocket vers les microservices : Partie 1

Quelques mois après le début de mon emploi chez Shoprocket, je commençais à me sentir frustré. Nous avions une application PHP sur laquelle travaillait notre petite équipe de développeurs talentueux, dispersés aux quatre coins du monde. Pourquoi étais-je frustré ? Pour moi, il semblait que les corrections de bogues entraînaient plus de bogues, l'intégration de nouvelles fonctionnalités n'était pas aussi simple qu'elle aurait pu l'être, et les déploiements étaient rares et stressants. La raison de ces problèmes : un code hautement couplé.

Nous avions une application monolithique, et presque tout notre code se trouvait dans un seul dépôt Github. Les mises à jour ou corrections d'une fonctionnalité se produisaient souvent à plusieurs endroits. Pour les tests, nous avions un processus de révision par les pairs, où au moins deux autres développeurs devaient approuver une branche avant qu'elle ne soit fusionnée dans la branche principale et déployée. Tout cela signifiait que lorsque des bogues réussissaient à passer inaperçus, il était souvent difficile de localiser les modifications problématiques. Et une fois que nous y parvenions, les corrections devaient passer par le même processus et l'ensemble de l'application devait être redéployé.

Étant un jeune développeur enthousiaste toujours à la recherche de la nouveauté, lorsque j'ai découvert les microservices, j'ai pensé que ce style architectural résoudrait tous nos problèmes. Il n'existe pas de définition formelle des microservices, mais d'après mes recherches, j'ai compris que l'architecture microservices est un moyen de concevoir des applications logicielles en tant que systèmes distribués de services indépendants, chacun hautement spécialisé et ayant son propre cycle de vie. Pour les lecteurs qui souhaitent une introduction plus détaillée au concept, je recommande l'excellent article de Martin Fowler.

Il y avait de nombreux aspects des microservices qui m'intéressaient, mais deux en particulier : D'abord, l'idée de diviser l'application en services avec des frontières très strictes. Cela réduit le risque que la logique spécifique à un contexte commercial fuite entre les composants, car les interfaces entre les limites doivent être soigneusement planifiées. Ce n'est pas aussi simple que de faire des appels de fonction locaux ; Deuxièmement, chaque composant peut avoir son propre cycle de vie indépendant. Cela permet aux équipes de prendre possession de leur code et d'utiliser une pile technologique mieux adaptée à chaque service. De plus, cela permet un contrôle plus précis sur l'application car les modifications peuvent être déployées à un service à la fois et annulées sans affecter le reste de l'application si quelque chose ne va pas.

Donc, j'étais convaincu. Shoprocket allait démanteler le monolithe ! Ceci est le premier d'une courte série de articles de blog suivant ce parcours. Mon espoir est que les lecteurs prévoyant ou traversant une transition similaire apprendront de nos succès et échecs et se sentiront mieux préparés à relever ce défi dans leurs propres projets.

Mon premier défi n'était pas technique, mais humain. Je devais convaincre le reste de l'équipe de l'idée. Ils semblaient curieux, mais ne partageaient pas le même enthousiasme et étaient réticents à abandonner des heures de développement à ce stade précoce de la vie de notre produit. Heureusement, le CTO voulait que je m'intéresse à notre gestion des sessions et j'ai saisi l'occasion en le convainquant que je pouvais créer un service de session.

Avec le recul, c'était peut-être un mauvais choix de composant pour un premier service. Notre produit comprend un plugin javascript qui permet le commerce électronique sur n'importe quel site web. Nous traitons les sessions comme une ressource, en enregistrant les informations de session dans la base de données pour une analyse détaillée des KPI tels que les taux d'abandon de panier. Cependant, cette ressource n'est pas aussi tangible que quelque chose comme des commandes ou des lignes d'articles. De plus, nous utilisions la ressource de session presque à chaque changement d'état de l'application. Cela signifiait que le service serait inévitablement bavard avec le reste de l'application, ce que je n'avais pas prévu, mais cela compliquait ma tâche.

Après avoir convaincu mon patron, j'ai intensifié mes recherches sur les microservices. En dehors de l'article mentionné, j'ai également trouvé le livre de Sam Newman « Building Microservices » être une ressource inestimable. Je m'y référerai souvent dans mes articles.

Dans son livre, Newman recommande d'abord de restructurer une application existante en modules qui reflètent les contextes délimités du domaine. Ensuite, une fois que les développeurs sont satisfaits, les modules peuvent être séparés en leurs propres services. La raison en est qu'il est beaucoup plus facile de décomposer et de réécrire des modules si leurs frontières étaient mal choisies que de décomposer et de réécrire des services entiers, avec tout leur code de plomberie supplémentaire et leurs ressources persistantes. Cependant, en raison des contraintes de temps et de mon empressement à construire un composant de ma propre initiative, j'ai poursuivi la création du premier service.

J'ai choisi une pile seulement marginalement différente de celle que nous utilisions pour notre monolithe et j'ai commencé à construire. La construction elle-même s'est déroulée assez rapidement, prenant quelques semaines pour produire une application autonome avec une API REST. Ce n'est qu'alors que les véritables défis ont commencé.

Je devais faire communiquer le service avec le monolithe. C'est à ce moment que j'ai appris à quel point la gestion des sessions était étroitement couplée au reste du code. Il m'a fallu un certain temps pour décomposer les appels de fonction existants et les traduire en appels d'API. Cela s'est avéré délicat. Comme le service de session et le monolithe avaient leurs propres schémas de base de données, je devais réécrire toute logique dans le monolithe qui utilisait des ressources de session de l'ancienne base de données, restructurant les données à la frontière de l'application pour maintenir la compatibilité avec des clients tels que notre plugin javascript.

L'intégration du service avec notre application existante a pris plus de temps que d'écrire le service lui-même, et cela n'incluait pas beaucoup de la surcharge supplémentaire que les microservices apportent normalement, comme la découverte de services, la journalisation et la surveillance. De plus, en raison du couplage étroit, des changements ont été apportés à de nombreux domaines du code. Comme l'équipe avait travaillé sur divers domaines du code en parallèle durant ce temps, cela aurait nécessité beaucoup plus de travail pour fusionner les changements et mettre le service de session en production.

Le service pourrait bientôt passer en production, cependant, je ressens maintenant que j'aurais dû suivre les conseils de Newman et investir mes efforts dans la modularisation de notre application existante. Le bénéfice d'avoir un service vivant seul est marginal. Le véritable avantage viendra de la division de l'ensemble, au moins en services à grains grossiers, qui communiquent le moins possible. Cela nécessite des frontières de composants très bien pensées, et nous n'en sommes pas encore là.

Je suis toujours convaincu par l'idée des microservices, et je considère ma tentative de créer un service comme une expérience réussie. J'ai beaucoup appris sur l'architecture des applications et la modélisation du domaine dans le processus, et j'ai amélioré ma compréhension des principes REST, entre autres choses. Cela a eu un effet immédiat sur d'autres domaines de notre code.

Pour les lecteurs cherchant à se convertir, je vous recommande de lire autant que possible sur le sujet, et d'attendre avant de vous mettre au travail jusqu'à ce que vous soyez très à l'aise avec votre code existant et votre modèle de domaine. Il existe d'autres moyens d'introduire la stabilité et la résilience dans une application monolithique. Le développement dirigé par les tests et les tests unitaires et fonctionnels automatisés aident beaucoup. L'évolutivité horizontale aide également à rendre les déploiements un peu plus fluides.

Shoprocket continuera son voyage vers les microservices. Nous avons hâte de vous en dire plus dans la partie 2 !