Windows Azure – Perguntas e respostas

Quando o assunto é computação em nuvem (no caso da Microsoft, Windows Azure) é comum encontrar muitas dúvidas entre profissionais de desenvolvimento. Assim, este post pretende apresentar algumas questões comumente encontradas sobre o Windows Azure e suas respectivas respostas.

As perguntas apresentadas aqui são algumas das que encontrei em alguns dos momentos em que conversei com desenvolvedores na comunidade técnica e clientes/parceiros da Microsoft. Se você possui alguma dúvida não contemplada neste post, por favor, envie sua dúvida que terei o maior prazer em adicioná-la no conteúdo do post com a respectiva resposta.

1. Existem vantagens em levar minhas aplicações para nuvem? Quais?

A computação em nuvem apresenta uma mudança considerável de paradigma. Neste novo modelo, algumas características se destacam e são elas justamente que agregam valor à empresas e desenvolvedores que adotam esta plataforma. A seguir, apresento estes aspectos e como eles podem proporcionar vantagens ao seu modelo de negócio.

• Pagamento sob demanda: esta é uma das principais vantagens proporcionadas pelo modelo de computação disponibilizado pelo Windows Azure. A ideia aqui é que se pague apenas pelo consumo ao invés de pagar por recursos ou capacidades que pouco ou nunca seriam utilizadas. A vantagem aqui é clara: otimização na utilização de recursos e consequentemente economia nas finanças.
• Alta disponibilidade: ao levar suas aplicações para nuvem (com no mínimo duas instâncias) sua aplicação estará disponível todo o tempo. A Microsoft garante através do contrato SLA que sua aplicação terá uptime de 99,95%. É uma boa taxa não?!
• Complexidade encapsulada: Windows Azure encapsula toda complexidade relacionada à infraestrutura. Ao ser hospedada na plataforma Azure, todo balanceamento de carga, backup e demais operações relacionadas à infraestrutura necessária para que a aplicação funcione de forma segura e com bom desempenho.
• Elasticidade: com Windows Azure é possível incrementar a capacidade de computação conforme a necessidade. Para que a vantagem proporcionada por esta característica fique clara, considere o exemplo de uma loja virtual onde o número normal de acessos é x entretanto, em ocasiões especiais como dia das mães, dia dos pais, dia dos namorados, etc., tem este número incrementado em 3x. Nestes períodos, você pode incrementar sua capacidade de computação e após eles, voltar a capacidade normalmente contratada.
• Incremento de performance: Windows Azure disponibiliza diversos recursos que possibilitam incrementar a performance das aplicações “hosteadas” por ele. Recursos como CDN, Cache, HPC, etc., são alguns deles.
• Segurança: muito embora o conceito de cloud computing seja conhecido também como “nuvem pública” os dados hospedados no Windows Azure não são expostos publicamente, a menos é claro, que você deseje expor certos aspectos de sua aplicação. A Microsoft garante a confiabilidade dos dados armazenados na nuvem.

Estas são algumas das vantagens que podem ser mencionadas ao pensar em computação em nuvem com a plataforma Azure, entretanto, existem diversas outras. Se você gostaria de saber um pouco mais sobre as vantagens da computação em nuvem para seu cenário, entre em contato comigo para falarmos sobre.

2. Minhas aplicações atuais funcionam na nuvem da forma como estão ou preciso reescrevê-las?

Windows Azure apresenta um modelo diferenciado de computação. Com Windows Azure, temos um ambiente conhecido como PaaS (Platform as a Service) assim, você pode utilizar o Windows Azure como ambiente base para executar suas aplicações.

Para que possamos responder a esta questão de forma efetiva, precisamos dividir as aplicações em duas categorias: web apps e desktop apps.

Quando falamos de aplicações web, temos no Windows Azure um ambiente extremamente favorável para execução das mesmas. Suas aplicações web podem estar hospedadas em Web Roles ou ainda, estar estruturada em diferentes camadas de forma desacoplada com parte da mesma sendo executada sob Worker Roles e parte sob Web Roles. Para saber mais sobre as diferenças entre Web Roles, Worker Roles e VM Roles basta seguir este link. Evidentemente que, o que mandatóriamente define como a aplicação web será executada é a arquitetura da mesma.

Em termos de aplicações para desktop Windows Azure disponibiliza alguns cenários possíveis de execução sendo que, o principal deles, é a construção de um ambiente híbrido (mescla de on-premisses com Azure). Neste cenário seria possível por exemplo, migrar sua estrutura de banco de dados relacional para a nuvem (SQL Azure) e sua aplicação on-premisses (isto é, em servidor local) consumindo estas informações de forma direta ou através de web services. Outro cenário possível é a migração do core de determinado sistema para a nuvem (para execução em background através de Worker Roles), a migração dos dados relacionais mantidos na estrutura do SQL Azure e finalmente, a manutenção da parte consumidora (tanto dos resultados provenientes do processamento da Worker Role quanto do banco de dados) no ambiente local.

