Windows Azure

Movendo seus aplicativos para o Windows Azure

Alex Homer

Especialistas em estilo de vida dirão que mudar para uma nova casa é um dos eventos mais estressantes pelos quais as pessoas passam durante a vida, mas mesmo assim, dada uma escolha entre isso ou mover aplicativos para uma nova plataforma, muitos de nós começariam a embalar as porcelanas sem hesitar. Felizmente, no entanto, mover seus aplicativos para o Windows Azure é muito fácil.

Por muitos anos, a Microsoft vem criando aplicativos altamente escalonáveis em datacenters do mundo todo — aplicativos que têm alcance global e alta disponibilidade e oferecem grande funcionalidade aos usuários. O Windows Azure permite aproveitar a mesma infraestrutura para implantar seus próprios aplicativos, com os recursos correspondentes para reduzir requisitos de manutenção, aumentar o desempenho e minimizar custos.

Naturalmente, as pessoas vêm terceirizando seus aplicativos para outras empresas de hospedagem há muitos anos. Isso poderia ser o aluguel de um espaço em rack ou um servidor em um datacenter remoto para instalar e executar seus aplicativos, ou pode apenas significar alugar um espaço em um servidor Web e um banco de dados de uma empresa de hospedagem. Em ambos os casos, no entanto, a gama de recursos disponíveis é geralmente limitada. Normalmente, não há mecanismo de autenticação, enfileiramento de mensagens, gerenciamento de tráfego, sincronização de dados ou outros serviços periféricos que são uma parte padrão do Windows Azure.

Pode parecer que todos esses recursos tornam a mudança de aplicativos para o Windows Azure bastante complexa, mas, contanto que você pondere suas necessidades e explore os recursos disponíveis, mudar para o Windows Azure pode ser um processo rápido e relativamente fácil. Para ajudá-lo a entender as opções e tomar as decisões corretas, o grupo de padrões e práticas da Microsoft publicou recentemente uma versão atualizada do guia de migração do Windows Azure: “Moving Applications to the Cloud on Windows Azure” (msdn.microsoft.com/library/ff728592).

O guia abrange uma ampla variedade de cenários de migração de aplicativos para o Windows Azure. No restante deste artigo, vou explorar esses cenários, apontar as decisões que você precisa tomar e ver como o guia oferece conselhos práticos e úteis para ajudá-lo a fazer as escolhas adequadas. Embora o guia siga um processo de migração de várias etapas um pouco artificial — que a maioria das pessoas não seguirá por completo — essa abordagem demonstra a maioria das opções e mostra os recursos do Windows Azure que podem ser úteis em seus próprios aplicativos. A Figura 1, retirada do guia, mostra um mapa conceitual dos caminhos de migração que você pode seguir quando for migrar um aplicativo de um datacenter local para o Windows Azure.

Figura 1 Mapa conceitual de alguns caminhos possíveis de migração no Windows Azure

Infraestrutura ou plataforma de hospedagem?

Como você pode ver no mapa, a decisão inicial ao migrar para o Windows Azure é escolher qual rota seguir — infraestrutura como serviço (IaaS) ou plataforma como serviço (PaaS).

Como o nome sugere, a abordagem IaaS fornece a infraestrutura do tempo de execução — como servidor virtual e conectividade de rede — para você instalar o sistema operacional, os serviços e aplicativos de sua escolha. Efetivamente, basta escolher seu servidor e executá-lo em datacenters da Microsoft. O Windows Azure oferece uma série de sistemas operacionais pré-instalados que você pode escolher (como Windows Server e Linux), e você ainda pode aproveitar os serviços periféricos, como autenticação por meio do Windows Azure Active Directory, mensagens com filas de armazenamento do Windows Azure ou barramento de serviço, roteamento global para seu aplicativo através do Traffic Manager e muito mais.

