Projetar arquitetura de carga de trabalho antes da migração

Este artigo descreve o processo e as considerações para projetar o estado migrado pretendido de uma carga de trabalho na nuvem. O artigo analisa as atividades que fazem parte da definição da arquitetura de uma carga de trabalho dentro de uma iteração.

O artigo sobre racionalização incremental indica que algumas suposições arquitetônicas fazem parte de qualquer transformação de negócios que inclua uma migração. Este artigo esclarece pressupostos típicos. Ele também aponta alguns obstáculos que você pode evitar e identifica oportunidades para acelerar o valor dos negócios desafiando as suposições arquitetônicas. Esse modelo incremental para projetar a arquitetura ajuda as equipes a se moverem mais rapidamente e obterem resultados de negócios mais cedo.

Basear o projeto de arquitetura em pressupostos comuns

As seguintes suposições são típicas para qualquer esforço de migração:

• Suponha uma carga de trabalho de infraestrutura como serviço (IaaS). A migração de cargas de trabalho envolve principalmente a movimentação de servidores de um datacenter físico para um datacenter em nuvem por meio de uma migração IaaS. O processo normalmente requer redesenvolvimento ou reconfiguração mínima. Essa abordagem é conhecida como migração de elevador e turno .
• Mantenha a arquitetura consistente. Fazer alterações na arquitetura central durante uma migração aumenta consideravelmente a complexidade. A depuração de um sistema alterado numa nova plataforma apresenta muitas variáveis que podem ser difíceis de isolar. As cargas de trabalho devem sofrer apenas pequenas alterações durante a migração, e quaisquer alterações devem ser cuidadosamente testadas.
• Planeje o redimensionamento de ativos. Suponha que poucos ativos locais usam totalmente qualquer recurso. Antes ou durante a migração, os ativos são redimensionados para melhor se adequarem aos requisitos reais de uso. Ferramentas como o Azure Migrate e o Modernize fornecem dimensionamento com base no uso real.
• Capture os requisitos de continuidade de negócios e recuperação de desastres (BCDR). Se você tiver um contrato de nível de serviço (SLA) acordado para a carga de trabalho já negociada com a empresa, continue a usar o SLA após a migração para o Azure. Se um SLA ainda não estiver definido, defina um antes de projetar a carga de trabalho na nuvem para garantir que você projete adequadamente.
• Planeje o tempo de inatividade da migração. Assim como não atender aos requisitos de SLA, o tempo de inatividade que ocorre quando você promove uma carga de trabalho para a produção pode ter um efeito adverso nos negócios. Às vezes, as soluções que precisam fazer a transição com o mínimo de tempo de inatividade precisam de alterações na arquitetura. Antes de começar o planejamento de lançamento, suponha que uma compreensão geral dos requisitos de tempo de inatividade seja estabelecida.
• Defina padrões de tráfego de usuários e aplicativos. As soluções existentes podem depender de padrões e soluções de roteamento de rede existentes. Identifique os recursos necessários para dar suporte ao uso atual da rede.
• Planeje para evitar conflitos de rede. Quando você consolida datacenters em um único provedor de nuvem, é provável que crie conflitos no DNS (Sistema de Nomes de Domínio) ou em outras estruturas de rede. Durante a migração, é importante projetar para evitar esses conflitos e evitar interrupções nos sistemas de produção hospedados na nuvem.
• Planeje tabelas de roteamento. Certifique-se de que seu projeto inclua um plano para modificar tabelas de roteamento se você consolidar redes ou datacenters. Considere os requisitos de roteamento entre datacenters.

Arquitetura de projeto para uma zona de pouso

Na fase Pronto do Cloud Adoption Framework, sua organização implantou serviços de plataforma compartilhada como parte da adoção das zonas de aterrissagem do Azure. Em Preparar sua zona de destino para migração, você preparou a zona de destino para receber cargas de trabalho migradas.

Com base nesse planejamento, você pode supor que os seguintes componentes de migração estejam instalados:

• A conectividade híbrida conecta suas redes do Azure às suas redes locais.
• Os dispositivos de segurança de rede, como o Firewall do Azure, lidam com a inspeção do tráfego fora da sua carga de trabalho.
• As políticas do Azure para impor práticas de governança, como requisitos de registro, regiões permitidas, serviços não permitidos e outros controles, estão ativas.
• Um espaço de trabalho de Logs do Azure Monitor para log compartilhado é configurado no Azure Monitor.
• Recursos de identidade compartilhada para dar suporte a servidores ingressados no domínio ou outras necessidades de identidade são estabelecidos.

