Exportar (0) Imprimir
Expandir Tudo

Planejando uma migração para o Azure

Atualizado: abril de 2014

Quando você começa a planejar a migração, precisa considerar vários fatores importantes, tais como custo, requisitos comerciais e técnicos, linha de tempo e testes que serão necessários no processo de migração. Esta seção fornece um detalhamento sobre as diversas preocupações e etapas que você deve considerar ao planejar a migração para o Azure:

Autores: Steve Howard
Revisores: James Podgorski, Paolo Salvatori, Selcin Turkarslan, Stuart Ozer

O custo é uma das principais questões que precisam ser resolvidas. É recomendável resolvê-la no início do processo de tomada de decisão e de planejamento ao considerar a migração de um aplicativo local para o Azure. Fixar o preço de um aplicativo do Azure depende de vários fatores, como a carga do tráfego de rede, características de entrada/saída do aplicativo e o volume de dados processados pelo aplicativo. O preço de computação está fora do escopo deste tópico. Recomendamos que você use a calculadora de preços do Azure para ajudar a estimar o custo quando você começa a planejar a migração. Você pode localizar a calculadora de preços do Azure aqui.

Ao calcular o custo para a sua organização, lembre-se de incluir os custos diretos do Azure durante o desenvolvimento e o teste. Em um projeto de desenvolvimento local, você paga pelos servidores de desenvolvimento e teste. De maneira semelhante, no ambiente do Azure, você precisa pagar pelos recursos que usa durante o desenvolvimento e o teste. Além disso, você deve calcular os custos de treinamento e aprendizado, e os custos associados com carregar o aplicativo para o Azure. Recomendamos que você conduza um teste de desempenho e um planejamento de capacidade para avaliar a capacidade necessária para seu aplicativo com antecedência.

O Azure pode atender muito bem alguns requisitos de negócios e técnicos. Embora essa lista não seja totalmente inclusiva, os aplicativos com essas características são bons candidatos para a migração para o Azure:

  • Base de usuários distribuída: os data centers do Azure estão localizados em vários continentes. A interconexão entre os data centers permite a distribuição de dados de alto desempenho se for necessário. Os recursos do Azure, como os serviços CDN (Rede de Distribuição de Conteúdo) e de Sincronização de Dados, permitem que você mantenha os dados relevantes ou de alto uso distribuídos em data centers próximos aos usuários finais. Fazer os usuários acessarem os data centers próximos ao seu local geográfico minimiza o comprimento de uma viagem de ida e volta, otimizando a experiência do usuário.

  • Carga variável: você precisa comprar o hardware para que os aplicativos locais tratem dos picos de carga. Por exemplo, uma loja de varejo geralmente compra servidores para conseguir lidar com a carga para as compras de final de ano. De maneira semelhante, um departamento de contabilidade pode planejar uma infraestrutura adicional para conseguir tratar cargas de pico no final do mês ou no final dos ciclos de fechamento anual. No restante do tempo, os servidores destinados para lidar com essas cargas de pico são subutilizados. Por outro lado, os aplicativos projetados para a escala elástica podem aproveitar o Azure para colocar novas instâncias de aplicativos online durante horários de pico, e retornar para níveis inferiores de poder de processamento e capacidade durante períodos de menor necessidade. Desse modo, o Azure permite que você, com aplicativos corretamente projetados e gerenciados, pague somente pelo que precisa.

  • Multilocação: para provedores de serviços, o Azure permite várias maneiras de fornecer os serviços do aplicativo para qualquer número de clientes na mesma infraestrutura, minimizando os custos operacionais.

  • Necessidade de se concentrar em aplicativos: os provedores de serviços em particular querem concentrar o esforço da equipe no desenvolvimento de aplicativos e de recursos mais do que na infraestrutura de manutenção. O Azure libera você da maior parte da sobrecarga administrativa exigida pela infraestrutura que hospeda aplicativos locais ou tradicionalmente hospedados no servidor. Ele permite que você concentre seus esforços no desenvolvimento de aplicativos e recursos.

  • Minimizar requisitos de recursos de infraestrutura: quando você arquiteta seus aplicativos para se beneficiar da escala elástica que o Azure fornece, as instâncias de funções e os recursos podem ser alocados à medida que são necessários. Não há nenhum investimento prévio de hardware nem necessidade de manter os servidores capazes de lidar com a carga de pico durante os momentos de baixa utilização.