É importante observar aqui alguns aspectos esturturais em relação à plataforma Azure. São eles:

• As instâncias do Windows Azure são do tipo stateless, ou seja, as máquinas são “destruídas” e recriadas de tempos em tempos. Ao projetar suas aplicações, este fato deve ser levado em consideração para que não haja perda de dados quando a “reciclagem” ocorrer.
•  Windows Azure estrutura o armazenamento de arquivos e dados através de blobs, tables, queues e SQL Azure. Ao projetar ou migrar a aplicação para nuvem estes aspectos devem ser considerados para que a aplicação possa performar melhor.
• Toda comunicação com os serviços disponibilizados pelo Windows Azure são realizados via HTTP/HTTPS REST protocol. Assim, para que os dados possam ser manipulados de forma correta, é preciso conhecer em detalhes as especificações do protocolo. Um post com as principais características do modelo REST de comunicação pode ser encontrado clicando aqui.

3. Tenho um banco de dados SQL Server em servidor local. Posso migrar para a nuvem? É complicado?

De forma objetiva, a resposta é sim! É possível migrar sua base de dados SQL Server on-premisses para o Windows Azure e o processo é extremamente simples. Ao realizar esta migração, seu banco de dados sofrerá um transbordo para uma nova instância de SQL Azure que é replicada automaticamente pela plataforma em três diferentes nós no mesmo data center.

Existem basicamente duas formas possíveis para migrar um banco de dados relacional para a nuvem: através de alguma ferramenta dedicada a este fim ou de forma manual. A principal ferramenta dedicada a este fim é conhecida como “SQL Azure Migration”. A ferramenta é gratuíta, atualmente encontra-se na versão 3.8.6 e pode ser encontada seguindo este link. Você pode encontrar um tutorial apresentando o procedimento de migração seguindo este link (texto em inglês). De forma manual, o processo pode ser realizado via SQL Server Management Studio. Em artigo futuro (na série de artigos sobre Windows Azure que estou escrevendo aqui no site) apresentarei as principais formas possíveis para realizar este processo de migração.

Uma vez que sua base de dados esteja no SQL Azure, aplicações na nuvem ou fora dela, poderão consumir os dados deste ambiente. O gerenciamento do(s) banco(s) de dados pode(m) ser realizado(s) através do portal do Windows Azure ou via SQL Server Management Studio.

4. Windows Azure realiza “auto-scaling“?

Na resposta à primeira pergunta, mencionei o quesito “elasticidade” e como descrição do mesmo, apresentei a possibilidade de se ajustar (aumentar ou diminuir o número de instâncias conforme a necessidade) o ambiente de computação proposto pelo Windows Azure.

Para que possamos responder a esta pergunta de forma efetiva, é preciso separar o conceito de “auto-scaling” em dois grupos distintos: auto-scaling de recursos e auto-scaling de computação.

• Auto-scaling de recursos: analisando de forma minuciosa a estrutura de serviços proporcionada pelo Windows Azure, fica fácil evidenciar que a plataforma realiza auto-scaling de praticamente todos os seus recursos. Se pensarmos que um banco de dados relacional no Windows Azure cresce de forma automática a medida que novos dados são inseridos, podemos inferir que um auto dimensionamento está acontecendo. De igual forma, quando uma queue de mensagens cresce (de forma ilimitada) a cada nova inserção no modelo FIFO, temos um auto-scaling novamente acontecendo.
• Auto-scaling de recursos de computação: Sim, Windows Azure também realiza dimensionamento automático para instâncias de computação, bastando para isso, que você utilize a Service Management API. Com um modelo simplificado de programação que encapsula o modelo REST, você pode implementar o recurso de alocação automática de instâncias de computação.

A plataforma Windows Azure poderia fazer a alocação dinâmica de recursos sem precisar da API mencionada no ítem anterior, entretatanto, não realiza. Porque? É simples de se entender. Como o sistema de cobrança do Windows Azure é realizado de forma automática, os usuários contratantes dos serviços de computação poderiam questionar os valores cobrados pelo sistema de billing ao final de cada mês, fato este que tiraria toda a mágica e agilidade do negócio.

Em artigo futuro (na série de artigos sobre Windows Azure que estou escrevendo aqui no site) apresentarei como é possível alocar recursos de forma dinâmica através desta API.

5. Qual a diferença entre queues e service bus?

Esta é uma dúvida muito comum a quem inicia seus estudos sobre Windows Azure. Pretendo cobrir ambos os assuntos em artigos futuros, entretanto, explicar a diferença entre os recursos é relativamente simples.

