AWS design de aplicativos e estratégia de migração

Projetar e documentar o estado futuro do seu aplicativo é um fator-chave para o sucesso da migração. Recomendamos criar um design para qualquer tipo de estratégia de migração, por mais simples ou complexa que seja. A criação do design revelará possíveis bloqueadores, dependências e oportunidades para otimizar o aplicativo, mesmo nos casos em que não se espera que a arquitetura mude.

Também recomendamos abordar o estado futuro do aplicativo AWS com uma lente de estratégia de migração. Nesse estágio, certifique-se de definir a aparência do aplicativo AWS como resultado dessa migração. O design resultante servirá como base para uma maior evolução após a migração.

A lista a seguir contém recursos para auxiliar no processo de design:

• AWS O Architecture Center combina ferramentas e orientações, como o AWS Well-Architected Framework. Além disso, ele fornece arquiteturas de referência que você pode usar para seu aplicativo.

• A Amazon Builders' Library contém vários recursos sobre como a Amazon cria e opera software.

• AWS A Solutions Library oferece uma coleção de soluções baseadas em nuvem, avaliadas por AWS, para dezenas de problemas técnicos e comerciais. Ele inclui uma grande coleção de arquiteturas de referência.

• AWS A orientação prescritiva fornece estratégias, guias e padrões que auxiliam no processo de design e nas melhores práticas de migração.

• AWS Documentationcontém informações sobre AWS serviços, incluindo guias do usuário e referências de API.

• O Getting Started Resource Center fornece vários tutoriais práticos e mergulhos aprofundados para aprender os fundamentos para que você possa começar a desenvolver. AWS

Dependendo de onde você está na jornada para a nuvem, talvez já existam AWS bases. Essas AWS fundações incluem o seguinte:

• Regiões da AWS foram identificados.

• As contas foram criadas ou podem ser obtidas sob demanda.

• A rede geral foi implementada.

• AWS Serviços básicos foram implantados nas contas.

Por outro lado, você pode estar no início do processo e as AWS fundações ainda não estão estabelecidas. A falta de bases estabelecidas pode limitar o escopo do design do aplicativo ou exigir mais trabalho para defini-las. Se for esse o caso, recomendamos definir e implementar o design básico da landing zone em paralelo com o trabalho de design do aplicativo. O design do aplicativo ajuda a identificar requisitos como Conta da AWS estrutura, rede, nuvem privada virtual (VPCs), intervalos de roteamento entre domínios sem classe (CIDR), serviços compartilhados, segurança e operações em nuvem.

AWS Control Towerfornece a maneira mais fácil de configurar e controlar um AWS ambiente seguro com várias contas, chamado de landing zone. AWS Control Tower cria sua landing zone usando AWS Organizations, que fornece gerenciamento e governança contínuos de contas e implementação da experiência baseada em AWS melhores práticas trabalhando com milhares de clientes à medida que eles migram para a nuvem.

Estado futuro do aplicativo

Comece estabelecendo a estratégia de migração inicial para esse aplicativo. Nesse ponto, a estratégia é considerada inicial porque pode mudar como parte do design do future state, o que pode revelar possíveis limitações. Para validar as suposições iniciais, consulte a árvore decisória de 6 Rs. Além disso, documente as possíveis fases de migração. Por exemplo, esse aplicativo será migrado em um único evento (todos os componentes serão migrados ao mesmo tempo)? Ou isso é uma migração em fases (alguns componentes são migrados posteriormente)?

Observe que as estratégias de migração para um determinado aplicativo podem não ser exclusivas. Isso ocorre porque vários tipos de R podem ser usados para migrar os componentes do aplicativo. Por exemplo, a abordagem inicial pode ser levantar e deslocar o aplicativo sem alterações. No entanto, os componentes de um aplicativo podem residir em diferentes ativos de infraestrutura que podem exigir tratamentos diversos. Por exemplo, um aplicativo é composto por três componentes, cada um executado em um servidor separado, e um dos servidores executa um sistema operacional legado que não é suportado na nuvem. Esse componente exigirá uma abordagem de replataforma, enquanto os outros dois componentes, executados em versões de servidor suportadas, poderão ser hospedados novamente. É fundamental atribuir uma estratégia de migração a cada componente do aplicativo e à infraestrutura associada que está sendo migrada.

Em seguida, documente o contexto e o problema e vincule os artefatos existentes que definem o estado atual:

• Por que esse aplicativo está sendo migrado?

• Quais são as mudanças propostas?

• Quais são os benefícios?

• Existem riscos ou bloqueadores importantes?

• Quais são as desvantagens atuais?

• O que está dentro e fora do escopo?

