Share via

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

Olá pessoal, tudo certo?

No post anterior, falamos sobre classificação de aplicações para o bom uso da plataforma Windows Azure. Vamos continuar nosso estudo nesse post.

Vimos que de modo geral, podemos classificar nossas aplicações em 5 grandes grupos: Gerenciamento de Negócio, Produtividade, Infraestrutura, Web e outras (gerais). Porém, essa classificação é apenas o primeiro passo em nosso estudo, apesar de muito importante.

Outra forma de classificar sua aplicação é quanto a sua utilização e integração com outros sistemas. Confira as perguntas abaixo e utilize-as para uma avaliação mais detalhada de sua aplicação:

Qual é a melhor forma de classificar sua aplicação?

1. Aplicação legada, baseada em tecnologias antigas (ASP, VB6, COM+, C/S, etc)
2. Aplicação baseada em plataforma .NET (.NET 2.0, 3.0, 3.5, 4.0, ASP.NET, WCF, WF, etc.)
3. Aplicação baseada em plataforma não-Microsoft (Java, Delphi, PHP, etc)
4. Novo desenvolvimento em plataforma .NET (.NET 4.0/VISUAL STUDIO 2010)

Qual é a melhor forma de descrever o tamanho de sua aplicação?

1. Grande (>10 servidores/VMs)
2. Médio (4 a 10 servidores /VMs)
3. Pequeno (<4 servidores /VMs)

Quanto à integração de sua aplicação com outras aplicações locais ou na nuvem, qual é a melhor descrição?

1. Altamente integrada (10 conexões ou mais)
2. Moderadamente integrada (de 5 a 10 conexões)
3. Levemente integrada (de 2 a 5 conexões)
4. Não integrada (1 conexão)

Qual é a melhor classificação para o número de logins sobre sua aplicação?

1. Heavy user logins (mais de 500 logins simultâneos)
2. Medium user logins (de 100 a 500 logins simultâneos)
3. Light user logins (menos de 100 logins simultâneos)
4. No user logins

Qual é a melhor descrição para o crescimento estimado de sua aplicação ao longo do tempo?

1. Variável/Sazonal – a aplicação é usada somente por determinado período de tempo (por exemplo, um site de comércio eletrônico que é publicado somente em dezembro, para vendas de Natal e Ano Novo).

2. Crescimento Constante – crescimento consistente ao longo do tempo, por um longo período.

3. Picos Previsíveis – a aplicação é usada por um longo período de tempo, com picos de carga previsíveis (por exemplo, carga elevada nos últimos 3 dias de todo mês).

4. Picos Imprevisíveis – a aplicação é usada por um longo período de tempo com picos de carga não previstos, ocorrendo de forma esporádica (por exemplo, picos de acessos em site de notícias, devido mídia externa).

Fique a vontade para ajustar alguns números acima. Para alguns cenários, Heavy user logins pode ser mesmo mais de 2000 logins e não 500. Os valores acima são uma primeira impressão e podem ser ajustados conforme o cenário.

Nota: ao responder as perguntas acima você estará conhecendo um pouco mais sobre sua solução. Não teremos o número de instâncias de Web Roles de forma automática, mas as perguntas ajudam nesse processo de definição e planejamento de capacidades para uma solução sobre o Windows Azure.