Se esses fundamentos de migração não forem estabelecidos, sua organização deverá revisitar imediatamente a fase Pronto para atender a essas necessidades. Sem esses componentes, sua migração provavelmente terá atrasos e contratempos e será menos bem-sucedida.

A carga de trabalho que você está projetando tem uma assinatura atribuída a ela, idealmente por meio de um processo de venda automática de assinatura. A assinatura pode conter várias cargas de trabalho ou apenas uma carga de trabalho, dependendo de como sua organização concluiu sua organização de recursos para cargas de trabalho. Se você migrar uma carga de trabalho com muitos ambientes de aplicativos, poderá até ter várias assinaturas com base nas diretrizes para ambientes de aplicativos.

Projetar arquitetura de rede de carga de trabalho

Planeje implantar recursos específicos do aplicativo em uma assinatura específica e planeje projetar uma rede virtual dedicada para a carga de trabalho. Para obter mais informações, consulte as diretrizes para projetar sua arquitetura de rede. Você deve se concentrar especialmente na segmentação de redes virtuais.

Sua rede provavelmente precisa de recursos como balanceadores de carga e outros recursos de entrega de aplicativos. Você pode usar o guia de arquitetura de N camadas para planejar esses recursos no Azure.

Projetar dependências de carga de trabalho

Suas ferramentas de avaliação de migração devem fornecer uma maneira de fazer análise de dependência, como análise de dependência no Azure Migrar e Modernizar. A ferramenta ajuda a identificar interdependências entre servidores.

Além de planejar a arquitetura para a carga de trabalho em si, talvez seja necessário considerar as dependências de carga de trabalho para carga de trabalho. Por exemplo, algumas cargas de trabalho podem precisar de comunicação frequente. Nesse caso, planejar suas ondas de migração e dependências para levar em conta esse requisito ajuda a tornar a migração bem-sucedida.

Você pode usar as orientações na Central de Arquitetura do Azure, como para redes faladas , para projetar como as cargas de trabalho interconectadas funcionam após a migração.

Prepare-se para adotar computação confidencial

Um subconjunto de suas cargas de trabalho com requisitos de soberania pode levar ao uso de computação confidencial. Como parte de uma implantação de zona de pouso soberano, grupos de gerenciamento para computação confidencial são criados.

Dentro de um contexto de soberania, o uso de computação confidencial requer o Cofre de Chaves do Azure e chaves gerenciadas pelo cliente como um serviço de suporte. Para obter mais informações, consulte criptografia com chaves gerenciadas pelo cliente no Microsoft Cloud for Sovereignty.

Atualize sua estimativa inicial de nuvem

Ao concluir o projeto de arquitetura, reveja sua estimativa de nuvem para garantir que você ainda esteja dentro do orçamento planejado. À medida que você adiciona serviços de suporte, como balanceadores de carga ou backups, os custos podem mudar. Embora você possa usar ferramentas como casos de negócios no Azure Migrate and Modernize para fazer exercícios detalhados de gerenciamento de custos, você deve revisitar periodicamente suas estimativas à medida que ajusta seu design de arquitetura.

Se você estiver familiarizado com os processos tradicionais de aquisição de TI, estimar recursos na nuvem pode parecer estranho. Quando você adota tecnologias de nuvem, a aquisição muda de um modelo de despesas de capital rígido e estruturado para um modelo de despesas operacionais fluido. Planejar uma migração para a nuvem geralmente é a primeira vez que uma organização ou equipe de TI encontra essa mudança.

No modelo tradicional de despesas de capital, uma equipe de TI tenta combinar o poder de compra para várias cargas de trabalho em vários programas. Essa abordagem centraliza um pool de ativos de TI compartilhados que podem dar suporte a cada uma dessas soluções. No modelo de nuvem de despesas operacionais, os custos podem ser diretamente atribuídos às necessidades de suporte de cargas de trabalho individuais, equipes ou unidades de negócios. Proporciona a uma organização uma atribuição mais direta de custos aos clientes internos e aos objetivos de negócio que estes suportam. Esta abordagem mais dinâmica da gestão financeira é frequentemente designada por operações financeiras (FinOps). Embora o FinOps não seja uma consideração específica do Azure, pode ser útil ter uma compreensão expandida do FinOps. Para obter mais informações, consulte O que é FinOps?.