Repetibilidade

Durante todo o trabalho de design, considere como essa solução e a arquitetura desse aplicativo podem ser reutilizadas para outros aplicativos. Essa solução pode ser generalizada?

Requisitos

Documente os requisitos funcionais e não funcionais desse aplicativo, incluindo segurança. Isso inclui os requisitos do estado atual e futuro, dependendo da estratégia de migração escolhida. Use as informações coletadas durante a avaliação detalhada do aplicativo para orientar esse processo.

Arquitetura futura

Descreva a arquitetura futura desse aplicativo. Considere criar um modelo de diagrama reutilizável que contenha elementos básicos para seu ambiente de origem (local) e AWS ambiente de destino (por exemplo, destino Região da AWS VPCs, conta e zonas de disponibilidade).

Crie uma tabela de componentes que estão sendo migrados e componentes que serão novos. Inclua outros aplicativos e serviços (no local ou na nuvem) que interajam com esse aplicativo.

A tabela a seguir lista exemplos de componentes. Ela não representa uma arquitetura de referência nem uma configuração verificada.

Name (Nome)	Descrição	Detalhes
Aplicação	Serviço externo (conexão de entrada)	O serviço consome dados da API exposta.
DNS	Resolução de nomes (interna)	Amazon Route 53 implantado como parte das configurações básicas da conta
Application Load Balancer	Distribui o tráfego entre os serviços de back-end	Substitui o balanceador de carga local. Migrar o pool A.
Segurança de aplicações	Proteção contra DDoS	Implementado usando AWS Shield
Grupo de segurança	Firewall virtual	Limite o acesso às instâncias do aplicativo na porta 443 (entrada).
Servidor A	Front-end	Hospede novamente, usando o Amazon Elastic Compute Cloud (Amazon EC2).
Servidor B	Front-end	Hospede novamente usando a Amazon EC2.
Servidor C	Lógica de aplicação	Hospede novamente usando a Amazon EC2.
Servidor D	Lógica de aplicação	Hospede novamente usando a Amazon EC2.
Amazon Relational Database Service (Amazon RDS) — Amazon Aurora	Banco de dados	Substitui os servidores E e F
Monitoramento e alertas	Controle de mudanças	Amazon CloudWatch
Registro em log de auditoria	Controle de mudanças	AWS CloudTrail
Aplicação de patches e acesso remoto	Manutenção	AWS Systems Manager
Acesso ao recurso	Controle de acesso seguro	AWS Identity and Access Management (IAM)
Autenticação	Acesso do usuário	Amazon Cognito
Certificados	SSL/TLS	AWS Certificate Manager
API 1	API externa	Amazon API Gateway
Armazenamento de objetos	Hospedagem de imagens	Amazon Simple Storage Service (Amazon S3)
Credenciais	Gerenciamento e hospedagem de credenciais	AWS Secrets Manager
AWS Lambda função	Recuperação de credenciais de banco de dados e chaves de API	AWS Lambda
Gateway da Internet	Acesso externo à Internet	Gateway de Internet para uma VPC
Sub-rede privada 1	Back-end e banco de dados	Zona de disponibilidade 1 — VPC 1
Sub-rede privada 2	Back-end e banco de dados	Zona de disponibilidade 2 — VPC 1
Sub-rede pública 1	Front-end	Zona de disponibilidade 1 — VPC 1
Sub-rede pública 2	Front-end	Zona de disponibilidade 2 — VPC 1
Serviços de backup	Backup de bancos de dados e EC2 instâncias	AWS Backup
DR	EC2 Resiliência da Amazon	AWS Elastic Disaster Recovery

Depois que os componentes forem identificados, plote-os em um diagrama usando sua ferramenta preferida. Compartilhe o design inicial com as principais partes interessadas do aplicativo, incluindo proprietários de aplicativos, arquitetos corporativos e as equipes de plataforma e migração. Considere fazer as seguintes perguntas:

• A equipe geralmente concorda com o design?

• As equipes de operações podem apoiá-lo?

• O design pode ser evoluído?

• Há outras opções?

• O design está em conformidade com os padrões arquitetônicos e as políticas de segurança?

• Há algum componente ausente (por exemplo, repositórios de código, ferramentas de CI/CD, endpoints de VPC)?

Decisões arquitetônicas

Como parte do processo de design, você provavelmente encontrará mais opções para a arquitetura geral ou partes específicas dela. Documente essas opções junto com a justificativa para uma opção preferida ou selecionada. Essas decisões podem ser documentadas como decisões arquitetônicas.

Certifique-se de que as opções principais estejam listadas e descritas com detalhes suficientes para que um novo leitor entenda as opções e os motivos por trás da decisão de usar uma opção em vez de outra.