Além da plataforma tradicional com a vantagem de ser orientada a serviço, o Azure pode hospedar máquinas virtuais. Essas máquinas virtuais podem executar qualquer sistema operacional com o suporte do Azure e podem executar aplicativos da mesma maneira que seriam executados localmente. Para obter uma lista de sistemas operacionais com suporte, consulte Visão geral das máquinas virtuais do Azure. Essas máquinas virtuais também podem fazer parte de uma arquitetura de aplicativos maior, que pode incluir instâncias da Web ou de funções de trabalho, e outros componentes do Azure. As máquinas virtuais são uma forma de portar alguns serviços ou partes de aplicativos que não podem ser facilmente portáteis no Azure de outra maneira. Para obter mais informações, consulte Migrando com máquinas virtuais do Windows Azure.

Na fase de análise e design, você deve identificar os aplicativos mais benéficos ao passar a usar o Azure. Em seguida, comece a criar a implementação do Azure e o plano de implementação. Durante essa fase, você deve planejar o esboço do design e da linha do tempo da arquitetura.

Alguns dos elementos principais do planejamento são:

  • Identificar os desafios atuais: a lista a seguir mostra alguns exemplos dos desafios que devem ser identificados no planejamento de todas as necessidades de uma nova arquitetura:

    • Componentes de aplicativo que não tenham o desempenho padrão em cargas atuais na arquitetura atual: por exemplo, se uma consulta SQL não for executada satisfatoriamente, você deverá ajustá-la antes da migração ou do design adicional. Você também deve recriar o design e dimensionar novamente todos os componentes de aplicativo da camada.

    • Determinar requisitos de escala elástica: você deve identificar como seu aplicativo pode ser decomposto em unidades funcionais e escaláveis independentemente que podem ser executadas separadas uma da outra.

    • Padrões irregulares de carga: você deve identificar os padrões irregulares de carga e criar o aplicativo para que a expansão lide com os períodos de pico. Você deve fazer planos sobre como gerenciar o nível de expansão de períodos de pico para períodos de pouca demanda.

    • Projeções de crescimento: geralmente as projeções de crescimento são o primeiro alerta para o departamento de TI entender que uma alteração de paradigmas pode ser necessária. Decida onde a expansão pode ser uma solução para solucionar projeções de crescimento. As projeções de crescimento também podem ser o indicador de que você precisa considerar mudanças de paradigma como, por exemplo, mudar de um paradigma de análise de grandes dados em determinados aplicativos centrados em data warehouses. Na fase de planejamento, você deve discutir essas opções. Lembre-se de que você pode não conhecer a solução realmente até mais tarde no processo de design e implementação. Você deve listar essas contingências e fatores determinantes para poder avaliá-los em um momento apropriado, por exemplo, durante a migração inicial ou em outro dia.

  • Identificar requisitos técnicos: saiba quais requisitos de cada componente do aplicativo estão no horário de pico e fora dele. Em seguida, planeje a expansão para cada componente. Cada componente pode ter uma capacidade e um mecanismo diferentes para expandir. Os requisitos técnicos podem ser mais do que apenas desempenho. Por exemplo, os requisitos de alta disponibilidade e recuperação de desastres, ou os requisitos para a latência máxima de rede devem ser determinados e comparados com os recursos do Azure ao se planejar uma migração. A seguinte lista mostra alguns exemplos de requisitos técnicos:

    • Uso de armazenamento relacional: examine os dados armazenados nos bancos de dados relacionais. Os dados que são realmente relacionais e transacionais por natureza, ou dados que exigem processamento transacional de fato devem permanecer no armazenamento relacional. Você pode usar um Banco de dados SQL do Azure (banco de dados SQL) ou o SQL Server que é executado em máquinas virtuais para armazenar esse tipo de dados. Você pode armazenar outros tipo de dados em tabelas do Azure, no armazenamento Blob do Azure, ou em unidades do Azure de maneira eficiente. Recomendamos que você identifique o tipo de armazenamento que é necessário para cada parte dos dados.

    • Escolhendo seu armazenamento de dados relacional: a opção do banco de dados SQL ou SQL Server executado em máquinas virtuais do Azure depende de vários fatores. Se você quiser evitar a sobrecarga administrativa de alta disponibilidade, balanceamento de carga e failover transparente, o banco de dados SQL é a melhor escolha. No entanto; para um estado intermediário na migração de um aplicativo, ou para casos especiais onde os recursos ainda não estão disponíveis no banco de dados SQL, o SQL Server executado em máquinas virtuais do Azure pode ser a melhor solução. As respostas a essas perguntas dependem da situação e da solução. A lista a seguir mostra algumas considerações sobre isso:

      • Tamanho do banco de dados: os bancos de dados SQL do Azure atualmente estão limitados a 5 GB de dados para o banco de dados da Web Edition e a 150 GB de dados para o banco de dados da Business Edition. Para ampliar a capacidade do banco de dados, use um método de expansão. Para saber mais sobre métodos de expansão do Azure, leia "Expandindo bancos de dados SQL do Windows Azure". Para obter as informações mais atualizadas sobre edições e tamanhos de banco de dados disponíveis, consulte Contas e cobrança no Banco de dados SQL do Azure.

      • Número de banco de dados: por padrão, o banco de dados SQL oferece suporte a até 6 servidores por assinatura e 150 bancos de dados em cada servidor do banco de dados SQL, incluindo o banco de dados mestre. Uma extensão desse limite está disponível. Para obter mais informações, entre em contato com um representante do atendimento ao cliente no Portal do Cliente do Microsoft Online Services.

      • Consultas de bancos de dados: o banco de dados SQL, no momento, não oferece suporte a junções de banco de dados ou outras consultas de banco de dados. Se houver uniões ou junções que exigem dados de mais de um banco de dados no banco de dados SQL, você deverá executar essa lógica na camada de aplicativo de seu aplicativo.

      • Objetos de banco de dados de CLR (Common Language Runtime): o banco de dados SQL no momento não oferece suporte a procedimentos armazenados CLR, agregações, gatilhos ou funções. Você deve portar procedimentos armazenados, gatilhos ou funções no Transact-SQL para execução no banco de dados SQL. A lógica ou as operações complexas, como agregações, que não podem ser executadas no Transact-SQL na camada de banco de dados devem ser movidas para a camada de aplicativo. Você pode usar uma função de trabalho para executar esse trabalho.

      • Tipos de dados: o banco de dados SQL não fornece suporte a alguns tipos de dados do sistema do SQL Server. Para obter as informações mais atualizadas, consulte Tipos de dados (Banco de Dados SQL do Azure) na biblioteca SQL do MSDN.

      • Replicação: os tipos de replicação como replicação transacional ou replicação de mesclagem não estão disponíveis no banco de dados SQL. Você pode configurá-los e executá-los no SQL Server que são executados em máquinas virtuais do Azure. Você pode usar a Sincronização de Dados do SQL para sincronizar dados entre instâncias do banco de dados SQL. Mas o serviço Sincronização de Dados do SQL pode não ser satisfatório quando são necessárias a consistência transacional ou as resoluções de conflito complexas. Aviso: a Sincronização de Dados do SQL está disponível apenas como uma Visualização para fins de comentários sobre o produto para futuras versões e não deve ser usada em ambientes de produção.

      • Pesquisa de texto completo: o Banco de Dados SQL do Azure não oferece suporte a pesquisa de texto completo. Se seu aplicativo executar consultas de texto completo em dados de caractere em tabelas do SQL Server, você deverá migrar seu banco de dados para o SQL Server em uma máquina virtual do Azure. Para obter mais informações sobre o SQL Server na VM do Azure, consulte o tópico Migrando para o SQL Server em uma máquina virtual do Azure.

      • Licenciamento: o banco de dados SQL cobra por mês de acordo com o tamanho do banco de dados escolhido. O SQL Server exige uma licença ao ser executado em uma máquina virtual do Azure.

      • Logon e segurança: a autenticação do Windows (segurança integrada) não tem suporte no Banco de Dados SQL, mas está disponível para o SQL Server que é executado em máquinas virtuais do Azure. Para obter mais diretrizes de segurança e limitações do banco de dados SQL, consulte Diretrizes e limitações de segurança do Banco de Dados do SQL Azure.

      • Paridade de recursos: para obter mais informações sobre as semelhanças e diferenças entre o SQL Server e o Banco de Dados SQL, consulte SQL Database Overview.

  • Logon e segurança do usuário: com novos aprimoramentos da rede do Azure, um domínio do Active Directory da rede local pode ser estendido para o Azure. Para obter mais informações, consulte Migrando com máquinas virtuais do Windows Azure. Para obter informações detalhadas sobre a Administração da Segurança do banco de dados SQL, consulte Gerenciando bancos de dados e logons no Banco de dados SQL do Azure.

  • Decomposição funcional do aplicativo: identifica onde o aplicativo pode ser dividido em unidades funcionais de modo que possa ser executado em funções separadas ou em máquinas virtuais do Azure. Você pode fazer isso para produzir a escala elástica e também para permitir aplicativos híbridos se alguns aplicativos não forem adequados para a computação em nuvem.

  • PCI (Payment Card Industry) e outros requisitos reguladores: antes de mover um aplicativo ou componente para o Azure, verifique o status atual das certificações ou os requisitos necessários. Em casos como os requisitos de conformidade PCI, remova algumas partes do aplicativo e do banco de dados do que foi migrado para o Azure, e execute um aplicativo híbrido. Isso oferece os benefícios do Azure e da computação em nuvem na maioria dos componentes, e ainda permite o controle institucional razoável e a conformidade necessária para as partes dos dados e do aplicativo.

  • Componentes principais que não podem ser hospedados na Plataforma do Azure: você não poderá hospedar alguns componentes ou alguns tipos de dados na nuvem pública devido a outras preocupações. Identifique esses componentes e utilize um aplicativo híbrido. Com a arquitetura híbrida, você pode hospedar alguns componentes do Azure para realizar o benefício completo do Azure e da computação em nuvem. Ao mesmo tempo, você ainda pode obter o controle institucional razoável e a conformidade necessária para as partes dos dados e do aplicativo.

