O Windows 8 é a próxima versão do sistema operacional para computadores “não-servidores” da Microsoft. Ele ainda não está completamente desenvolvido, mas a Microsoft anunciou recentemente suas principais características.

Eu diria que o Windows 8 tem uma ”dupla personalidade” . A primeira delas é a personalidade “normal”, no qual ele é uma evolução do Windows 7. Ele roda exatamente os mesmos aplicativos que o Windows 7 rodava, porém com algumas vantagens:

• Menor consumo de CPU;
• Menor consumo de memória;
• Menor consumo de energia e bateria;
• Mais rápido.

Até aí, seria simplesmente uma evolução do que vem acontecendo pelo menos a partir do Windows Vista, para não dizer do Windows 2000. Mas o Windows 8 tem uma segunda personalidade: a personalidade ”Metro”.

A personalidade Metro tem as seguintes características principais:

• Uma interface com usuário completamente nova;
• Um novo modelo de distribuição;
• Um novo conjunto de APIs, semelhantes às existente anteriormente, mas não idêntico;
• Muito mais conectado à nuvem.

A interface Metro é essencialmente a mesma apresentada no Windows Phone 7. Ela é simples, limpa e otimizada para uso com interface a toque. Uma das suas características mais surpreendentes é que ela *não suporta janelas*. Todas as aplicações são em tela cheia, assim como todas as telas de interface das aplicações. Adeus às janelas sobrepostas e caixas de diálogo. Ela é uma grande mudança na maneira limpa, apresenta cores básicas e tipografia simples. Quem deve aparecer é o seu aplicativo, não a interface.

A interface Metro deve ser rápida e fluida. Isso coloca algumas responsabilidades sobre os aplicativos, pois eles não devem nunca demorar à responder, o que causaria travamento da interface. Sabemos disso desde os tempos do Windows 1.0 e a “solução” foi apresentada no Windows 95: multi-thread. Infelizmente o uso de multi-threads é algo extremamente complexo e difícil de fazer direito. O Windows 8 traz então apenas APIs assíncronas – sem suprir as variedades síncronas”, de forma a evitar o seu uso. Mas para facilitar seu uso, as linguagens suportam um mecanismo de “co-rotinas”, que é uma solução simples e eficaz para o problema – e algo que eu defendo há muitos anos!

O novo modelo de distribuição é otimizado para uso em “loja de aplicativos”. Todos os arquivos necessários ao aplicativo são empacotados em um único arquivo, em conjunto com um “manifesto” que diz que recursos o aplicativo precisa (por exemplo, GPS ou acesso a arquivos), de forma a garantir que o aplicativo não acesse mais do que ele pode, aumentando a integridade e segurança. Além disso, evita que os aplicativos acumulem lixo na instalação do Windows ao longo do uso. Essa é uma promessa antiga (não usar o registry, sem problemas de versionamento de DLL), mas parece que ela finalmente será completamente cumprida.