Ambientes de ciclo de vida de software

Documente todas as alterações nos ambientes atuais. Por exemplo, ambientes de teste e desenvolvimento serão recriados AWS e não migrados.

Tags

Descreva a marcação obrigatória e recomendada para cada componente da infraestrutura, bem como o valor da marcação para esse design.

Estratégia de migração

Nesse ponto do projeto, as suposições iniciais sobre a estratégia de migração devem ser validadas. Confirme se há consenso sobre a estratégia R escolhida. Documente a estratégia geral de migração de aplicativos e as estratégias para componentes individuais do aplicativo. Conforme mencionado anteriormente, diferentes componentes do aplicativo podem exigir diferentes tipos de R para migração.

Além disso, alinhe a estratégia de migração aos principais fatores e resultados comerciais. Além disso, descreva qualquer abordagem em fases da migração, como a movimentação de componentes em diferentes eventos de migração.

Para obter mais informações sobre como determinar seus 6 Rs, consulte as recomendações de AWS Migration Hub estratégia.

Padrões e ferramentas de migração

Com uma estratégia de migração definida para os componentes do aplicativo e da infraestrutura, agora você pode explorar padrões técnicos específicos. Por exemplo, uma estratégia de rehospedagem pode ser implementada por meio de ferramentas de migração, como. AWS Application Migration Service Se você não precisar replicar o estado ou os dados, poderá obter o mesmo resultado reimplantando o aplicativo usando uma Amazon Machine Image (AMI) e um pipeline de implantação de aplicativos.

Da mesma forma, para reformatar ou refatorar (rearquitetar) um aplicativo, você pode usar ferramentas como AWS App2Container, AWS Database Migration Service (AWS DMS), (), AWS Schema Conversion Tool.AWS SCTAWS DataSync Para conteinerização, você pode usar o Amazon Elastic Container Service (Amazon ECS), o Amazon Elastic Kubernetes Service (Amazon EKS) ou. AWS Fargate Ao recomprar, você pode usar uma AMI para um produto específico ou uma solução de software como serviço (SaaS) da. AWS Marketplace

Avalie os diferentes padrões e opções disponíveis para atingir a meta. Considere os prós e os contras e a prontidão operacional da migração. Para ajudar na sua análise, use as seguintes perguntas:

• As equipes de migração podem suportar esses padrões?

• Qual é o equilíbrio entre custo e benefícios?

• Esse aplicativo, serviço ou componente pode ser movido para um serviço gerenciado?

• Qual é o esforço para implementar esse padrão?

• Existe alguma regulamentação ou política de conformidade que impeça o uso de um padrão específico?

• Esse padrão pode ser reutilizado? Padrões reutilizáveis são preferidos. No entanto, às vezes, um padrão será usado apenas uma vez. Considere o equilíbrio entre o esforço de um padrão de uso único em relação a um padrão alternativo reutilizável.

AWS A orientação prescritiva contém uma variedade de padrões e técnicas de migração.

Gerenciamento e operações de serviços

Ao criar designs de aplicativos para migração para AWS, considere a prontidão operacional. Ao avaliar os requisitos de prontidão com suas equipes de aplicativos e infraestrutura, considere as seguintes questões:

• Eles estão prontos para operá-lo?

• Os procedimentos de resposta a incidentes estão definidos?

• Qual é o contrato de nível de serviço (SLA) esperado?

• A separação de deveres é necessária?

• As diferentes equipes estão prontas para coordenar as ações de apoio?

• Quem é responsável pelo quê?

Considerações de transição

Considerando a estratégia e os padrões de migração, o que é importante saber no momento em que o aplicativo é migrado? O planejamento de transição é uma atividade de pós-design. No entanto, documente todas as considerações sobre atividades e requisitos que possam ser previstos. Por exemplo, documente a exigência de realizar uma prova de conceito, se aplicável, e descreva os requisitos de teste, auditoria ou validação.

Riscos, suposições, problemas e dependências

Documente todos os riscos em aberto, suposições e possíveis problemas que ainda não foram resolvidos. Atribua uma propriedade clara a esses itens e acompanhe o progresso para que o design e a estratégia gerais possam ser aprovados para implementação. Além disso, documente as principais dependências para implementar esse design.

Estimando o custo de operação

Para estimar o custo de sua AWS arquitetura alvo, use a Calculadora AWS de preços. Adicione seus componentes de infraestrutura conforme definido pelo seu projeto e obtenha um custo operacional estimado. Considere as licenças de software que são necessárias para os componentes do seu aplicativo e que ainda não estão incluídas nos AWS serviços que você usará.