Depois de definir o escopo da migração, a quantidade de trabalho para cada etapa no plano de migração torna-se claro também. Observe cada componente de aplicativo e o componente de dados e estime o tempo e os recursos necessários para o desenvolvimento, o teste e a migração. Quando estiver decompondo funcionalmente o seu aplicativo, desenvolva esses componentes decompostos em paralelo para produzir os componentes escalonáveis elasticamente.

Defina etapas de projeto como testes funcionais e de desempenho, e as datas de início no seu plano de migração. A migração pode continuar em uma série de etapas e iterações à medida que componentes diferentes ficam prontos para o Azure, ou para serem movidos para funções Web e de trabalho do Azure.

Quando a linha de tempo para o desenvolvimento e a migração estiver definida, planeje para o crescimento nesse período de tempo e decida o que deve ser feito para o aplicativo e a infraestrutura existentes. Esse tipo de planejamento permite que você opere seu sistema existente até que a migração esteja concluída. Ao formar esse plano provisório, identifique pontos problemáticos atuais e identifique o que deve ser feito para permitir operações contínuas, e em que escala as operações podem continuar na infraestrutura temporária. Além disso, identifique as etapas que você pode precisar para permitir operações contínuas. Geralmente essas etapas podem ser simples como ajustar uma consulta SQL ou adicionar um servidor Web dependendo das características específicas do seu aplicativo. Identifique planos de contingência no caso de crescimento mais rápido que o esperado ou de explosões inesperadas. Ao fazer planos de contingência, considere se as explosões ou o crescimento podem ser tratados expandindo para Máquinas Virtuais do Azure, porque isso pode permitir que você trate essas situações sem o investimento adicional de hardware.