Opcionalmente, você deixar que Microsoft gerencie o sistema operacional e a plataforma de tempo de execução para você adotando a abordagem PaaS. Os Sites do Windows Azure fornecem uma plataforma de hospedagem fácil de usar para aplicativos Web e sites com recursos simples de gerenciamento e implantação que podem se integrar diretamente com muitos sistemas de controle de origem, e aceita uma variedade de linguagens de programação. Se você quiser mais controle sobre a plataforma, incluindo a capacidade de executar uma mistura de diferentes tipos de funções e integrar diretamente o cache, você pode escolher a abordagem de serviços em nuvem. Isso permite implantar funções Web e de trabalho separadas; fornece uma ampla variedade de opções de configuração; e é ideal para um ambiente de implantação versionada e dividida em fases.

Como você verá neste artigo, a escolha entre IaaS e PaaS não se limita ao código do aplicativo. Quando você segue a rota IaaS, pode optar por implantar uma máquina virtual (VM) do Windows Azure que tenha um banco de dados, como SQL Server ou MySQL, pré-instalado. Por outro lado, na rota PaaS, o Windows Azure também oferece um mecanismo de banco de dados hospedado chamado Windows Azure SQL Database que é efetivamente uma instância hospedada do SQL Server que você pode usar quase exatamente da mesma forma que um SQL Server local.

Chegando à nuvem com o IaaS

Há várias vantagens distintas em usar a abordagem IaaS para hospedar seus aplicativos. Por exemplo, você conseguir mudar para uma VM na nuvem sem precisar alterar seu código de aplicativo e conectá-la à sua rede interna e ao domínio por meio de uma rede virtual, e todos os seus sistemas de testes, implantação, gerenciamento e monitoramento continuarão a funcionar como antes.

Efetivamente, tudo o que você fez foi substituir o cabo Ethernet em seu datacenter por uma conexão com a Internet para o Windows Azure. Uma rede virtual do Windows Azure pode conectar sua rede local a uma rede configurada na nuvem usando um roteador VPN, permitindo que você use endereços IP da rede interna como o faria localmente. Sim, há certa latência adicional na conexão, e você precisa considerar como as falhas de conexão transitórias ocasionais serão administradas, mas não precisa gerenciar e atualizar o hardware, a infraestrutura e o sistema operacional. (Para administrar falhas de conexão transitórias para muitos tipos diferentes de operações, considere usar o Microsoft Transient Fault Handling Application Block. Para mais detalhes, consulte msdn.microsoft.com/library/hh680934(PandP.50)).  

A abordagem IaaS usando VMs do Windows Azure é ideal quando é preciso executar software ou serviços onde você não tem acesso ao código-fonte ou não pode modificar o aplicativo (por exemplo, quando você depende de um aplicativo de terceiros). Também funciona bem quando você precisa de uma configuração não padrão do sistema operacional ou dos serviços habituais, ou se você quer ter a possibilidade de definir permissões específicas em arquivos e recursos.

Em termos de implantação e testes, suas equipes de desenvolvimento não verão diferença em relação aos processos existentes. Os computadores de desenvolvimento locais e o servidor de compilação podem implantar nos ambientes de teste e produção no Windows Azure, ou você pode instalar os servidores de teste e compilação na nuvem. A Figura 2, baseada em uma figura do guia, mostra um exemplo de uma configuração de teste e implantação que abrange ambientes de teste locais e hospedados na nuvem usando duas assinaturas separadas do Windows Azure — uma para testes e outra para o aplicativo ativo.

Figura 2 Visão geral de um possível mecanismo de desenvolvimento, teste e implantação

Então, a única diferença na escolha da abordagem IaaS do Windows Azure é que o aplicativo não é mais executando em sua dispendiosa sala de servidores com ar-condicionado, consumindo recursos e exigindo largura de banda de sua conexão com a Internet. Em vez disso, ele é executado em um datacenter da Microsoft de sua escolha onde as mudanças do VM são mantidas no armazenamento de backup da imagem original, uma conectividade confiável é fornecida a todo o momento e a plataforma do tempo de execução irá garantir sua disponibilidade contínua.

Além disso, você pode escolher entre uma variedade de tamanhos para sua VM; atualizar as instâncias em execução quando necessário; configurar o sistema operacional e seus serviços para atender às demandas específicas do aplicativo; implantar instâncias adicionais para atender às mudanças de carga; e até mesmo configurar o roteamento automático para implantações em datacenters diferentes para maximizar a disponibilidade e minimizar os tempos de resposta para usuários do mundo todo.

