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.
# Architecture de microservices simple sur AWS
Les applications monolithiques classiques se composent de différentes couches : une couche de présentation, une couche d'application et une couche de données. Les architectures de microservices, quant à elles, séparent les fonctionnalités en *secteurs verticaux* cohérents en fonction de domaines spécifiques, plutôt que de couches technologiques. La figure 1 illustre une architecture de référence pour une application de microservices typique sur AWS.
![\[Schéma illustrant une application de microservices typique sur AWS\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/microservices-on-aws/images/typical-microservices-application.png)
# Interface utilisateur
Les applications Web modernes utilisent souvent JavaScript des frameworks pour développer des applications d'une seule page qui communiquent avec le backend APIs. Ils APIs sont généralement créés à l'aide de Representational State Transfer (REST) ou RESTful APIs GraphQL APIs. Le contenu Web statique peut être diffusé à l'aide d'Amazon Simple Storage Service ([Amazon S3](https://aws.amazon.com/s3/)) et [d'Amazon CloudFront](https://aws.amazon.com/cloudfront/).
# Microservices
APIs sont considérés comme la *porte d'entrée* des microservices, car ils constituent le point d'entrée de la logique des applications. Généralement, l'API des services RESTful Web ou GraphQL APIs sont utilisés. Ils APIs gèrent et traitent les appels des clients, en gérant des fonctions telles que la gestion du trafic, le filtrage des demandes, le routage, la mise en cache, l'authentification et l'autorisation.
## Implémentations de microservices
AWS propose des éléments de base pour développer des microservices, notamment Amazon ECS et Amazon EKS en tant que moteurs d'orchestration de conteneurs AWS Fargate et EC2 en tant qu'options d'hébergement. AWS Lambda est un autre moyen sans serveur de créer des microservices. AWS Le choix entre ces options d'hébergement dépend des exigences du client en matière de gestion de l'infrastructure sous-jacente.
AWS Lambda vous permet de télécharger votre code, de le dimensionner automatiquement et de gérer son exécution avec une haute disponibilité. Cela élimine le besoin de gestion de l'infrastructure, ce qui vous permet d'agir rapidement et de vous concentrer sur votre logique métier. Lambda prend en charge [plusieurs langages de programmation](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html) et peut être déclenché par d'autres AWS services ou appelé directement depuis des applications Web ou mobiles.
Les applications basées sur des conteneurs ont gagné en popularité en raison de leur portabilité, de leur productivité et de leur efficacité.AWS propose plusieurs services pour créer, déployer et gérer des conteneurs.
+ [App2Container](https://aws.amazon.com/app2container/), un outil de ligne de commande pour la migration et la modernisation des applications Web Java et .NET au format conteneur. AWS A2C analyse et dresse un inventaire des applications exécutées sur du matériel nu, des machines virtuelles, des instances Amazon Elastic Compute Cloud (EC2) ou dans le cloud.
+ Amazon Elastic Container Service ([Amazon ECS](https://aws.amazon.com/ecs/)) et Amazon Elastic Kubernetes Service [(Amazon](https://aws.amazon.com/eks/) EKS) gèrent votre infrastructure de conteneurs, ce qui facilite le lancement et la maintenance des applications conteneurisées.
+ [Amazon EKS est un service Kubernetes géré permettant d'exécuter Kubernetes dans le AWS cloud et dans des centres de données sur site (Amazon EKS Anywhere).](https://aws.amazon.com/eks/eks-anywhere/) Cela étend les services cloud aux environnements sur site pour le traitement local des données à faible latence, les coûts de transfert de données élevés ou les exigences en matière de résidence des données (consultez le livre blanc intitulé « [Running Hybrid Container Workloads with Amazon EKS Anywhere](https://d1.awsstatic.com/kubernetes-pmm/eks-a/getting-started/AWS_Whitepaper_Running_Hybrid_Container_Workloads_with_Amazon_EKS_Anywhere.pdf) »). Vous pouvez utiliser tous les plug-ins et outils existants de la communauté Kubernetes avec EKS.
+ Amazon Elastic Container Service (Amazon ECS) est un service d'orchestration de conteneurs entièrement géré qui simplifie le déploiement, la gestion et le dimensionnement des applications conteneurisées. Les clients choisissent ECS pour sa simplicité et son intégration approfondie avec AWS les services.
Pour en savoir plus, consultez le blog [Amazon ECS vs Amazon EKS : making sense of AWS container services](https://aws.amazon.com/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/).
+ [AWS App Runner](https://aws.amazon.com/apprunner/)est un service d'applications de conteneur entièrement géré qui vous permet de créer, de déployer et d'exécuter des applications Web conteneurisées et des services d'API sans expérience préalable en matière d'infrastructure ou de conteneur.
+ [AWS Fargate](https://aws.amazon.com/fargate/), un moteur de calcul sans serveur, fonctionne à la fois avec Amazon ECS et Amazon EKS pour gérer automatiquement les ressources de calcul pour les applications de conteneurs.
+ [Amazon ECR](https://aws.amazon.com/ecr/) est un registre de conteneurs entièrement géré offrant un hébergement performant, qui vous permet de déployer de manière fiable des images et des artefacts d'applications où que vous soyez.
# Intégration continue et déploiement continu (CI/CD)
L'intégration continue et la livraison continue (CI/CD) constituent un élément crucial d'une DevOps initiative visant à modifier rapidement les logiciels. AWS propose des services à implémenter CI/CD pour les microservices, mais une discussion détaillée dépasse le cadre de ce document. Pour plus d'informations, consultez le AWS livre blanc [Practizing Continuous Integration and Continuous Delivery on](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html).
# Réseaux privés
AWS PrivateLink est une technologie qui améliore la sécurité des microservices en permettant des connexions privées entre votre Virtual Private Cloud (VPC) et les services pris en charge. AWS Il permet d'isoler et de sécuriser le trafic des microservices, en veillant à ce qu'il ne traverse jamais l'Internet public. Cela est particulièrement utile pour se conformer à des réglementations telles que PCI ou HIPAA.
# Banque de données
Le magasin de données est utilisé pour conserver les données nécessaires aux microservices. Les magasins les plus populaires pour les données de session sont les caches en mémoire tels que Memcached ou Redis. AWS propose les deux technologies dans le cadre du ElastiCache service géré [Amazon](https://aws.amazon.com/elasticache/).
La mise en cache entre les serveurs d'applications et une base de données est un mécanisme courant pour réduire la charge de lecture sur la base de données, ce qui peut permettre d'utiliser des ressources pour prendre en charge un plus grand nombre d'écritures. Les caches peuvent également améliorer la latence.
Les bases de données relationnelles sont toujours très populaires pour stocker des données structurées et des objets métiers. AWS propose six moteurs de base de données (Microsoft SQL Server, Oracle, MySQL, MariaDB, PostgreSQL [et Amazon Aurora) sous forme de services gérés via Amazon](https://aws.amazon.com/rds/aurora/) [Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS).
Cependant, les bases de données relationnelles ne sont pas conçues pour une échelle infinie, ce qui peut rendre difficile et chronophage l'application de techniques permettant de prendre en charge un grand nombre de requêtes.
Les bases de données NoSQL ont été conçues pour privilégier l'évolutivité, les performances et la disponibilité par rapport à la cohérence des bases de données relationnelles. Un élément important des bases de données NoSQL est qu'elles n'appliquent généralement pas de schéma strict. Les données sont réparties sur des partitions qui peuvent être redimensionnées horizontalement et sont récupérées à l'aide de clés de partition.
Les microservices individuels étant conçus pour faire une chose bien, ils disposent généralement d'un modèle de données simplifié qui peut être bien adapté à la persistance NoSQL. Il est important de comprendre que les modèles d'accès aux bases de données NoSQL sont différents de ceux des bases de données relationnelles. Par exemple, il n'est pas possible de joindre des tables. Si cela est nécessaire, la logique doit être implémentée dans l'application. Vous pouvez utiliser [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) pour créer une table de base de données capable de stocker et de récupérer n'importe quel volume de données et de traiter n'importe quel niveau de trafic de demandes. DynamoDB fournit des performances à un chiffre en millisecondes, mais certains cas d'utilisation nécessitent des temps de réponse en microsecondes. L'accélérateur [DynamoDB](https://aws.amazon.com/dynamodb/dax/) (DAX) fournit des fonctionnalités de mise en cache pour accéder aux données.
DynamoDB propose également une fonction de mise à l'échelle automatique pour ajuster dynamiquement la capacité de débit en réponse au trafic réel. Cependant, dans certains cas, la planification des capacités est difficile ou impossible en raison de pics d'activité importants de courte durée dans votre application. Dans de telles situations, DynamoDB propose une option à la demande, qui propose une tarification simple. pay-per-request DynamoDB à la demande est capable de répondre instantanément à des milliers de demandes par seconde, sans planification des capacités.
Pour plus d'informations, voir [Gestion distribuée des données](distributed-data-management.md) [Comment choisir une base de données](https://aws.amazon.com/startups/learn/maximizing-performance-with-aws-databases).
# Simplification des opérations
Pour simplifier davantage les efforts opérationnels nécessaires à l'exécution, à la maintenance et à la surveillance des microservices, nous pouvons utiliser une architecture entièrement sans serveur.
## Déploiement d'applications basées sur Lambda
Vous pouvez déployer votre code Lambda en chargeant une archive de `zip` fichiers ou en créant et en téléchargeant une image de conteneur via l'interface utilisateur de la console à l'aide d'une URI d'image Amazon ECR valide. Toutefois, lorsqu'une fonction Lambda devient complexe, c'est-à-dire qu'elle comporte des couches, des dépendances et des autorisations, le téléchargement via l'interface utilisateur peut s'avérer fastidieux en cas de modification du code.
L'utilisation de AWS CloudFormation and the AWS Serverless Application Model ([AWS SAM](https://github.com/awslabs/serverless-application-model)) ou de Terraform rationalise le processus de définition des applications sans serveur. AWS Cloud Development Kit (AWS CDK) AWS SAM, pris en charge nativement par CloudFormation, propose une syntaxe simplifiée pour spécifier les ressources sans serveur.AWS Lambda Les couches aident à gérer les bibliothèques partagées entre plusieurs fonctions Lambda, en minimisant l'encombrement des fonctions, en centralisant les bibliothèques adaptées aux locataires et en améliorant l'expérience des développeurs. Lambda SnapStart pour Java améliore les performances de démarrage des applications sensibles à la latence.
Pour déployer, spécifiez les ressources et les politiques d'autorisation dans un CloudFormation modèle, empaquetez les artefacts de déploiement et déployez le modèle. SAM Local, un AWS CLI outil, permet le développement local, le test et l'analyse d'applications sans serveur avant leur téléchargement vers Lambda.
L'intégration avec des outils tels que l' AWS Cloud9 IDE et AWS CodePipeline rationalise la création AWS CodeBuild AWS CodeDeploy, les tests, le débogage et le déploiement d'applications basées sur le SAM.
Le schéma suivant montre le déploiement de AWS Serverless Application Model ressources à l'aide CloudFormation d'outils AWS CI/CD.
![\[Schéma montrant AWS Serverless Application Model (AWS SAM)\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/microservices-on-aws/images/aws-sam.png)
## Abstraction des complexités liées à la multilocation
Dans un environnement mutualisé tel que les plateformes SaaS, il est essentiel de rationaliser les subtilités liées à la mutualisation, afin de permettre aux développeurs de se concentrer sur le développement des fonctionnalités. Cela peut être réalisé à l'aide d'outils tels que [AWS Lambda Layers](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html), qui proposent des bibliothèques partagées pour répondre à des préoccupations transversales. La raison d'être de cette approche est que les bibliothèques et les outils partagés, lorsqu'ils sont utilisés correctement, gèrent efficacement le contexte des locataires.
Cependant, ils ne devraient pas s'étendre à l'encapsulation de la logique métier en raison de la complexité et des risques qu'ils peuvent introduire. L'un des problèmes fondamentaux des bibliothèques partagées est la complexité croissante des mises à jour, qui les rend plus difficiles à gérer par rapport à la duplication de code standard. Il est donc essentiel de trouver un équilibre entre l'utilisation de bibliothèques partagées et la duplication dans la recherche de l'abstraction la plus efficace.
## Gestion des API
La gestion APIs peut prendre beaucoup de temps, en particulier lorsqu'il s'agit de plusieurs versions, d'étapes du cycle de développement, d'autorisations et d'autres fonctionnalités telles que la limitation et la mise en cache. Outre [API Gateway](https://aws.amazon.com/api-gateway/), certains clients utilisent également ALB (Application Load Balancer) ou NLB (Network Load Balancer) pour la gestion des API. Amazon API Gateway permet de réduire la complexité opérationnelle liée à la création et à la maintenance RESTful APIs. Il vous permet de créer APIs par programmation, sert de « porte d'entrée » pour accéder aux données, à la logique métier ou aux fonctionnalités de vos services principaux, à l'autorisation et au contrôle d'accès, à la limitation du débit, à la mise en cache, à la surveillance et à la gestion du trafic et fonctionne APIs sans gérer de serveurs.
La figure 3 montre comment API Gateway gère les appels d'API et interagit avec les autres composants. Les demandes provenant d'appareils mobiles, de sites Web ou d'autres services principaux sont acheminées vers le CloudFront point de présence (PoP) le plus proche afin de réduire la latence et d'offrir une expérience utilisateur optimale.
![\[Schéma illustrant le flux d'appels API Gateway\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/microservices-on-aws/images/api-gateway-call-flow.png)