Artigo .net magazine 71 - Encarando o Desenvolvedor

Em artigos anteriores nesta coluna eu defendi a ideia de que: 1) existem enormes economias de escala em hospedagem de sites e 2) a infraestrutura 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 infraestrutura). 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 ideia 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 a 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 para 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.