Retour d’expérience. D’une architecture monolithe aux micro-services

Partie 1 : la conception

L’objectif de ce papier est de partager avec vous notre retour d’expérience suite au passage en micro-service du site reparcar.fr. En effet, les micro-services on en parle beaucoup, c’est un sujet à la mode et j’entends beaucoup de monde dire que c’est la solution. Mais qui met cela réellement en place ? Très peu d’entreprises en fait et cela s’explique par le fait de devoir repenser le projet, former les équipes et accepter de passer du temps en conception (pour en gagner énormément après).

La mise en place d’une infra en micro-service nécessite une réflexion plus profonde pour l’équipe technique. L’impulsion et le soutient du CTO est donc ici indispensable afin de faire accepter la difficulté du début de projet à l’équipe et d’enlever la tentation de la simplicité de mettre en place un projet monolithe qui se monte plus facilement et plus rapidement mais qui deviendra rapidement très compliqué à maintenir et qui posera de gros problèmes de scalabilité.

Avant de s’attaquer au modèle micro-services, Il est préférable d’avoir une très bonne connaissance du produit pour assurer une bonne conception. Dans le cas de Reparcar, Nous avons délibérément choisi de passer en mode Monolithe Symfony 4 / bootstrap afin de réaliser notre POC.

Pourquoi passer en micro-services ?

Avec notre environnement technique monolithe, nous avons fait rapidement plusieurs constats :

• Nombre de dépendances élevées
• Impossibilité d’upgrader le framework (limité par certains bundles)
• Difficultés à maintenir l’ensemble
• Scalabilité menacée
• Problème de performances
• Complexité du code et de la compréhension des interactions entre les bundles
• Nécessite d’installer l’ensemble du projet même pour ajouter une petite fonctionnalité
• Intégration de nouveaux développeurs complexe
• La liste pourrait être encore très longue …

Bien sûr le projet souffre aussi de la non-intégration des bonnes pratiques dès la conception mais ici l’idée c’était d’aller vite. On savait qu’on était dans un POC et qu’il serait nécessaire de re-factoriser si le succès était au rendez-vous. 1 an plus tard, On y est …

Les avantages de passer en micro-service sont très nombreux :

• Une séparation du code améliorant sa maintenance et sa compréhension. puisque chacun fonctionne sa façon indépendante il peut également évoluer de façon indépendante.
• Nous pouvons plus facilement confier une d’à une entreprise externe sans lui envoyer l’ensemble du projet.
• Une intégration continue.
• Une fois terminé, nous intégrons le micro-service dans le projet actuel et nous effaçons petit à petit notre dette technique sans attendre la fin du développement de l’ensemble des micro-services.
• La possibilité de choisir (facilement) le langage le plus adapté à la fonctionnalité du micro-service (Php, python, java, react ;)
• On mélange plus les choses. Chaque fonctionnalité a son micro-service. C’est beau, c’est clair, c’est simple.

Les points critiques

La réussite d’un projet quel qu’il soit est dans sa préparation. Nous avons donc consacré 3 jours à la phase préparatoire. Celle-ci nous a permis de découper notre projet et de bien définir les interactions entre les micro-services (de façon macro). Nous nous sommes assuré que chaque micro-service soit indépendant et puisse fonctionner de façon autonome sans dépendance d’un autre.

Shéma préparatoire passage en micro-services

Lors de notre réunion technique préparatoire, nous avions identifié plusieurs points critiques pour lesquels nous devions trouver une solution afin de valider le passage en micro-service :

• Pouvoir faire du SSR (serveur side rendering)
• Disposer d’un SSO avec système de token pour sécuriser les interactions avec les différents services
• Avoir un système d’abonnement entre les micro-services pour la gestion des évènements.

Nos choix techno

Notre objectif est de découper nos besoins en un ensemble d’APIs. Chacune répondant à un besoin métier : oauth2, facturation, paiement, catalogue, véhiculé … et bien sûr un micro-service front pour l’affichage en PWA.