Como próximo passo, vamos questionar sobre o comportamento de sua aplicação. Para isso, algumas questões oferecem um bom mapa, como vemos a seguir:

  1. A aplicação usa um banco de dados SQL Server ou outro de mercado?
    • Qual é a plataforma?
    • Quantas instâncias de bases de dados estão presentes?
    • Qual é o tamanho de cada instância?
    • Quantas stored procedures são usadas?
    • Qual é a expectativa de crescimento das bases?
    • Existe rotina de expurgo de dados?
    • Existe necessidade de manutenção de histórico de dados por um longo tempo?
    • Existe necessidade de transações distribuídas entre bases?
    • Outros clientes ou serviços consomem os dados de sua base?
  2. A aplicação usa mensageria via MSMQ ou outra de mercado?
  3. A aplicação usa FILE SYSTEM/NTFS como parte da solução?
  4. A aplicação usa REGISTRY como parte da solução?
  5. A aplicação usa mecanismos de segurança, como certificados, criptografia, tokens, etc. como parte da solução?
  6. A aplicação tem exigências quanto ao tempo de resposta de rede?
  7. A aplicação tem restrições quanto ao SLA (Service Level Agreement) definido junto aos seus usuários?
  8. A aplicação usa autenticação baseada em Active Directory (AD) ou ADFS?
  9. A aplicação usa Windows Workflow Foundation (WF) ou outro mecanismo de workflow de mercado?
  10. A aplicação usa barramento de serviços para pub/sub de Web Services?
  11. A aplicação usa uma abordagem STATELESS (sem estado) ou STATEFULL (com controle de estado)?
  12. A aplicação usa protocolos de comunicação além do HTTP, como TCP, UDP, SOAP, REST, etc.?
  13. A aplicação usa objetos ou componentes COM/COM+?
  14. A aplicação usa um processo de instalação via XCOPY?
  15. A aplicação usa variáveis de ambiente?
  16. A aplicação usa componentes registrados no Global Assembly Cache (GAC)?
  17. A aplicação usa ASP.NET Session State?
  18. A aplicação usa App.Config ou Web.Config como base de configuração?
  19. A aplicação usa Custom Domain Name previamente definido?
  20. A aplicação usa CLR Stored Procedures ou CLR User-Defined Types (UDTs)?
  21. A aplicação usa Service Broker no SQL Server?
  22. A aplicação usa componentes ou recursos não-gerenciados (não .NET)?
  23. A aplicação usa Ruby ou Ruby on Rails?
  24. A aplicação usa Java ou Java Beans?
  25. A aplicação usa soluções de e-mail de forma integrada?
  26. A aplicação deve estar registrada em barramentas de serviços locais (on-premise)?
  27. A aplicação deve ser consumida por clientes móveis, como Windows Phone 7, etc.?
  28. A aplicação usa recursos de geo-localização, mapas, GPS, etc.?
  29. A aplicação usa recursos de mídia diversos, como AUDIO, VIDEO, IMAGENS, etc.?
  30. A aplicação usa intenso processamento para cálculos em paralelo, simulações, etc.?
  31. Qual é o número de transações estimado por hora em sua aplicação?
  32. Qual é o número de consultas de dados (em GB) estimados por hora em sua aplicação?
  33. Qual é o número de uploads de dados (em GB) estimados por hora em sua aplicação?
  34. Qual é o tamanho da base de dados inicial (em GB) necessária para sua aplicação entrar em produção?
  35. Qual é o orçamento mensal previsto com manutenção da infraestrutura para sua aplicação?

Várias perguntas, certo? Algumas são fáceis de se responder, outras nem tanto.

O objetivo final desse estudo é a construção de uma tabela geral para nosso projeto para o Windows Azure.

Veja o exemplo abaixo, com estimativas para cada tipo de aplicação do grupo Business Productivity (use como referência em seus projetos):

image

Na tabela acima, vemos as colunas:

  • Número de instâncias de máquinas virtuais no Azure, estimadas para o projeto inicial;
  • Carga média de entrada de dados, em GB por hora;
  • Carga média de saída de dados, em GB por hora;
  • Armazenamento inicial em GB no Azure Storage (para dados não estruturados, como blobs, tabels, queues);
  • Armazenamento inicial em GB no SQL Azure (para dados relacionais);

Com essas definições, é possível fazer uma estimativa macro sobre a dimensão do projeto, assim como custo aproximado na plataforma Windows Azure.

Sobre custos unitários na plataforma Azure, veja o link a seguir:

Windows Azure Platform Consumption
Ref.: https://www.microsoft.com/windowsazure/offers/popup/popup.aspx?lang=en&locale=en-us&offer=MS-AZR-0003P

Sem uma ideia de dimensão de nossa solução, é muito difícil avaliar a viabilidade do projeto na nuvem. Por isso, conhecer a fundo as necessidades de sua aplicação é muito importante.

Para informações completas sobre os custos na plataforma Windows Azure, confira o link:

Ref.: https://www.microsoft.com/windowsazure/offers/ 

Espero que ajude!

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

Waldemir.

Comments

  • Last updated on