Projetar a arquitetura da 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 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 as suposições arquitetônicas. Esse modelo incremental para projetar arquitetura ajuda as equipes a se moverem mais rapidamente e obterem resultados de negócios mais cedo.

Projeto de arquitetura base em suposições comuns

As suposições a seguir 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 lift and shift .
• Mantenha a arquitetura consistente. Fazer alterações na arquitetura principal durante uma migração aumenta consideravelmente a complexidade. Depurar um sistema alterado em uma nova plataforma introduz 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 exaustivamente testadas.
• Planeje o redimensionamento de 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 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 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.
• Planejar 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 da versão, suponha que uma compreensão geral dos requisitos de tempo de inatividade seja estabelecida.
• Definir 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. 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.
• Planejar 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.

Projetar arquitetura para uma zona de pouso

Na fase Pronto da Estrutura de Adoção de Nuvem, sua organização implantou serviços de plataforma compartilhada como parte da adoção de zonas de aterrissagem do Azure. Em Preparar sua zona de aterrissagem para migração, você preparou a zona de aterrissagem 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 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 carga de trabalho.
• As políticas do Azure para impor práticas de governança, como requisitos de log, regiões permitidas, serviços não permitidos e outros controles estão ativas.
• Um espaço de trabalho Logs do Azure Monitor para log compartilhado é configurado no Azure Monitor.
• Recursos de identidade compartilhados 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 que tenha 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 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 Migrate and Modernize. 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 diretrizes no Centro de Arquitetura do Azure, como para redes de fala para spoke , para projetar como as cargas de trabalho interconectadas funcionam após a migração.

Prepare-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 pouso soberana, grupos de gerenciamento para computação confidencial são criados.

Em 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 Soberania.

Atualize sua estimativa inicial de nuvem

Ao concluir o design da arquitetura, revisite a 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 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 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 oferecer 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 dá a uma organização uma atribuição mais direta de custos aos clientes internos e aos objetivos de negócios que eles apoiam. Essa abordagem mais dinâmica para a gestão financeira é muitas vezes chamada de operações financeiras (FinOps). Embora FinOps não seja uma consideração específica do Azure, pode ser útil ter uma compreensão expandida de 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 sua arquitetura

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

• Pagamento de dívida técnica. Algumas cargas de trabalho envelhecidas carregam uma alta quantidade de dívidas técnicas. 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 naturalmente 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 altos, 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 arquitetônicas para resolver preocupações específicas de custo.
• Requisitos de desempenho. Quando o desempenho da carga de trabalho afeta diretamente os negócios, uma consideração arquitetônica extra pode ser necessária.
• Aplicações seguras. 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 obstáculo à migração. Na maioria dos casos, você pode resolver 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 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.

A carga de trabalho é então classificada como um esforço de rearquitetura ou modernização em seu plano de adoção da 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ê aborde 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 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 as máquinas virtuais estão dimensionadas adequadamente para o tempo de computação real necessário.
• Confirme se os discos estã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 Azure Application Gateway, do Azure Front Door ou do Azure Traffic Manager.
• Confirme se você planejou os requisitos de soberania e computação confidencial, se eles forem necessários.

Próxima etapa