POUR LE FRONT

Nous avons opté pour React avec Next js pour la gestion du SSR et du routing.

Next js amène bien d’autres choses, je reviendrai dessus avec un billet dédié.

Nous avons opté pour une organisation des modules en atomic design. Nous utilisons Storybook qui est un formidable outil open source permettant de créer une documentation graphique et technique des modules au fur et à mesure de l’avancée du projet.

Storybook Reparcar

Si comme nous vous commencer un projet avec React et que vous avez besoin de SSR (ou d’un rendu static), je vous conseille vivement de développer dès le début avec Nextjs afin d’éviter trop de re-factorisation par la suite.

Essayer de lancer le plus tôt possible le développement de vos modules React car le rendu front prend du temps et doit être fait en parallèle du back afin de ne pas retarder le projet par la suite.

Même si cela peut paraître contraignant, il est indispensable d’utiliser Typescript dans votre projet car cela force le typage du Javascript et simplifiera la compréhension / re-factorisation du code.

react-hook-form est un plugin React bien utile. Performant, flexible et extensible pour gérer la validation des formulaires.

Si vous avez des icônes à mettre dans votre application, je vous recommande de jeter un oeil à React-icons

OAUTH2 / TOKEN

Le Micro-service oauth2 / tokens nous a donné du fil à retordre. Dans un premier temps, nous avons pensé mettre en place un Symfony avec un serveur d’auto2 et JWT mais honnêtement à vouloir réinventer la roue on s’est cassé les dents. Nous avions pourtant visualisé des vidéos nous expliquant la complexité du sujet qui nous donnait même la solution … bon au moins on a bien creusé le sujet et on le comprend bien mieux maintenant. Notre choix final c’est donc porté sur Keycloak qui a l’avantage d’être ultra-complet et open source.

Ne perdez donc pas votre temps. Si vous avez besoin d’un serveur qui gère vos utilisateurs, d’un SSO, d’Oauth2 et bien d’autres choses, Keycloak est sûrement la solution.

Pour tester rapidement Keycloak avec docker :

docker run -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin quay.io/keycloak/keycloak:13.0.1

Pour sécuriser les APIs, nous avons mis en place une gateway avec Nginx qui vérifie le token à chaque appel d’un des services. Si vous voulez un tuto complet, Yann vous explique cela en détails ici.

Shéma technique Gateway avec Nginx

MICRO-SERVICES API

Pour les autres micro-services (qui sont pour l’ensemble des APIs) le duo Symfony 5 / api-platform répond parfaitement à nos besoins. Une petite période de prise en main d’api-platform est nécessaire mais une fois dedans on se demande comment on a pu utiliser FOS-Rest un jour ;-)

Pour sécuriser les appels APIs, nous utilisons LexikJWTAuthenticationBundle pour valider le token passé dans le header de la requête.

GESTION DES EVENTS ENTRE MICRO-SERVICES (WEBHOOCK)

Un sujet simple dans un projet monolithe qui l’est beaucoup moins dans un environnement micro-services. Alexandre vous explique en détails notre réflexion. Et comme on est sympa Alexandre vous explique dans un tuto comment faire en détails ici.

L’avantage quand on refait un projet c’est qu’on peut mettre en place les bonnes pratiques dès le début. Chaque micro-service possède son GIT, sa configuration Docker et bien sûr l’ensemble est documenté et testé.

Nous avons décidé de passer les requêtes en GraphQL afin d’optimiser au maximum la taille des échanges. Nous y reviendrons plus tard.

Cette première partie est terminé. Nous allons essayer de publier de nouveaux articles après chaque sprint afin de prolonger le partage d’expérience. L’équipe reste disponible pour échanger sur le sujet.

Enfin j’en profite pour vous informer que nous recrutons des devs chez Reparcar. Donc si le projet vous plait faut pas hésiter à me contacter.