![\"\"](\"https:\/\/lh4.googleusercontent.com\/LJNBLc7RQmE82gtn20rlG5_f5-9x7L_OLHhH4tO4adLJka9RTjUPe0WzVFh7ksCVDJJwYkj1FAeuLw1LSmu6byQZevHtsP4GVQMZdmpI6YLp8W4g6rAvEVFqNYtSAOXmsSELETIIkoLLwE0KnQzzMQ\")
<\/figure>\n\nL’architecture monolithique est le mod\u00e8le traditionnel de conception d’un programme logiciel construit comme une unit\u00e9 combin\u00e9e qui est ferm\u00e9e et ind\u00e9pendante des autres applications. Cette architecture est consid\u00e9r\u00e9e comme l’approche traditionnelle de la construction et de la cr\u00e9ation d’applications en tant qu’unit\u00e9s uniques et unifi\u00e9es. En g\u00e9n\u00e9ral, cette approche consiste en une interface utilisateur c\u00f4t\u00e9 client, une application c\u00f4t\u00e9 serveur et une base de donn\u00e9es. Une architecture monolithique est un r\u00e9seau informatique \u00e9tendu dot\u00e9 d’une grande base de code qui int\u00e8gre toutes les pr\u00e9occupations de l’entreprise. <\/p>\n\n
Lorsque vous souhaitez modifier une application monolithique, vous devez mettre \u00e0 jour l’ensemble de la pile en acc\u00e9dant \u00e0 la base de code et en construisant et installant une version actualis\u00e9e de l’interface c\u00f4t\u00e9 service.<\/p>\n\n
Les logiciels monolithiques sont g\u00e9n\u00e9ralement constitu\u00e9s de trois composants ;<\/p>\n\n
- \n
- Interface utilisateur c\u00f4t\u00e9 client – consiste en des pages HTML ou Javascript ex\u00e9cut\u00e9es dans un navigateur.<\/li>\n\n\n\n
- Application c\u00f4t\u00e9 serveur – traite les requ\u00eates HTTP, met en \u0153uvre la logique propre au domaine, r\u00e9cup\u00e8re et met \u00e0 jour les donn\u00e9es de la base de donn\u00e9es et remplit les vues HTML \u00e0 envoyer au navigateur.<\/li>\n\n\n\n
- Base de donn\u00e9es – contient de nombreux tableaux, g\u00e9n\u00e9ralement dans un syst\u00e8me de gestion de base de donn\u00e9es relationnelle.<\/li>\n<\/ul>\n\n
Ce mod\u00e8le permet de rationaliser le pipeline ETL au fur et \u00e0 mesure que les donn\u00e9es sont transf\u00e9r\u00e9es dans une base de donn\u00e9es unique \u00e0 travers le monolithe. Cependant, m\u00eame si vous appliquez un mod\u00e8le de microservices, vous pouvez \u00e9galement simplifier votre pipeline ETL avec une solution sans code comme Xplenty. <\/p>\n\n
Avantages de l’architecture monolithique<\/strong><\/p>\n\n
Une organisation peut tirer profit d’une architecture monolithique en fonction de diff\u00e9rents facteurs. L’utilisation d’une architecture monolithique lors de la construction de votre application pr\u00e9sente plusieurs avantages, dont voici quelques-uns. <\/p>\n\n
- \n
- Traitement ais\u00e9 des probl\u00e8mes susceptibles d’affecter l’ensemble du logiciel. En g\u00e9n\u00e9ral, les d\u00e9veloppeurs appellent ces probl\u00e8mes des pr\u00e9occupations transversales, notamment la surveillance des performances, la mise en cache, la journalisation et le traitement. Tout est plac\u00e9 au m\u00eame endroit dans une application monolithique et n’est pas dispers\u00e9 entre les microservices. L’architecture monolithique minimisera consid\u00e9rablement les difficult\u00e9s li\u00e9es \u00e0 la r\u00e9solution de ces probl\u00e8mes. <\/li>\n\n\n\n
- Simplicit\u00e9. Lorsqu’il s’agit de cr\u00e9er des applications de petite ou moyenne taille, l’architecture monolithique est plus simple \u00e0 d\u00e9velopper, \u00e0 d\u00e9ployer et \u00e0 mettre \u00e0 l’\u00e9chelle. La plupart des environnements de d\u00e9veloppement int\u00e9gr\u00e9s et des moteurs de d\u00e9veloppement prennent en charge l’architecture monolithique en tant que mod\u00e8le traditionnel de cr\u00e9ation d’applications. Les tests de bout en bout sont beaucoup plus faciles \u00e0 r\u00e9aliser lorsqu’on n’a affaire qu’\u00e0 une seule base de code \u00e9tendue. <\/li>\n\n\n\n
- Performance. Les applications monolithiques sont g\u00e9n\u00e9ralement plus performantes que les microservices. Une API peut servir le m\u00eame objectif dans les applications monolithiques parce qu’elle a consolid\u00e9 le code et la m\u00e9moire. <\/li>\n<\/ul>\n\n
Inconv\u00e9nients de l’architecture monolithique<\/strong><\/p>\n\n
Les applications monolithiques sont pratiques jusqu’\u00e0 ce qu’elles se d\u00e9veloppent et que leur mise \u00e0 l’\u00e9chelle devienne un probl\u00e8me. Le d\u00e9ploiement d’une l\u00e9g\u00e8re modification d’une fonction n\u00e9cessite de compiler et de tester l’ensemble de la plateforme, ce qui va \u00e0 l’encontre de l’approche agile moderne adopt\u00e9e par la plupart des d\u00e9veloppeurs. L’architecture monolithique pr\u00e9sente des inconv\u00e9nients, dont voici quelques-uns. <\/p>\n\n
- \n
- Potentiel d’\u00e9volutivit\u00e9. Le potentiel d’\u00e9volutivit\u00e9 d’une application monolithique d\u00e9pend de sa taille. Si vous souhaitez concevoir une application \u00e9tendue et complexe, il existe de meilleures architectures logicielles que l’architecture monolithique. Dans une application plus complexe, l’\u00e9volutivit\u00e9 sera consid\u00e9rable. Elle deviendra une pr\u00e9occupation consid\u00e9rable, car il sera plus difficile de g\u00e9rer et de contenir un projet logiciel aggrav\u00e9 dans le cadre d’une vaste base de code. <\/li>\n\n\n\n
- Flexibilit\u00e9. Les applications monolithiques sont rigides en mati\u00e8re de flexibilit\u00e9. Avec une application monolithique, attendez-vous \u00e0 l’utiliser pendant un certain temps sans changer votre pile technologique. Or, avec une architecture monolithique, il est pratiquement impossible de modifier votre pile technologique. Vous devrez r\u00e9\u00e9crire votre logiciel pour y int\u00e9grer la pile que vous souhaitez mettre en \u0153uvre, ce qui n\u00e9cessite des ressources consid\u00e9rables et n’en vaut pas la peine. <\/li>\n\n\n\n
- L’architecture monolithique complique votre code. La base de code \u00e9tant unique, elle devient exponentiellement complexe au fur et \u00e0 mesure que l’application se d\u00e9veloppe et \u00e9volue. Ces changements ou mises \u00e0 jour n\u00e9cessitent une coordination \u00e0 l’\u00e9chelle de l’application, mais les utilisateurs peuvent les \u00e9tendre au-del\u00e0 d’une seule partie. <\/li>\n<\/ul>\n\n
Architecture de microservices<\/strong><\/p>\n\n
<\/figure>\n\n
Alors qu’une application monolithique est une unit\u00e9 int\u00e9gr\u00e9e unique, l’architecture microservice la divise en plusieurs unit\u00e9s autonomes plus petites. Ces unit\u00e9s ex\u00e9cutent g\u00e9n\u00e9ralement chaque processus d’application comme un service ind\u00e9pendant. Par cons\u00e9quent, tous les services ont leur base de donn\u00e9es et leur logique et ex\u00e9cutent des fonctions sp\u00e9cifiques. <\/p>\n\n
L’architecture microservice est une approche dans laquelle une application unique est d\u00e9velopp\u00e9e comme une suite de petits services, chacun fonctionnant dans son processus et communiquant avec des m\u00e9canismes l\u00e9gers, g\u00e9n\u00e9ralement une API de ressources HTTP. Sam Newman, consultant ind\u00e9pendant, affirme que \u00ab\u00a0les microservices sont de petits services qui fonctionnent ensemble\u00a0\u00bb. <\/p>\n\n
L’architecture microservice est constitu\u00e9e d’une collection de services minuscules et autonomes. Chaque service est ind\u00e9pendant et met en \u0153uvre une capacit\u00e9 commerciale ou technique de l’application qu’il encapsule dans un contexte d\u00e9limit\u00e9. Un contexte d\u00e9limit\u00e9 fait r\u00e9f\u00e9rence \u00e0 une section naturelle de l’organisation et fournit une limite claire \u00e0 l’int\u00e9rieur de laquelle le mod\u00e8le de domaine existe. <\/p>\n\n
L’architecture microservices modifie consid\u00e9rablement la relation entre la base de donn\u00e9es et l’application. Ainsi, au lieu d’utiliser une base de donn\u00e9es unique avec d’autres microservices, chaque microservice a sa propre base de donn\u00e9es. Une base de donn\u00e9es par microservice est indispensable si vous souhaitez b\u00e9n\u00e9ficier de cette architecture pour assurer un couplage l\u00e2che. <\/p>\n\n
Composants de l’architecture microservice<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-pixabay-326461-1024x678.jpg\")
<\/figure>\n\nLes microservices sont petits, autonomes et faiblement coupl\u00e9s. Une petite \u00e9quipe de programmeurs peut \u00e9crire et soutenir le service puisque chaque service poss\u00e8de sa propre base de donn\u00e9es. Les services sont responsables de la pr\u00e9servation de leurs donn\u00e9es ou de leur \u00e9tat externe. Cela va \u00e0 l’encontre de l’approche traditionnelle, o\u00f9 une couche de donn\u00e9es s\u00e9par\u00e9e g\u00e8re la pr\u00e9servation des donn\u00e9es. Voici quelques-uns des composants d’une architecture microservices <\/p>\n\n
- \n
- Orchestration. Ce composant s’occupe de placer les services sur les n\u0153uds, de reconna\u00eetre les d\u00e9faillances, de stabiliser les services sur les n\u0153uds, etc. En g\u00e9n\u00e9ral, ce composant est une technologie \u00ab\u00a0off-the-shell\u00a0\u00bb comme Kubernetes plut\u00f4t qu’une technologie personnalis\u00e9e. <\/li>\n\n\n\n
- Passerelle API. La passerelle API est le point d’entr\u00e9e des clients. Au lieu d’appeler les services directement, les clients t\u00e9l\u00e9phonent \u00e0 la passerelle API et transmettent l’appel aux services appropri\u00e9s dans le back-end. <\/li>\n<\/ul>\n\n
Avantages de l’architecture microservices<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-sebastian-voortman-411207-1024x683.jpg\")
<\/figure>\n\nL’architecture microservices a progress\u00e9 gr\u00e2ce au nuage, \u00e0 la conteneurisation et aux syst\u00e8mes hyperconnect\u00e9s. De plus, l’architecture microservices pr\u00e9sente certains avantages pour l’utilisateur, comme indiqu\u00e9 ci-dessous. <\/p>\n\n
- \n
- Am\u00e9lioration de l’agilit\u00e9. Avec ce type d’architecture logicielle, les d\u00e9veloppeurs peuvent travailler sur des modules ind\u00e9pendants. Chaque d\u00e9veloppeur peut cr\u00e9er et d\u00e9ployer un module ind\u00e9pendamment, ce qui minimise les frictions op\u00e9rationnelles de l’\u00e9quipe. Il est \u00e9galement facile de contr\u00f4ler les corrections de bogues et les mises \u00e0 jour. Vous pouvez mettre \u00e0 jour un service sans red\u00e9ployer l’ensemble de l’application et annuler la mise \u00e0 jour en cas de probl\u00e8me. Habituellement, lorsqu’un bogue est d\u00e9couvert dans une partie d’une application monolithique, il peut bloquer l’ensemble du processus de mise \u00e0 jour. <\/li>\n\n\n\n
- Meilleure \u00e9volutivit\u00e9. L’architecture microservices peut faire \u00e9voluer chaque service de mani\u00e8re ind\u00e9pendante. Elle vous permet de faire \u00e9voluer les sous-syst\u00e8mes qui ont besoin de plus de ressources sans faire \u00e9voluer l’ensemble de l’application. La mise \u00e0 l’\u00e9chelle d’applications monolithiques prend du temps et engendre des co\u00fbts, m\u00eame lorsqu’elle n’est pas n\u00e9cessaire. L’utilisation d’un orchestrateur comme Service Fabric ou Kubernetes permet d’augmenter la densit\u00e9 des services sur un seul h\u00f4te, ce qui permet une utilisation efficace des ressources. <\/li>\n\n\n\n
- L’architecture microservices encourage la d\u00e9centralisation. Un gouvernement central bien cibl\u00e9 est essentiel pour une gouvernance r\u00e9ussie. Ce type de structure serait facile \u00e0 d\u00e9manteler, politique mise \u00e0 part. La centralisation des choses en un seul endroit signifie que si l’une d’entre elles ne fonctionne pas, c’est tout le syst\u00e8me qui s’effondre. L’ensemble du syst\u00e8me s’effondre. L’architecture microservices favorise la d\u00e9centralisation, ce qui permet aux d\u00e9veloppeurs d’\u00eatre plus ind\u00e9pendants et de travailler en \u00e9quipe, quel que soit l’endroit o\u00f9 ils se trouvent. La flexibilit\u00e9 est \u00e9galement au rendez-vous. Vous pouvez mettre en \u0153uvre plusieurs piles technologiques dans une seule application. Cela vous aide \u00e0 s\u00e9lectionner la pile technologique la plus influente pour concevoir un service. <\/li>\n<\/ul>\n\n
Inconv\u00e9nients de l’architecture microservices<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-tim-gouw-52608-1024x685.jpg\")
<\/figure>\n\nLes avantages des microservices sont trop beaux pour \u00eatre gratuits. Les inconv\u00e9nients d’une architecture de microservices sont un peu difficiles \u00e0 supporter. Aussi, vous devez vous assurer que vous choisissez l’architecture logicielle exemplaire pour votre entreprise. <\/p>\n\n
- \n
- Complexit\u00e9. L’architecture microservices comporte plusieurs parties mobiles par rapport \u00e0 l’architecture monolithique. Chaque service est simple, mais le syst\u00e8me dans son ensemble devient complexe. La communication entre les services est compliqu\u00e9e ; les API encouragent g\u00e9n\u00e9ralement cette communication et sont g\u00e9n\u00e9ralement mises en \u0153uvre pour relier les plateformes logicielles. La complexit\u00e9 des applications microservices augmente avec le nombre de microservices. <\/li>\n\n\n\n
- Congestion du r\u00e9seau. L’utilisation d’un grand nombre de petits services peut entra\u00eener une communication interservices. Et lorsque la cha\u00eene de d\u00e9pendances des services devient tr\u00e8s longue, la latence suppl\u00e9mentaire devient un probl\u00e8me. Cela signifie que vous devrez cr\u00e9er des API avec soin. Pensez aux formats de s\u00e9rialisation et cherchez \u00e0 utiliser des mod\u00e8les de communication asynchrones. <\/li>\n\n\n\n
- D\u00e9veloppement et tests. La conception d’un petit service qui d\u00e9pend d’autres services d\u00e9pendants n\u00e9cessite une approche diff\u00e9rente de l’\u00e9criture d’un programme traditionnel en couches. Les outils disponibles ne sont pas toujours con\u00e7us pour fonctionner avec des d\u00e9pendances de service. Le remaniement \u00e0 travers les fronti\u00e8res des services devient ardu, et les tests des d\u00e9pendances de services sont complexes, en particulier lorsque l’application \u00e9volue rapidement. <\/li>\n<\/ul>\n\n
Migrer d’un monolithe \u00e0 des microservices<\/strong><\/p>\n\n
![\"\"](\"https:\/\/devologyx.io\/wp-content\/uploads\/2023\/07\/pexels-liz-lauren-6000599-1024x683.jpg\")
<\/figure>\n\nL’\u00e9volutivit\u00e9 est la principale raison pour laquelle les d\u00e9veloppeurs passent d’une architecture monolithique \u00e0 une architecture microservices. L’\u00e9volutivit\u00e9 des composants rarement utilis\u00e9s est insignifiante. Les composants utilis\u00e9s par la plupart des utilisateurs doivent \u00eatre pris en compte en premier lieu lors de la migration. Voici une proc\u00e9dure typique pour passer d’un syst\u00e8me monolithique \u00e0 une approche microservices. <\/p>\n\n
- \n
- Identifiez les composants logiques.<\/li>\n<\/ol>\n\n
Les donn\u00e9es utilis\u00e9es dans le syst\u00e8me comportent principalement trois \u00e9l\u00e9ments d’information : les objets de donn\u00e9es, les actions, les t\u00e2ches \u00e0 effectuer et les cas d’utilisation. Les constructions logiques sont les objets de donn\u00e9es qui repr\u00e9sentent les donn\u00e9es utilis\u00e9es. Les actions de donn\u00e9es sont des commandes permettant d’ex\u00e9cuter une t\u00e2che sur un ou plusieurs objets de donn\u00e9es. Les t\u00e2ches \u00e0 effectuer repr\u00e9sentent les fonctions que les utilisateurs appellent pour remplir leur r\u00f4le. <\/p>\n\n
- \n
- Refactoriser les composants<\/li>\n<\/ol>\n\n
Lorsque tous les composants ont \u00e9t\u00e9 identifi\u00e9s et assembl\u00e9s, organisez-les en interne – certaines fonctionnalit\u00e9s en double doivent \u00eatre \u00e9limin\u00e9es avant d’appliquer le microservice. Il ne doit y avoir qu’un seul microservice qui ex\u00e9cute une fonction. <\/p>\n\n
- \n
- Identifier les d\u00e9pendances des composants<\/li>\n<\/ol>\n\n
Apr\u00e8s avoir identifi\u00e9 et organis\u00e9 les composants \u00e0 migrer, le syst\u00e8me doit reconna\u00eetre les d\u00e9pendances au sein des composants. Pour ce faire, il utilise g\u00e9n\u00e9ralement une analyse statique du code source pour rechercher les appels entre les diff\u00e9rentes biblioth\u00e8ques et les diff\u00e9rents types de donn\u00e9es. <\/p>\n\n
- \n
- Groupes de composants ponctuels<\/li>\n<\/ol>\n\n
L’architecte du syst\u00e8me doit se concentrer sur la cat\u00e9gorisation des composants en groupes pouvant \u00eatre transform\u00e9s en microservices. L’objectif est de trouver un petit ensemble d’objets et leurs actions \u00e9l\u00e9mentaires qui doivent \u00eatre s\u00e9par\u00e9s dans le syst\u00e8me final. <\/p>\n\n
- \n
- Cr\u00e9er une API pour l’interface utilisateur \u00e0 distance<\/li>\n<\/ol>\n\n
L’interface utilisateur \u00e0 distance est la seule approche de la communication entre le syst\u00e8me, ses composants et ses utilisateurs. Cette interface doit \u00eatre syst\u00e9matiquement planifi\u00e9e et \u00e9volutive afin d’\u00e9viter les probl\u00e8mes au fur et \u00e0 mesure de la croissance du syst\u00e8me. <\/p>\n\n
- \n
- D\u00e9placez les groupes de composants vers les macroservices.<\/li>\n<\/ol>\n\n
Les macro-services ont tendance \u00e0 avoir une position mod\u00e9r\u00e9e en ce qui concerne la r\u00e9partition des r\u00e9f\u00e9rentiels de donn\u00e9es et \u00e0 permettre des interactions plus complexes avec les objets de donn\u00e9es. Il est donc essentiel de consid\u00e9rer leur utilisation comme une \u00e9tape provisoire pour achever la migration. <\/p>\n\n
- \n
- Passer des macroservices aux microservices<\/li>\n<\/ol>\n\n
L’extraction des objets de donn\u00e9es, des composants et des fonctions de l’architecture monolithique vers les macroservices permet de comprendre comment ces composants peuvent \u00eatre divis\u00e9s en microservices. N’oubliez pas que chaque microservice contient sa base de donn\u00e9es et n’ex\u00e9cute qu’un ensemble limit\u00e9 d’actions sur ses objets de donn\u00e9es. <\/p>\n\n
- \n
- D\u00e9ploiement et essais<\/li>\n<\/ol>\n\n
L’\u00e9tape suivante comprend les tests d’int\u00e9gration et le d\u00e9ploiement lorsque le microservice est pr\u00eat. L’architecture monolithique doit \u00eatre adapt\u00e9e pour utiliser le nouveau service pour ses demandes de donn\u00e9es au lieu de la base de donn\u00e9es existante. <\/p>\n\n
Conclusion<\/strong><\/p>\n\n
Adopter une architecture de microservices n’est pas une approche universelle. Bien qu’elle soit de plus en plus c\u00e9l\u00e8bre, l’architecture monolithique pr\u00e9sente des avantages robustes et importants par rapport aux microservices, ainsi que des points forts. Vous devriez commencer par une architecture monolithique pour valider votre nouvelle id\u00e9e commerciale. Une petite \u00e9quipe de d\u00e9veloppeurs vous accompagne pour d\u00e9velopper une application simple sans avoir besoin de microservices. <\/p>\n\n
L’architecture microservices est plus satisfaisante pour les applications \u00e9tendues et complexes. Elle fournit des solutions de produits pour un syst\u00e8me complexe avec plusieurs fonctions et services au sein d’une seule application. Les microservices sont parfaits pour les plateformes couvrant de nombreux parcours et flux de travail des utilisateurs. <\/p>\n","protected":false},"excerpt":{"rendered":"
Je suis s\u00fbr que vous avez rencontr\u00e9 un sujet comme l’architecture monolithique VS microservices moins souvent que vous n’avez entendu les gens discuter des paradigmes de programmation, des outils ou des cadres logiciels. Vous devez choisir le type d’architecture logicielle d\u00e8s le d\u00e9but de votre projet. Il permet de d\u00e9finir la conception de votre application […]<\/p>\n","protected":false},"author":1,"featured_media":16699,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false,"_jet_sm_ready_style":"","_jet_sm_style":"","_jet_sm_controls_values":"","_jet_sm_fonts_collection":"","_jet_sm_fonts_links":"","footnotes":""},"categories":[85],"tags":[],"writer":[],"class_list":["post-19702","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-non-classifiee"],"_links":{"self":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19702","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/comments?post=19702"}],"version-history":[{"count":1,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19702\/revisions"}],"predecessor-version":[{"id":19705,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/posts\/19702\/revisions\/19705"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media\/16699"}],"wp:attachment":[{"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/media?parent=19702"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/categories?post=19702"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/tags?post=19702"},{"taxonomy":"writer","embeddable":true,"href":"https:\/\/devologyx.io\/fr\/wp-json\/wp\/v2\/writer?post=19702"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- D\u00e9ploiement et essais<\/li>\n<\/ol>\n\n
- Passer des macroservices aux microservices<\/li>\n<\/ol>\n\n
- D\u00e9placez les groupes de composants vers les macroservices.<\/li>\n<\/ol>\n\n
- Cr\u00e9er une API pour l’interface utilisateur \u00e0 distance<\/li>\n<\/ol>\n\n
- Groupes de composants ponctuels<\/li>\n<\/ol>\n\n
- Identifier les d\u00e9pendances des composants<\/li>\n<\/ol>\n\n
- Refactoriser les composants<\/li>\n<\/ol>\n\n
- Identifiez les composants logiques.<\/li>\n<\/ol>\n\n