Essa orientação utiliza os princípios MACH para microsserviços, priorização de APIs, SaaS nativo da nuvem e aplicações headless (descentralizadas) para integrar com perfeição diversos sistemas na AWS. O comércio unificado engloba todos os pontos de contato voltados para o cliente para oferecer uma experiência unificada, independentemente do canal, e elimina os silos de uma abordagem multicanal. Ao implantar essa orientação, você pode unir o marketing e as operações para melhorar a satisfação do cliente com um engajamento coerente com a marca que aumentará a representação.
Diagrama de arquitetura
[Descrição do diagrama de arquitetura]
Etapa 1
As aplicações de front-end, ou heads, usam um conjunto comum de microsserviços e outras aplicações que são abstraídas por trás de uma camada de API, como o AWS AppSync, criando assim aplicações headless.
Etapa 2
Os microsserviços comuns, como o Amazon DynamoDB e o Amazon Neptune, fornecem lógica e dados de aplicações para potencializar as aplicações de experiência de front-end. Eles geralmente fornecem serviços que diferenciam a oferta do varejista das ofertas da concorrência.
Etapa 3
Aplicações de software como serviço (SaaS) são usadas sempre que possível para fornecer uma lógica de aplicação perene e madura, especialmente quando o serviço não gera diferenciação para o varejista.
Etapa 4
Aplicações comerciais prontas para uso tradicionais também podem ser implantadas em serviços da AWS, como o Amazon Elastic Compute Cloud (Amazon EC2) e o Amazon Relational Database Service (Amazon RDS), para fornecer serviços de aplicações que não estão disponíveis como SaaS ou que ainda não foram decompostas em microsserviços.
Etapa 5
Os sistemas existentes de registros ou baseados em localização, como sistemas de gerenciamento de armazéns e software de planejamento de recursos empresariais (ERP) ou financeiro on-premises, também são integrados por trás da API de agregação.
Etapa 6
Todos os microsserviços e aplicações produzem eventos que são publicados nos barramentos de eventos personalizados do Amazon EventBridge e consumidos por aplicações desacopladas usando regras.
Etapa 7
Os dados e eventos de aplicações são transmitidos para uma plataforma de dados como o Amazon Simple Storage Service (Amazon S3) ou o Amazon Athena para produzir análises e relatórios históricos e em tempo real.
Etapa 8
A personalização de ofertas de marketing e conteúdo dinâmico é baseada em eventos em tempo real e enviada para os clientes nos canais de engajamento escolhidos. O machine learning usa a camada de dados como fonte para gerar previsões e insights inteligentes.
Etapa 1
As aplicações de front-end, ou heads, usam um conjunto comum de microsserviços e outras aplicações que são abstraídas por trás de uma camada de API, como o AWS AppSync, criando assim aplicações headless.
Etapa 2
Os microsserviços comuns, como o Amazon DynamoDB e o Amazon Neptune, fornecem lógica e dados de aplicações para potencializar as aplicações de experiência de front-end. Eles geralmente fornecem serviços que diferenciam a oferta do varejista das ofertas da concorrência.
Etapa 3
Aplicações de software como serviço (SaaS) são usadas sempre que possível para fornecer uma lógica de aplicação perene e madura, especialmente quando o serviço não gera diferenciação para o varejista.
Etapa 4
Aplicações comerciais prontas para uso tradicionais também podem ser implantadas em serviços da AWS, como o Amazon Elastic Compute Cloud (Amazon EC2) e o Amazon Relational Database Service (Amazon RDS), para fornecer serviços de aplicações que não estão disponíveis como SaaS ou que ainda não foram decompostas em microsserviços.
Etapa 5
Os sistemas existentes de registros ou baseados em localização, como sistemas de gerenciamento de armazéns e software de planejamento de recursos empresariais (ERP) ou financeiro on-premises, também são integrados por trás da API de agregação.
Etapa 6
Todos os microsserviços e aplicações produzem eventos que são publicados nos barramentos de eventos personalizados do Amazon EventBridge e consumidos por aplicações desacopladas usando regras.
Etapa 7
Os dados e eventos de aplicações são transmitidos para uma plataforma de dados como o Amazon Simple Storage Service (Amazon S3) ou o Amazon Athena para produzir análises e relatórios históricos e em tempo real.
Etapa 8
A personalização de ofertas de marketing e conteúdo dinâmico é baseada em eventos em tempo real e enviada para os clientes nos canais de engajamento escolhidos. O machine learning usa a camada de dados como fonte para gerar previsões e insights inteligentes.
Pilares do Well-Architected
O AWS Well-Architected Framework ajuda a entender as vantagens e as desvantagens das decisões tomadas durante a criação de sistemas na nuvem. Os seis pilares do Framework permitem que você aprenda as melhores práticas de arquitetura, a fim de projetar e operar sistemas confiáveis, seguros, eficientes, econômicos e sustentáveis. Com a Ferramenta AWS Well-Architected, disponível gratuitamente no Console de Gerenciamento da AWS, você pode avaliar suas workloads em relação às práticas recomendadas ao responder a uma série de questões para cada pilar.
O diagrama de arquitetura acima exemplifica a criação de uma solução pautada nas melhores práticas do Well-Architected. Para ser totalmente Well-Architected, é preciso respeitar a maior quantidade possível das melhores práticas desse framework.
-
Excelência operacionalLeia o whitepaper sobre excelência operacional
A arquitetura proposta é capaz de operar em grande escala, pois utiliza os serviços gerenciados sempre que possível. As aplicações comerciais prontas para uso tradicionais utilizariam as métricas de instâncias do Amazon EC2 com alarmes e logs do Amazon CloudWatch. Grupos do Auto Scaling e o Amazon RDS gerenciado podem se recuperar de falhas.
-
SegurançaLeia o whitepaper sobre segurança
A arquitetura usa serviços gerenciados sempre que possível. Portanto, grande parte da responsabilidade de segurança recai sobre a AWS para seguir as práticas recomendadas de segurança, incluindo dados criptografados do Amazon S3, perfis do IAM com escopo reduzido e criptografia do Amazon DynamoDB em repouso. Uma identidade forte é imposta aos consumidores por meio do Amazon Cognito e aos operadores por meio de perfis do IAM. O CloudWatch Logs e o AWS CloudTrail fornecem rastreabilidade e podem ser usados com recursos de toda a organização, como o Amazon GuardDuty, o AWS Security Hub e uma solução de Security Information and Event Management (SIEM – Gerenciamento de Informações e Eventos de Segurança) central.
-
ConfiabilidadeLeia o whitepaper sobre confiabilidade
Usando serviços gerenciados, a confiabilidade é alcançada por padrão. A redundância no armazenamento no Amazon S3 e no DynamoDB, a escalabilidade das instâncias do SageMaker, o Amazon Redshift, o Athena, o Amazon Forecast, o Amazon Pinpoint, o Amazon Personalize, o AWS AppSync e o EventBridge também oferecem alta disponibilidade por padrão. Em caso de problemas, os dados podem ser reproduzidos desde eventos brutos no Amazon S3 usando o mesmo pipeline. Os eventos também podem ser reproduzidos usando a funcionalidade de arquivamento e resposta do EventBridge. A arquitetura do contêiner é escalada horizontalmente com base em uma escolha entre o Amazon Elastic Container Service (Amazon ECS) ou o Amazon Elastic Kubernetes Service (Amazon EKS) executados no Fargate e se adapta dinamicamente às demandas de capacidade.
-
Eficiência de performanceLeia o whitepaper sobre eficiência da performance
A escalabilidade é baseada no uso de serviços com tecnologia sem servidor da AWS, como o AWS Lambda, DynamoDB, endpoints do SageMaker e Amazon Redshift, sempre que possível.
-
Otimização de custosBaixe o whitepaper sobre otimização de custos
O uso de serviços gerenciados e sem servidor garante custo mínimo para a arquitetura, pois eles são cobrados somente quando em uso.
-
SustentabilidadeLeia o whitepaper sobre sustentabilidade
A arquitetura proposta usa serviços gerenciados e sem servidor sempre que possível para adotar uma abordagem sustentável em que os serviços funcionam somente quando são necessários. A ferramenta de pegada de carbono do cliente da AWS pode ser usada para obter números de impacto total.
Recursos de implementação
Com sua conta da AWS, um guia detalhado é fornecido para experimentação e uso. Cada etapa da criação das orientações, incluindo implantação, uso e limpeza, é examinada para prepará-las para a implantação.
O código de exemplo é um ponto de partida. Ele é validado para o setor, é prescritivo, mas não definitivo, e mostra o que há por trás de tudo para ajudar você a começar.
Conteúdo relacionado
[Título]
Aviso de isenção de responsabilidade
O código de exemplo, as bibliotecas de software, as ferramentas de linha de comando, as provas de conceito, os modelos ou outra tecnologia relacionada (incluindo qualquer uma das anteriores fornecidas por nossa equipe) são fornecidos a você como Conteúdo da AWS nos termos do Contrato de Cliente da AWS ou o contrato por escrito pertinente entre você e a AWS (o que for aplicável). Você não deve usar esse Conteúdo da AWS em suas contas de produção, na produção ou em outros dados essenciais. Você é responsável por testar, proteger e otimizar o Conteúdo da AWS, como código de exemplo, conforme apropriado para uso em nível de produção com base em suas práticas e padrões específicos de controle de qualidade. A implantação de Conteúdo da AWS pode gerar cobranças da AWS para criar ou usar recursos cobráveis, como executar instâncias do Amazon EC2 ou usar armazenamento do Amazon S3.
As referências a serviços ou organizações terceirizadas nesta orientação não implicam em endosso, patrocínio ou afiliação entre a Amazon ou a AWS e terceiros. A orientação da AWS é um ponto de partida técnico, e você pode personalizar sua integração com serviços de terceiros ao implantar a arquitetura.