Microsoft Azure ? Tudo na nuvem, a nuvem é tudo ? parte 1

Confesso que minha cabeça não andava literalmente “nas nuvens” nos últimos tempos. Procurei destrinchar o conceito tempos atrás quando se começou a falar deste assunto. Até escrevi uma coluna chamada “Cloud Computing, que confusão” na qual discutia as diferentes nuvens, aos olhos de cada fornecedor de serviço.

Mas é fato, a nuvem veio para ficar. A presença de gigantes como Google, Amazon, Microsoft, VMware, comprova isso. Mas graça a minha participação no Microsoft Tech-Ed Brasil em meados de setembro de 2010 pude fazer nova imersão no assunto, notadamente nos aspectos do serviço Azure da Microsoft. Lembro que no começo do Azure não entendia direito o conceito do produto ou serviço. Talvez lá nos primeiros dias nem a própria Microsoft tivesse a precisa ideia de onde chegaria… Mas chegou e este é o assunto das minhas próximas colunas.

Inicialmente eu me entusiasmei com o AZURE por causa de uma característica específica. Eu enxergara que o ambiente tinha também foco no desenvolvedor, ambiente o qual a Microsoft nada de braçada com seu muito competente VISUAL STUDIO. Mas como “nuvem” a força do MS AZURE está no provisionamento de recursos, ou seja, permitir que recursos sejam alocados com facilidade e agilidade na medida em que estes são necessários. Este ponto não diferencia a solução da Microsoft das soluções de outros provedores de nuvem, porém após um período de maturação o AZURE tornou-se mais “sólido” e preparado para receber aplicações diversas.

Há muito sobre o quê se falar. Por isso que esta coluna inicia uma série. Notadamente vou percorrer assuntos ligados a banco de dados na nuvem (SQL Azure), Sistema de Arquivos Virtual, BPOS (Exchange, Share Point, etc.) na nuvem, plataforma para publicação de aplicações, etc.

Seria um assunto à parte falar do mega datacenter construído pela Microsoft em Chicago com 700 mil metros quadrados, para hospedar os seus serviços. Tem dimensões “épicas”!! São milhares de servidores de alto calibre. Cada um deles com possibilidade de virtualização, multiplicando imensamente a quantidade de aplicações que podem rodar em paralelo. Banda de acesso pela Internet também absurda!

MODELO DE COBRANÇA “on demand”

É um dos aspectos mais interessantes e que demanda maior atenção. O conceito “pague o que você usa” é um sonho para gestores de TI das empresas. Isso porque investimento em TI costuma ser elevado e geralmente precisa ser feito “em degraus”. Ninguém expande sua infraestrutura de TI para suportar os próximos três meses e sim para atender pelo menos nos próximos 18 a 36 meses (no mínimo). Isso implica em ter um parque de equipamentos, servidores, storages superdimensionados por bom tempo. Isso custa bastante dinheiro.

Poder usar mais recursos quando se necessita, seja pela expansão natural e desejável da empresa, ou por um motivo sazonal, é uma possibilidade muito interessante. Imagine uma empresa do varejo, que tradicionalmente tem seus picos de atividade no natal, dia das mães e dia dos namorados (exemplo). Ou mesmo um período no qual uma maciça campanha publicitária tenha sido feita para vendas online pelo site da empresa… O modelo de provisionamento de servidores do Azure permite que vários servidores possam ser alocados para rodar (em paralelo) a aplicação (site de comércio eletrônico) naquele período de tempo para suportar o acréscimo de uso. E apenas durante aquelas duas, três ou quatro semanas de intenso movimento este “reforço” de infraestrutura estará em uso. Depois deste momento crítico a aplicação pode voltar ao seu estado natural, rodando em apenas um ou dois servidores.

No presente momento esta ampliação deve se feita de forma “manual”, ou seja, mudando um parâmetro da aplicação que a fará usar mais servidores (e pagando por isso). Talvez no futuro padrões de SLA ou tempos de resposta poderão nortear a ativação automática de acordo com um acréscimo de carga da aplicação. Mas neste momento é bom que seja “manual”, pois desta forma o responsável pela aplicação tem total controle sobre a alocação de mais recursos e seus custos associados.

A propósito a forma de cobrança por aplicações rodando na nuvem da Microsoft é “sui generis”. A cobrança se dá pelo TEMPO no ar da aplicação. Não pelo consumo de CPU, volume de acesso a disco, etc. Uma aplicação que nada faz, uma vez iniciada no Azure dispara o “taxímetro” acumulando horas de uso em um ou mais servidores e a cobrança será proporcional ao número de horas no ar e quantidade de servidores alocados para a tarefa.

APLICAÇÕES PARA AZURE

Essencialmente a forma de desenvolvimento para AZURE é igual ao desenvolvimento de aplicações para rede local. Claro que há diversas funções e chamadas de caráter específico para rodar a aplicação na nuvem, mas o desenvolvimento é muito parecido. Desde o Visual Studio 2008 e agora com o Visual Studio 2010, há ferramentas embutidas na plataforma de desenvolvimento que trazem muitas facilidades. Existe de fato um “simulador de Azure”, o qual pode receber publicações de aplicações e testá-las antes de leva-las em definitivo para a nuvem. Isso facilita bastante o trabalho para o desenvolvedor.