Uma queue (em português brasileiro, fila) é uma estrutura de dados simples que trabalha no formato FIFO (First In, First Out – o primeiro a entrar é o primeiro a sair). Uma queue possui a função de armazenar mensagens para serem consumidas por outros módulos do sistema em um momento posterior. Ela é o principal agente desacoplador de aplicações estruturadas na nuvem.

Service Bus possui a função de atuar como um hub de serviços (popularmente conhecido no mundo do desenvolvimento de aplicações como ESB – Enterprise Service Bus). Ele tem a função de realizar o interfaceamento entre serviços internos e externos (a nuvem) e máquinas consumidoras.

De forma resumida: enquanto as queues possuem uma função mais “interna” para a aplicação, service bus exerce uma função mais externa.

6. O que é o Windows Azure AppFabric?

Quando o assunto é AppFabric é comum encontrar divergência de opiniões em relação a definição do recurso assim, achei por bem adicionar este tópico.

Este é outro dos assuntos que pretendo abordar na série sobre Azure que estou escrevendo aqui no site mas, em linhas gerais, AppFabric é o nome dado a um set de recursos criados para atender a demandas específicas intrínsecas ao processo de desenvolvimento de aplicações para cloud computing. Dentre estes recursos encontram-se: Windows Azure cache, Windows Azure Service Bus, Windows Azure Access Control (ACS), módulo gerenciador de conectividade de rede, dentre outros.

7. Qual a diferença entre SQL Azure e Windows Azure Tables?

SQL Azure é a plataforma para gerenciamento de dados relacionais na nuvem (é a versão de nuvem do SQL Server que você já conhece do ambiente on-premisses) e, desta forma, todos os conceitos relacionados a bancos de dados relacionais são válidos neste serviço.

Em contrapartida, o Windows Azure Tables traz a ideia de armazenamento de objetos/entidades sem estrutura bem definida (de forma semelhante ao que acontece com NoSQL) ao invés de armazenar registros estruturados, como acontece com bancos de dados relacionais. Deve estar se perguntando neste momento: Fabrício, mas porque Azure Tables? Pode gerar uma confusão com as tabelas de bancos de dados relacionais, não? Concorso, a escolha do nome talvez não tenha sido das mais felizes, mas tem uma justificativa plausível – Internamente, o Windows Azure gerencia estes objetos através de tabelas estrturadas, daí o nome “Azure Tables”.

Falarei especificamente sobre Azure Tables em um post futuro na série de artigos que estou escrevendo sobre Windows Azure aqui mesmo no site.

8. Todos os recursos do SQL Server estão disponíveis no SQL Azure?

O modelo relacional de dados proporcionado pelo SQL Server on-premisses possui muitas semelhanças com aquele proposto pelo SQL Azure, entretanto, não são exatamente iguais.  Usando o SQL Azure, DBA’s podem gerenciar a criação de esquemas, de estatísticas, ajustar índices, otimizar consultas e administrar recursos de segurança (logins, usuários, funções, etc.).

Existem diferenças fundamentais que devem ser levadas em consideração no processo de migração de uma base de dados entre diferentes ambientes ou ao projetar-se um novo modelo de dados para nuvem. A seguir apresento algumas destas diferenças.

• Administração: SQL Server no modelo on-premisses proporciona maior poder administrativo para profissionais responsáveis por administrar seus recursos. Do ponto de vista físico por exemplo, DBA’s podem cuidar de aspectos relacionados ao hardware, etc. Como Windows Azure encapsula um modelo lógico de administração, a administração dos recursos se limitam a aspectos lógicos.
• Chaves: SQL Azure requer que as chaves primárias de suas tabelas sejam “clusterizadas”, requisito não obrigatório em bancos de dados on-premisses. Ao migrar sua base de dados de um ambiente para outro, a própria ferramenta realiza esta operação.
• Recursos não suportados: alguns recursos disponíveis no SQL Server on-premisses não suportados no SQL Azure são: Analysis Services, Service Broken, Replicação, dentre outras.

Você pode encontrar um texto apresentando a comparação entre os dois modelos de banco de dados seguindo este link (em inglês). Em post futuro também abordarei estes aspectos ao falar especificamente sobre SQL Azure.

9. Posso acessar uma instância no Windows Azure via Remote Desktop Connection (RDC)?

Sim é possível, entretanto, é preciso ter em mente três aspectos fundamentais:

1. A conexão suporta apenas um usuário conectado. Se outro se conectar, o primeiro será “derrubado”.
2. A conexão via RDC é suportada apenas para fins administrativos.
3. Instâncias no Windows Azure são stateless, desta forma, suas configurações podem ser perdidas quando o ambiente for “reciclado”.

Possui alguma dúvida sobre o Windows Azure que não foi contemplada neste post? Por favor, me ajude a ajudá-lo. Envie sua dúvida para que eu possa atualizar este post com a resposta a ela. A ideia é fazer um FAQ com as dúvidas mais comuns à plataforma.