Simplificando o gerenciamento com PaaS

Se você quiser evitar gerenciar o sistema operacional sozinho, escolha a abordagem PaaS. Embora isso signifique que você abrirá mão de algumas oportunidades de configurar sua plataforma de tempo de execução, isso reduz as tarefas administrativas e os custos de gerenciamento porque a Microsoft fica responsável por manter os servidores, atualizar o sistema operacional e aplicar patches. Você simplesmente concentrar no código de aplicativo e em sua interação com serviços periféricos.    

A maneira mais fácil de mover um site ou aplicativo Web para o Windows Azure é implantá-lo nos Sites do Windows Azure; pouquíssimas alterações, se houver, são necessárias no aplicativo. Você pode implantar a partir do Microsoft Team Foundation Server (TFS) ou de outros sistemas de repositório de códigos-fonte, como o GitHub. Dependendo de suas necessidades e de seu orçamento de hospedagem, você pode optar por hospedar em um servidor Web compartilhado ou em uma instância reservada onde você possa garantir o desempenho e gerenciar o número de instâncias para atender à demanda.

Opcionalmente, se você precisa de um mecanismo interno para controlar a versão de implantações e preparar aplicativos, e ter a liberdade de escalonar partes do aplicativo separadamente, você pode optar por usar funções da Web e de trabalho dos Serviços de Nuvem do Windows Azure para hospedar seu aplicativo. Movendo as tarefas em segundo plano para funções de trabalho e colocar a interface de usuário em funções da Web, você pode equilibrar a carga sobre o aplicativo, executar processamento assíncrono em segundo plano e escalonar cada tipo de função separadamente executando o número apropriado de instâncias de cada um.

(Para implementar o escalonamento automático para funções em uma implantação dos Serviços de Nuvem em um cronograma predefinido, ou em resposta a eventos de tempo de execução, como mudanças na carga do servidor, considere usar o Autoscaling Microsoft Application Block. Para mais detalhes, consulte msdn.microsoft.com/library/hh680892(PandP.50)).  

Para conectar funções da Web e de trabalho, você normalmente passa dados entre elas como mensagens usando filas de armazenamento do Windows Azure ou filas do Barramento de Serviços do Windows Azure. (As filas do Barramento de Serviço suportam um tamanho de mensagem maior e tem recursos internos para autenticação e controle de acesso.) Usar mensagens também abre o design para permitir o uso de padrões de mensagens e armazenamento comuns, como Request/Response, Fire and Forget, Delayed Write e muito mais. Se seu aplicativo for criado como componente seguindo o design SOA (arquitetura orientada a serviço), movê-lo para os Serviços de Nuvem do Windows será relativamente fácil. 

Naturalmente, usar funções da Web e de trabalho pode significar a necessidade de certa refatoração do aplicativo. No entanto, em muitos casos, isso não é oneroso e não afeta o código de lógica de negócios ou de apresentação essencial. Por exemplo, aplicativos MVC ASP.NET funcionam bem quando migrados para o Windows Azure, e eles podem acessar repositórios de dados, como o SQL Server, exatamente da mesma maneira que o fazem quando executados localmente ou quando implantados em VMs usando a abordagem IaaS.

Mudar para os Serviços de Nuvem do Windows Azure também pode apresentar a oportunidade de atualizar o mecanismo de autenticação e autorização, especialmente se você achar que precisa fazer certa refatoração do código. Os aplicativos modernos usam cada vez mais um mecanismo de autenticação baseada em declarações, incluindo identidade federada e logon único (SSO).

Esse tipo de mecanismo permite que os usuários façam logon usando uma variedade de credenciais existentes em vez de exigir credenciais específicas apenas para seu aplicativo, e fazer logon uma única vez ao acessar mais de um aplicativo ou site. O recurso de controle de acesso do Windows Azure Active Directory, juntamente com o Windows Identity Framework (WIF), facilita a implementação da autenticação baseada em declarações e da identidade federada. A Figura 3, baseada em uma figura do guia, mostra um exemplo do aplicativo a-Expense da empresa fictícia Adatum, onde os usuários são autenticados pelo próprio Active Directory e recebem um token que apresentam ao aplicativo para obter acesso.