Nas APIs é que existem as maiores diferenças. De cara, a velha Win32, existente desde a primeira versão do Windows não é mais suportada nos aplicativos Metro. Ela essencialmente foi substituída por uma API chamada WinRT. Esta API é orientada a objeto e definida em C++, uma linguagem que pode chamar diretamente o runtime. No entanto, ela pode ser chamada diretamente a partir de código gerenciado (C#, VB.NET) e JavaScript. Muitas APIs gerenciadas estão disponíveis, mas alguma não ou foram substituídas por chamadas nativas “WinRT” de forma a não haver sobreposição. Ou seja, o ambiente de desenvolvimento mesmo para C# e VB.NET é ligeiramente diferente.

Além disso, dada a ênfase na nuvem, os aplicativos Metro deverão se concentrar na interface com usuário, deixando coisas como armazenamento de dados e cálculos complexos para serem feitas “na nuvem”, chamando via WebServices ou algum mecanismo assemelhado.

O outro ambiente de desenvolvimento é HTML/JavaScript/CSS, que pode ser utilizado também para aplicativos “desktop”.

Todos os ambientes contam com suporte em uma nova versão do Visual Studio, inclusive com suporte a depuração de JavaScript.

O Metro me parece uma resposta à altura da Microsoft, utilizando sua liderança em sistemas operacionais e excelência em ferramentas de desenvolvimento para atender às necessidades de um mercado com diferentes dispositivos e mais orientado ao consumidor.

Isso tudo está ou estará disponível para download até o final desta semana para qualquer um experimentar.

Não me lembro de outro evento da Microsoft guardado com tanto segredo. Nem o PDC 2000, onde foi anunciado o .NET foi tão secreto; mesmo  amigos meus de cargos relativamente altos em Redmond juravam não saber nada a respeito do que seria anunciado no Build.

A organização do evento também não foi feita pelas mesmas pessoas que organizam o TechEd, Mix e PDC e sim pelo time do Windows, que está mais acostumado a eventos relativamente pequenos para fornecedores de hardware, como  o WinHEC.

Por estas razões, havia uma enorme expectativa no ar. A única coisa que vazou, na Nova Zelândia, foi que os atendentes iriam receber um tablet com Windows 8, o que efetivamente aconteceu: foi distribuído um Tablet da Samsung com tela de umas 11 polegadas “wide”, tela “touch”, WiFi, modem 3G com um ano de plano de dados da AT&T, processador i5 “segunda geração”, 4GB de RAM, 64 GB de drive de estado sólido, saída de vídeo HDMI, “docking station” com ethernet, USB , HDMI e bateria com oito horas de duração. Versões de instalação do Windows 8 também foram colocadas em uma rede interna para serem copiadas livremente.

A minha impressão foi que a alta expectativa foi cumprida. O Windows 8 roda os aplicativos feitos para Windows 7, mas eles são considerados obsoletos. Os novos aplicativos usam uma interface com usuário muito semelhante a do Windows Phone 7, chamada de “Metro”. É uma interface simples e intuitiva, desenvolvida para ser fácil de usar. Uma das grandes surpresas é que todos os aplicativos são “tela cheia”. Ou seja, o Windows não tem mais janelas, nem caixas de diálogo!

As novas APIs são expostas como classes em C++ e chamáveis diretamente a partir de C++, C#, VB.NET e JavaScript/HTML/CSS, em uma nova versão do Visual Studio. As APIs antigas são obsoletas e não podem ser utilizadas pelos aplicativos “Metro”. O Silverlight é suportado, mas não é necessário; a interface com usuário pode ser especificada em XAML, contudo.

Todos os arquivos dos aplicativos Metro são empacotados em um arquivo e podem ser distribuídos a partir de uma “loja” que entrará no ar futuramente, em um modelo parecido com os existentes para Windows Phone 7, iPhone e Android.

Embora o software ainda seja beta, as apresentações me pareceram seguras e que existe uma visão clara do que deve ser feito e do estado adiantado da nova plataforma. Parece-me que é uma resposta à altura da Microsoft aos desafios lançados pela Apple e Google/Android nos últimos anos.

No “waterfall”, se uma fase deu errado, é sempre possível “apontar um culpado” em alguma fase anterior e resolver qualquer dilema. Em geral, a fase padrão para levar a culpa é a primeira, o levantamento. Por exemplo: o usuário não disse bem o que queria ou o analista que fez o levantamento não anotou direito. Ou seja, é “só fazer o levantamento direito que tudo dará certo na próxima vez”. Ou algo parecido.
Se o waterfall é tão estudado e tão preciso, por que as coisas dão tão errado? Cada um tem uma opinião ligeiramente diferente, mas as minhas razões preferidas são as seguintes:

• É impossível capturar todas as nuances no levantamento. O usuário sempre se esquece de coisas – sem querer ou até mesmo de propósito. O analista não só não é um ser onisciente e telepata como na verdade está mais interessado em produzir um monte de documentos bonitos mesmo que sem utilidade real, já que são os outros que vão construir o software. Mesmo escalonar as prioridades, ou seja dizer o que é mais ou menos importante, é uma atividade que costuma ser ofuscada por preconceitos ou modas;

• Todo software tem alguma complexidade que só pode ser definida na implementação. Quase sempre estamos fazendo algo mais complexo do que antes e usando novas tecnologias. Isto traz inerentemente uma boa dose de risco, algo que devemos gerenciar ao invés de fingir que não existe. Por mais levantamento e projeto que façamos, eles nunca serão suficientes;

• Os negócios mudam. Eu um mundo de negócios cada vez mais dinâmico, é comum durante e execução de um projeto de software que as prioridades mudem e que as pessoas troquem de emprego. Mesmo que o levantamento seja executado 100% à perfeição – algo que considero simplesmente impossível – é muito provável que no momento da implantação aquele software perfeitamente desenvolvido não adéqüe-se mais às necessidades de negócio naquele momento.

As metodologias ágeis reconhecem que os problemas acima existem e procuram abraçá-los, de forma a conviver com eles. Existem vários métodos “ágeis”, como por exemplo “Extreme Programming (XP)”, “MSF/Agile” e “Scrum”.

Pessoalmente eu estou cada dia mais interessado no Scrum, também apoiado por vários criadores do “Agile Manifest”. Ao contrário de algumas técnicas ágeis, especialmente o XP, o Scrum inclui bastante planejamento, disciplina, responsabilidade dos integrantes da equipe e gerenciamento de riscos, em um pacote que faz sentido.

É perfeitamente possível trabalhar com Scrum sem nenhuma ferramenta de software, mas obviamente as coisas ficam mais fáceis se você tiver uma ferramenta para registrar as tarefas a fazer, as feitas e prioridades. Recentemente a Microsoft anunciou apoio ao Scrum e, com o apoio do Ken Schwaber (www.scrum.org), um dos “profetas” do Scrum, criou um template “Scrum” para o Visual Studio 2010. Isto, certamente dará um impulso extra a esta técnica na plataforma Microsoft.

O Scrum não é uma “bala de prata”, pois exige mudanças culturais, tanto em quem contrata como em quem desenvolve. Ele exige que todos trabalhem em comum de forma a entregar alguma coisa que tenha valor ao negócio, substituindo o relacionamento antagonista e burocratizado tradicional.

Por esta razão os países em desenvolvimento e, especialmente os BRIC (Brasil , Rússia, Índia e China), foram alvos de muita atenção nos últimos anos por parte das empresas de informática: são países grandes e nos quais havia ainda o potencial de crescimento comparável aos “anos de ouro” dos países desenvolvidos. Os BRIC ainda têm algum potencial inexplorado, mas são mercados com algumas complicações, como pouco respeito à propriedade intelectual, problemas de infra-estrutura ou até mesmo um “capitalismo oligárquico” difícil para estrangeiros navegar. Será que ainda não existe algum grande mercado de informática inexplorado?

A constante miniaturização dos componentes de computador aliada a diminuição do consumo de eletricidade permite agora fazer um computador bastante capaz, equivalente a um desktop de dez anos atrás, mas que cabe no bolso e funcionam vários dias com uma única carga de bateria. É também simples e barato colocar um telefone celular com acesso à internet no mesmo aparelho.

Depois de sofrer por anos com poucas vendas de seus “smartphones” – telefones com computadores acoplados, tanto a Microsoft como a Nokia viram seu mercado ser roubado pela Apple, exatamente quando o hardware tina tornado-se suficientemente barato e poderoso. Não só a Apple redefiniu o que deveria ser um computador portátil com telefone, ela fez isso com margens de lucro mais associadas à época de ouro dos próprios computadores. Estima-se que a Apple nos EUA recebe da AT&T, a operadora exclusiva, algo como US$300 por ano por cada iPhone vendido.
Depois de salivar ao ver estes números, os concorrentes se deram conta que a penetração do iPhone no universo dos “smartphones” ainda é relativamente pequena, algo na casa dos 15%. Se levarmos em conta as vendas totais de telefones celulares, as vendas do iPhone correspondem a menos de 3% das vendas totais de aparelhos celulares. Isso é que é um grande mercado inexplorado!

Por estas razões, a Google lançou rapidamente seu “smartphone” o Android, produzido tanto por terceiros como por ela mesma.

Após vários altos e baixos com sua plataforma “Windows Mobile”, a Microsoft finalmente renovou completamente sua oferta de Smartphone com o seu “Windows Phone 7”. Desta vez ela resolveu deter mais controle sobre o hardware, impedindo o aparecimento de telefones de mau desempenho e também padronizando a interface com o usuário. Ele é claramente inspirado no iPhone, mas promete brilhar onde a Microsoft é forte: integração com seus outros softwares, como Windows e Office e disponibilidade de boas ferramentas de desenvolvimento.

O kit de desenvolvimento de software do iPhone não fazia parte dos planos originais da Apple e foi feito às pressas, utilizando uma tecnologia de desenvolvimento relativamente obsoleta e também exige que o desenvolvedor utilize um computador Mac, mais caro e raro que os Windows.

Acredito que a Microsoft trará para o seu telefone uma plataforma de desenvolvimento muito mais moderna, poderosa e fácil de usar. Isso deve atrair imediatamente para a plataforma os desenvolvedores tradicionais de aplicativos e contribuir bastante para o sucesso do “Windows Phone 7”.

Eu confesso que fiquei um pouco decepcionado, visto que este tipo de oferta não aproveita o ponto forte da Microsoft, que é exatamente a possibilidade de estender a plataforma de desenvolvimento e execução. Ela é semelhante a outras ofertas de hospedagem em máquinas virtuais como a Amazon ou mesmo de provedores tradicionais. O ambiente virtual continua lá, mas não é enfatizado – pelo menos nesta versão.

Por que esta mudança de paradigma? A resposta, em uma palavra é “inércia”. Em primeiro lugar, pouca gente está interessada em modificar aplicativos que já funcionam. Em segundo lugar, o pessoal já está meio acostumado – para o bem e para o mal – com máquinas virtuais. A oferta do “ambiente virtual” é pouco familiar e talvez até mesmo desconfortável.

Além disso, existe nas empresas uma divisão forte em departamento de desenvolvimento e departamento de produção (ou infra-estrutura). Eles usualmente têm orçamentos separados e não gostam de conversar muito um com o outro. A quem o Azure se destina então? A médio e longo prazo, os desenvolvedores teriam que desenvolver aplicativos para ele. Mas visto que não existe ainda nenhum aplicativo desenvolvido, quem poderia comprar o Azure agora? Evidentemente o pessoal de “produção”, que está acostumado com a idéia de máquinas virtuais, mas é absolutamente imune a conversas de “plataformas virtuais”, para as quais eles não têm a menor necessidade, visto a falta de aplicativos para rodar.

A realidade é então que a Microsoft teve que oferecer um produto para o qual existe um mercado agora – as máquinas virtuais, mesmo que isso não a interesse tanto em longo prazo.

Isto significa que nós desenvolvedores devemos esquecer o Azure? Eu acho que não. O principal é que escrevamos os novos aplicativos de forma que eles possam ser facilmente adaptados no futuro par o Azure, mesmo que eles rodem de maneira convencional no presente. Por exemplo, devemos fatorar serviços de forma que o código de negócios esteja bem separado e possa ser colocado no futuro em um “Worker Role”. Ou separa o código de acesso a banco de dados. Na verdade, se implementarmos as boas práticas de desenvolvimento, nossos aplicativos estarão substancialmente bem preparados para uma eventual migração futura para o Azure.

É então possível descompilar programas .NET, de maneira semelhante ao que era possível com descompiladores para o Clipper como “Unclip” ou “Valkyre”, que tanto transtornos causaram nos anos noventa? A resposta curta é sim. Mas continue lendo.

Uma das grandes vantagens dos “assemblies”.NET  (.EXE ou .DLL) é que eles rodam em um “ambiente gerenciado”, onde os programas não podem causar danos aos outros programas rodando no computador do usuário. Este ambiente gerenciado depende basicamente do seguinte para funcionar:

• Código executável definido em uma “linguagem intermediária – IL” ao invés da linguagem do processador. Este código pode ser “verificado” em tempo de carga e execução pelo compilador “JIT”, de forma que o mesmo não possa efetuar operações não permitidas pelas configurações de segurança, como acessar um endereço de memória não permitido;
• Informação de tipo em tempo de execução (“metadata”) de forma a validar os “casts”, chamadas de funções entre diferentes DLLs e manter a integridade do sistema de tipos;
• A primeira compilação (VB ou C# para IL) não deve otimizar o código, pois as otimizações podem impedir que o compilador JIT verifique o código. A presença de otimizações tem o efeito colateral de atrapalhar os descompiladores.

Evidentemente, os fatores acima facilitam a descompilação dos programas. Note que estes recursos têm como efeito principal o aumento da segurança e integridade tanto para os desenvolvedores como para os usuários finais, o que é considerado hoje em dia uma grande vantagem. Por exemplo, a maioria dos erros no gerenciamento manual de memória dos ambientes tradicionais é eliminada. A robustez e a vulnerabilidade à descompilação também são características do outro grande ambiente gerenciado utilizado atualmente, o Java.

Dito isto, como impedir que um usuário do seu software possa descompilá-los? Existem várias maneiras:

• Impedir o acesso aos executáveis. Um aplicativo web, por exemplo, roda em um servidor e os usuários não têm acesso aos executáveis. Mesmo um aplicativo desktop pode ter parte da sua funcionalidade em WebServices, que também rodam em um servidor.
• Escrever parte do programa como código não gerenciado, quer como DLL, objeto COM ou mesmo em código não-gerenciado dentro de programas C++ .NET. Evidentemente isto elimina as vantagens do código gerenciado pelo menos em parte do seu programa.
• Escrever parte do código em Assembler IL usando recursos que dificultam a descompilação, como o uso de identificadores não suportados pelas linguagens C# ou VB.NET, por exemplo, chamando uma função com o mesmo nome de uma palavra reservada de linguagem de alto-nível.
• Usar um “ofuscator” para alterar o código de forma a impedir a descompilação.

Os ofuscadores (pesquise por “.NET obfuscators” na Web) são a maneira mais fácil e direta de proteger o seu código, pelo menos a níveis comparáveis aos de outras linguagens de alto nível como C/C++ ou Delphi. Basicamente eles processam os assemblies (.EXE/.DLL) e geram outros assemblies que tem a mesma funcionalidade, mas que são mais difíceis de descompilar.

Como isso é feito? Um dos truques é renomear os símbolos (funções, propridedades, campos etc) “private” de seus executáveis. Quando um programa .NET referencia um símbolo dentro do mesmo assembly, ele não o faz por nome e sim através de um índice em uma tabela. O nome é então supérfluo e pode ser trocado para identificadores repetidos ou mesmo palavras reservadas da linguagem, tornando o fonte descompilado impossível de ser recompilado. Alguns produtos possuem recursos bastante sofisticados e o resultado é uma proteção até maior que um programa Delphi ou C++.

Caso você deseje proteger seus programas, os ofuscadores são uma alternativa bastante prática.

Durante a Segunda Guerra Mundial os americanos ocuparam várias ilhas no Pacífico Sul em suporte às operações contra o Japão. Eles construíram nestas ilhas pistas de pouso e armazéns para facilitar a movimentação de carga por via aérea. De forma a não serem massacrados e devorados pela população local – que estava em ampla maioria – os americanos distribuíam parte da carga que circulava pelas bases à população local. Os nativos adoraram ganhar coisas como comida enlatada e tendas. Rapidamente eles se acostumaram com as comodidades da “vida moderna”.

Terminada a guerra os americanos foram embora e abandonaram as instalações, até porque os aviões tinham autonomia maior e as pistas não eram mais necessárias. Os nativos, acostumados com a carga ficaram desolados. Partiram então para imitar o que os militares americanos costumavam fazer e que, na percepção deles, era a causa da vinda dos aviões. Construíram novas pistas de pouso, torres de controle, fones de ouvido de madeira “operados” por nativos e tudo mais de forma que os aviões “pudessem” voltar à pousar. Eles criaram um “Culto à Carga” (“cargo cult”). Evidentemente, apesar do grande esforço empreendido pelos nativos, os aviões não retornaram.

Note que construir as pistas de pouso era a forma encontrada para suprir a razão original de movimentar carga. Os nativos confundiram a forma com a necessidade original e ficavam cultuando a forma sem se importar com a razão.

Nós, desenvolvedores, nos achamos mais espertos que os nativos da Micronésia, mas o “Culto à Carga” é muito comum no desenvolvimento de software. Às vezes gasta-se um grande esforço para repetir um ritual cuja razão original de existir há muito se foi. O meu exemplo preferido é a chamada “notação húngara” para dar nomes às variáveis.

Na década de oitenta, Chales Symoniy, então um arquiteto chefe da Microsoft, defendeu uma convenção na qual os nomes das variáveis na linguagem C deveriam ter o tipo como prefixo. Por exemplo, uma variável do tipo usingned int teria o prefixo uint. Essa notação resolvia um sério problema da linguagem C antiga (padrão “Kernighan & Ritchie”) usada na época, que era a falta de tipagem forte. Podia-se atribuir um “char * para um int e o compilador não reclamava! Com a notação, tinha-se alguma tipagem no “olhômetro”: era só ver se os prefixos nas atribuições eram iguais. Como os nomes das variáveis ficavam muitas vezes impronunciáveis e dada a origem Húngara do Sr. Symoniy, seus colegas por gozação deram o apelido de “notação húngara” e o apelido pegou. Ela foi bastante popularizada pela API do Windows 3.0 e muito utilizada pela Microsoft e pelos programadores em geral.

A notação húngara tinha lá seus problemas. Ela impedia que se abstraíssem os tipos com o uso do comando typedef. Se você desejasse mudar o tipo de uma variável (de int para float, por exemplo), deveria alterar não só a declaração, mas também todos os lugares que usassem a variável, já que o prefixo tinha mudado de “i” para “f”.
Com o passar dos anos, a utilidade da notação húngara foi diminuindo. O padrão C ANSI de 1990 que substituiu o “Kernighan & Ritchie” era fortemente tipado e não permitia coisas como atribuir um char * a um int por acidente. A API do Windows 3.10 de 1991 abandonou o húngaro tradicional, pois já previa futuras extensões de 32 bits e a codificar tipos de 16 bits nos programas traria problemas no futuro. Acabou a guerra. Os aviões voltaram para casa. É o fim da notação húngara então?

Nem tanto. Ainda hoje, em 2004, eu vejo nativos, quer dizer, programadores de linguagem fortemente tipadas como o C# usando notação húngara, mais de 10 anos depois de qualquer razão lógica para seu uso ter evaporado. Na verdade, nas minhas consultorias eu freqüentemente encontro não só a notação húngara como normas e convenções sem o menor sentido. A única explicação que eu recebo sobre sua existência é uma variação do “aqui nós sempre fizemos assim”. Fico então imaginando algum analista bem intencionado de farda verde e com um capacete de tenente do exército americano elaborando um padrão que fazia sentido para resolver um problema que com o tempo desapareceu, mas que continua sendo cultuado pelos nativos em trajes sumários, colares de conchas e ossos amarrados aos cabelos sentados à frente dos computadores.
Conclamo a todos os desenvolvedores que são vítimas de padrões aparentemente sem sentido que questionem a razão da existência desses padrões. Caso as razões não sejam aparentes, adote um novo padrão usando o bom senso. No caso dos nomes de variáveis, acho um bom padrão usar uma expressão baseada em um ou mais substantivos seguido ou não de um adjetivo que expresse o que a variável é. Por exemplo, “TotalPedido”, “NomeUsuario” e “QtdTelasAbertas” e evitar nomes que não tem significado como “temp1”, “var2” e “xxx0”, para não dizer do “húngaro”.

Ao contrário dos habitantes da Micronésia, não temos a desculpa de sermos nativos ignorantes para adorarmos algum “Culto à Carga”.

Mauro Sant’Anna (mas_mauro@hotmail.com) não conhece a Micronésia nem nunca gostou da notação húngara, até porque mesmo antes do padrão ANSI a maioria dos compiladores C já tinha tipagem forte. Para saber mais sobre Culto à Carga leia em http://en.wikipedia.org/wiki/Cargo_cult. Charles Simonyi (http://en.wikipedia.org/wiki/Charles_Simonyi) tornou-se o primeiro turista espacial a repetir a viajem.

Em um recente anúncio (http://bit.ly/aP8w4f), a Microsoft declarou seu apoio continuado a plataforma atual e até mesmo uma nova versão para o próximo ano.

Então, me parece que a Microsoft terá duas linhas de sistemas operacionais para telefone/celular:

• Phone 7: Mais orientada para o consumidor, um pouco fechado (como o iPhone)
• Windows Embedded Compact 7: uma nova versão da plataforma atual, aberta e compatível

Vejo isso como boa notícia. Sempre gostei de meus dispositivos de CE (estou no meu terceiro telefone WinMo). Eu nunca gostei da abordagem “fechada” da Apple; essa é a razão que eu nunca tive um iPhone. Apesar de perder mercado e um pouco órfãos, ainda existem alguns bons produtos baseados WinMo, como o Samsung Omnia II.

Em artigos anteriores nesta coluna eu defendi a idéia de que: 1)existem enormes economias de escala em hospedagem de sites e 2)a infra-estrutura atual, por ter acumulado anos e anos de modificações, é muito mais complexa do que deveria ser. Estes fatores apontam para grandes oportunidades em uma nova plataforma, feita desde o início visando fácil hospedagem e escalabilidade. Idealmente, os aplicativos nesta nova plataforma não deveriam sequer se preocupar com servidores físicos; o ambiente todo seria “virtual”. O Microsoft Azure, conforme inicialmente anunciado seria uma plataforma assim. Ele é baseado no ASP.NET, mas com APIs novas, de forma a viabilizar este “ambiente virtual”. Por exemplo, existe um novo tipo de aplicativo chamado “Worker Role” que é uma espécie de serviço, mas sem as suas complexidades de instalação e administração.

A Microsoft anunciou em novembro de 2009 os detalhes da versão final do Azure, disponível em ambiente de produção a partir do segundo trimestre de 2010. A versão final inclui além do “ambiente virtual” a possibilidade de executar praticamente qualquer aplicativo Windows em “máquinas virtuais”, incluindo aplicativos não desenvolvidos especificamente para o Azure. Evidentemente, neste caso temos que nos preocupar muito mais com o ambiente de execução, negando muitas das vantagens do “ambiente virtual”.

Eu confesso que fiquei um pouco decepcionado, visto que este tipo de oferta não aproveita o ponto forte da Microsoft, que é exatamente a possibilidade de estender a plataforma de desenvolvimento e execução. Ela é semelhante a outras ofertas de hospedagem em máquinas virtuais como a Amazon ou mesmo de provedores tradicionais. O ambiente virtual continua lá, mas não é enfatizado – pelo menos nesta versão.

Por que esta mudança de paradigma? A resposta, em uma palavra é “inércia”. Em primeiro lugar, pouca gente está interessada em modificar aplicativos que já funcionam. Em segundo lugar, o pessoal já está meio acostumado – para o bem e para o mal – com máquinas virtuais. A oferta do “ambiente virtual” é pouco familiar e talvez até mesmo desconfortável.

Além disso, existe nas empresas uma divisão forte em departamento de desenvolvimento e departamento de produção (ou infra-estrutura). Eles usualmente têm orçamentos separados e não gostam de conversar muito um com o outro. A quem o Azure se destina então? A médio e longo prazo, os desenvolvedores teriam que desenvolver aplicativos para ele. Mas visto que não existe ainda nenhum aplicativo desenvolvido, quem poderia comprar o Azure agora? Evidentemente o pessoal de “produção”, que está acostumado com a idéia de máquinas virtuais, mas é absolutamente imune a conversas de “plataformas virtuais”, para as quais eles não têm a menor necessidade, visto a falta de aplicativos para rodar.

A realidade é então que a Microsoft teve que oferecer um produto para o qual existe um mercado agora – as máquinas virtuais, mesmo que isso não a interesse tanto em longo prazo.

Isto significa que nós desenvolvedores devemos esquecer o Azure? Eu acho que não. O principal é que escrevamos os novos aplicativos de forma que eles possam ser facilmente adaptados no futuro par o Azure, mesmo que eles rodem de maneira convencional no presente. Por exemplo, devemos fatorar serviços de forma que o código de negócios esteja bem separado e possa ser colocado no futuro em um “Worker Role”. Ou separa o código de acesso a banco de dados. Na verdade, se implementarmos as boas práticas de desenvolvimento, nossos aplicativos estarão substancialmente bem preparados para uma eventual migração futura para o Azure.