Questa guida utilizza i principi MACH di microservizi, API-first, SaaS nativo del cloud e applicazioni headless per integrare perfettamente più sistemi su AWS. Il commercio unificato comprende tutti i punti di contatto rivolti ai clienti per offrire un'esperienza unificata indipendentemente dal canale e abbatte i silos di un approccio multicanale. Implementando questa guida potrai unire marketing e operazioni, in modo da migliorare la soddisfazione dei tuoi clienti con un coinvolgimento coerente del marchio che ne aumenterà il sostegno.
Diagramma di architettura
[Descrizione del diagramma dell’architettura]
Fase 1
Le applicazioni front-end, o head, utilizzano un set comune di microservizi e altre applicazioni astratte dietro un livello API come AWS AppSync per creare applicazioni headless.
Fase 2
I microservizi comuni, come ad esempio HAQM DynamoDB e HAQM Neptune, forniscono la logica e i dati applicativi necessari a supportare le applicazioni dell'esperienza di front-end. In genere, offrono funzionalità che contraddistinguono l'offerta del rivenditore da quella della concorrenza.
Fase 3
Le applicazioni Software-as-a-Service (SaaS) sono comunemente utilizzate per fornire una logica applicativa matura e costantemente aggiornata, soprattutto in situazioni in cui il servizio offerto non rappresenta un elemento di differenziazione per il rivenditore.
Fase 4
Le tradizionali applicazioni commerciali pronte all'uso (COTS) possono anche essere implementate in servizi AWS come HAQM Elastic Compute Cloud (HAQM EC2) e HAQM Relational Database Service (HAQM RDS) per fornire servizi applicativi che non sono disponibili come SaaS o non sono ancora stati scomposti in microservizi.
Fase 5
Tramite l'API di aggregazione è possibile integrare anche i sistemi preesistenti di gestione dei record o basati sulla posizione, come ad esempio i sistemi di gestione del magazzino on-premises, quelli per la pianificazione delle risorse aziendali (ERP) o i software finanziari.
Fase 6
Tutti i microservizi e le applicazioni producono eventi che vengono pubblicati su router di eventi personalizzati di HAQM EventBridge e utilizzati da applicazioni disaccoppiate utilizzando regole.
Fase 7
I dati e gli eventi delle applicazioni vengono trasmessi in streaming su una piattaforma di dati come HAQM Simple Storage Service (HAQM S3) o HAQM Athena per fornire analisi e report storici e in tempo reale.
Fase 8
La personalizzazione di contenuti dinamici e offerte di marketing si basa su eventi in tempo reale e viene inoltrata al cliente tramite i canali di coinvolgimento prescelti. Il machine learning utilizza il livello di dati come origine dalla quale generare previsioni e fornire approfondimenti intelligenti.
Fase 9
Il machine learning utilizza il livello di dati come origine dalla quale generare previsioni e fornire approfondimenti intelligenti.
Fase 1
Le applicazioni front-end, o head, utilizzano un set comune di microservizi e altre applicazioni astratte dietro un livello API come AWS AppSync per creare applicazioni headless.
Fase 2
I microservizi comuni, come ad esempio HAQM DynamoDB e HAQM Neptune, forniscono la logica e i dati applicativi necessari a supportare le applicazioni dell'esperienza di front-end. In genere, offrono funzionalità che contraddistinguono l'offerta del rivenditore da quella della concorrenza.
Fase 3
Le applicazioni Software-as-a-Service (SaaS) sono comunemente utilizzate per fornire una logica applicativa matura e costantemente aggiornata, soprattutto in situazioni in cui il servizio offerto non rappresenta un elemento di differenziazione per il rivenditore.
Fase 4
Le tradizionali applicazioni commerciali pronte all'uso (COTS) possono anche essere implementate in servizi AWS come HAQM Elastic Compute Cloud (HAQM EC2) e HAQM Relational Database Service (HAQM RDS) per fornire servizi applicativi che non sono disponibili come SaaS o non sono ancora stati scomposti in microservizi.
Fase 5
Tramite l'API di aggregazione è possibile integrare anche i sistemi preesistenti di gestione dei record o basati sulla posizione, come ad esempio i sistemi di gestione del magazzino on-premises, quelli per la pianificazione delle risorse aziendali (ERP) o i software finanziari.
Fase 6
Tutti i microservizi e le applicazioni producono eventi che vengono pubblicati su router di eventi personalizzati di HAQM EventBridge e utilizzati da applicazioni disaccoppiate utilizzando regole.
Fase 7
I dati e gli eventi delle applicazioni vengono trasmessi in streaming su una piattaforma di dati come HAQM Simple Storage Service (HAQM S3) o HAQM Athena per fornire analisi e report storici e in tempo reale.
Fase 8
La personalizzazione di contenuti dinamici e offerte di marketing si basa su eventi in tempo reale e viene inoltrata al cliente tramite i canali di coinvolgimento prescelti. Il machine learning utilizza il livello di dati come origine dalla quale generare previsioni e fornire approfondimenti intelligenti.
Fase 9
Il machine learning utilizza il livello di dati come origine dalla quale generare previsioni e fornire approfondimenti intelligenti.
Principi di Well-Architected
Il framework AWS Well-Architected consente di valutare i pro e i contro delle decisioni prese durante il processo di creazione di sistemi nel cloud. I sei principi del framework consentono di apprendere le best practice architetturali per la progettazione e il funzionamento di sistemi affidabili, sicuri, efficienti, convenienti e sostenibili. Grazie allo strumento AWS Well-Architected, disponibile gratuitamente nella Console di gestione AWS, puoi rivedere i tuoi carichi di lavoro rispetto a queste best practice rispondendo a una serie di domande per ciascun principio.
Il diagramma dell'architettura sopra riportato è un esempio di una soluzione creata tenendo conto delle best practice Well-Architected. Per essere completamente Well-Architected, dovresti seguire il maggior numero possibile di best practice.
-
Eccellenza operativaLeggi il whitepaper sull'eccellenza operativa
L'architettura proposta è in grado di funzionare su larga scala poiché sfrutta i servizi gestiti, ove possibile. Le tradizionali applicazioni COTS sfrutterebbero i parametri delle istanze HAQM EC2 con gli allarmi e i log di HAQM CloudWatch. I gruppi con dimensionamento automatico e HAQM RDS gestito possono essere ripristinati in caso di errori.
-
SicurezzaLeggi il whitepaper sulla sicurezza
Quando possibile, l'architettura adotta un approccio basato sull'utilizzo di servizi gestiti in modo da trasferire gran parte della responsabilità della sicurezza ad AWS, che segue le migliori pratiche di sicurezza, tra cui la crittografia dei dati di HAQM S3, la definizione dei ruoli IAM e la crittografia dei dati inattivi di HAQM DynamoDB. L'identità forte viene applicata per i consumatori tramite HAQM Cognito, e per gli operatori tramite i ruoli IAM. I log di CloudWatch e AWS CloudTrail offrono tracciabilità e possono essere utilizzati con funzionalità a livello di organizzazione, come HAQM GuardDuty, Centrale di sicurezza AWS e un SIEM centrale.
-
AffidabilitàLeggi il whitepaper sull'affidabilità
Grazie ai servizi gestiti, è possibile ottenere l'affidabilità in modo predefinito. La ridondanza nell'archiviazione su HAQM S3 e DynamoDB, così come il dimensionamento delle istanze HAQM SageMaker, HAQM Redshift, Athena, HAQM SageMaker Canvas, HAQM Pinpoint, HAQM Personalize, AWS AppSynce EventBridge sono, per progettazione, altamente disponibili. In caso di problemi, i dati possono essere riprodotti da eventi non elaborati su HAQM S3 utilizzando la stessa pipeline. Gli eventi possono anche essere riprodotti utilizzando la funzionalità di archiviazione e risposta di EventBridge. L'architettura dei container è scalabile orizzontalmente, con la possibilità di scegliere tra HAQM Elastic Container Service (HAQM ECS) o HAQM Elastic Kubernetes Service (HAQM EKS) in esecuzione su AWS Fargate, e si adatta dinamicamente alle richieste di capacità.
-
Efficienza delle prestazioniLeggi il whitepaper sull'efficienza delle prestazioni
La scalabilità si basa sull'uso di servizi AWS serverless come AWS Lambda, DynamoDB, gli endpoint HAQM SageMaker e HAQM Redshift, ove possibile.
-
Ottimizzazione dei costiLeggi il whitepaper sull'ottimizzazione dei costi
L'utilizzo di servizi gestiti e serverless consente di minimizzare i costi dell'architettura, poiché questi servizi sono progettati per essere addebitati solo quando sono effettivamente in uso.
-
SostenibilitàLeggi il whitepaper sulla sostenibilità
L'architettura proposta utilizza servizi gestiti e serverless ove possibile per garantire un approccio sostenibile, in esecuzione solo quando necessario. Lo strumento relativo all'impronta di carbonio dei clienti AWS può essere utilizzato per ottenere dati sull'impatto totale.
Risorse per l'implementazione
Viene fornita una guida dettagliata da sperimentare e utilizzare all'interno del tuo account AWS. Ogni fase della creazione della guida, inclusa l'implementazione, l'utilizzo e la pulizia, viene esaminata per prepararla all'implementazione.
Il codice di esempio è un punto di partenza. È convalidato dal settore, prescrittivo ma non definitivo, ed è il punto di partenza per iniziare a lavorare.
Contenuti correlati
[Titolo]
Avvertenza
Il codice di esempio, le librerie software, gli strumenti della linea di comando, le proof of concept, i modelli e le altre tecnologie correlate (comprese tutte le tecnologie di cui sopra fornite dal nostro personale) vengono forniti all'utente sotto forma di contenuto AWS ai sensi dell'Accordo cliente AWS o del relativo accordo scritto stipulato tra l'utente e AWS (a seconda dei casi). Non bisogna utilizzare il contenuto AWS in questione negli account di produzione o sui dati di produzione o altri dati fondamentali. L'utente è responsabile dei test, della sicurezza e dell'ottimizzazione del contenuto AWS, come il codice di esempio, in modo appropriato per l'utilizzo in produzione sulla base delle pratiche e degli standard di qualità specifici. L'implementazione del contenuto AWS può comportare costi AWS per la creazione o l'utilizzo di risorse AWS addebitabili, quali le istanze HAQM EC2 in esecuzione o l'archiviazione HAQM S3.
Eventuali riferimenti a servizi o organizzazioni di terze parti contenuti in questa guida non implicano alcuna approvazione, sponsorizzazione o affiliazione tra HAQM o AWS e dette terze parti. La guida di AWS è un punto di partenza tecnico e l'integrazione con servizi di terze parti può essere personalizzata al momento dell'implementazione dell'architettura.