Comment migrer vers une architecture composable ?

Vous souhaitez remplacer votre legacy et vous tourner vers l’architecture composable ?

Cette approche apporte de nombreux avantages pour obtenir une architecture IT moderne et totalement adaptée à vos besoins. Toutefois, ce changement présente quelques contraintes, car il implique aussi un changement dans la manière de travailler.

Pour migrer vers une architecture composable, il faut tout d’abord faire le point sur votre architecture actuelle : lire l’article « Moderniser son architecture IT : quelles options pour transformer son legacy ? »

Puis, suivre une méthodologie spécifique que nous vous présentons avec une étude de cas centrée sur un site e-commerce. Enfin, nous vous donnons les bonnes pratiques à mettre en place et gérer ce type de système.

Qu’est-ce qu’une architecture composable ? Avantages et contraintes

Comprendre l’architecture composable

Re-développer votre legacy en choisissant une architecture composable permet de sortir de la vision monolithique des outils IT. En effet, le modèle traditionnel du monolithe se présente sous forme d’un bloc qui réunit des applications métiers différentes. Celles-ci sont généralement intégrées sous forme de plug-ins. Si ces derniers permettent d’exécuter différents besoins métiers, leur intégration ne suffit pas toujours à répondre à tous les besoins.

Une architecture composable se présente différemment. Elle utilise des fonctionnalités matérialisées par des composants individuels qui opèrent indépendamment. Cela offre davantage de souplesse, car vous pouvez travailler uniquement sur l’un des composants sans que cela impacte le reste de l’architecture.

La plateforme présente une expérience client optimale qui ne laisse apparaître aucune couture. Le back for front sert à faire la liaison entre celle-ci et les différents outils métiers, tels qu’un CRM, un PIM ou OMS en faisant remonter les informations nécessaires au bon moment.

Les avantages d’une architecture composable

Ainsi, passer à une architecture composable offre la possibilité de :

• Posséder les bons outils qui correspondent véritablement à vos besoins sans passer par une solution de plug-in. Vous possédez véritablement les outils en question et pas seulement des adds-on qui viennent compléter un système.
• Faire des développements spécifiques en fonction de besoins précis.
• Proposer une expérience client sans couture de haute qualité.

Les contraintes de ce type d’architecture

Toutefois, adopter ce type d’architecture nécessite de s’adapter. Les méthodes de travail sont très différentes par rapport à un monolithe. Cela implique de se baser sur le cloud pour assurer la scalabilité de la plateforme et de travailler avec des outils tels que :

• Docker/Kubernetes ;
• Infrastructure as a code ;
• Déploiements automatisés ;
• Monitoring de type APM ;
• Logs centralisés.

Il est indispensable d’utiliser l’API first pour respecter le headless avec :

• Des outils pour travailler en local ;
• Une culture DevOps ;
• Des cycles de déploiement plus courts ;
• Des dépendances et rétrocompatibilités ;
• Une stratégie de tests.

De plus, il faut mener un changement de culture qui nécessite :

• La compréhension du headless ;
• De savoir où appliquer une règle métier ;
• D’être capable de monter en compétence sur les outils mis en œuvre.

Faire le point sur son architecture IT

Avant de migrer vers une architecture composable, il est nécessaire de bien connaître votre architecture IT. Cela implique de savoir précisément ce que fait votre legacy :

• Les dépendances directes du legacy : de quels systèmes se nourrit-il ? Quels sont les flux et les règles métiers ?
• Les usages exotiques existants : quels sont les usages faits par les utilisateurs qui répondent à des règles implicites ? À quel point ces utilisations sont-elles importantes ? Quelles sont les conséquences de leur éventuelle suppression ?
• Les règles métiers réelles : ces règles sont-elles documentées ? Si oui, est-ce fait de manière précise ?

Migrer vers une architecture composable : étude de cas avec un projet e-commerce

Imaginons le scénario suivant avec la migration d’un site e-commerce. Celui-ci possède un legacy tout-en-un. Cette entreprise e-commerce fusionne avec une autre entreprise. Cette dernière a elle aussi un legacy. Il est impossible de fusionner ces deux architectures. La décision est alors prise de migrer le site e-commerce vers une architecture composable.

Pour réussir cette migration, il convient de suivre différentes étapes.

L’ajout d’un CMS headless

Cela peut prendre un peu de temps de s’habituer au fonctionnement d’un CMS headless. En effet, celui-ci est très différent de celui d’un CMS traditionnel. Un CMS headless n’a pas de lien fort avec le menu de navigation. La gestion du contenu est indépendante de l’arborescence. Les différents contenus peuvent être des titres, des images, des textes, qui sont empilables.

Ainsi, pour faire apparaître un contenu sur une page produit, il faut :

• Dans le CMS, dans l’édition des articles, mettre en place un champ “articles” pour saisir les identifiants produits.
• Au niveau du back for front, le contenu éditorial doit être lié aux données du produit.
• Au niveau du front, il faut demander explicitement de récupérer le contenu éditorial en plus des données produit grâce à un appel GraphQL.
• Quand les données sont présentes, elles doivent être mises en page.

Prévoir l’arrivée d’un PIM

Pour intégrer un PIM, la cible est :

