Plutôt que de s'appuyer sur des applications monolithiques où tout est interconnecté, les microservices proposent une architecture décomposée, où chaque fonctionnalité est gérée par un service distinct. Cette organisation modifie non seulement la façon dont les plateformes e-commerce fonctionnent d'un point de vue technique, mais elle offre également une multitude d'avantages en termes d'agilité, de scalabilité et de résilience.
En effet, les partisans des microservices affirment que l'isolation des différents services et la finesse des interfaces offrent de plus grandes possibilités en termes de mise en œuvre et de composition. Cependant, les microservices ne sont pas toujours la solution magique que l'on s'imagine.
Vous êtes à la recherche de la meilleure façon de concevoir votre software e-commerce ? Découvrez ici les avantages et les limites d'une architecture intégrant les microservices et déterminez grâce à nos conseils si cette approche est adaptée à votre projet.
Microservices e-commerce : une définition
Les microservices désignent une approche architecturale dans laquelle une application unique est composée de plusieurs composants, ou services, plus petits, faiblement couplés et pouvant être déployés de manière indépendante. Cette approche architecturale propre aux softwares e-commerce peut être décrite sur la base des caractéristiques suivantes :
-
Piles technologiques indépendantes. Chaque service dispose de sa propre pile technologique, incluant la base de données et le modèle de gestion des données.
-
Dépendance aux protocoles de communication. Les services échangent des informations en utilisant des protocoles spécifiques, tels que les API REST via HTTP ou une messagerie asynchrone légère.
- Organisation selon les compétences métier. Les services sont structurés selon les compétences métier, la délimitation entre ces services étant souvent désignée comme un « contexte borné ». Par exemple, en e-commerce, tout ce qui concerne la gestion des clients pourrait être regroupé au sein d’un même contexte borné.
Avantages d’une architecture en microservices
|
1. Flexibilité et agilité
L’architecture des microservices permet aux entreprises de modifier, d’ajouter ou de supprimer des services particuliers sans perturber l’ensemble du système. En ce sens, une architecture microservices offre aux équipes une infrastructure optimisée pour traiter séparément les différentes problématiques et mieux les coordonner les unes aux autres. Le code peut alors être facilement mis à jour et de nouvelles fonctionnalités déployées sans avoir à intervenir sur l’intégralité de l’application. Les microservices permettent également aux équipes de déployer des mises à jour élément par élément et de les tester rapidement.
2. Autonomie
Puisque chaque service est autonome, les équipes peuvent développer, déployer et échelonner ces services de manière indépendante. Au niveau du code, les développeurs et les équipes peuvent travailler de manière indépendante et, éventuellement, utiliser différents outils et cadres (frameworks). En conséquence, le rythme de développement en est accéléré, et différentes équipes peuvent travailler simultanément sur différents aspects de la plateforme.
3. Scalabilité
Les microservices sont naturellement évolutifs. Si une fonctionnalité spécifique connaît une demande accrue, cette partie spécifique du système peut être mise à l’échelle sans affecter les autres services.
Quels désavantages à adopter les microservices ecommerce ?
|
1. Augmentation des coûts de maintenance
Si chaque microservice est en mesure de fonctionner indépendamment, la maintenance devra elle aussi se faire de façon indépendante pour chacun. Lorsque les microservices se font plus nombreux au sein d’une structure, cela signifie que la maintenance peut potentiellement devenir plus complexe, exigeant une plus grande vigilance au quotidien, mais aussi la réalisation de tests et de corrections spécifiques. Cela peut donc entraîner une augmentation des coûts associés à la maintenance de l’ensemble du software e-commerce.
D’autre part, il est important de noter que l’extensibilité et la composition sont des attributs rattachés à la conception du système, et non au choix d’utiliser des microservices.
Les microservices ne sont pas la seule voie vers l’extensibilité. Les extensions de noyau et les pilotes sont des modèles qui offrent les avantages d’une plateforme – vitesse, cohésion et faible maintenance – tout en permettant une extensibilité et une configuration modulaire.
Une extension de noyau offre la possibilité d’un couplage entre les services centraux du noyau, tout en permettant une personnalisation en ligne de son comportement ou de sa logique. Bien réalisée, la logique fournie est exécutée dans un environnement d’exécution sécurisé, optimisé et géré qui élimine le compromis entre coordination, vitesse et extensibilité. Les pilotes, en revanche, fournissent une intégration de haute cohésion avec le noyau et confèrent au système d’exploitation de nouvelles capacités.
2. Complexité organisationnelle et frais généraux
Les microservices permettent aux développeurs de travailler indépendamment en utilisant les outils et frameworks de leur choix. Ils peuvent ainsi mettre en avant leurs compétences et déployer des solutions rapidement. Cependant, pour les dirigeants d’entreprise, accorder une grande autonomie aux équipes entraîne des coûts indirects.
Il est alors nécessaire de spécifier clairement les responsabilités de chacun et de délimiter un périmètre autour de chaque fonction, notamment touchant aux interactions entre les différents microservices, ainsi que leur gestion à long terme. Sans contrôle, les entreprises peuvent perdre le levier opérationnel et les avantages souvent tirés des normes partagées, des modèles généraux de l’entreprise et de la complémentarité des savoirs entre équipes.
Ainsi, la complexité de mise en place d’un tel système peut entraîner une augmentation des coûts techniques, requérir l’embauche de chefs de projet supplémentaires, créer une certaine opacité dans les processus, chaque service et projet étant géré par un seul ingénieur détenant toutes les clés de son projet.
D’autre part, l’adoption d’une architecture en microservices peut entraîner une refonte de la structure organisationnelle. Avec de multiples équipes travaillant sur différents services, une surcharge administrative peut aussi survenir, requérant davantage de coordination entre les équipes et générant potentiellement des frais généraux supplémentaires.
3. Complexité de coordination
L’un des coûts les plus souvent associés aux microservices est celui en lien avec la maintenance et la coordination de nombreux éléments en mouvement. Même si les microservices peuvent être déployés séparément, ils doivent être conçus d’une certaine façon, permettant au système de fonctionner et à l’entreprise d’atteindre ses objectifs. Cette dépendance qui existe entre les différents microservices peut souvent être à l’origine de déploiements complexes et fragiles quand on en vient à concevoir un système e-commerce.
Une bonne architecture tire parti de l’isolement des composants et des services là où c’est nécessaire. Un excès d’isolement, un écueil fréquent dans le domaine des microservices, peut conduire à des produits au développement fragile, difficiles à vérifier, à développer et à dépanner.
Un exemple parlant :
Lorsque Airbnb est passé à une architecture orientée services afin de se débarrasser de la complexité monolithique, l’entreprise a constaté que l’approche basée sur les microservices nouvellement adoptée entraînait sa propre série de complications. La société compte actuellement 2 000 services, gérés par 500 ingénieurs. « Il était difficile de comprendre le graphe des dépendances », avait alors déclaré Jessica Tai, responsable technique et ingénieure en infrastructure pour les core services chez Airbnb, lors d’une conférence InfoQ Qcon en 2021.
Une telle complexité rendait difficile le débogage des services pour l’équipe d’Airbnb. Le développement de nouvelles fonctionnalités prenait également plus de temps en raison d’un nombre croissant de modifications à effectuer aux points d’intégration, les services commençaient à dupliquer les fonctionnalités, et les données étaient de plus en plus fragmentées.
4. Risque de défaillances en cascade
La multiplication des services – chacun avec sa propre mise en œuvre, architecture et ses différentes caractéristiques de performance – augmente considérablement le risque de défaillances en cascade, nécessitant de la part des chefs de projet et de l’équipe des capacités avancées en traçage et en débogage inter-services.
Les plateformes les plus performantes intègrent un ensemble soigneusement sélectionné de primitives, de flux de travail, et de bonnes pratiques intégrées. En d’autres termes, bien penser ses choix architecturaux est essentiel et conduira à de meilleurs résultats.
Une API (Interfaces de Programmation d’Application) bien conçue et une abstraction bien définie sont essentielles au développement d’une interface au fonctionnement fluide et à la présentation claire et concise. Par exemple, un langage de modélisation d’opinion peut efficacement éliminer les attaques de type cross-site scripting (XSS) et d’autres attaques courantes affectant la sécurité côté client. Ou, du moins, rendre ces attaques très difficiles à exécuter. Un environnement d’exécution géré avec des limites d’exécution, mises en cache, tentatives de reconnexion et coupe-circuits peut également offrir un contrat solide garantissant une performance continue en cas de charge extrême.
Des choix judicieux, intégrés dans les plateformes et les SDK, seront d’une aide précieuse pour les développeurs. Encapsulant les fonctionnalités et besoins courants derrière des interfaces standards, ils empêchent la mise en place de mauvaises commandes, permettent une meilleure valeur ajoutée et réduisent les coûts de développement et de maintenance.
5. Problèmes de performance et de fiabilité
Tandis que les microservices peuvent offrir une scalabilité accrue, la nécessité d’échanges fréquents entre les différents services peut être à l’origine de latences. De plus, garantir une performance et une fiabilité constantes à travers un grand nombre de services autonomes peut nécessiter des efforts supplémentaires et une surveillance continue.
Un exemple parlant :
Steve Cosenza, ancien ingénieur en chef chez Twitter, décrit ce qui se passe lorsque des équipes indépendantes conçoivent et créent des points d’accès pour leurs cas d’utilisation spécifiques sans coordination suffisante : « Les microservices entraînent une fragmentation et, inévitablement, un ralentissement de la productivité des développeurs. Si l’approche des microservices a initialement permis d’accélérer le développement, elle a également abouti à une API Twitter éparpillée et désorganisée. »
L’absence de convention de code partagée ou de SDK (Software Development Kit) augmente les risques de sécurité et les coûts d’audit, et de subtiles incompatibilités de version et d’API peuvent entraîner des problèmes utilisateurs erratiques et difficiles à déboguer.
Pour répondre à ces défis, il est nécessaire d’avoir une culture d’ingénierie mature, incluant des ingénieurs expérimentés sachant comment déboguer une application distribuée complexe, ainsi qu’une équipe opérationnelle et fiable, sans oublier un investissement continu dans la maintenance et l’ingénierie de résilience.
Les microservices sont-ils adaptés à votre projet ?
Spoiler alert : probablement pas.
Les microservices peuvent vous offrir une flexibilité supplémentaire par rapport à d’autres systèmes. Cela ne signifie pas que cette flexibilité est forcément facile à mettre en place.
D’autre part, mettre en place des microservices n’est pas donné : ils sont notoirement coûteux à développer et à entretenir. Si vous êtes Amazon ou Netflix et que vous avez besoin de cette flexibilité supplémentaire, ces coûts finiront par être rentabilisés. Pour des entreprises de cette envergure, il est certainement judicieux d’envisager les microservices.
Mais le plus souvent, les microservices ne font qu’ajouter des coûts et une complexité supplémentaires et inutiles, poussant les organisations à adopter une technologie plus développée que nécessaire, détournant leurs ressources financières et humaines de projets ayant la capacité d’apporter une réelle valeur aux clients.
La grande majorité des entreprises seront ainsi mieux loties en adoptant une plateforme de commerce robuste, capable de leur offrir les avantages d’une plus grande rapidité de mise en place et d’exécution, d’un cadre cohérent et d’une maintenance réduite. Le tout leur permettant une extensibilité et une configuration modulaire avec des composants préconstruits si nécessaire.
Shopify est, et a toujours été, une plateforme en tant que service (PaaS). La plateforme offre un environnement d’exécution capable de fournir l’extensibilité fonctionnelle, la composition modulaire, et un ensemble large et croissant de services et d’applications développées par des tiers dont peuvent avoir besoin les détaillants.
Bien qu’il n’y ait pas de recette unique pour réussir, une plateforme bien construite peut réduire la charge de travail, les coûts et les risques associés au développement d’une plateforme e-commerce. Elle peut aussi permettre aux entreprises de réduire leurs délais de mise sur le marché, et les aider à se concentrer sur leur cœur d’expertise.
Headless vs. microservices : quelle différence ?
Le terme « headless » fait référence à un système où la partie front-end (l’interface utilisateur) est séparée de la partie back-end (où les données sont stockées et traitées). Dans le contexte du e-commerce, un système headless permettrait d’utiliser n’importe quelle interface front-end tout en se connectant à un back-end spécifique pour la gestion des produits, des commandes, etc.
Les microservices, quant à eux, désignent une architecture où une application est divisée en un ensemble de services plus petits et indépendants, chacun ayant sa propre fonctionnalité spécifique. Ces services peuvent communiquer entre eux via des API.
Ainsi, la différence majeure est que le headless fait référence à la séparation du front-end et du back-end, tandis que les microservices définissent la manière dont l’application back-end est structurée et organisée. Ainsi, il est tout à fait possible d’avoir une architecture headless qui utilise également une approche intégrant les microservices.