Qualquer plano de migração deve incluir planos para teste abrangentes de funcionalidade e teste de carga. Uma descrição de metodologias de teste está além do escopo deste artigo. A lista a seguir mostra alguns pontos críticos para se lembrar ao testar:

  • Automatizar os scripts de teste

  • Testar todas as camadas e todos os componentes do aplicativo

  • Testar em taxas de atividades que representem as taxas reais de seus sistemas

  • Testar a um nível de sua maior utilização esperada ou além

Recomendamos que você inclua tempo para criar e executar testes além de corrigir os problemas encontrados pelo teste.

Quando você definir os requisitos comerciais e técnicos, identifique os recursos necessários para executar a migração com êxito. Você pode precisar trazê-los para a migração. Há três áreas principais para observar ao identificar os recursos:

  • Pessoal: você pode precisar contratar funcionários com habilidades adicionais para migrar corretamente o aplicativo. Além disso, após a migração, as funções da equipe técnica podem ser alteradas e as habilidades podem precisar de atualização. Por exemplo, considere as funções de Administrador de conta e administradores de serviço para gerenciar logons, acesso, e níveis de serviço e escala.

  • Ferramentas: identifique as ferramentas que você precisa para desenvolver, testar e implantar seu aplicativo do Azure. Para obter mais informações, consulte Ferramentas do Azure para Microsoft Visual Studio e Suporte para ferramentas e utilitários de Banco de dados do SQL Azure.

  • Consultoria: você pode precisar de experiência específica para migrar seu aplicativo. Um especialista de migração pode economizar tempo e dinheiro consideráveis ajudando-o a impedir armadilhas comuns.

Para aplicativos pequenos, o Portal de Gerenciamento do Azure pode ser suficiente para o gerenciamento das implantações do Azure. O Portal de Gerenciamento do Azure permite fazer logon e gerenciar as implantações e os aplicativos incluindo alterar o número de funções de instância, e gerenciar instâncias do banco de dados SQL. No entanto, para aplicativos complexos e aplicativos que fornecem um serviço para clientes, o Portal de Gerenciamento do Azure pode não ser suficiente.

O Azure expõe a API REST para permitir gerenciar programaticamente os aplicativos e as máquinas virtuais hospedadas no Azure além de provisionar e usar o armazenamento do Azure. Você pode escrever uma interface de gerenciamento para lidar com a escala e o monitoramento de seu ambiente do Azure. Seu plano de migração deverá incluir um plano para gerenciar o aplicativo após a migração, especialmente se esse gerenciamento for incluir uma interface ou uma automação personalizada.

Para obter mais informações sobre a API REST para gerenciar as implantações do Azure, consulte Referências de API para o Azure.

Consulte também

Mostrar:
© 2014 Microsoft