# REL 3 Comment concevoir l'architecture de service de votre charge de travail ?
Créez des charges de travail hautement évolutives et fiables à l'aide d'une architecture orientée service (SOA) ou d'une architecture de microservices. La SOA consiste à rendre les composants logiciels réutilisables via les interfaces de service. L'architecture des microservices va plus loin, en particulier en rendant les composants plus petits et plus simples.
**Topics**
+ [REL03-BP01 Choisir comment segmenter votre charge de travail](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Créer des services axés sur des domaines d'activité et la fonctionnalité](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fournir des contrats de service par API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Choisir 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 et de 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 souhaité :** 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 :**
+ La version [microservice *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 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 évolutivité.
+ 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 de risque exposé 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 orientée service (SOA) ou une architecture de microservices (ou, dans de rares cas, une architecture monolithique). Même si vous choisissez de commencer avec une architecture monolithe, vous devez vous assurer qu'elle est modulaire et peut évoluer vers une SOA ou vers des microservices à mesure que votre produit se développe avec son adoption par les utilisateurs. Une SOA et une architecture de microservices offrent une segmentation plus petite. Si elle est préférable en tant qu'architecture moderne évolutive et fiable, il faut prendre en compte des compromis, notamment 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.
![\[Schéma comparant les architectures monolithique, orientée services et de microservices\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Étapes d'implémentation
+ Déterminer l'architecture adaptée pour refactoriser ou créer votre application. SOA et les microservices offrent respectivement une segmentation plus petite, ce qui est préférable pour une architecture moderne évolutive et fiable. SOA peut constituer un bon compromis pour parvenir à une segmentation plus réduite tout en évitant certaines des complexités des microservices. Pour en savoir plus, voir [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html).
+ 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 en savoir plus, voir [Implémentation des microservices sur AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Tenir compte du modèle [*Figuier étrangleur* pour](https://martinfowler.com/bliki/StranglerFigApplication.html) refactoriser une architecture monolithique en composants plus petits. Cela implique de remplacer petit à petit des composants d'une application spécifique par de nouveaux services et applications. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) agit comme le point de départ de la refactorisation incrémentielle. Pour en savoir plus, voir [Migrer sans interruption vers des charges de travail existantes sur site à l'aide d'un modèle Figuier étrangleur](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ L'implémentation d'une architecture de microservices peut exiger un mécanisme de découverte de service pour permettre à ces services distribués de communiquer entre eux. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) peut être utilisé avec des architectures orientées service afin de fournir une découverte et un accès fiables aux services. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) peut également être utilisé pour la découverte dynamique de service basée sur un DNS.
+ Si vous migrez d'une architecture monolithique vers une architecture orientée service, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) peut combler le fossé en tant que bus de services lors de la reconception des 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 d'utiliser un type de base de données relationnelle ou non relationnelle. Pour en savoir plus, voir [De SQL à NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Niveau d'effort du plan d'implémentation :** Élevé
## Ressources
**Bonnes pratiques associées :**
+ [REL03-BP02 Créer des services axés sur des domaines d'activité et la fonctionnalité](rel_service_architecture_business_domains.md)
**Documents connexes :**
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Qu'est-ce que l'architecture orientée service ?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
+ [Qu'est-ce qu'AWS App Mesh ?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Exemples connexes :**
+ [Atelier sur la modernisation itérative des applications](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vidéos connexes :**
+ [Offrir l'excellence avec l'architecture de microservices sur AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Créer des services axés sur des domaines d'activité et la fonctionnalité
Une architecture orientée services (SOA) crée des services avec des fonctions bien définies dictées par les besoins métier. Les microservices utilisent des modèles de domaine et un contexte délimité pour limiter ces éléments de façon à ce que chaque service fasse une seule chose. En vous concentrant sur des fonctionnalités spécifiques, vous pouvez différencier les exigences de fiabilité des différents services et cibler les investissements avec plus de précision. Un problème commercial concis et une petite équipe associée à chaque service permettent également une mise à l'échelle organisationnelle plus facile.
Lors de la conception d'une architecture de microservices, il est intéressant d'utiliser la conception pilotée par le domaine (DDD) pour modéliser le problème métier à l'aide d'entités. Par exemple, pour le site Amazon.com, les entités peuvent inclure le colis, la livraison, le calendrier, le prix, la remise et la devise. Ensuite, le modèle est subdivisé en modèles plus petits à l'aide du [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)dans lequel les entités qui partagent des fonctions et des attributs similaires sont regroupées. Par conséquent, si nous reprenons l'exemple Amazon.com, le colis, la livraison et le calendrier feraient partie du contexte d'expédition, tandis que le prix, la remise et la devise appartiendraient au contexte de tarification. La divisison en contextes permet de faire émerger un modèle de délimitation des microservices.
![\[Modèle expliquant comment délimiter les microservices\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/building-services.png)
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Concevez votre charge de travail en fonction de vos domaines d'activité et de leurs fonctionnalités respectives. En vous concentrant sur des fonctionnalités spécifiques, vous pouvez différencier les exigences de fiabilité des différents services et cibler les investissements avec plus de précision. Un problème commercial concis et une petite équipe associée à chaque service permet également une mise à l'échelle organisationnelle plus facile.
+ Effectuez une analyse de domaine pour définir une conception orientée domaine (DDD) pour votre charge de travail. Ensuite, vous pouvez choisir un type d'architecture pour répondre aux besoins de votre charge de travail.
+ [Comment convertir un monolithe en microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Premiers pas avec DDD en présence de systèmes hérités](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans « Domain-Driven Design: Tackling Complexity in the Heart of Software »](https://www.amazon.com/gp/product/0321125215)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Décomposez vos services en composants aussi petits que possible. Avec l'architecture de microservices, vous pouvez séparer votre charge de travail en composants ayant la fonctionnalité minimale favorisant une mise à l'échelle organisationnelle et l'agilité.
+ Définissez l'API pour la charge de travail ainsi que ses objectifs de conception, ses limites et toutes autres considérations liées à son utilisation.
+ Définissez l'API
+ La définition de l'API doit tenir compte de la croissance et prévoir des paramètres supplémentaires.
+ Définissez les disponibilités conçues.
+ Votre API peut avoir plusieurs objectifs de conception pour différentes fonctions.
+ Établir des limites
+ Utilisez des tests pour définir les limites des capacités de votre charge de travail.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans « Domain-Driven Design: Tackling Complexity in the Heart of Software »](https://www.amazon.com/gp/product/0321125215)
+ [Premiers pas avec DDD en présence de systèmes hérités](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Comment convertir un monolithe en microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Fournir des contrats de service par API
Les contrats de service sont des accords documentés entre les équipes sur l'intégration de service et incluent une définition d'API lisible par la machine, des limites de taux et des attentes en matière de performance. Une stratégie de gestion des versions permet aux clients de continuer à utiliser l'API existante et de procéder à la migration de leurs applications vers la nouvelle API lorsqu'ils sont prêts. Le déploiement peut se produire à tout moment, tant que le contrat n'est pas enfreint. L'équipe du fournisseur de services peut utiliser la pile technologique de son choix pour satisfaire aux clauses du contrat d'API. De même, le consommateur du service peut utiliser sa propre technologie.
Les microservices s'appuient sur le concept d'architecture orientée service (SOA) pour créer des services offrant un ensemble minimal de fonctionnalités. Chaque service publie une API et des objectifs de conception, des limites et d'autres considérations pour l'utilisation du service. L'ensemble forme un *contrat* avec les applications appelantes. Ce système permet d'obtenir trois principaux avantages :
+ Le service fait face à un problème commercial concis devant être géré et une petite équipe doit y remédier. Cela permet un meilleur scaling-up organisationnel.
+ L'équipe peut déployer à tout moment, tant qu'elle respecte les exigences de son API et de son autre contrat.
+ Elle peut utiliser la pile technologique de son choix, dès lors qu'elle respecte les exigences de son API et de son autre contrat.
Amazon API Gateway est un service totalement géré qui permet aux développeurs de créer, de publier, de gérer, de surveiller et de sécuriser facilement des API à n'importe quelle échelle. Il gère toutes les tâches liées à l'acceptation et au traitement de plusieurs centaines de milliers d'appels d'API simultanés, notamment la gestion du trafic, le contrôle des autorisations et des accès, la surveillance et la gestion de la version de l'API. Grâce à OpenAPI Specification (OAS), anciennement appelé Swagger Specification, vous pouvez définir votre contrat d'API et l'importer dans API Gateway. Avec API Gateway, vous pouvez ensuite gérer les versions et déployer les API.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Faible
## Directives d'implémentation
+ Fournir des contrats de service par API : les contrats de service sont des accords documentés entre les équipes sur l'intégration de service et incluent une définition d'API lisible par machine, des limites de taux et des attentes en termes de performances.
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Une stratégie de gestion des versions permet aux clients de continuer à utiliser l'API existante et de procéder à la migration de leurs applications vers la nouvelle API lorsqu'ils sont prêts.
+ Amazon API Gateway est un service entièrement géré qui permet aux développeurs de créer facilement des API à n'importe quelle échelle. Grâce à OpenAPI Specification (OAS), anciennement appelé Swagger Specification, vous pouvez définir votre contrat d'API et l'importer dans API Gateway. Avec API Gateway, vous pouvez ensuite gérer les versions et déployer les API.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)