Assessment de aplicações para o Windows Azure – Parte 1/2

Olá pessoal, tudo certo?

Tenho participado de diversas discussões sobre migração de aplicações para a plataforma Windows Azure. Algumas questões recorrentes são sobre a classificação das aplicações existentes no ambiente local (on-premise) e como estimar o comportamento no ambiente Windows Azure.

De modo geral, poucas empresas possuem um inventário atualizado sobre suas aplicações em produção, assim como informações reais sobre o comportamento de cada sistema. Quando pergunto sobre o número de aplicações para Web, para produtividade, ou mesmo sobre integração entre departamentos, normalmente tenho respostas vagas ou ideias gerais sobre o real estado da TI na empresa.

Quando pensamos em usar os benefícios da computação em nuvem, três cenários são possíveis:

1. Vamos iniciar um projeto novo, pensado para a nuvem;
2. Vamos estender uma aplicação existente on-premise, que terá algumas funcionalidades na nuvem (seja full-time ou apenas em momentos específicos);
3. Vamos migrar uma aplicação existente on-premise completamente para a nuvem.

O primeiro cenário é o mais controlado. Não temos legado envolvido com o código hospedado na nuvem. Pensando em Windows Azure, será possível comunicar essa nova aplicação com componentes, serviços e bases de dados locais, através dos vários mecanismos de integração existentes, como ODBC, ADO.NET, SQL AZURE DATA SYNC, WCF WEB SERVICES, APPFABRIC SERVICES BUS, etc. 

O segundo cenário é misto, onde parte da aplicação está local e parte está na nuvem. Imagine uma aplicação que terá uma interface de atendimento Web no Azure, para milhares de usuários. Parte da lógica de negócio e atualização de bases de dados podem estar on-premise, por necessidades de integração com outros sistemas da empresa. Ainda, o Windows Azure AppFabric Connect, atualmente em CTP permitirá a criação de uma VPN com o Windows Azure, o que irá permitir a comunicação entre máquinas do ambiente local da empresa com máquinas do datacenter Windows Azure por um canal seguro. A extensão de aplicações também é possível com a subida de Web Roles ou Worker Roles conforme a necessidade, ampliando o poder de atendimento de uma aplicação existentes em picos de carga, por exemplo.

Finalmente, o terceiro cenário envolve mover uma aplicação existente para a nuvem. Isso significa que vamos eliminar a infraestrutura local para sua execução e aproveitar apenas o ambiente da nuvem para isso.

Para todos os cenários acima, precisamos conhecer o comportamento e tipo de aplicação envolvidos. Não podemos pensar em estender um serviço para a nuvem ou migrar uma interface ASP.NET sem saber o número de usuários esperados, o volume de consultas a banco ou mesmo o nível de integração da aplicação com recursos locais como AD, ADFS, banco de dados ou barramentos de serviços existentes.

De modo geral, podemos classificar nossas aplicações em 5 grupos gerais:

• Business Management Application / Aplicações para Gerenciamento de Negócios
• Business Productivity Application / Aplicações para Produtividade
• Core Infrastructure Application / Aplicações de Infraestrutura
• Web Applications / Aplicações Web
• Outras Aplicações (mais específicas ou fora da lista acima)

Claro, essa é uma simplificação. Cada grupo pode ainda ser detalhado, como vemos a seguir:

Aplicações voltadas para produtividade de negócios, com BI, Colaboração, etc, temos:

Aplicações específicas para o gerenciamento e lógica de negócios temos:

Para cenários específicos de infraestrutura, como segurança, suporte a mobilidade, armazenamento, temos:

Finalmente, soluções voltadas para o ambiente Web, como portais, games, mídias, etc, temos:

O próximo passos em nosso estudo será classificar o comportamento de nossa aplicação, quanto ao número de requisições, volume transacional, uso de mensageria, número de requisições em banco de dados, etc.

Veremos essas questões no próximo post.

Quais categorias de aplicação você possui em sua empresa? Use essas tabelas de classificação como uma versão 1.0 de seu inventário. A partir desse primeiro mapa, será possível conhecer melhor o comportamento de sua aplicação, preparando uma boa migração e melhor uso dos recursos da plataforma Windows Azure.

Por enquanto é só! Até o próximo post :)

Waldemir.