Há também um conjunto de boas práticas que devem ser conceitualmente entendidas. Quando se leva uma aplicação para um ambiente de ALTA DISPONIBILIDADE, isso é extremamente poderoso, versátil e de grande performance, mas alguns “vícios” de desenvolvimento trazidos da forma convencional de programação devem ser evitados. Sem entrar demais em detalhes técnicos de programação, por exemplo, o uso de “variáveis de sessão” é fatal no Azure. Isto porque como a aplicação pode estar rodando em muitas máquinas em paralelo, não há como garantir que uma informação preservada em uma variável de sessão criada em um servidor esteja visível no clique seguinte se for outro servidor que irá processar aquela requisição.  Isso exemplifica um tipo de cuidado. Mas esta cautela não é aplicável apenas no Azure ou na nuvem. Aplicações feitas para rodar dentro da própria empresa, em ambiente “clusterizado” (servidores em paralelo), também estão sujeitas aos mesmos cuidados. A diferença é que para montar uma infraestrutura de “cluster”, um “web farm”, unidades de armazenamento de dados compartilhadas, etc. na rede local, dentro da empresa é consideravelmente complexo. Já no Azure basta apenas alocar e pagar pelo serviço. Toda a complexidade de “setup” e mesmo do investimento para montar este cenário fica totalmente transparente.

E O CUSTO?? E O CHOQUE CULTURAL?

Ainda não me sinto confortável para opinar em relação a este tópico, até porque eu penso que este mercado de “provedores de nuvens” ainda está amadurecendo e buscando o seu equilíbrio. O Azure dispõe de vários planos de serviços, incluindo uma versão gratuita (com algumas limitações de capacidades) que permite muitas experimentações e testes. Por exemplo, há planos que por preços fixos :

“Development Accelerator Core” : custa US$ 59,95 (preço promocional) por mês e permite que sejam consumidas 750 horas de processamento, 10 GB de armazenamento,  transferência de dados de 7 GB (entrada) e 14 GB (saída ? acesso dos usuário) e também 1.000.000 de transações de aplicações.

“Development Accelerator Extended“: custa US$ 109,95 (preço promocional) por mês e permite que sejam consumidas 750 horas de processamento, 10 GB de armazenamento,  transferência de dados de 7 GB (entrada) e 14 GB (saída ? acesso dos usuário, 1.000.000 de transações de aplicações e também uma base de dados SQL Azure de tamanho até 10 GB.

Estes são só alguns exemplos, há vários outros planos que podem ser visto com mais detalhes aqui. Há inclusive planos separados para SQL Azure, BPOS (ambos serão comentados futuramente) e planos “paga o que consumir” no qual tudo é cobrado individualmente.

É difícil julgar do ponto de vista estritamente econômico o preço do Azure porque se trata de uma fortíssima quebra de paradigma. É uma forma totalmente nova de se entender infraestrutura de TI. E não deveria ser algo assim tão “dramático”. Afinal em nossas casas podemos aumentar a quantidade de canais de TV por assinatura, podemos aumentar a velocidade de nosso link de Internet e pagamos uma conta maior de eletricidade se dobramos a quantidade de equipamentos ligados. Para mim tudo isso é semelhante à forma de uso do Azure.

Acredito que o uso de nuvens em larga escala ainda passa por uma “pedra no sapato”. A sempre falada segurança é o aspecto. Não me refiro somente à inviolabilidade das informações. Falo também da DISPONIBILIDADE!! O nível de SLA (“service level agreement” ? nível de serviço contrado) é minuciosamente definido pela Microsoft, veja aqui. Embora o SLA varie um pouco em função do tipo do serviço (disco, aplicação, SQL, etc.), grosso modo a garantia de funcionamento é em média de 99,9%. Isso significa que em UM ANO o sistema pode estar indisponível no máximo por pouco mais de 8 horas. Isso é bom. Para mim é ótimo, porém alguns tipos de aplicação podem requerer indisponibilidade ainda menor. Depende da aplicação.

Ainda há o outro lado da história. Não adianta o Microsoft Azure ter um SLA de 99,9% se o link de Internet da empresa tiver SLA de 98%, quem limitará o acesso ao serviço será este link. Isto é sério e não pode ser negligenciado.

Em minha opinião há ainda um conflito cultural envolvido no processo de “cloudização” (que palavra estranha!!) dos recursos da empresa. Haverá uma forte disrupção nos poderes estabelecidos dentro da empresa. Funcionários de TI, responsáveis pela planificação e manutenção de sofisticadas infraestruturas podem ser sentir diminuídos em sua importância. Isso em teoria os faria serem objetores naturais destas mudanças. Isso é uma visão míope, pois onde estão “as máquinas” é menos importante que todas as mudanças, simplificações e necessidade ainda premente de gerenciar toda esta nova infraestrutura virtualizada. A quebra do paradigma é a barreira cultural a ser transposta.

Nas próximas colunas sobre o assunto vou entrar em detalhes nos diferentes serviços disponíveis no Microsoft AZURE. Começarei pelo MS SQL Azure, algo que me surpreendeu pela evolução do primitivo “SQL Data Services”. Até lá…