[Cloud Journey] - Tamanhos e Quantidades de Máquinas Virtuais

Olá PessoALL,

Como falei em um post anterior, Estou trabalhando em uma migração de um sistema legado (e por legado digo feito há +/- 20 anos) para o azure. Tem sido um desafio principalmente porque quase ninguem no time atual conhece o sistema como um todo, então em cada análise acabamos por descobrir algo novo.

Hoje quero compartilhar com vocês um pouco sobre a experiência de trabalhar com os diversos tipos de máquinas virtuais que existem no Azure.
Devo confessar que minha área de expertise são os App Services e tem sido um desafio interessante aplicar os mesmos conhecimentos de PaaS em uma plataforma IaaS.

Mas, como diria um mentor que tive, first things first:

Por quê voce está usando Máquinas Virtuais?

Como mencionei antes, o sistema foi desenvolvido há +/- 20 anos atrás e usa MUITOS alguns recursos nativos de windows, principalmente registro de componentes COM.
Como o registro de componentes não é suportado no App Services precisamos rodar essa aplicação em especifico usando VM Scale Set.

Um pequeno adendo aqui, se voce tem interesse em aprender mais sobre scale sets e/ou migração de aplicações legadas para nuvem deixa um comentário ou me manda uma mensagem.

Tipos de máquinas virtuais disponiveis

Quando estamos migrando uma aplicação para nuvem a primeira coisa que falamos e normalmente se espera é redução de custos, e com essa mentalidade eu comecei a criar meu scale set.

Comecei criando as máquinas usando as intâncias BS. Segundo o site oficial:

As VMs da Série B oferecem uma solução econômica e de baixo custo para cargas de trabalho que normalmente não usam bastante CPU, mas ocasionalmente precisam de intermitência para manipular cargas de trabalho mais altas. 

Depois de tudo configurado, o que voces acham que aconteceu? Sim, a performance da aplicação estava bem ruim. (sim preciso confessar, eu achei mesmo que ia ter uma performance bacana).

Eis um outro aprendizado: Na hora da migração não pense somente na economia de custos, mas tente balancear economia com as necessidades da sua aplicação.

Antes de falar sobre qual familia estou usando, quero falar de outro ponto:

Quantidade de máquinas

Em aplicações novas geralmente usamos mais servidores de menor configuração para podermos atender a maior quantidade de requests possiveis, mas falando de legado precisamos levar alguns pontos em consideração:

• Diferente do asp.net e outras plataformas, o asp clássico só consegue armazenar dados de sessão na memória do servidor (voce pode usar um servidor dedicado ou banco de dados, mas isso exige uma implementação customizada e estamos evitando ao máximo mexer no código)

Isso me fez perceber que para esse cenário eu preciso de menos máquinas, mas com bastante memória e processamento:

• Todos os dados de sessão ficam na memória do servidor.
• Eu não posso usar load-balancer com uma distribuição equalitária, pois uma vez que um usuário inicia a sessão em um servidor, todas as requisições dele precisam ir para esse mesmo servidor.

Por fim, minha recomendação para aplicações legadas são a familia atual DsV3:

As instâncias D2-64 v3 são a última geração de instâncias para uso geral com a tecnologia Hyper-Threading. As instâncias D2-64 v3 se baseiam no processador Intel XEON® E5-2673 v4 (Broadwell) de 2,3 GHz e podem atingir 3,5 GHz com a Tecnologia Intel Turbo Boost 2.0. As instâncias D2-64 v3 oferecem a combinação de CPU, memória e disco local para a maioria das cargas de trabalho de produção.

Após alguns testes estamos usando 3 máquinas D4 v3. Em testes de comparação com a infra atual a aplicação esta com os tempos de carregamento bem parecidos, temos uma pequena diferença devido a latência com o banco que será a última peça a ser migrada.

Por enquanto é só, na próxima semana falarei um pouco mais sobre os scale sets do ponto de vista de desenvolvimento e DevOps.