Ao projetar sua arquitetura de carga de trabalho para migração, você pode usar a calculadora de preços com suas informações de avaliação para entender o preço de toda a carga de trabalho.

Além disso, depois que sua carga de trabalho for migrada, você deve continuar a trabalhar para otimizar os custos da carga de trabalho. Para obter mais informações sobre como as organizações podem amadurecer suas habilidades de gerenciamento de custos, consulte Melhorar a disciplina de gerenciamento de custos.

Saiba quando mudar a sua arquitetura

As migrações tendem a se concentrar na manutenção de uma arquitetura existente e na transição para sua plataforma de nuvem. No entanto, há momentos em que você pode precisar rearquitetar sua carga de trabalho, mesmo para migração. Esta lista fornece exemplos de quando você pode precisar fazer alterações na arquitetura antes de migrar:

• Pagamento da dívida técnica. Algumas cargas de trabalho envelhecidas carregam uma alta quantidade de dívida técnica. A dívida técnica pode levar a desafios de longo prazo, aumentando os custos de hospedagem com qualquer provedor de nuvem. Quando a dívida técnica aumenta de forma não natural os custos de hospedagem, você deve avaliar arquiteturas alternativas.
• Melhorar a fiabilidade. As linhas de base de operação padrão fornecem um grau de confiabilidade e recuperação na nuvem. Algumas equipes de carga de trabalho podem exigir SLAs mais altos, o que pode levar a alterações na arquitetura.
• Cargas de trabalho de alto custo. Durante a migração, você deve otimizar todos os ativos para alinhar o dimensionamento com o uso real. Algumas cargas de trabalho podem exigir modificações arquitetônicas para resolver problemas de custo específicos.
• Requisitos de desempenho. Quando o desempenho da carga de trabalho afeta diretamente os negócios, pode ser necessária uma consideração extra na arquitetura.
• Aplicações seguras. Os requisitos de segurança tendem a ser implementados centralmente e normalmente são aplicados a todas as cargas de trabalho de um portfólio. Algumas cargas de trabalho podem ter requisitos de segurança específicos que podem levar a alterações na arquitetura.

Cada um destes critérios serve de indicador de um potencial obstáculo à migração. Na maioria dos casos, você pode abordar o critério depois de migrar a carga de trabalho dimensionando corretamente os servidores, adicionando novos servidores ou fazendo outras alterações. No entanto, se algum desses critérios for necessário antes de migrar uma carga de trabalho, remova a carga de trabalho da onda de migração e avalie-a individualmente.

O Azure Well-Architected Framework e o Azure Well-Architected Review podem ajudar a orientar conversas com o proprietário técnico de uma carga de trabalho específica para ajudá-lo a considerar opções alternativas para implantar a carga de trabalho.

A carga de trabalho é então classificada como um esforço de rearquitetura ou modernização em seu plano de adoção de nuvem. Devido ao tempo extra necessário para rearquitetar uma carga de trabalho, considere esses caminhos alternativos de adoção de carga de trabalho como separados do processo de migração.

Lista de verificação de arquitetura

Você pode usar a lista de verificação a seguir para garantir que você cubra considerações críticas de arquitetura:

• Confirme se sua arquitetura atende aos SLAs de disponibilidade, recuperação de desastres e recuperação de dados.
• Confirme se aplicou práticas de segmentação de rede ao seu design de rede.
• Confirme se você planejou o monitoramento e a captura de logs.
• Confirme se suas máquinas virtuais estão dimensionadas adequadamente para o tempo de computação real que você precisa.
• Confirme se os discos estão dimensionados adequadamente para o tamanho e desempenho reais de que você precisa.
• Confirme se você planejou serviços de balanceamento de carga, se necessário. Os serviços podem incluir instâncias do Azure Load Balancer, Azure Application Gateway, Azure Front Door ou Azure Traffic Manager.
• Confirme se você planejou os requisitos de soberania e computação confidencial, se necessário.

Próximo passo

Implantar cargas de trabalho de migração