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

Este artigo descreve o processo e as considerações para criar 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 em uma iteração.

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

Baseie o design da arquitetura em suposições comuns

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

• Suponha uma workload de IaaS (Infraestrutura como Serviço). A migração de cargas de trabalho envolve principalmente a movimentação de servidores de um datacenter físico para um datacenter de nuvem por meio de uma migração de IaaS. O processo normalmente requer redesenvolvimento mínimo ou reconfiguração. Essa abordagem é conhecida como migração por lift-and-shift.
• Mantenha a arquitetura consistente. Fazer alterações na arquitetura principal durante uma migração aumenta consideravelmente a complexidade. O debugging de um sistema alterado em uma nova plataforma apresenta muitas variáveis que podem ser difíceis de isolar. As cargas de trabalho devem passar por apenas pequenas alterações durante a migração e todas as alterações devem ser testadas minuciosamente.
• Planeje redimensionar ativos. Suponha que poucos ativos locais usem totalmente qualquer recurso. Antes ou durante a migração, os ativos são redimensionados para melhor atender aos requisitos de uso reais. Ferramentas como Migrações para Azure e Modernização fornecem dimensionamento com base no uso real.
• Capture os requisitos de BCDR (continuidade dos negócios e recuperação de desastre). Se você tiver um SLA (contrato de nível de serviço) 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 durante a migração. Como não atender aos requisitos de SLA, o tempo de inatividade que ocorre quando você promove uma carga de trabalho para produção pode ter um efeito adverso nos negócios. Às vezes, as soluções que devem fazer a transição com tempo de inatividade mínimo precisam de alterações de 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ário e aplicativo. 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 evitar conflitos de rede. Ao consolidar datacenters em um único provedor de nuvem, é provável que você 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 para evitar interrupções nos sistemas de produção hospedados na nuvem.
• Planeje tabelas de roteamento. Verifique se seu projeto inclui um plano para modificar tabelas de roteamento se você consolidar redes ou datacenters. Considere os requisitos de roteamento entre datacenter.

Projetar a arquitetura de uma zona de destino

Na fase Pronto do Cloud Adoption Framework, sua organização implantou serviços de plataforma compartilhada como parte da adoção de zonas de destino 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 assumir que os seguintes componentes de migração estão em vigor:

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

Se esses conceitos essenciais 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, de preferência, por meio de um processo de venda de assinaturas. 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 que tenha muitos ambientes de aplicativo, poderá até ter várias assinaturas com base nas diretrizes para ambientes de aplicativo.

Projetar a arquitetura de rede da 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 criar 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 da carga de trabalho

Suas ferramentas de avaliação de migração devem fornecer uma maneira de fazer a análise de dependência, como análise de dependência no Azure Migrate and Modernize. A ferramenta ajuda você 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 entre cargas 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 considerar esse requisito ajuda a tornar sua migração bem-sucedida.

Você pode usar diretrizes no Centro de Arquitetura do Azure, como para rede spoke-to-spoke , para projetar como as cargas de trabalho interconectadas funcionam após a migração.

Preparar-se para adotar a 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 destino soberana, são criados grupos de gerenciamento para computação confidencial.

Em um contexto de soberania, o uso de computação confidencial requer o Azure Key Vault e as 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.

Atualizar sua estimativa inicial de nuvem

Ao concluir seu design 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 e Modernize para realizar 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 rígido e estruturado de despesas de capital para um modelo de despesas operacionais fluidas. Planejar uma migração para a nuvem geralmente é a primeira vez que uma organização ou equipe de TI encontra essa alteração.

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. Ele fornece a uma organização uma atribuição mais direta de custos aos clientes internos e aos objetivos de negócios que eles dão suporte. Essa abordagem mais dinâmica para a gestão financeira geralmente é chamada de 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ê deverá continuar trabalhando 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 Aprimorar a disciplina de gerenciamento de custos.

Saiba quando alterar sua arquitetura

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

• Pagando por dívidas técnicas. Algumas cargas de trabalho obsoletas carregam um alto volume 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 inaturalmente os custos de hospedagem, você deve avaliar arquiteturas alternativas.
• Melhorando a confiabilidade. 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 altas, o que pode levar a alterações de 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 de arquitetura para resolver preocupações de custo específicas.
• Requisitos de desempenho. Quando o desempenho da carga de trabalho afeta diretamente os negócios, talvez seja necessário considerar a arquitetura extra.
• Aplicativos seguros. Os requisitos de segurança tendem a ser implementados centralmente e normalmente são aplicados a todas as cargas de trabalho em um portfólio. Algumas cargas de trabalho podem ter requisitos de segurança específicos que podem levar a alterações de arquitetura.

Cada um desses critérios serve como um indicador de um possível bloqueio de migração. Na maioria dos casos, você pode resolver o critério depois de migrar a carga de trabalho por meio de servidores de dimensionamento correto, adicionando novos servidores ou fazendo outras alterações. No entanto, se qualquer um 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á-los a considerar opções alternativas para implantar a carga de trabalho.

Em seguida, a carga de trabalho é classificada como um esforço de rearquitectura ou modernização em seu plano de adoção de nuvem. Devido ao tempo extra necessário para rearquipar uma carga de trabalho, considere esses caminhos alternativos de adoção da 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 de arquitetura críticas:

• Confirme se sua arquitetura atende a SLAs para disponibilidade, recuperação de desastre e recuperação de dados.
• Confirme se você 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 são dimensionadas adequadamente para o tempo de computação real de que você precisa.
• Confirme se os discos são dimensionados adequadamente para o tamanho real e o desempenho necessários.
• Confirme se você planejou serviços de balanceamento de carga se eles forem necessários. Os serviços podem incluir instâncias do Azure Load Balancer, do Gateway de Aplicativo do Azure, do Azure Front Door ou do Gerenciador de Tráfego do Azure.
• Confirme se você planejou os requisitos de soberania e computação confidencial, caso sejam necessários.

Próxima etapa

Implantar cargas de trabalho de migração