Figura 3 Adotando um sistema de autenticação baseada em declarações

Para obter mais informações sobre a autenticação baseada em declarações, consulte a publicação relacionada a padrões e práticas, “A Guide to Claims-Based Identity and Access Control”, em msdn.microsoft.com/library/ff423674. 

Onde ficarão meus dados?

Quase todas as aplicações de negócio usam dados, e muitas vezes isso é armazenado em um banco de dados como SQL Server ou um sistema de gerenciamento de banco de dados relacional (RDBMS) de outro fornecedor. Um cenário típico ao migrar um aplicativo que usa um banco de dados relacional é implantar uma VM do Windows Azure que hospeda o servidor de banco de dados (o Windows Azure fornece VMs pré-configuradas contendo o SQL Server ou o MySQL). Opcionalmente, você pode instalar qualquer outro tipo de repositório de dados que seja executado no Windows ou Linux em uma VM em execução no Windows Azure.

Você se conecta a um banco de dados hospedado na nuvem a partir do seu aplicativo hospedado na nuvem assim como o faria se o banco de dados e o aplicativo estivessem em seu próprio datacenter. No entanto, essa é apenas uma das opções disponíveis no Windows Azure. Normalmente, você precisará decidir se implantará os dados de seus aplicativos na nuvem ou se os manterá no local e se comunicará com o servidor de banco de dados em uma rede virtual ou através de mensagens. Se você escolher a nuvem, também deverá decidir se seguirá o caminho IaaS ou PaaS (banco de dados SQL).

O padrão CQRS (Command Query Responsibility Segregation) normalmente usa mensagens para comunicar atualizações de dados e resultados de consultas entre os componentes do aplicativo, e o Windows Azure fornece dois mecanismos de enfileiramento que seu aplicativo pode usar para isso. No entanto, para o acesso a dados padrão, introduzir uma rede como a Internet entre o aplicativo e o banco de dados pode resultar em atrasos e mau desempenho subsequente. Se as circunstâncias ou normas exigirem um banco de dados local, o Caching do Windows Azure pode ajudar a reduzir esses atrasos. (Para obter mais informações sobre o padrão CQRS, confira o guia de padrões e práticas relacionados, “CQRS Journey”, em msdn.microsoft.com/library/jj554200.) 

O Banco de Dados SQL do Windows Azure é uma solução ideal para o armazenamento de dados em geral ao migrar um aplicativo existente que usa o SQL Server. A menos que o código exija alguns dos recursos mais esotéricos do SQL Server — como a pesquisa de texto livre, recursos de manipulação de XML, procedimentos que exigem programação CLR ou consultas distribuídas que usam o SQL Server Service Broker — o aplicativo existente funcionará sem alterações.

O Banco de Dados SQL do Windows Azure também é muito econômico quando você precisa armazenar apenas os volumes de dados habituais. No entanto, para grandes volumes de dados ou quando você precisa implantar muitos bancos de dados, usar um servidor de banco de dados hospedado em uma VM torna-se uma solução atrativa. Você pode escolher o tamanho apropriado da VM e até usar várias VMs para implementar failover de banco de dados ou um repositório de dados compartilhado.

Às vezes, as necessidades de armazenamento de dados e consulta vão além das capacidades dos sistemas de bancos de dados relacionais. Por exemplo, as corporações têm geralmente petabytes de dados nos logs do servidor Web, arquivos de transações financeiras, informações de mídias sociais, dados médicos ou outros tipos de dados que não são regularmente processados, mas que podem ser úteis para consultas ocasionais ou futuras. O Windows Azure oferece o serviço HDInsight (baseado em tecnologias Hadoop de código-fonte aberto) para esse cenário. Para obter mais informações, consulte hadooponazure.com.

Tabelas, blobs, filas e unidades

O Windows Azure também oferece um tipo diferente de armazenamento que não se baseia no paradigma relacional do SQL. Você pode usar tabelas de armazenamento e blobs do Windows Azure para armazenar dados de aplicativo, filas de armazenamento para passar mensagens entre componentes do aplicativo e unidades de armazenamento que atuam como um sistema de arquivamento em disco tradicional.