• Exposer une méthode dans le back for front du type get_product_by_id.
• Connecter le back for front au PIM pour qu’il y récupère les données correspondant à un produit.
• Mettre en place un cache de type clé / valeur au niveau du back for front pour éviter de solliciter le PIM pour des données déjà connues.
• Implémenter une méthode de purge du cache (par expiration ou exposition d’une API).

Cependant, il est possible de proposer une étape de transition. Elle permet de prévoir l’arrivée plus tardive du PIM. Pour cela, la démarche est la suivante :

• Exposer une méthode dans le back for front du type get_product_by_id.
• Connecter le back for front au legacy pour qu’il y récupère les données correspondant à un produit.
• Mettre en place un cache de type clé / valeur au niveau du back for front pour éviter de solliciter le legacy pour des données déjà connues.
• Implémenter une méthode de purge du cache (par expiration ou exposition d’une API).

Le legacy est donc utilisé comme un outil headless de transition en étant coupé du front office. Par la suite, le PIM pourra remplacer le legacy sans impacter le développement front.

Comment débrancher le front end du legacy pour adopter une solution de transition ?

Il existe deux options possibles.

Dans le premier cas, le “branchement” du legacy se fait au niveau de l’URL. L’intégralité du site est, par défaut, servie par le legacy. Quand une section du site est gérée par la nouvelle architecture, on peut y rediriger le trafic en se basant sur l’URL. Par exemple, toutes les URLs en …./product_detail/… seront déconnectées du legacy.

Cependant, il y a différentes problématiques à anticiper :

• Faut-il reprendre des éléments transverses tels que le header ou le footer afin de conserver une expérience client sans couture ?
• Faut-il reprendre le style graphique ?
• Comment faire apparaître le panier sur l’écran ?
• Est-ce que vous savez générer des liens vers l’application monolithique ?

La seconde méthode repose sur l’insertion de composants dans la page issue de la nouvelle architecture. C’est par un appel Javascript initié dans le legacy qu’un nouveau contenu va s’ajouter dans la page (carrousel, contenu éditorial, nouveau moyen de paiement, etc.). Là encore, certaines problématiques sont à anticiper :

• Est-ce que vous savez modifier le template du monolithe pour y insérer du javascript dynamique ?
• Est-ce que le comportement du composant injecté dépend de l’identification de l’utilisateur ?
• Comment s’adapter au style du monolithe ?

Les bonnes pratiques pour migrer vers une architecture composable

Voici quelques conseils pour vous aider à préparer votre migration vers une architecture composable.

Accepter les imprévus

Il est important de prévoir certains points, mais cela implique également de vous adapter en acceptant les imprévus :

• L’objectif est clair, mais il évoluera probablement dans les détails.
• La roadmap est prête, mais il y aura des opportunités qui se présenteront.
• Les estimations sont faites, mais elles n’ont pas encore été confrontées à la réalité.

Vous vous poserez les questions suivantes :

• Comment reconnaître une opportunité d’une mauvaise idée ?
• Comment se préparer pour revoir ses plans efficacement ?
• Comment faire la distinction entre le temps de monter en compétence et l’inefficacité ?

Préparer les fondamentaux

Si l’architecture composable est tout ou partie nouvelle pour vous, mettez-la en pratique avant de commencer le travail de développement :

• Choisissez votre plateforme cloud.
• Mettez en application l’usage de Terraform pour afficher un “bonjour monde” sur une application composée des technologies que vous avez décidé d’utiliser.
• Déployez le “bonjour monde” de façon automatisée.
• Si vous avez des sujets de réseau pour accéder à des ressources particulières, adressez-les dans le “bonjour monde”.
• Mettez en place le monitoring et la centralisation des logs. Il est important de centraliser les éléments pour ne pas perdre de temps et détecter rapidement les problèmes.

Mettre en place un déploiement en continu

Vous devez également mettre en place le déploiement en continu pour éviter tout blocage :

• Déployez au plus tôt : vous saurez ce que vous déployez et vous aurez des indicateurs de tests en conditions réelles.
• Surveillez en récupérant et en centralisant les logs et en observant la façon dont la charge serveur varie avec les déploiements successifs.
• Préférez les petits incréments, vous suivrez plus facilement leurs impacts.
• Apprenez à revenir en arrière, le rollback doit être simple et rapide.
• Privilégier l’activation au déploiement : dans ce cas, le rollback devient une désactivation.
• Anticipez les migrations de données, elles sont généralement plus complexes que prévu.
• N’oubliez pas de fêter les succès !

Tester le système est incontournable :

• N’hésitez pas à faire des POC.
• N’hésitez pas à les déployer jusqu’en production (désactivés).
• Investissez du temps dans la mise en place de tests automatisés (avec parcimonie).
• Surveillez l’impact sur vos utilisateurs en prévoyant l’analyse des comportements avant / après.

Migrer vers une architecture composable et anticiper le changement

Passer à une architecture composable ne doit pas être envisagé comme une simple évolution technologique. Elle doit aussi être anticipée de manière à accepter le changement. Son utilisation diffère beaucoup de celle d’un CMS classique. Il faut donc un temps d’adaptation avant d’en accueillir les bénéfices.

N’hésitez pas à vous entourer de personnes ayant la connaissance et l’expertise nécessaire pour vous accompagner dans la migration de votre architecture composable. Pour cela, vous pouvez contacter Kaliop.