Ce guide utilise les principes MACH des microservices, des technologies orientées API, du SaaS natif cloud et des applications sans tête (headless) pour intégrer de manière fluide plusieurs systèmes sur AWS. Le commerce unifié englobe tous les points de contact avec les clients afin d'offrir une expérience unifiée quel que soit le canal et de briser les silos d'une approche multicanale. En déployant ce guide, vous pouvez associer le marketing et les opérations pour améliorer la satisfaction de vos clients grâce à un engagement de marque cohérent qui renforcera la promotion.
Diagramme d’architecture
[Description du schéma d’architecture]
Étape 1
Les applications frontend utilisent un ensemble commun de microservices et d'autres applications qui sont abstraites derrière une couche d'API telle qu'AWS AppSync, créant ainsi des applications sans tête.
Étape 2
Les microservices courants tels qu'Amazon DynamoDB et Amazon Neptune fournissent une logique d'application et des données qui alimentent les applications frontend. Ils fournissent généralement des services qui différencient l'offre du détaillant de celle de ses concurrents.
Étape 3
Les applications logicielles en tant que service (SaaS) sont utilisées dans la mesure du possible pour fournir une logique applicative évolutive et mature, en particulier lorsque le service ne différencie pas le détaillant.
Étape 4
Les applications commerciales prêtes à l'emploi traditionnelles peuvent également être déployées dans des services AWS tels qu'Amazon Elastic Compute Cloud (Amazon EC2) et Amazon Relational Database Service (Amazon RDS) afin de fournir des services applicatifs qui ne sont pas disponibles en tant que SaaS ou qui n'ont pas encore été décomposés en microservices.
Étape 5
Les systèmes d'enregistrement ou les systèmes basés sur la localisation existants, tels que les systèmes de gestion d'entrepôt sur site et les logiciels de planification des ressources d'entreprise (ERP) ou de finance, sont également intégrés derrière l'API d'agrégation.
Étape 6
Tous les microservices et applications génèrent des événements qui sont publiés dans des bus d'événements personnalisés Amazon EventBridge et utilisés par des applications découplées à l'aide de règles.
Étape 7
Les données et les événements des applications sont diffusés sur une plateforme de données telle qu'Amazon Simple Storage Service (Amazon S3) ou Amazon Athena pour des analyses et des rapports historiques et en temps réel.
Étape 8
La personnalisation du contenu dynamique et des offres marketing est basée sur des événements en temps réel et transmise au client sur les canaux d'engagement de son choix. Le machine learning utilise la couche de données comme source pour générer des prévisions et des informations intelligentes.
Étape 9
Le machine learning utilise la couche de données comme source pour générer des prévisions et des informations intelligentes.
Étape 1
Les applications frontend utilisent un ensemble commun de microservices et d'autres applications qui sont abstraites derrière une couche d'API telle qu'AWS AppSync, créant ainsi des applications sans tête.
Étape 2
Les microservices courants tels qu'Amazon DynamoDB et Amazon Neptune fournissent une logique d'application et des données qui alimentent les applications frontend. Ils fournissent généralement des services qui différencient l'offre du détaillant de celle de ses concurrents.
Étape 3
Les applications logicielles en tant que service (SaaS) sont utilisées dans la mesure du possible pour fournir une logique applicative évolutive et mature, en particulier lorsque le service ne différencie pas le détaillant.
Étape 4
Les applications commerciales prêtes à l'emploi traditionnelles peuvent également être déployées dans des services AWS tels qu'Amazon Elastic Compute Cloud (Amazon EC2) et Amazon Relational Database Service (Amazon RDS) afin de fournir des services applicatifs qui ne sont pas disponibles en tant que SaaS ou qui n'ont pas encore été décomposés en microservices.
Étape 5
Les systèmes d'enregistrement ou les systèmes basés sur la localisation existants, tels que les systèmes de gestion d'entrepôt sur site et les logiciels de planification des ressources d'entreprise (ERP) ou de finance, sont également intégrés derrière l'API d'agrégation.
Étape 6
Tous les microservices et applications génèrent des événements qui sont publiés dans des bus d'événements personnalisés Amazon EventBridge et utilisés par des applications découplées à l'aide de règles.
Étape 7
Les données et les événements des applications sont diffusés sur une plateforme de données telle qu'Amazon Simple Storage Service (Amazon S3) ou Amazon Athena pour des analyses et des rapports historiques et en temps réel.
Étape 8
La personnalisation du contenu dynamique et des offres marketing est basée sur des événements en temps réel et transmise au client sur les canaux d'engagement de son choix. Le machine learning utilise la couche de données comme source pour générer des prévisions et des informations intelligentes.
Étape 9
Le machine learning utilise la couche de données comme source pour générer des prévisions et des informations intelligentes.
Piliers AWS Well-Architected
Le cadre AWS Well-Architected vous permet de comprendre les avantages et les inconvénients des décisions que vous prenez lors de la création de systèmes dans le cloud. Les six piliers du cadre vous permettent d'apprendre les bonnes pratiques architecturales pour concevoir et exploiter des systèmes fiables, sécurisés, efficaces, rentables et durables. Grâce à l'outil AWS Well-Architected Tool, disponible gratuitement dans la console de gestion AWS, vous pouvez examiner vos charges de travail par rapport à ces bonnes pratiques en répondant à une série de questions pour chaque pilier.
Le diagramme d'architecture ci-dessus est un exemple de solution créée en tenant compte des bonnes pratiques Well-Architected. Pour être totalement conforme à Well-Architected, vous devez suivre autant de bonnes pratiques Well-Architected que possible.
-
Excellence opérationnelleLire le livre blanc d'excellence opérationnelle
L'architecture proposée est capable de fonctionner à grande échelle, car elle tire parti des services gérés dans la mesure du possible. Les applications commerciales prêtes à l'emploi traditionnelles exploiteraient les métriques des instances Amazon EC2 avec les alarmes et les journaux Amazon CloudWatch. Les groupes Auto Scaling et Amazon RDS géré peuvent se rétablir en cas de panne.
-
SécuritéLire le livre blanc sur la sécurité
L'architecture utilise des services gérés dans la mesure du possible, de sorte qu'une grande partie de la responsabilité en matière de sécurité incombe à AWS, conformément aux bonnes pratiques de sécurité, notamment le chiffrement des données Amazon S3, la réduction des rôles IAM et le chiffrement Amazon DynamoDB au repos. Une identité forte est renforcée pour les consommateurs via Amazon Cognito et pour les opérateurs via des rôles IAM . Les journaux CloudWatch et AWS CloudTrail assurent la traçabilité et peuvent être utilisés avec des fonctionnalités à l'échelle de l'entreprise, telles qu'Amazon GuardDuty, AWS Security Hub, et un SIEM central.
-
FiabilitéLire le livre blanc sur la fiabilité
En utilisant les services gérés, la fiabilité est atteinte par défaut. La redondance du stockage sur Amazon S3 et DynamoDB, la mise à l'échelle des instances Amazon SageMaker, Amazon Redshift, Athena, Amazon SageMaker Canvas, Amazon Pinpoint, Amazon Personalize, AWS AppSync et EventBridge sont également des éléments hautement disponibles de par leur conception. En cas de problème, les données peuvent être relancées à partir d'événements bruts sur Amazon S3 en utilisant le même pipeline. Les événements peuvent également être relancés à l’aide de la fonctionnalité d’archivage et de réponse d’EventBridge. L’architecture de conteneurs se met à l’échelle horizontalement selon que vous choisissez Amazon Elastic Container Service (Amazon ECS) ou Amazon Elastic Kubernetes Service (Amazon EKS) s’exécutant sur AWS Fargate, et s’adapte de manière dynamique aux demandes de capacité.
-
Efficacité des performancesLire le livre blanc sur l’efficacité des performances
La mise à l'échelle est basée sur l'utilisation de services AWS sans serveur tels qu'AWS Lambda, DynamoDB, les points de terminaison SageMaker, et Amazon Redshift, dans la mesure du possible.
-
Optimisation des coûtsLire le livre blanc sur l'optimisation des coûts
L'utilisation de services gérés et sans serveur garantit un coût minimal pour l'architecture, car ils sont conçus pour être facturés uniquement lorsqu'ils sont utilisés.
-
Développement durableLire le livre blanc sur le développement durable
L'architecture proposée utilise des services gérés et sans serveur dans la mesure du possible pour adopter une approche durable, ne s'exécutant que lorsque cela est nécessaire. L'outil de calcul de l'empreinte carbone des clients AWS peut être utilisé pour obtenir des chiffres d'impact total.
Ressources d'implémentation
Un guide détaillé d'expérimentation et d'utilisation est fourni dans votre compte AWS. Chaque étape de la construction du guide, y compris le déploiement, l'utilisation et le nettoyage, est examinée pour le préparer au déploiement.
L'exemple de code est un point de départ. Il s'agit d'un document validé par l'industrie, prescriptif mais non définitif, et d'un aperçu pour vous aider à commencer.
Contenu connexe
[Titre]
Avis de non-responsabilité
Les exemples de code, les bibliothèques de logiciels, les outils de ligne de commande, les preuves de concept, les modèles ou toute autre technologie connexe (y compris tout ce qui précède qui est fourni par notre personnel) vous sont fournis en tant que contenu AWS en vertu du contrat client AWS ou de l'accord écrit pertinent entre vous et AWS (selon le cas). Vous ne devez pas utiliser ce contenu AWS dans vos comptes de production, ni sur des données de production ou autres données critiques. Vous êtes responsable des tests, de la sécurisation et de l'optimisation du contenu AWS, tel que les exemples de code, comme il convient pour une utilisation en production, en fonction de vos pratiques et normes de contrôle de qualité spécifiques. Le déploiement de contenu AWS peut entraîner des frais AWS pour la création ou l'utilisation de ressources payantes AWS, telles que l'exécution d'instances Amazon EC2 ou l'utilisation du stockage Amazon S3.
Les références à des services ou organisations tiers dans ce guide n'impliquent pas une approbation, un parrainage ou une affiliation entre Amazon ou AWS et le tiers. Les conseils fournis par AWS constituent un point de départ technique, et vous pouvez personnaliser votre intégration avec des services tiers lorsque vous déployez l'architecture.