As tabelas de armazenamento do Windows Azure não têm esquema, ou seja, cada linha é uma entidade que contém um conjunto de valores de propriedades, e uma tabela pode ter diferentes tipos de entidades em cada linha. Isso é ideal para dados estruturados (colunas e linhas) e semiestruturados. Os blobs de armazenamento do Windows Azure, por outro lado, são mais adequados para o armazenamento de dados não estruturados, como documentos, dados binários, arquivos XML e imagens.  

O armazenamento do Windows Azure também é muito barato em comparação ao uso de um servidor de banco de dados hospedado por VM ou um banco de dados SQL, mas isso significa que o código de acesso a dados existente deve ser reescrito. Normalmente, as tabelas e os blobs Windows Azure são mais úteis quando você cria seus aplicativos do zero para execução no Windows Azure. No entanto, se seu aplicativo tiver uma camada de acesso a dados claramente delineada que você possa substituir por uma projetado para usar tabelas e blobs do Windows Azure, é razoavelmente fácil passar a usar o armazenamento do Windows Azure em vez de um banco de dados relacional.    

Como em todos os serviços baseados em nuvem, há uma chance de que problemas de rede transitórios ou intermitentes e a limitação de recursos temporária possa causar a falha de uma solicitação de conexão inicial. O Transient Fault Handling Application Block (mencionado anteriormente) pode ser usado para detectar falhas e repetir todas as operações de armazenamento, incluindo bancos de dados relacionais e storage do Windows Azure. Essa é uma boa prática para todos os aplicativos baseados em nuvem, e o Transient Fault Handling Application Block facilita a implementação.

Funções de trabalho e tarefas em segundo plano

Um dos pontos fortes dos Serviços de Nuvem do Windows Azure é a provisão de um tipo especial de função projetado para executar o processamento em segundo plano. A função de trabalho não se limita ao uso apenas como parte auxiliar de um aplicativo; na realidade, é uma função da Web sem o servidor Web (IIS) instalado. No entanto, o cenário típico é executar tarefas contínuas na função de trabalho que ouvem as mensagens da fila do Windows Azure (ou filas do Barramento de Serviço) que instruem a função a executar alguma ação em segundo plano, como ilustrado na Figura 4.

Figura 4 Passando mensagens de uma função Web para uma função de trabalho

Separar tarefas assíncronas e de segundo plano dessa maneira ajuda a implementar muitos princípios de design de aplicativo básicos, como a separação de preocupações e responsabilidade individual. Passando informações e comandos como mensagens entre funções, você ajuda no encapsulamento de cada função e reduz dependências, basicamente da mesma maneira que se faz aplicando princípios SOA.

Por exemplo, o guia explora como a Adatum usa funções de trabalho para compactar e armazenar imagens de recibos carregados por usuários a fim de economizar espaço de armazenamento, e para exportar os dados de despesas ao aplicativo de folha de pagamento da Adatum. Ambas as tarefas são iniciadas por uma mensagem colocada em uma fila. A mensagem contém dados relevantes para a tarefa individual.    

Conforme você refatora seu aplicativo para implantação em funções dos Serviços de Nuvem do Windows Azure, as tarefas que são apropriadas para execução em uma função de trabalho geralmente serão óbvias. As tarefas em segundo plano também podem ser iniciadas de acordo com um cronograma, e você pode minimizar os custos de hospedagem executando mais de uma tarefa em uma função de trabalho, contanto que você inclua o código para reiniciar as tarefas que possam falhar ou travar. O Windows Azure detecta quando uma função falha e tenta reiniciá-la, mas ele não consegue detectar quando uma tarefa individual falha em função.

Você também deve considerar como você irá lidar com os comentários ou resultados da tarefa em segundo plano. Por exemplo, você pode decidir usar o padrão de gravação atrasada para armazenar detalhes das ordens que os usuários enviam empacotando cada uma em uma mensagem que a interface de usuário envia para uma tarefa de função de trabalho. A função de trabalho irá ler a mensagem da fila e armazenar os dados no banco de dados. No entanto, se o número de ordem for gerado apenas no ponto de armazenamento, será mais complexo para a função de trabalho retornar esse número de ordem à função Web para exibição na interface de usuário.

