# Le voyage de Shoprocket vers les microservices, partie 1 : ce que j'ai raté en découpant le monolithe > Un article de l'équipe technique des premières années de Shoprocket sur la première tentative d'extraire un service d'un monolithe PHP. Pourquoi j'ai choisi le mauvais premier service, ce que le couplage fort m'a appris, et le conseil de Newman que j'aurais dû suivre plus tôt. Winston Berty - 17 mars 2016 - 5 min de lecture Quelques mois après mon arrivée chez Shoprocket, je commençais à être frustré. Nous avions une application PHP développée par une petite équipe de développeurs brillants répartis aux quatre coins du monde, et il me semblait que les corrections de bugs en engendraient de nouveaux, que l'intégration de nouvelles fonctionnalités n'était pas aussi simple qu'elle aurait dû l'être, et que les déploiements étaient rares et stressants. La cause : un code fortement couplé. Nous avions une application monolithique, presque entièrement dans un seul dépôt GitHub. La mise à jour ou la correction d'une fonctionnalité exigeait souvent des changements à plusieurs endroits. Pour les tests, nous avions un processus de revue par les pairs où au moins deux autres développeurs devaient valider une branche avant qu'elle soit fusionnée dans master et déployée. Tout cela signifiait que lorsqu'un bug s'infiltrait, il était souvent difficile de localiser le changement fautif. Une fois trouvé, la correction suivait le même processus, et toute l'application devait être redéployée. En jeune développeur enthousiaste toujours à l'affût de la nouveauté, quand j'ai découvert les microservices, j'ai pensé que cela allait résoudre tous nos problèmes. ## Ce que je pensais que les microservices étaient Il n'existe pas de définition formelle des microservices, mais de mes recherches j'ai retenu que l'architecture en microservices est une façon de concevoir des applications logicielles comme des systèmes distribués de services indépendants, chacun très spécialisé et doté de son propre cycle de vie. Pour une introduction détaillée, l'[article](https://martinfowler.com/articles/microservices.html) de Martin Fowler est excellent. Deux aspects m'ont séduit. D'abord, l'idée de découper l'application en services aux frontières strictes. Cela réduit le risque qu'une logique propre à un contexte métier fuite entre les composants, parce que les interfaces entre les frontières doivent être soigneusement planifiées. Ce n'est pas aussi simple que de faire des appels de fonctions locaux. Ensuite, chaque composant peut avoir son propre cycle de vie indépendant. Les équipes peuvent être propriétaires de leur code et utiliser la pile la mieux adaptée au service, et les changements peuvent être déployés un service à la fois et annulés sans affecter le reste. J'étais convaincu. Shoprocket allait découper le monolithe. Voici la partie 1 d'une courte série qui suit ce parcours. J'espère que les lecteurs qui planifient ou traversent une transition similaire apprendront de nos réussites et de nos échecs. ## Le premier défi était humain, pas technique J'ai dû vendre l'idée au reste de l'équipe. Ils étaient curieux mais ne partageaient pas mon enthousiasme, et ils rechignaient à sacrifier des heures de développement à ce stade précoce de la vie du produit. Heureusement, le directeur technique voulait que j'examine notre gestion des sessions, alors j'ai saisi l'occasion : je l'ai convaincu que je pouvais extraire un service de sessions. Avec le recul, c'était un mauvais choix de premier service. Notre produit comprend un widget JavaScript qui [permet l'e-commerce sur n'importe quel site web](https://v3.shoprocket.io/fr/fonctionnalites/vendre-sur-nimporte-quel-site.md). Nous traitons les sessions comme une ressource, en enregistrant les informations de session en base de données pour analyser l'abandon de panier et d'autres indicateurs. Mais cette ressource n'est pas aussi tangible que des commandes ou des lignes de commande, et nous utilisions les sessions à presque chaque changement d'état de l'application. Le service allait donc inévitablement beaucoup dialoguer avec le reste de l'application, ce que je n'avais pas prévu et qui a rendu ma tâche plus difficile. ## Ce que j'ai appris en le construisant vraiment J'ai intensifié mes recherches. Aux côtés de Fowler, **Building Microservices** de Sam Newman s'est révélé une ressource indispensable. Le conseil de Newman, avec le recul, était celui que j'aurais dû suivre : restructurer d'abord l'application existante en modules qui reflètent les contextes délimités du domaine. Une fois que les développeurs sont satisfaits des frontières, *alors* on extrait les modules en services à part entière. La raison est qu'il est beaucoup plus facile de démonter et de réécrire des modules aux mauvaises frontières que de démonter et de réécrire des services entiers avec toute leur tuyauterie supplémentaire et leurs ressources persistantes. Je n'ai pas suivi ce conseil. Impatient de construire un composant à moi, je suis allé de l'avant avec le service de sessions. J'ai choisi une pile à peine différente de celle du monolithe et je me suis mis à construire. Le service lui-même a pris forme rapidement, quelques semaines pour produire une application autonome avec une API REST. Ce n'était pas là que résidait la difficulté. La difficulté, c'était de faire dialoguer le service avec le monolithe. La gestion des sessions s'est révélée fortement couplée au reste du code. Remplacer des appels de fonctions par des appels d'API était un travail lent. Comme le service de sessions et le monolithe avaient des schémas de base de données distincts, j'ai dû réécrire toute la logique du monolithe qui utilisait les ressources de session de l'ancienne base, en restructurant les données à la frontière de l'application pour garder la compatibilité avec des clients comme notre widget JavaScript. L'intégration a pris plus de temps que la construction. Et cela n'incluait toujours pas l'essentiel de la charge que les microservices apportent normalement : découverte de services, journalisation, supervision, traçage distribué. Pire, le couplage fort faisait que les changements se répandaient dans de nombreuses zones du code. Comme l'équipe avait travaillé en parallèle pendant ce temps, la fusion et la mise en production du service de sessions auraient demandé bien plus de coordination que ce que j'avais estimé. ## Le bilan honnête Le service va peut-être bientôt passer en production. Mais je pense maintenant que j'aurais dû suivre le conseil de Newman et consacrer mes efforts à modulariser d'abord l'application existante. L'intérêt d'avoir un seul service qui vit tout seul est marginal. Le vrai bénéfice vient du découpage de l'ensemble, au moins en services à gros grain qui dialoguent le moins possible entre eux. Cela exige des frontières de composants bien réfléchies, et nous n'en étions pas là. Je reste convaincu par les microservices comme idée. Je vois ma tentative comme une expérience utile. J'ai beaucoup appris sur l'architecture applicative, la modélisation du domaine et les principes REST, et ces leçons ont eu des effets en cascade sur d'autres parties de notre code. Pour quiconque envisage une transition similaire, mes recommandations honnêtes : - Lisez le plus possible sur le sujet avant de vous engager - Repoussez le travail jusqu'à ce que vous soyez vraiment à l'aise avec votre base de code existante et votre modèle de domaine - Souvenez-vous qu'il existe d'autres façons d'apporter stabilité et résilience à un monolithe. Les tests unitaires et fonctionnels automatisés aident énormément. Le développement piloté par les tests réduit les régressions. La mise à l'échelle horizontale rend les déploiements moins pénibles - Commencez par modulariser votre monolithe avant d'extraire des services Shoprocket va poursuivre son voyage. C'est dans la partie 2 que cela devient plus intéressant. --- *Publié à l'origine comme le premier d'une courte série documentant la migration initiale de Shoprocket hors d'un monolithe PHP. Le voyage complet, y compris les erreurs corrigées dans les itérations suivantes, s'est poursuivi à travers chaque refonte majeure de la plateforme depuis.* --- - HTML version: https://v3.shoprocket.io/fr/blog/shoprocket-vers-les-microservices-partie-1-decouper-le-monolithe - Language: Français (fr) - Also in: [العربية](https://v3.shoprocket.io/ar/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Deutsch](https://v3.shoprocket.io/de/blog/shoprocket-microservices-teil-1-monolith-zerlegen-fehler.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [English](https://v3.shoprocket.io/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Español](https://v3.shoprocket.io/es/blog/shoprocket-microservicios-parte-1-lo-que-hice-mal-monolito.md), [עברית](https://v3.shoprocket.io/he/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [हिन्दी](https://v3.shoprocket.io/hi/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Bahasa Indonesia](https://v3.shoprocket.io/id/blog/perjalanan-shoprocket-menuju-microservices-bagian-1-salah-memecah-monolit.md), [Italiano](https://v3.shoprocket.io/it/blog/viaggio-di-shoprocket-verso-i-microservizi-parte-1-cosa-ho-sbagliato-sul-monolite.md), [日本語](https://v3.shoprocket.io/ja/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Lietuvių](https://v3.shoprocket.io/lt/tinklarastis/shoprocket-kelione-i-mikropaslaugas-1-dalis.md), [Norsk](https://v3.shoprocket.io/nb/blogg/shoprockets-vei-mot-mikrotjenester-del-1-hva-jeg-tok-feil-av.md), [Nederlands](https://v3.shoprocket.io/nl/blog/shoprocket-microservices-deel-1-monoliet-opknippen.md), [Polski](https://v3.shoprocket.io/pl/blog/droga-shoprocket-do-mikroserwisow-czesc-1-rozbijanie-monolitu.md), [Português](https://v3.shoprocket.io/pt/blog/jornada-do-shoprocket-para-microsservicos-parte-1-o-que-errei-ao-quebrar-o-monolito.md), [Română](https://v3.shoprocket.io/ro/blog/drumul-shoprocket-spre-microservicii-partea-1-ce-am-gresit-cu-monolitul.md), [Русский](https://v3.shoprocket.io/ru/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [ไทย](https://v3.shoprocket.io/th/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Türkçe](https://v3.shoprocket.io/tr/blog/shoprocket-mikroservis-yolculugu-1-monoliti-parcalarken-yanlis-yaptiklarim.md), [中文](https://v3.shoprocket.io/zh/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md)