Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
REL03-BP01 Choisissez comment segmenter votre charge de travail
La segmentation de la charge de travail est importante lorsqu’il s’agit de déterminer les exigences de résilience de votre application. L’architecture monolithique doit être évitée dans la mesure du possible. À la place, réfléchissez bien aux composants de l’application capables d’être divisés en microservices. Selon les exigences de votre application, il peut s'agir d'une combinaison d'une architecture orientée services (SOA) avec des microservices dans la mesure du possible. Les charges de travail capables d’absence d’état sont davantage en mesure d’être déployées en tant que microservices.
Résultat désiré : les charges de travail doivent être supportables, évolutives et aussi faiblement couplées que possible.
Lorsque vous choisissez comment segmenter votre charge de travail, comparez les avantages aux complexités. Ce qui convient pour un nouveau produit en course pour un premier lancement est différent de ce dont a besoin une charge de travail conçue pour augmenter d’échelle. Lors de la refactorisation d’une architecture monolithique existante, vous devez évaluer comment l’application prendra en charge une décomposition vers l’absence d’état. La division de services en microservices permet aux petites équipes bien définies de les développer et les gérer. Toutefois, les services plus petits peuvent créer des complexités, dont une latence supérieure, un débogage plus complexe et une charge opérationnelle accrue.
Anti-modèles courants :
-
Le microservice Death Star
est une situation dans laquelle les composants atomiques deviennent si interdépendants que l’échec de l’un d’entre eux résulte en un échec encore plus important, ce qui rend les composants aussi rigides et fragiles qu’une architecture monolithique.
Avantages liés au respect de cette pratique :
-
L’utilisation de segments plus petits permet une plus grande agilité, une plus grande flexibilité organisationnelle et une capacité de mise à l’échelle.
-
L’impact réduit des interruptions de service.
-
Les composants de l’application peuvent avoir différentes exigences de disponibilité, pouvant être pris en charge par une segmentation plus atomique.
-
Des responsabilités bien définies pour les équipes prenant en charge la charge de travail.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
Choisissez votre type d’architecture en fonction de la façon dont vous segmenterez votre charge de travail. Choisissez une architecture SOA ou une architecture de microservices (ou dans de rares cas, une architecture monolithique). Même si vous choisissez de commencer par une architecture monolithe, vous devez vous assurer qu'elle est modulaire et qu'elle puisse finalement évoluer vers des microservices au fur et à SOA mesure que votre produit évolue avec l'adoption par les utilisateurs. SOAet les microservices offrent respectivement une segmentation plus petite, ce qui est préférable en tant qu'architecture moderne, évolutive et fiable, mais certains compromis doivent être pris en compte, en particulier lors du déploiement d'une architecture de microservices.
Le principal compromis est que vous avez maintenant une architecture pour le calcul distribué qui peut compliquer le respect des exigences en matière de latence des utilisateurs et qui complexifie le suivi et le débogage des interactions des utilisateurs. AWS X-Ray peut vous aider à résoudre ce problème. Un autre effet à prendre en compte est la hausse de la complexité opérationnelle à mesure que vous augmentez le nombre d’applications que vous gérez, ce qui nécessite le déploiement de plusieurs composants indépendants.
Architectures monolithique, orientée services et de microservices
Étapes d’implémentation
-
Déterminer l’architecture adaptée pour refactoriser ou créer votre application. SOAet les microservices offrent respectivement une segmentation plus petite, ce qui est préférable en tant qu'architecture moderne, évolutive et fiable. SOApeut être un bon compromis pour réduire la segmentation tout en évitant certaines des complexités des microservices. Pour plus de détails, consultez la section Compromis des microservices
. -
Si votre charge de travail est appropriée et que votre organisation peut la prendre en charge, vous devez utiliser une architecture de microservices pour obtenir la meilleure agilité et la meilleure fiabilité. Pour plus de détails, voir Implémentation de microservices sur AWS.
-
Envisagez de suivre le modèle Strangler Fig
pour refactoriser un monolithe en composants plus petits. Cela implique le remplacement progressif de composants spécifiques de l’application par de nouvelles applications et de nouveaux services. AWS Migration Hub Refactor Spaces sert de point de départ à la refactorisation incrémentielle. Pour plus de détails, consulter Migrer sans interruption vers des charges de travail existantes sur site à l’aide d’un modèle Figuier étrangleur . -
La mise en œuvre de microservices peut nécessiter un mécanisme de découverte de services pour permettre à ces services distribués de communiquer entre eux. AWS App Meshpeut être utilisé avec des architectures orientées services pour permettre une découverte et un accès fiables aux services. AWS Cloud Map
peut également être utilisé pour la découverte de services dynamique DNS basée sur des données. -
Si vous passez d'un monolithe à un bus de service, Amazon SOA MQ peut vous aider à combler cette lacune lors de la refonte d'applications existantes dans le cloud.
-
Pour les architectures monolithiques existantes avec une base de données partagée unique, choisissez comment réorganiser les données en segments plus petits. Vous pouvez les réorganiser par unité commerciale, modèle d’accès ou structure de données. À ce stade du processus de refactorisation, vous devez choisir de passer à un type de base de données relationnel ou non relationnel (nonSQL). Pour plus de détails, voir De SQL à Non SQL.
Niveau d’effort du plan d’implémentation : élevé
Ressources
Bonnes pratiques associées :
Documents connexes :
Exemples connexes :
Vidéos connexes :