Posso pagar o Windows Azure?

Como você viu, o Windows Azure contém uma ampla variedade de recursos e serviços que devem cumprir os requisitos de todos os seus aplicativos, mesmo se você não souber quais são todos eles no momento. Você pode implantar em qualquer um dos datacenters localizados no mundo todo e tirar proveito da vasta capacidade de armazenamento e escalabilidade. Mas você realmente pode pagar para manter seus aplicativos no Windows Azure? 

No capítulo 6, “Evaluating Cloud Hosting Costs”, do guia, a Adatum faz diversos exercícios de custos para descobrir aproximadamente quanto será cobrado pela execução de seu aplicativo a-Expense no Windows Azure. O aplicativo usará uma única função Web e uma única função de trabalho, e precisará armazenar cerca de 20 GB de dados em um banco de dados relacional e 120 GB de imagens no armazenamento do Windows Azure. Pela tabela atual de preços, a Adatum espera que isso custe cerca de US$ 3.000 por ano. Embora a Adatum não possa identificar com precisão o custo da execução desse aplicativo em seu próprio datacenter, porque muitos dos recursos que ele usa são compartilhados com outros aplicativos locais, o custo esperado do Windows Azure se compara de forma muito favorável.

Melhor ainda, com a introdução de uma solução de escalonamento automático, como o Enterprise Library Autoscaling Application Block, a Adatum calcula que pode executar o aplicativo apenas durante o horário comercial, mas dobra a capacidade adicionando instâncias de função extras no final de cada mês, quando a maioria dos gastos é arquivada e reduz o custo geral para cerca de US$ 2.000 por ano. Além disso, adaptando o aplicativo para usar as tabelas e os blobs do Windows Azure em vez do banco de dados SQL ou SQL Server, a Adatum calcula que poderia economizar mais US$ 750 por ano.

Naturalmente, seus próprios requisitos de capacidade do aplicativo e os horários de operação serão diferentes, e dependerão da carga que os aplicativos devem suportar e o armazenamento necessário. No entanto, parece claro que você pode pagar para usar o Windows Azure, e que essa mudança será bem menos estressante do que se mudar com a família toda para uma nova casa!

Mais informações

O guia de padrões e práticas, “Moving Applications to the Cloud on Windows Azure”, está disponível em msdn.microsoft.com/­library/ff728592. Você pode baixar uma cópia em PDF do guia do site microsoft.com/download/details.aspx?id=29252.

Os guias e estruturas associados dos padrões e práticas são:

• Developing Multi-tenant Applications for the Cloud: msdn.microsoft.com/library/ff966499
• Building Hybrid Applications in the Cloud on Windows Azure: msdn.microsoft.com/library/hh871440
• A Guide to Claims-Based Identity and Access Control: msdn.microsoft.com/library/ff423674
• The Transient Fault Handling Application Block: msdn.microsoft.com/library/hh680934(PandP.50)
• The Autoscaling Application Block: msdn.microsoft.com/library/hh680892(PandP.50)

Você pode encontrar a homepage do Windows Azure em windowsazure.com e o Windows Azure Developer Center em windowsazure.com/en-us/develop/overview.

Alex Homer é redator técnico da divisão de padrões e práticas da Microsoft em Redmond, Wash. No entanto, ele tem resistido até agora às atrações duvidosas do clima de Seattle em favor de trabalhar em casa nos arredores rurais idílicos de Derbyshire Dales, na Inglaterra. Suas divagações semicoerentes sobre o setor de TI e a vida em geral podem ser encontradas em blogs.msdn.com/alexhomer.

Agradecemos ao seguinte especialista técnico pela revisão deste artigo: Masashi Narumoto
Masashi Narumoto é gerente de programa sênior no setor de padrões e práticas. Ele tem trabalhado em uma série de guias do Windows Azure e atualmente está focado no Big Data. Anteriormente, ele passou mais de 20 anos desenvolvendo e prestando consultoria sobre uma variedade de soluções, especialmente nos setores de varejo e manufatura. Você pode encontrá-lo em https://blogs.msdn.com/masashi_narumoto ou no Twitter como @dragon119.